Microsoft Graph lets an agent read and write across Microsoft 365 and Entra ID, which makes it powerful and risky. For enterprise agents, prompt-only guardrails are not enough because a single mis-scoped OAuth grant can turn a bad prompt into real mailbox, file, or directory changes.
Claw EA runs OpenClaw as the baseline agent runtime and uses permissioned execution: a WPC (Work Policy Contract) to define what Graph actions are allowed, CST (scoped token) to bind a job to that policy, and gateway receipts plus proof bundles to audit model-assisted decisions. Microsoft Graph connectivity is implementable via official API with enterprise buildout controls, not a native connector.
Step-by-step runbook
1) Pick an agent identity strategy in Entra ID. Decide whether the agent uses delegated permissions (acts as a signed-in user) or application permissions (no user). For most unattended agents, application permissions are operationally simpler but raise the blast radius, so start with the minimum application scopes.
2) Define least-privilege Graph permissions and admin consent boundaries. Create an app registration and request only the Graph permissions you can justify, avoiding broad scopes like full mailbox or full site control unless there is a gated workflow. Use PIM for the humans who can grant admin consent, and treat consent as a change-controlled event.
3) Write a WPC that encodes what the agent is allowed to do. The WPC should constrain Graph endpoints, allowed verbs, target tenants, and any high-risk write operations that require a human approval gate. Store the signed, hash-addressed WPC in the WPC registry served by clawcontrols.
4) Bind execution to the WPC with CST. Issue a CST (scoped token) from clawscope for the specific job, with optional policy hash pinning to the WPC hash. Use the marketplace anti-replay binding so the CST is job-scoped and cannot be replayed across runs.
5) Run the agent in OpenClaw with tool policy and sandboxing enabled. Use OpenClaw tool allowlists to ensure the agent can only invoke the Graph tool surface you intend, and prefer sandboxed tool execution to reduce local filesystem and process exposure. Run OpenClaw’s security audit as part of deployment checks when configs change.
6) Route model calls through clawproxy and keep the Graph side auditable. Model calls can be routed through clawproxy to produce gateway receipts, and the run can emit a proof bundle that ties together job identifiers, WPC hash, CST scope hash, and the model call receipts. For Graph API calls (via official API), log request metadata and correlate it to the job id for post-incident reconstruction.
Threat model
Microsoft Graph is a protected API gateway into Microsoft 365 and Entra ID. The failure mode for agents is usually not “Graph was hacked”, it is “the agent got permissions and exercised them after prompt injection, plugin abuse, or misconfiguration”.
| Threat | What happens | Control |
|---|---|---|
| Over-scoped Graph permissions | An agent intended to read calendar events can also read mail, enumerate users, or access SharePoint content, depending on granted scopes. | Least-privilege Graph permissions, documented consent process, and a WPC that denies out-of-scope endpoints even if OAuth scopes allow them. |
| Prompt injection causes unauthorized writes | The model is tricked into sending emails, creating inbox rules, modifying Teams messages, or changing calendar entries in ways that look legitimate. | WPC approval gates for write and admin actions, plus OpenClaw tool allowlists so “write” tools are not available during read-only tasks. |
| Credential replay or token leakage | A leaked token is replayed later to call Graph outside of the intended job window, possibly from a different environment. | Issue CST per job with anti-replay binding, keep Entra secrets out of prompts, and design for short-lived tokens where feasible. |
| Malicious or compromised plugin/tool wrapper | A tool wrapper silently expands queries, calls extra endpoints, or exfiltrates response bodies to other destinations. | Permissioned execution with WPC constraints on allowed endpoints and verbs, plus OpenClaw sandboxing to reduce local exfil paths. |
| “Human admin” escalation path | An operator grants broad consent during an incident and forgets to roll it back, leaving durable power behind. | Use PIM for admin roles and enforce an explicit rollback checklist, with the WPC updated to block high-risk operations until reviewed. |
Policy-as-code example
This example shows the idea: a WPC expresses what Graph calls are permitted for a specific job class, and the run is bound to that exact policy hash. The goal is to make “what the agent can do” machine-checkable, not dependent on prompt text.
{
"wpc_version": "1",
"policy_name": "m365-calendar-read-and-draft-email",
"allow": [
{ "service": "microsoft_graph", "method": "GET", "path": "/v1.0/me/events" },
{ "service": "microsoft_graph", "method": "GET", "path": "/v1.0/users/{userId}/calendar/events" },
{ "service": "microsoft_graph", "method": "POST", "path": "/v1.0/me/messages", "constraints": { "send": false } }
],
"deny": [
{ "service": "microsoft_graph", "method": "POST", "path": "/v1.0/me/sendMail" },
{ "service": "microsoft_graph", "method": "POST", "path": "/v1.0/users" },
{ "service": "microsoft_graph", "method": "PATCH", "path": "/v1.0/users/{userId}" }
],
"approvals": [
{ "match": { "service": "microsoft_graph", "method": "POST", "path": "/v1.0/me/sendMail" }, "required": true }
],
"token_binding": {
"cst_policy_hash_pinning": true
}
}
If the model tries to “just send the email”, prompt-only rules can fail quietly. With a WPC, the execution layer can fail closed because the tool call is not permitted under the signed policy.
What proof do you get?
For model activity, clawproxy emits gateway receipts for model calls. Those receipts can be bundled into a proof bundle that includes job identifiers, CST scope hash, and the WPC policy hash used for the run.
For Microsoft Graph activity (via official API in an enterprise buildout), you typically preserve request metadata and correlate it to the job id included in the run context. The proof bundle can carry those correlations alongside the gateway receipts so an auditor can verify what the model was asked, what it answered, and what the job attempted to do next.
When you want a stable place to view audit artifacts, you can store the resulting proof bundle as a Trust Pulse artifact for later review. This is useful when an incident review needs a single, shareable record tied to a specific job run.
Rollback posture
Rollback is where permissioned execution matters most: you need fast, concrete levers that do not depend on the model cooperating. Design rollback across three layers: Entra ID, the agent runtime (OpenClaw), and Claw Bureau policy and tokens.
| Action | Safe rollback | Evidence |
|---|---|---|
| OAuth permissions were too broad | Remove the unnecessary Microsoft Graph permissions, revoke admin consent as needed, and re-issue the app credentials. | Entra ID audit events plus the WPC version that justified the final scope set. |
| Agent is behaving unexpectedly mid-run | Stop the job, revoke the CST in clawscope, and re-run under a tighter WPC that removes write paths. | CST issuance and revocation records, plus the proof bundle for the run that triggered rollback. |
| Prompt injection caused risky tool attempts | Change the WPC to require approvals for the targeted operations and deny the specific endpoint paths until reviewed. | WPC hash history and proof bundle correlations showing attempted tool intent versus permitted execution. |
| Local host exposure concerns | Move tool execution into OpenClaw sandbox mode and remove any elevated host escape hatches not strictly required. | OpenClaw configuration diffs and security audit outputs for the environment. |
FAQ
Is this a native Claw EA connector to Microsoft Graph?
No. Microsoft Graph can be connected via official API with enterprise buildout controls, and the connection should be treated as an integration project with explicit permission scoping and audit requirements.
Why is prompt-only control not sufficient for Graph?
Because Microsoft Graph permissions and admin consent determine what is possible, regardless of what the prompt says. Policy-as-code (WPC) lets the execution layer block disallowed operations even when the model produces a plausible but unsafe instruction.
Should agents use delegated or application permissions?
Delegated permissions can reduce blast radius but require a signed-in user context and careful session handling. Application permissions support unattended automation but must be tightly scoped, with explicit gates for write and admin actions.
How do Conditional Access and PIM fit?
Use PIM to control who can grant consent and manage high-privilege Entra roles. Conditional Access can be applied to agent access patterns; Conditional Access for Agent ID is documented by Microsoft as a preview capability, so validate your tenant behavior before relying on it for enforcement.
What do gateway receipts prove in this setup?
Gateway receipts prove what model calls were made when routed through clawproxy and let you verify that the recorded outputs match what was returned. They do not automatically prove Graph API side effects, so you should log Graph request metadata and attach it to the same job context in the proof bundle.