Claw EA provides enterprise tools for running permissioned agents where execution is controlled by policy-as-code, not by prompts. OpenClaw is the baseline agent runtime, and Claw Bureau primitives add machine-verifiable authorization and audit artifacts around model calls and tool execution.
Prompt-only controls fail because the model can be coerced into taking actions you did not intend, especially when tool access is broad. A permissioned execution layer ties actions to a signed Work Policy Contract (WPC), a CST (scoped token), and gateway receipts, so you can prove what was allowed and what actually happened.
Tools taxonomy (what this hub covers):
- Work Policy Contracts (WPC): define the allowed tools, constraints, and identity bindings as a signed, hash-addressed artifact served by clawcontrols.
- CST (scoped token): issue job-scoped, least-privilege tokens from clawscope and pin them to a WPC hash when you need strict policy binding.
- Model gatewaying: route model calls through clawproxy to get gateway receipts and a consistent enforcement point for what the agent can request.
- Proof bundles: produce a proof bundle that packages receipts and metadata for verification and audit.
- Microsoft Graph: call Microsoft Graph via official API with explicit Microsoft Graph permissions/scopes, mapped to tool-level policies in your WPC.
- Outlook / mail actions: constrain mailbox operations (read, draft, send, delete) via Graph scopes and per-job CST, with receipts for model decisions leading to the action.
- Files and data access: restrict filesystem and workspace access using OpenClaw sandboxing and tool policy, then align remote calls to the WPC.
- Browser automation: keep browser control scoped, and prefer sandboxed browsers where possible; treat remote browser control as a high-risk tool.
- Approvals and change control: can be implemented as an enterprise buildout so high-impact actions require an external approval step, before a CST is issued for that step.
Step-by-step runbook
-
Start with an OpenClaw tool inventory. List every tool the agent can call (shell, browser, HTTP, Graph client, ticketing client) and decide which ones must be disabled by default. Use OpenClaw tool policy and sandbox settings to set a small baseline blast radius before you add any enterprise permissions.
-
Author a WPC for the job class. Put concrete constraints in the WPC: allowed tools, allowed model routing, and external APIs that are permitted (for example “Graph mail read” but not “send”). Store the WPC in the WPC registry so it can be fetched and verified consistently.
-
Issue a CST for a single job. Use clawscope to mint a CST with the minimum scope set for the run, and include a scope hash that corresponds to the allowed tool and API set. If you need strict change control, enable optional policy hash pinning so the CST is only valid with the intended WPC hash.
-
Route model calls through clawproxy. Configure the agent’s model provider path to go through clawproxy so each model call emits gateway receipts. If you use OpenRouter via fal, route that traffic through clawproxy as well so receipts are still produced.
-
Integrate enterprise actions via official APIs. For Microsoft 365 actions, call Microsoft Graph via official API and keep Graph permissions/scopes explicit, reviewed, and minimal. Use Entra ID controls like Conditional Access and PIM for the human operators and service principals that can issue or approve agent credentials.
-
Run, then verify the output artifacts. After the job completes, collect the proof bundle and verify it in your audit pipeline. Store the resulting artifact in Trust Pulse for later inspection and for incident response timelines.
Getting started checklist: pick one narrow workflow, write one WPC, issue one CST per job, force model traffic through clawproxy, and reject runs that do not produce a proof bundle. Add additional tools only after you can explain and test the failure modes for that tool.
Threat model
Enterprise agents fail in predictable ways: an attacker influences the prompt, the agent gains broader privileges than intended, or you cannot reconstruct who allowed what after an incident. The controls below are designed to make failures bounded and auditable, even when the model output is unreliable.
| Threat | What happens | Control (permissioned execution) |
|---|---|---|
| Prompt injection causes tool misuse | The model is tricked into calling a high-impact tool (send email, delete files, exfiltrate data). | WPC restricts which tools and actions exist; OpenClaw tool policy and sandboxing reduce local blast radius; CST enforces least privilege for remote calls. |
| Over-scoped credentials | A token or app registration grants broad Microsoft Graph permissions, so one compromise impacts many mailboxes. | CST is job-scoped and can be pinned to a WPC hash; keep Graph permissions/scopes minimal and separate read from send; use Entra ID governance (Conditional Access, PIM) around who can provision credentials. |
| Replay of a prior authorization | An old token or request is replayed to repeat an action after the job is over. | Marketplace anti-replay binding ties authorization to a specific job-scoped CST binding, reducing re-use outside the intended run window. |
| Disputed “who did what” after an incident | You have logs, but they are incomplete or easy to forge, so audit and forensics stall. | Gateway receipts from clawproxy capture model call metadata; proof bundles package receipts plus related metadata for verification and audit; Trust Pulse stores the artifact for later review. |
| Sandbox escape or host-impact tool usage | A tool runs on the host or mounts sensitive paths, turning a bad decision into host compromise. | Use OpenClaw sandboxing modes and keep “elevated” execution tightly gated; treat bind mounts and host browser control as explicit exceptions that must be justified in policy. |
Policy-as-code example
This example shows the kind of concrete, reviewable constraints you want in a WPC. The point is not the syntax, but that policy is a signed artifact with a stable hash, not a paragraph in a prompt.
{
"wpc_version": "v1",
"policy_name": "mail-triage-outlook-readonly",
"allowed_models": [
{ "provider": "openrouter_via_fal", "route": "through_clawproxy" }
],
"tools": {
"openclaw": {
"sandbox_mode": "all",
"tool_allowlist": ["http", "graph_mail_read", "graph_calendar_read", "summarize"]
},
"deny": ["shell", "filesystem_write", "graph_mail_send", "graph_mail_delete"]
},
"external_access": {
"microsoft_graph": {
"via": "official_api",
"permissions_scopes": [
"Mail.Read",
"Calendars.Read"
],
"tenant_boundary": "single-tenant"
}
},
"token_requirements": {
"require_cst": true,
"cst_scope_hash": "sha256:...expected...",
"optional_policy_hash_pinning": true
},
"audit": {
"require_gateway_receipts": true,
"require_proof_bundle": true,
"store_to_trust_pulse": true
}
}
If you need approvals for “send mail” or “create user,” that is typically done as an enterprise buildout where the approval system issues a new CST for the approved step. Keep the WPC split into stages so a read-only agent cannot silently transition into a write-capable agent.
What proof do you get?
For each model call routed through clawproxy, you get gateway receipts that can be checked later to confirm the call happened under the expected controls. Those receipts become part of a proof bundle, which is the unit you hand to audit and incident response when you need to reconstruct decisions and authorization.
Operationally, the proof bundle ties together the WPC hash (what was allowed), the CST scope hash (what was authorized for this job), and the gateway receipts (what the model calls looked like at the gateway). When you store the artifact in Trust Pulse, you have a consistent place to review runs without depending on ad hoc log retention.
Rollback posture
Rollback for agents should be a planned playbook, not a debate during an incident. The goal is to quickly stop unsafe action, narrow permissions, and preserve evidence without destroying the audit trail.
| Action | Safe rollback | Evidence to check |
|---|---|---|
| Suspected token compromise | Revoke the CST and re-issue a new CST with a narrower scope hash; shorten TTL for the job class. | Proof bundle for the last known-good run; confirm CST scope hash and job binding match expectations. |
| Tool is being abused (ex: mail send) | Update the WPC to remove the tool or switch to read-only stage; require a new WPC hash for any further runs. | Gateway receipts showing tool-triggering prompts and model outputs leading to the action. |
| Model routing drift or provider confusion | Force model traffic through clawproxy only and reject runs without receipts; pin to approved routes (for example OpenRouter via fal through clawproxy). | Receipts indicating the routed provider path and the presence of required receipt fields. |
| Local execution risk increases | Switch OpenClaw sandboxing to a stricter mode and reduce workspace access; remove elevated execution paths. | OpenClaw security audit output plus proof bundles from runs before and after the change. |
Egress allowlists enforced outside clawproxy and automatic cost budget enforcement are often requested as additional guardrails. Those are optional or planned items and should be treated as separate implementation workstreams.
FAQ
Why is prompt-only “do not send email” not sufficient?
Because the model does not enforce anything, it only generates text and tool calls. Permissioned execution enforces the boundary in code, using a WPC and a CST, so the action is rejected even if the model tries.
How do WPC and CST work together in practice?
The WPC defines the allowed surface area as a signed artifact with a stable hash. The CST is issued per job with a scope hash and can optionally be pinned to the WPC hash, so policy changes do not silently apply to a running job.
What do gateway receipts cover?
Gateway receipts are signed receipts emitted by clawproxy for model calls. They help you verify that model traffic went through the expected gateway and can be packaged into a proof bundle for audit.
Can Claw EA enforce Microsoft Graph scopes automatically?
Claw EA can constrain what the agent is allowed to attempt by policy and by only issuing CST for approved Graph actions. Actual Graph authorization is still governed by Entra ID and the app’s configured Microsoft Graph permissions/scopes, which you should manage with standard enterprise controls like Conditional Access and PIM.
What is the minimum setup to be meaningfully safer?
Run OpenClaw with sandboxing enabled for tool execution, put a WPC in place for one workflow, and require a per-job CST. Route model calls through clawproxy so every run yields gateway receipts and a proof bundle.