This hub collects implementation guides for running permissioned enterprise agents on Claw EA, using OpenClaw as the baseline agent runtime. The goal is to make agent execution verifiable and restrictable using policy-as-code, rather than relying on prompt text to “behave.”
In practice, you express allowed actions as a WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols), bind runtime access using a CST = scoped token (issued by clawscope), route model calls through clawproxy for gateway receipts, and retain a proof bundle for audit and rollback.
Step-by-step runbook
Use this as the default path for a first production pilot. Keep the first WPC small, then widen only after you can review receipts and prove that enforcement is working.
-
Pick one job shape and one tool surface. Example: “triage inbound tickets and draft responses,” with a single write surface (your ticketing system via official API or via MCP server) and read-only access elsewhere.
-
Write a WPC that describes the allowed work. The WPC should encode tool allow/deny, sandbox requirements, and model routing constraints that you can check mechanically. A prompt can guide behavior, but it cannot enforce it when the model decides to call tools anyway.
-
Issue a CST with scope hash and optional policy hash pinning. Use clawscope to mint a CST that is job-scoped, with the intended scope hash and, when appropriate, a pinned WPC hash. This keeps “what the agent can do” bound to a signed artifact, not to a chat transcript.
-
Configure OpenClaw to run with strict tool policy and sandboxing. Use OpenClaw tool policy (allow/deny profiles) plus sandbox mode to reduce local blast radius, and avoid elevated execution unless you can justify it. Treat elevated as a last-resort escape hatch that must be explicitly permissioned.
-
Route model traffic through clawproxy and capture gateway receipts. For LLM calls, route through clawproxy so each model call emits gateway receipts. If you use OpenRouter via fal, run it through clawproxy so receipts can be verified later.
-
Require proof review before widening privileges. On each pilot run, archive the proof bundle, verify it, and review the tool and model-call boundaries you actually observed. Only then update the WPC and re-issue CSTs for the next iteration.
How to get started checklist: define one WPC, run one OpenClaw agent in sandbox mode, issue one job-scoped CST, route all model calls through clawproxy, and require a proof bundle attached to every run before sign-off.
Threat model
Enterprise agent security fails most often at the execution layer: the agent gains a tool it should not have, or it uses a permitted tool in an unpermitted way. Prompt-only controls are advisory and can be bypassed by prompt injection, tool descriptions that drift, or plugin behavior that changes.
The controls below treat policies and tokens as signed constraints and require verifiable evidence after the run.
| Threat | What happens | Control (operational) |
|---|---|---|
| Prompt injection causes unsafe tool use | The model is convinced to call a tool that changes state or exfiltrates data | Enforce tool allow/deny via OpenClaw tool policy and sandboxing; express the allowed work as a WPC and require CST policy hash pinning for runs that change state |
| Token replay across jobs | A captured token is reused to run a different job or widen access | Use marketplace anti-replay binding with job-scoped CST binding; rotate CSTs per job and revoke quickly on suspicion |
| Model call disputes after an incident | You cannot prove which prompts and model responses occurred during execution | Route model calls through clawproxy to generate gateway receipts; bundle receipts into a proof bundle for independent verification |
| Sandbox escape or host impact | Tool execution touches host filesystem or processes beyond intent | Run tools in OpenClaw Docker sandbox where possible; avoid elevated execution unless the WPC explicitly allows it and the run is limited in scope |
| Unbounded outbound calls | The agent uses HTTP tooling to reach arbitrary hosts and leak data | Implement egress allowlists enforced outside clawproxy (optional, can be implemented) and keep the WPC tool allowlist minimal; review receipts and tool logs for unexpected destinations |
Policy-as-code example
A WPC should be a portable, signed contract that the runtime can fetch and verify, and that your reviewers can diff like code. The key difference from “prompt rules” is that this policy is intended to be enforced mechanically, and referenced by hash in the CST when you need strict pinning.
Example JSON-like structure (illustrative):
{
"wpc_version": "1",
"intent": "ticket-triage-draft-only",
"model_routing": {
"provider": "openrouter_via_fal",
"must_route_through": "clawproxy"
},
"openclaw": {
"sandbox": { "mode": "all", "workspaceAccess": "ro" },
"tools": {
"allow": ["read", "search", "http_get"],
"deny": ["exec", "write", "edit", "apply_patch"],
"elevated": { "allow": [] }
}
},
"data_handling": {
"redact": ["secrets", "tokens"]
}
}
For a production run that can change state, issue a CST that includes a scope hash for the job and optional policy hash pinning to the WPC hash you approved. This makes “what was allowed” checkable even when prompts and skills evolve.
What proof do you get?
Every model call routed through clawproxy can produce gateway receipts. Receipts are designed to be verified later, so you can answer “what did the model see and say” without relying on an application log that might be incomplete or edited.
Claw EA groups those receipts and related metadata into a proof bundle per run. The proof bundle is the unit you hand to security review, compliance sampling, or incident response to reconstruct the execution boundary and validate it independently.
For org-wide viewing and audit workflows, you can store and view artifacts as a Trust Pulse. For replay resistance, use marketplace anti-replay binding (job-scoped CST binding) so a token from one job cannot be reused to generate “valid-looking” proof for another job.
Rollback posture
Permissioned agents need a rollback plan that is fast, testable, and evidence-driven. Treat rollback as a set of switches you can flip without debating what happened, because the proof bundle and gateway receipts already anchor the record.
| Action | Safe rollback | Evidence to confirm |
|---|---|---|
| Suspected credential or token leak | Revoke the CST and re-issue job-scoped CSTs with narrower scope hash; rotate affected secrets | Proof bundle shows last valid run; subsequent calls fail to authenticate, and no new gateway receipts appear for the revoked CST |
| Tool misuse or unexpected side effects | Update the WPC to deny the tool or require a stricter sandbox mode; pin the new WPC hash in new CSTs | Diff between WPC versions plus proof bundles that demonstrate the tool is no longer called |
| Model output dispute (what was sent to the model) | Freeze changes, verify gateway receipts from clawproxy, and re-run with the same WPC and a fresh CST for reproduction | Verified gateway receipts and the associated proof bundle; comparison across runs is anchored by receipts |
| Network exfiltration concern | Temporarily remove outbound HTTP tools from the allowlist and implement egress allowlists enforced outside clawproxy (optional, can be implemented) | Receipts and tool logs show no outbound calls after the policy change |
FAQ
Why isn’t prompt-only “do not exfiltrate data” sufficient?
Prompt rules are not enforcement. When an agent can call tools, the execution layer must be permissioned with policy-as-code so that disallowed actions cannot execute even if the model is manipulated.
How do WPC and CST work together during a run?
The WPC defines the approved work boundary as a signed artifact. The CST is the runtime credential that can carry a scope hash and optionally pin the policy hash, so a run is bound to both “who/what can run” and “what is allowed.”
What do gateway receipts cover and what do they not cover?
Gateway receipts cover model calls routed through clawproxy, so you can verify what was sent and returned at the model boundary. They do not automatically prove what happened inside every external system, so you still pair this with system-side logs via official API or enterprise buildout.
Can we integrate enterprise identity like Entra ID?
Yes, typically by issuing CSTs based on your enterprise identity workflow and binding runs to job context, with enforcement in Claw Bureau services. If you need Entra ID features like Conditional Access or PIM to gate who can mint or approve tokens, that is usually done as an enterprise buildout around your existing identity plane.
Do you block egress by default?
Claw EA focuses on permissioned execution, receipts, and proof bundles. Egress allowlists enforced outside clawproxy are optional and can be implemented when your environment requires network-level controls.