Policy-as-code for agents means the execution layer enforces permissions the same way your APIs do: explicit, versioned rules that decide what the agent may do, with which credentials, and under what conditions. In Claw EA, you express those rules as a WPC (Work Policy Contract) and bind them to runtime access using a CST (scoped token), so an OpenClaw agent cannot exceed its approved authority even if a prompt tries to push it.
Prompt-only controls are advisory and easy to bypass through prompt injection, tool ambiguity, or configuration drift. Permissioned execution makes approvals durable: the policy is signed, hash-addressed, fetched and verified at runtime, and its enforcement is evidenced through gateway receipts and proof bundles.
Step-by-step runbook
-
Define the job boundary and approval surface. Decide what the agent is allowed to change (read-only vs write), where it is allowed to act (systems and environments), and what “completion” means so you can stop the run on policy failure.
Keep the initial boundary narrow: one business purpose, one environment, and a minimal set of tools.
-
Write a WPC (Work Policy Contract) that is concrete enough to be enforced. Include tool allow/deny intent, model/provider constraints where you have them, and any required human approval gates (for example, “writes require ticket id”).
Store and serve the WPC from clawcontrols, using the WPC hash as the stable identifier.
-
Issue a CST (scoped token) from clawscope for the specific job. Bind the CST to a scope hash that matches the WPC intent, and optionally pin the policy hash so the runtime must use that exact WPC version.
Use short TTLs and job scoping so a captured token cannot be replayed across jobs.
-
Route model traffic through clawproxy so model calls are receipted. This yields gateway receipts for each model request and response, allowing you to prove what model was invoked and under which authorization context.
If you use OpenRouter via fal, route it through clawproxy so the same receipt and verification flow applies.
-
Configure OpenClaw with a strict tool policy and sandbox defaults, then map the WPC into the agent’s effective tool availability. OpenClaw already separates sandboxing, tool policy, and elevated execution; keep elevated execution off unless you have an explicit reason and a separate approval.
Run OpenClaw’s own security audit regularly to catch common footguns (permissions, exposed gateway surfaces, and over-broad tool exposure).
-
Run the job and fail closed on policy mismatches. At start, fetch the WPC by hash and verify it; on each sensitive action, ensure the CST scope hash and any pinned policy hash still match the effective policy.
On mismatch, stop the run and preserve the evidence bundle rather than trying to “fix forward” mid-flight.
-
Export a proof bundle and publish it to Trust Pulse if you need centralized review. The proof bundle aggregates gateway receipts and related metadata so verification and audit can happen after the fact without trusting the operator’s narrative.
Use this bundle in incident review, change management, or to justify approvals that were granted.
Threat model
Permissioned execution is mainly about preventing an agent from gaining capability through conversation, indirect instructions, or drift. The table below lists concrete failure modes we see in enterprise agent deployments and the control that should carry the load.
| Threat | What happens | Control (permissioned execution) |
|---|---|---|
| Prompt injection into a tool-enabled agent | The agent is convinced to run a higher-impact tool sequence (exfiltrate files, alter configs, send messages) because the prompt “sounds authorized”. | WPC defines allowed tools and preconditions; OpenClaw tool policy enforces the local boundary; CST scope hash ensures the runtime cannot silently widen permissions for convenience. |
| Scope creep across iterations | A “temporary” permission becomes permanent as teams add scopes to make failures go away, until the agent has broad privileges. | Approvals result in a new WPC hash; CST can pin the policy hash; review diff is done on policy artifacts, not on prompts or chat logs. |
| Model call repudiation | After an incident, you cannot prove which model produced an instruction, what was sent, or whether the transcript was edited. | Gateway receipts from clawproxy provide signed evidence for model calls; proof bundles package receipts for verification and retention workflows. |
| Replay of credentials across jobs | A token from one run is reused to execute a different run with different intent. | Marketplace anti-replay binding using job-scoped CST binding; keep TTL short and require fresh CST issuance per run. |
| Sandbox escape by configuration | Tools that should run in a container run on the host due to “elevated” escape hatches or permissive binds. | OpenClaw sandbox settings plus tool policy separation; express “no elevated” and “no dangerous binds” in your WPC and enforce locally in the OpenClaw config review process. |
| Plugin/tool sprawl | New extensions appear on disk or in config and become callable without a formal approval. | Enforce explicit allowlists in OpenClaw tool profiles; treat any tool surface change as a WPC change requiring approval and new policy hash. |
Some controls sit outside the proxy layer. For example, egress allowlists enforced outside clawproxy can be implemented as an optional layer if you need deterministic outbound restrictions per environment.
Policy-as-code example
This example shows the shape of a permissioned execution policy you can operationalize. In practice, you publish the signed artifact as a WPC in clawcontrols and bind it to a job CST from clawscope so enforcement is not dependent on the prompt.
{
"wpc_version": "1",
"policy_name": "agent-change-reviewer",
"purpose": "Review a PR and propose edits; no direct deploys",
"constraints": {
"tool_policy": {
"allow": ["read", "search", "repo.diff", "repo.comment"],
"deny": ["exec", "shell", "repo.merge", "deploy.*"]
},
"sandbox": {
"required": true,
"workspaceAccess": "ro",
"elevated_exec": "deny"
},
"approvals": [
{
"when": "tool == 'repo.comment' && content.contains('SECURITY:')",
"require": "human_approval"
}
],
"model_calls": {
"route_via": "clawproxy",
"receipts_required": true
}
},
"binding": {
"cst_scope_hash_required": true,
"optional_policy_hash_pinning": true
}
}
Two operational rules matter here. First, the agent only receives a CST whose scope matches the policy intent, so it cannot “ask for more permissions” mid-run without a new approval and a new token.
Second, the model calls are required to be routed through clawproxy so you can later validate what happened using gateway receipts and a proof bundle.
What proof do you get?
You get signed gateway receipts emitted by clawproxy for each model call that is routed through it. Receipts are the primary evidence for model invocation details and are designed to be verified later rather than trusted implicitly.
You also get a proof bundle, which is a harness artifact bundling receipts and related metadata for audit and verification. This is what you hand to a reviewer, an auditor, or your own incident process so they can validate the run without relying on screenshots or edited transcripts.
If you publish to Trust Pulse, you have a marketplace-stored artifact for audit/viewing. Use that when multiple teams need consistent access to the same evidence set, or when you want a stable reference in a ticket.
What this does not do by itself is prevent all data egress or enforce a spend ceiling. Egress allowlists enforced outside clawproxy and automatic cost budget enforcement are optional or planned layers, depending on your environment and change-control requirements.
Rollback posture
Permissioned execution should include a rollback posture that is simple and testable. The goal is to be able to stop work, revoke authority, and produce evidence within minutes, without debating what the agent “meant” in the chat.
| Action | Safe rollback | Evidence to retain |
|---|---|---|
| Policy mistake discovered (WPC too permissive) | Issue a new WPC and require policy hash pinning for new runs; do not reuse the old WPC hash. | Old and new WPC hashes, approval record, proof bundle from the run that revealed the gap. |
| Token leak suspected | Revoke the CST at clawscope and rotate job credentials; restart the job with a fresh CST bound to the job. | CST issuance metadata, revocation event, proof bundle up to the stop point. |
| Unapproved tool invocation attempt | Fail closed and stop the agent session; widen policy only after review and new WPC hash. | Gateway receipts showing the attempted model call and the denial path, plus the effective tool policy snapshot. |
| Model provider dispute or audit request | Re-run the verification flow on the proof bundle and provide the receipts; do not rely on chat logs alone. | Proof bundle, gateway receipts, and verification output used internally for the decision. |
Operationally, rollback should be rehearsed. Treat “revoke CST, stop job, export proof bundle” as the agent equivalent of “disable key, stop deploy, preserve logs”.
FAQ
Why is prompt-only control not enough for enterprise agents?
Prompts are not an enforcement boundary. A prompt can be overridden by new instructions, hidden content, or tool outputs, while permissioned execution uses WPC and CST constraints that the runtime checks regardless of what the agent says.
How do approvals work in a policy-as-code workflow?
Approvals should produce a new WPC version with a new hash, not just an updated prompt. You then issue a job-specific CST whose scope hash matches the approved WPC, and optionally pin the policy hash so the job cannot drift.
Where does OpenClaw fit if Claw EA is enforcing policy?
OpenClaw is the baseline agent runtime where tools execute and where local sandbox and tool policy are applied. Claw EA adds portable policy artifacts (WPC), scoped authorization (CST), and verifiable evidence (gateway receipts and proof bundles) so the run can be governed and audited consistently.
What do gateway receipts prove, and what do they not prove?
Gateway receipts prove details about model calls that went through clawproxy and were receipted, and they support later verification. They do not magically prove what happened in systems the agent touched unless those actions are also mediated and logged by your tools or environment.
Can I enforce outbound network allowlists or cost budgets with this?
Egress allowlists enforced outside clawproxy can be implemented as an optional layer, depending on where you can enforce network controls in your environment. Automatic cost budget enforcement is planned, so today you should implement spend limits via your provider controls and internal guardrails.