In Claw EA, “Policy Artifacts” are the objects you use to approve and constrain real execution by OpenClaw agents: WPC, CST, gateway receipts, and proof bundles. They make approvals machine-enforceable and auditable, instead of relying on prompt text that can be ignored, overwritten, or injected.
Prompt-only controls describe intent, but they do not bind tool access, token scope, or model calls to a specific approved policy. Policy-as-code turns approvals into signed artifacts that the execution path can verify, fail-closed, and later prove.
Quick taxonomy (what lives in this hub):
- Work Policy Contracts (WPC): Signed, hash-addressed policies that define what a job is allowed to do, served by clawcontrols.
- CST: A scoped token issued by clawscope that carries a scope hash and can optionally pin to a policy hash.
- Policy hash pinning: A mode where the CST is only valid for the referenced WPC hash, preventing “policy drift” mid-run.
- Gateway receipts: Signed receipts emitted by clawproxy for model calls, used to verify what was actually sent and received.
- Proof bundle: A harness artifact bundling receipts and related metadata for audit and verification.
- Marketplace anti-replay binding: A job-scoped CST binding that prevents reusing the same authorization context in a different job.
- Trust Pulse: A marketplace-stored artifact for audit/viewing when you need a durable, reviewable record.
- Local runtime controls (OpenClaw): Tool policy, sandboxing, and elevated mode that reduce blast radius on the host.
- Approvals workflow: Human or system gates that mint, sign, and distribute WPC and CST rather than “approving in chat”.
How to get started (checklist):
- Define a WPC for a single agent job and treat it like a deployment approval artifact.
- Issue a CST for that job from clawscope with a tight TTL and scope hash, and optionally pin the WPC hash.
- Route model traffic through clawproxy so gateway receipts are produced for each model call.
- Export the proof bundle at job end and store it alongside change tickets, incident records, or compliance evidence.
Step-by-step runbook
-
Write the WPC. Encode the job’s allowed tools, data boundaries, and operator requirements as a WPC. Keep it explicit about what is disallowed so reviewers can approve it quickly.
-
Register and reference the WPC by hash. Store the signed WPC in the WPC registry (served by clawcontrols) and use the hash as the stable identifier. Your runbooks and tickets should reference the hash, not a mutable file path.
-
Issue a CST for the job. Use clawscope to mint a CST with the minimum scope required, a short TTL, and (when needed) policy hash pinning to the WPC hash. This makes “approval” an authorization object, not a chat instruction.
-
Run the agent on OpenClaw with local controls enabled. Use OpenClaw tool policy and sandboxing so the local blast radius is limited even when the model behaves unexpectedly. Treat elevated mode as an exception path that must be explicitly allowed.
-
Proxy model calls through clawproxy. Route model traffic (for example OpenRouter via fal routed through clawproxy) so gateway receipts are emitted for model calls. This gives you verifiable evidence of model I/O for the run.
-
Export and verify the proof bundle. At the end of the job, collect the proof bundle and attach it to the change record or incident timeline. If you publish the record for reviewers, store it as a Trust Pulse for audit/viewing.
Threat model
Policy artifacts exist because execution failure modes are operational, not theoretical. The goal is to make unsafe states hard to reach, and to preserve evidence when something goes wrong.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection overrides “rules” | The agent is convinced to run a tool, access data, or broaden scope despite instructions to the contrary. | Permission is enforced by WPC plus CST scope hash, not by prompt text. OpenClaw tool policy and sandboxing reduce impact if an unsafe tool is available. |
| Policy drift during a long-running job | A job starts under one policy but later operates under a different, less-reviewed version. | Use WPC hash addressing and optional policy hash pinning in the CST so the run is cryptographically tied to the approved policy artifact. |
| Token replay across jobs or environments | A token issued for one job is reused to authorize a different job, bypassing the intended approval boundary. | Marketplace anti-replay binding (job-scoped CST binding) prevents cross-job reuse patterns. Keep CST TTL short and rotate issuance keys under standard key management. |
| Disputes about what the model actually saw | After an incident, teams cannot reliably reconstruct prompts, tool inputs, or model outputs. | Gateway receipts from clawproxy produce a signed record of model calls. Proof bundles collect those receipts with run metadata for later verification. |
| Over-broad local execution privileges | Tools run on the host with access to files, sockets, or credentials that were not intended for the job. | Prefer OpenClaw sandboxing and strict tool allowlists. Treat elevated mode as a controlled exception and document it in the WPC so the risk is reviewed. |
Optional or planned controls can be added depending on your risk profile. Egress allowlists enforced outside clawproxy, automatic cost budget enforcement, and transparency log inclusion proofs are not required to start, but can be implemented when you need stricter guarantees.
Policy-as-code example
This is a compact, JSON-like sketch of a WPC shape that teams commonly review. The point is not the exact schema, but the reviewable intent that gets signed, hashed, and referenced by jobs.
{
"wpc_version": "v1",
"policy_name": "customer-support-refund-assistant",
"allowed_tools": ["ticket.read", "ticket.comment", "refund.request"],
"denied_tools": ["shell.exec", "fs.write", "secrets.export"],
"data_boundaries": {
"pii": "redact_in_logs",
"export": "deny"
},
"model_routing": {
"must_proxy_via": "clawproxy",
"receipts_required": true
},
"approvals": {
"required": true,
"approver_group": "SupportOps-PIM-Eligible"
},
"token_constraints": {
"cst_ttl_minutes": 30,
"pin_policy_hash": true,
"job_bound": true
}
}
If you use Microsoft identity, keep the boundary clear: Entra ID, Conditional Access, and PIM can govern who is allowed to request approvals and who can mint job credentials. The WPC and CST still carry the execution-time constraints that the runtime can verify independent of the chat channel.
What proof do you get?
For each model call routed through clawproxy, you receive gateway receipts that can be independently checked for integrity. This is the core evidence for “what the model was asked” and “what it returned” at the time of execution.
A proof bundle packages those receipts together with job metadata so you can answer audit questions without scraping logs. In practice, teams store proof bundles with change approvals, and optionally publish a Trust Pulse artifact when they need a durable record for reviewers.
The approval boundary is also provable: the CST is minted with a scope hash and can optionally pin to a WPC hash. That creates a tight linkage between “what was approved” and “what was allowed to run,” even if prompts or skills change.
Rollback posture
Rollback in agent systems is less about reverting code and more about quickly shrinking permissions and stopping unsafe execution. The artifacts here support “fail closed” defaults: if verification fails, the job should not gain more capability.
| Action | Safe rollback | Evidence |
|---|---|---|
| Bad tool behavior discovered mid-run | Issue a new, tighter WPC and require a new CST for continued execution; stop issuing CST for the old policy. | WPC hashes show exactly when the policy changed; proof bundle shows which policy was active for each job window. |
| Suspected credential leak | Revoke CST (via clawscope) and rotate upstream credentials; rerun the job under a new WPC with narrowed scope. | CST issuance and revocation events plus job-scoped binding reduce ambiguity about what could be replayed. |
| Model output dispute or incident review | Freeze the proof bundle and share it with incident responders; do not rely on reconstructed prompts from chat logs. | Gateway receipts provide a signed record of model calls; proof bundle ties receipts to a specific run. |
| Local host exposure concerns | Move execution to OpenClaw sandbox mode for that agent profile and remove elevated allowances until reviewed. | OpenClaw configuration and audit outputs document the effective sandbox and tool policy posture. |
FAQ
Why isn’t a “please ask for approval” prompt sufficient?
Because the model can be persuaded to ignore it, and the runtime cannot verify that the prompt was followed. A WPC plus CST makes the approval decision part of the authorization path, not part of a conversation.
How do WPC and OpenClaw tool policy relate?
OpenClaw tool policy and sandboxing are local controls that limit what tools can run and where they run. WPC is the portable, signed contract that lets your platform enforce and audit the intended permissions across jobs and environments.
What should we pin in the CST: scope hash, policy hash, or both?
Start with scope hash to keep tokens minimally privileged. Add policy hash pinning when you need stronger guarantees that a job cannot switch policies without re-approval.
Do gateway receipts capture everything the agent did?
No. Gateway receipts cover model calls routed through clawproxy, which is often the critical evidence during reviews. Tool execution evidence is typically handled by the runtime and your logging pipeline; the proof bundle is the container that keeps model-call evidence and run metadata together.
Can we align this with enterprise approval patterns like deployment checks?
Yes, conceptually. Many teams map WPC signing and CST issuance to the same governance expectations as pipeline approvals and checks, where the approval gate is not editable by the job itself.