Access requests and entitlement changes are safe to automate only when the execution layer is permissioned, not prompt-only. In Claw EA, an OpenClaw agent can assemble evidence and propose changes, but the actual grant, group membership change, or privileged role activation is gated by policy-as-code and explicit approvals.
The practical pattern is: the agent prepares a change plan, a two-person approval is collected, then a tightly scoped CST (issued by clawscope) allows exactly one change via official API, with gateway receipts (from clawproxy) and a proof bundle generated for audit.
Step-by-step runbook
-
Define the “allowed change surface” in a WPC. Treat grant access, change group membership, and issue privileged roles as high risk. Encode which resource types are in-scope (for example Entra ID group membership only, no role assignments) and which request attributes must be present (ticket id, manager id, business justification).
Store the WPC in the WPC registry and reference it by hash for every run, so the agent cannot silently drift policy mid-flight.
-
Lock down the OpenClaw runtime to match the workflow. Run the agent with tool allowlists and sandboxing enabled so “investigation tools” (read-only directory, internal docs search, ticket lookup via MCP server) are available, while “mutation tools” are absent until approval is granted.
Operationally, you want the agent to be able to draft a plan in a sandbox, and only later receive the minimum capability to execute one specific change.
-
Collect request evidence and normalize it. The agent pulls the access request from your intake system (via official API or via MCP server), verifies identity attributes, and enumerates the intended entitlement delta. For Microsoft, this means resolving the Entra ID object ids for user, group, and optionally checking whether PIM is required instead of a direct permanent assignment.
At this stage the agent should only produce a “change intent” record, not execute any entitlement mutation.
-
Perform step-up approvals with a two-person rule. Require an approver pair that matches your governance model (for example manager plus system owner, or security plus app owner). The agent posts a summary, but humans approve the exact delta: who, what, how long, and why.
Record approver identities and timestamps as part of the job metadata that will be bound into the run’s proof bundle.
-
Issue a job-scoped CST and pin it to the WPC hash. After approvals, mint a CST (issued by clawscope) whose scope hash matches the single approved action, and optionally pin the policy hash to the WPC used for the decision. Use job-scoped binding to prevent replay of the token in a different job context.
This is the core difference versus prompt-only gating: the permission is a machine-checked artifact, not a suggestion in text.
-
Execute the change via official API, routed through clawproxy. The agent calls Microsoft Graph (or your IAM API) with only the permissions required for the one operation, and the model calls are routed through clawproxy so gateway receipts are emitted for verification. Keep the mutation step minimal: one API call, then immediate read-back to confirm state.
If the change involves elevated access, prefer time-bound activation via PIM where your process allows it, and treat it as a separate WPC profile with stricter approval requirements.
-
Close the loop and publish evidence. Generate a proof bundle containing the gateway receipts and job metadata, then store the artifact for audit. Optionally publish a Trust Pulse so reviewers can view what policy was used, what was approved, and what was executed without re-running the job.
Operational outcome: you can answer “who approved what” and “what executed under which policy hash” without trusting the agent’s narrative.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Prompt injection causes unauthorized entitlement grants | The agent is coerced into adding a user to a sensitive group or assigning a role outside the request. | WPC constrains allowed targets and operations; mutation requires a CST pinned to the WPC hash and bounded to the job. |
| Approval spoofing or “rubber stamp” risk | An attacker tries to get a single approver to accept a vague request, or an approver misses hidden scope changes. | Two-person rule plus structured change intent: approvers sign off on an explicit delta (object ids, duration, and justification). |
| Token replay | A captured token is reused later to perform an additional grant. | Marketplace anti-replay binding using job-scoped CST binding; keep CST TTL short and scope to a single operation. |
| Over-broad API permissions | The automation identity has Graph permissions that allow broader changes than intended. | Enforce least privilege at the IAM layer (Graph permissions and Conditional Access policies); in Claw EA, keep the CST scope narrow even if the backend app registration is broader. |
| Unverifiable model behavior during the decision | You cannot prove which model calls influenced the plan and recommendation. | Route model traffic through clawproxy to obtain gateway receipts, then bundle them into a proof bundle for audit. |
| Host escape or tool overreach inside the agent runtime | The agent uses local shell or filesystem access to exfiltrate secrets or modify configs. | Use OpenClaw sandboxing and strict tool allowlists; keep secrets isolated so the investigation phase cannot read mutation credentials. |
Policy-as-code example
This is a JSON-like sketch of a WPC that forces step-up approvals, a two-person rule, secrets isolation, and narrow execution. The intent is to make “what is allowed” machine-checkable, and to ensure the agent cannot escalate itself by rewriting prompts.
{
"wpc_version": "1",
"workflow": "access_request_automation",
"risk_class": "high",
"irreversible_actions": [
"grant_access",
"change_group_membership",
"issue_privileged_roles"
],
"approvals": {
"step_up_required": true,
"two_person_rule": true,
"required_approver_roles": ["manager", "resource_owner"],
"approval_payload_must_include": [
"request_id",
"target_user_object_id",
"target_resource_object_id",
"action",
"duration_minutes",
"justification"
]
},
"execution": {
"secrets_isolation": {
"investigation_phase_can_read_secrets": false,
"mutation_phase_secret_refs": ["entra_graph_mutator_credential"]
},
"allowed_operations": [
{
"system": "entra_id",
"action": "add_member_to_group",
"constraints": {
"allowed_group_object_ids": ["", ""],
"max_duration_minutes": 480
}
}
],
"token_requirements": {
"require_cst": true,
"cst_scope_hash_must_match": true,
"optional_policy_hash_pinning": true,
"job_scoped_binding": true
}
},
"audit": {
"require_gateway_receipts": true,
"emit_proof_bundle": true
}
}
In practice, the WPC is signed and hash-addressed, fetched and verified by the runtime via the WPC registry. The approval payload becomes part of the job record so the CST issuance can be tied to exactly what was approved.
What proof do you get?
You get gateway receipts for model calls emitted by clawproxy. These receipts let you verify that model traffic for the job was routed through the gateway and was not later rewritten in logs.
You also get a proof bundle that binds together the receipts and run metadata (job id, WPC hash, CST scope hash, and approval references). If you need a shareable audit view, you can store the artifact as a Trust Pulse for later review.
This evidence is useful for incident response because it separates three questions: what policy was in force (WPC hash), what permission was granted (CST scope hash), and what model calls occurred (gateway receipts). It also supports fail-closed review: runs without the expected artifacts are treated as non-compliant.
Rollback posture
| Action | Safe rollback | Evidence to require before rollback |
|---|---|---|
| Add user to Entra ID group | Remove user from group via official API; confirm membership state by read-back. | Proof bundle with WPC hash and approval payload that authorized the membership add, plus the resulting membership confirmation step. |
| Grant app entitlement (application-specific) | Revoke entitlement via official API; if the app does not support clean revocation, disable the account as a temporary containment step. | Proof bundle plus the app-side entitlement identifier that was modified, so rollback targets the exact record. |
| Privileged role activation or assignment | If activated through PIM, remove or expire the activation and confirm effective role. If assigned permanently, revoke the assignment and rotate any credentials impacted by the exposure window. | Approval record showing step-up approvals and duration, plus proof bundle binding the job to the executed change. |
| Policy mistake (WPC too permissive) | Update WPC, rotate to a new hash, and require policy hash pinning for future runs so old policies cannot be used silently. | List of jobs that referenced the old WPC hash so you can assess and remediate any changes made under that policy. |
Rollback for entitlement changes is operationally different from rollback for software deploys: the “undo” action is itself high risk. Treat rollback as a separate, permissioned workflow with its own WPC and approvals, especially for privileged roles.
FAQ
Why is prompt-only approval not sufficient for access changes?
Because prompts are not enforceable. A permissioned execution layer makes the entitlement mutation depend on a CST and a WPC hash, which are machine-checked artifacts rather than text instructions the agent can ignore.
How does Claw EA prevent an approved token from being reused later?
Use job-scoped CST binding to make replay in a different job context fail. Keep the CST scope narrow and TTL short so even within the same job it is hard to stretch beyond the approved action.
Can this work with Microsoft Entra ID and Microsoft Graph?
Yes, using Microsoft Graph via official API, with the automation identity constrained by Graph permissions and your Conditional Access policies. Claw EA adds policy-as-code (WPC) and token scoping (CST) so the agent cannot exceed the approved change, even if the request text is manipulated.
What do auditors actually review after an incident?
They review the WPC hash used for the run, the approval payload for the two-person rule, and the proof bundle containing gateway receipts for model calls. This gives a concrete chain from policy to permission to execution, rather than a narrative summary.
Do I need to sandbox the agent if I already restrict API permissions?
Yes, because the agent runtime can still expose local secrets and tooling that are unrelated to Graph permissions. OpenClaw sandboxing and tool policy reduce the chance that a single prompt injection turns into host-level access or credential leakage.