Enterprise agent governance is permissioned execution: every tool call and every model call runs under a machine-enforced policy, with approvals and scope limits that cannot be bypassed by a clever prompt.
Claw EA uses OpenClaw as the baseline agent runtime, then adds Claw Bureau primitives so runs are tied to a WPC, authorized by a CST, and evidenced by gateway receipts and a proof bundle you can verify later.
Step-by-step runbook
-
Define the work boundary as policy, not instructions. Start by listing allowed tools, allowed model providers, maximum session TTL, and what must be redacted in logs.
Keep this in a WPC so the runtime can fetch and verify the signed policy artifact instead of trusting a prompt.
-
Publish the WPC and treat it like an immutable release. Your deployment process should reference the WPC hash, not “latest,” so you can prove which policy governed a run.
Claw EA expects WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols).
-
Issue a CST per job or per run, scoped to that WPC. Pin the policy hash in the CST when you want fail-closed behavior: the run cannot proceed if the policy changes.
CST = scoped token (issued by clawscope).
-
Route all model traffic through clawproxy. This ensures every model call emits gateway receipts and is enforceable against the WPC and CST scope.
If you use OpenRouter via fal, route it through clawproxy so receipts are produced for each model request.
-
Wire approvals to the execution boundary, not to chat. Approvals should gate the issuance of a CST (or the upgrade to a higher-privilege CST), because the token is what tools and providers actually honor.
If you need Microsoft-native approval workflows, integrate approval decisions via official API and map them to CST issuance rules.
-
Run OpenClaw with explicit tool policy and sandboxing aligned to the WPC. Use OpenClaw tool allow/deny profiles and Docker sandboxing so prompt injection cannot silently turn into host execution.
Run OpenClaw’s security audit regularly to catch common “footguns” like open inbound policies or risky logging settings.
-
Collect proof bundles per run and store the verification artifact. A proof bundle ties together gateway receipts, the policy hash, and job-scoped bindings so you can audit who authorized what and what actually happened.
Optionally store the resulting artifact as a Trust Pulse for later viewing and review.
Threat model
Prompt-only controls fail because they are advisory text inside the same channel the attacker can influence. Governance needs enforcement at the execution layer: tokens, policy fetch/verify, tool allowlists, and receipted model traffic.
The table below shows concrete failure modes and the controls you should put in place in Claw EA deployments.
| Threat | What happens | Control (operational) |
|---|---|---|
| Prompt injection causes unauthorized tool use | An agent is convinced to run a tool sequence that reads files, exfiltrates data, or modifies systems. | Enforce tool policy in OpenClaw and bind the run to a WPC; require a CST that scopes tool categories and denies elevation by default. |
| Policy drift between approval and execution | A run is approved under “Policy A,” but executes under a modified “Policy B” after a config change. | Pin the WPC hash in the CST; at runtime, fetch/verify the WPC and fail closed if hashes do not match. |
| Replay of a previously approved credential | A captured token is reused to start a new job with the same privileges. | Use marketplace anti-replay binding with job-scoped CST binding so a CST cannot be replayed across jobs. |
| Unverified model calls (shadow egress) | Some model calls bypass your proxy, so you cannot prove what was sent or received. | Route model traffic through clawproxy so gateway receipts are emitted for model calls; restrict provider configuration to the proxied path. |
| Sandbox escape via “elevated” execution | A sandboxed agent uses a host escape hatch, intentionally or by misconfiguration, and runs on the host. | In OpenClaw, treat “elevated” as a break-glass path; require a higher-privilege CST for any workflow that enables it and keep it off in default profiles. |
| Budget overruns from long-running sessions | Costs grow because sessions run longer than intended or loop on retries. | Enforce tight TTLs in CST and session constraints in your WPC. Automatic cost budget enforcement is planned; today, implement usage caps via your provider billing controls and internal run limits. |
Policy-as-code example
This example illustrates the difference between “instructions” and “enforcement.” The policy is a WPC that is verified at runtime, and the CST pins the policy hash so the agent cannot switch policies mid-run.
Use this as a template for what you want to be explicit about: allowed tools, sandbox requirements, model routing, and approval gates for privilege upgrades.
{
"wpc_version": "1",
"policy": {
"job_class": "enterprise_agent_run",
"tool_policy": {
"allow": ["read", "write", "http", "process"],
"deny": ["exec_host", "docker_socket", "filesystem_mount_rw_outside_workspace"],
"require_sandbox": true
},
"model_policy": {
"require_proxy": "clawproxy",
"allowed_routes": ["openrouter_via_fal"],
"receipt_required": true
},
"approvals": [
{ "action": "enable_elevated", "require": "human_approval" },
{ "action": "access_production_data", "require": "human_approval" }
],
"session_limits": {
"max_ttl_seconds": 3600
},
"audit": {
"emit_gateway_receipts": true,
"bundle_proof": true
}
},
"cst_requirements": {
"policy_hash_pinned": true,
"job_scoped_binding": true
}
}
What proof do you get?
Governance is only credible if you can verify what ran, under which policy, and what the model saw. Claw EA produces evidence at the execution boundary, not just application logs.
For model calls, clawproxy emits gateway receipts. These receipts are signed and can be bundled to prove that a given prompt and response pair flowed through the governed proxy path.
For each run, Claw EA can produce a proof bundle. A proof bundle is a harness artifact bundling receipts and related metadata for audit/verification, including the WPC reference and the CST scope hash so you can connect “approved scope” to “observed behavior.”
For anti-replay, Claw EA supports marketplace anti-replay binding via job-scoped CST binding. In practice, this means a CST intended for one job cannot be reused to start another job with the same authority.
For storage and review workflows, you can store a Trust Pulse. Trust Pulse is a marketplace-stored artifact for audit/viewing, useful when you need to share a run record with security, compliance, or an external auditor without granting them access to the runtime.
Rollback posture
Rollback is part of governance because agents change behavior as tools, models, and policies change. Your goal is to revert privilege and stop execution quickly, then preserve evidence for review.
The table below summarizes safe rollback actions and the evidence you should expect to retain.
| Action | Safe rollback | Evidence |
|---|---|---|
| Revoke the active CST | Fail closed for new calls that require authorization; the agent cannot continue privileged actions. | Token issuance and revocation events, plus proof bundle linkage to the CST scope hash. |
| Rotate to a more restrictive WPC | New runs must fetch/verify a stricter WPC; existing pinned runs continue to enforce the pinned hash or fail closed if mismatched. | WPC hash history and the WPC reference embedded in the proof bundle. |
| Disable elevated execution in OpenClaw config | Tool execution stays inside Docker sandbox where configured; host escape hatch is removed. | OpenClaw config diff plus the run’s receipts showing tool usage did not include elevated paths. |
| Force model routing through clawproxy only | Blocks unreceipted model calls; any bypass becomes a deployment failure rather than a silent gap. | Gateway receipts coverage for model calls and proof bundle completeness checks. |
| Emergency stop for a job class | Issue no new CSTs for that job class and require re-approval for re-enable. | Audit trail for issuance decisions, plus historical proof bundles for already-completed runs. |
FAQ
Why is permissioned execution better than “system prompt governance”?
System prompts are editable text inside the same channel an attacker can influence, and they do not stop a tool call from happening. Permissioned execution uses a WPC and CST so the runtime can refuse actions, even if the prompt asks for them.
Where do approvals live in this model?
Approvals should gate authority, not conversation. In practice, an approval triggers issuance of a CST (or an upgraded CST) that is scoped to a WPC hash, and tools/providers only accept actions covered by that token.
How do budgets work today?
Automatic cost budget enforcement is planned. Today you can implement budgets operationally by constraining TTL and scope in the CST and WPC, and by applying provider-side usage limits and monitoring on the billing account.
Can this align with Microsoft Entra ID governance?
Yes, as an integration pattern: use Entra ID identities and your existing approval processes (for example via PIM or other governance workflows) to decide when a CST can be issued. The mapping is “human decision in Entra governed workflow” to “token issuance policy,” implemented via official API or enterprise buildout.
What do I show an auditor after an incident?
Provide the proof bundle for the run, including gateway receipts for model calls, the WPC hash reference, and the CST scope hash binding. If you stored the artifact as a Trust Pulse, you can share that viewing record without exposing the runtime.