Microsoft Entra ID is the identity and authorization control plane you already use for Microsoft Graph and tenant resources, so it is a natural place to anchor enterprise agent identities and access reviews. For permissioned agents, the important part is not just authenticating to Entra ID, but forcing every high-impact Entra and Graph action to pass a policy-as-code gate and produce auditable proof.
Claw EA runs OpenClaw as the baseline agent runtime and adds a permissioned execution layer using WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols), CST = scoped token (issued by clawscope), gateway receipts (from clawproxy), and proof bundles. Entra ID can be connected via official API with enterprise buildout controls, but it is not presented here as a native connector.
Step-by-step runbook
-
Define the agent’s Entra identity model first: workload identity (app registration or managed identity) or agent identity if you are adopting Microsoft Entra Agent ID (Preview). Write down the exact Microsoft Graph permissions and whether they are delegated or application permissions.
Keep the first iteration read-only where possible, since Graph write scopes are where agent mistakes turn into tenant-wide impact.
-
Create a WPC that enumerates allowed Graph operations at the level your auditors will recognize: tenant, resource types, and approved permission scopes. Make the WPC explicit about which actions are “write/admin” and require an approval gate before execution.
Because WPCs are signed and hash-addressed, you can pin a specific policy version to a run and later prove which rules were in force.
-
Issue a CST for the job with a scope hash that matches the WPC, and optionally pin the policy hash in the CST. Treat the CST as the single bearer capability that binds the job to its policy, rather than relying on prompt instructions like “do not change users.”
This is where permissioned execution differs from prompt-only: the runtime can refuse calls that do not match the policy, even if the model is coerced.
-
Route model calls through clawproxy so you get gateway receipts for every model call used during the run. This matters for Entra tasks because a significant part of the security story is reconstructing why an agent attempted a sensitive Graph action, not just that it did.
If you use OpenRouter via fal, keep it behind clawproxy so receipts stay consistent across providers.
-
Implement the Entra and Graph interaction via official API as an enterprise buildout tool for OpenClaw. Enforce “write and admin actions require WPC approval gates, CST, and explicit least-privilege auth scopes” as a hard rule in the tool boundary.
Do not let the model dynamically request broader Graph permissions mid-run without a new WPC and a new CST.
-
Enable Conditional Access and, where applicable, Privileged Identity Management (PIM) workflows for the identities the agent uses. Use Conditional Access to constrain when and how the agent identity can obtain tokens, but do not rely on Conditional Access alone to express “what the agent is allowed to do” inside Graph.
Think of Conditional Access as access context control, and WPC as action control.
-
At the end of each run, package evidence into a proof bundle that includes gateway receipts plus run metadata (policy hash, scope hash, job binding). Store the artifact as a Trust Pulse for audit and later replay checks.
This gives your security team an object they can review without needing to trust the agent’s self-reported logs.
Threat model
Entra ID and Microsoft Graph are high-leverage surfaces: a single over-scoped token can modify users, roles, app consents, Conditional Access, or group memberships. The failure modes below assume the agent runtime is capable, but potentially confused, tricked, or operating with a malicious skill/plugin.
| Threat | What happens | Control |
|---|---|---|
| Over-scoped Microsoft Graph permissions | An agent with application permissions like broad directory write can change users, groups, or app consents beyond the intended ticket. The incident looks like legitimate API traffic, because it is. | Require least-privilege auth scopes and force write/admin actions behind a WPC approval gate with a job-scoped CST. If the WPC does not authorize the action, the tool must refuse even if the prompt asks. |
| Prompt injection triggers admin-like actions | A message or document causes the model to “helpfully” add an exception in Conditional Access, grant consent, or create a new credential. Prompt-only safeguards can be bypassed by phrasing. | Permissioned execution: WPC expresses the allowed operations and a CST pins that policy. OpenClaw tool policy and sandboxing reduce local blast radius, but Entra actions still require policy gates. |
| Malicious plugin or misconfigured tool endpoint | A plugin exfiltrates tokens, requests new permissions, or calls Graph endpoints that are not part of the intended workflow. Misconfiguration can also point the tool at the wrong tenant or environment. | Use OpenClaw’s tool allow/deny model and sandboxing to constrain execution, then bind the job to a CST scope hash and a WPC policy hash. Keep Graph scopes fixed and reviewed, and separate prod vs non-prod identities. |
| Replay of prior approvals or runs | A previously approved action is replayed in a new context, or a token is reused to repeat sensitive operations. This is common when agents run on schedules or in shared runtimes. | Use marketplace anti-replay binding (job-scoped CST binding) so the authorization is tied to a specific job. Store a proof bundle and verify that the receipts and bindings match the intended run. |
| Hard-to-audit “why did it do that?” | After an incident, you have Graph audit logs but cannot reconstruct which model outputs led to which calls. Without evidence at the model boundary, you are left with partial timelines. | Route model traffic through clawproxy to emit gateway receipts for model calls. Package receipts into a proof bundle so auditors can correlate “model said X” with “tool attempted Y” under a specific WPC and CST. |
Policy-as-code example
This example shows the shape of a WPC for an Entra automation job. It separates read operations from write/admin operations, and it pins the run to a specific policy hash via CST so the agent cannot “talk its way” into broader permissions.
{
"wpc_version": "v1",
"policy_name": "entra-helpdesk-agent-prod",
"tenant": "contoso.onmicrosoft.com",
"tools": {
"microsoft_graph_via_official_api": {
"allowed_permissions": [
"User.Read.All",
"Group.Read.All"
],
"write_admin_requires_approval": true,
"allowed_write_operations": [
{ "op": "user.resetPassword", "constraints": { "ticket_required": true } },
{ "op": "group.addMember", "constraints": { "group_allowlist": ["Helpdesk-Scoped-Groups"] } }
]
}
},
"cst_requirements": {
"scope_hash_required": true,
"policy_hash_pinning": "optional"
},
"receipts": {
"require_gateway_receipts": true,
"bundle_on_completion": true
}
}
In practice, the “microsoft_graph_via_official_api” tool is an enterprise buildout that refuses calls outside the contract. If the model tries to add a new permission scope or call a different operation, it fails closed and the run records that refusal.
What proof do you get?
For model activity, clawproxy emits gateway receipts for model calls. These receipts are the external, verifiable record of what the model was asked and what it returned at the boundary where actions are decided.
For the overall job, Claw EA produces a proof bundle that packages gateway receipts with run metadata such as the WPC policy hash, the CST scope hash, and the job binding used for anti-replay. You can store and review the resulting artifact as a Trust Pulse, which is designed for audit viewing and later verification workflows.
Rollback posture
Rollback is about returning the tenant to a safe state quickly and proving which controls were active. You should prepare rollback actions that work even if the agent runtime is paused, compromised, or simply unavailable.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop new sensitive actions | Revoke or expire the CST for the job, and require a new CST issuance for any further execution. This cuts off the permissioned execution path without changing tenant configuration. | CST issuance and revocation records, plus the last proof bundle showing the job binding that was active. |
| Freeze policy at a known-good version | Pin the WPC policy hash for subsequent jobs and refuse runs that do not match that hash. This prevents silent policy drift during incident response. | WPC hash reference in the job metadata and proof bundle, showing which policy contract governed each run. |
| Contain identity blast radius | Disable the Entra identity or remove admin consents for high-risk Microsoft Graph permissions, then re-issue least-privilege credentials. Use PIM and Conditional Access adjustments as needed, but treat them as tenant-side containment. | Tenant audit logs from Entra plus the agent-side proof bundle that shows what the model attempted and when. |
| Contain runtime blast radius | Tighten OpenClaw tool policy (deny the Graph tool or restrict profiles) and ensure sandboxing is enabled for the agent sessions that can execute tools. This reduces the chance of lateral movement from an Entra task into local file or shell actions. | OpenClaw configuration review and security audit output, plus proof bundles from runs after the change. |
FAQ
Is this a native Entra ID connector in Claw EA?
No. Entra ID can be connected via official API with enterprise buildout controls, and you should assume an integration project that implements the tool boundary and policy enforcement you need.
Why is prompt-only control not enough for Entra and Microsoft Graph?
Because prompts are not enforcement. A model can be tricked or can misunderstand, and Graph will still accept the request if the token is over-scoped.
Permissioned execution uses WPC rules and CST bindings so the tool refuses disallowed actions even if the model requests them.
How does Conditional Access fit with WPC and CST?
Conditional Access is strong for constraining authentication context, such as where tokens can be acquired and under what conditions. WPC and CST control the action surface inside the agent runtime, so “what can be done” is enforced at execution time.
Can you support Microsoft Entra Agent ID concepts?
Yes, with care. Microsoft Entra Agent ID is described by Microsoft as Preview, so you should plan for change and treat it as an identity model option during enterprise buildout via official API.
What do auditors actually review after a run?
They review the WPC that governed the job, the CST scope hash and any policy hash pinning, and the proof bundle containing gateway receipts for model calls. This combination is designed to answer “who ran what, under which policy, with what model inputs and outputs at the boundary.”