CST (scoped token) is the execution approval artifact you hand to an agent run so it can call approved services and tools under machine-checked constraints. In Claw EA, CSTs are issued by clawscope and are typically bound to a specific policy (a WPC) and a specific job context to prevent reuse.
This matters because OpenClaw is a baseline agent runtime with real tool access, and prompt-only “rules” are not an enforcement layer. Permissioned execution means the runtime and gateways can fail closed when the token, scope hash, or pinned policy hash does not match what was approved.
Step-by-step runbook
Use this when you want an agent run that is approval-driven, auditable, and resistant to token replay. The goal is to make “what was allowed” explicit in a WPC and make “what was used” provable via receipts and a proof bundle.
-
Write a WPC for the work. Keep it narrow: which model traffic is allowed through clawproxy, which OpenClaw tools are allowed, and which high-risk capabilities are denied by default.
-
Publish the WPC to the WPC registry in clawcontrols. Treat the WPC hash as the policy identity and use it as the reference in change control.
-
Configure the OpenClaw Gateway tool policy and sandboxing to match the WPC intent. This keeps local execution aligned with the remote policy layer, especially for exec and filesystem tools.
-
Request a CST from clawscope with a scope hash that encodes the minimum permissions needed, and optionally pin the policy hash to the WPC. If you run via a marketplace job, use the job-scoped CST binding to prevent anti-replay failures later.
-
Run the agent. Route model calls through clawproxy (for example, OpenRouter via fal routed through clawproxy) so every model call produces gateway receipts.
-
Collect the proof bundle at the end of the run. Store it as an audit artifact and optionally publish it into Trust Pulse for easier review and sharing.
Threat model
CSTs reduce “ambient authority” by tying agent capability to an explicit scope hash and, when used, a pinned WPC hash. They do not replace OpenClaw’s local sandbox and tool policy; they complement it so remote calls and approvals are verifiable and fail closed.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection causes the agent to attempt unapproved actions | The model tries to call tools or services outside the intended run plan | OpenClaw tool allow/deny plus sandboxing for local tools, and CST scope hash checks for remote calls; deny-by-default behavior means missing permissions fail closed |
| Stolen token is replayed in a different job | An attacker reuses a CST to run the same permissions elsewhere | Marketplace anti-replay binding using job-scoped CST binding; token use outside the expected job context is rejected |
| Policy drift between what was approved and what executed | The runtime runs with looser settings than reviewers expected | Optional policy hash pinning in CST, plus WPC fetch/verify; a token intended for one WPC will not validate against a different policy hash |
| Operator disputes what the model actually sent to a provider | Logs are incomplete or can be edited after the fact | Gateway receipts emitted by clawproxy for model calls; receipts are signed and can be bundled for later verification |
| Local tool escape hatch is enabled | Sandboxed sessions still run host commands through elevated execution | Align OpenClaw elevated settings with the WPC and treat any elevated permission as a separate approval tier; investigate sessions where elevated was enabled |
Policy-as-code example
This is a minimal, JSON-like example of what you should be thinking about when you mint a CST for an agent run. The enforcement point is not the prompt; it is the token’s scope hash and the pinned WPC hash that the execution layer verifies before allowing protected actions.
{
"wpc_ref": {
"wpc_hash_b64u": "WPC_HASH_HERE",
"pin_policy_hash": true
},
"cst_request": {
"aud": "clawproxy",
"ttl_seconds": 1800,
"job_binding": {
"job_id": "job-2026-02-11-0142",
"anti_replay": true
},
"scope": {
"scope_hash": "SCOPE_HASH_HERE",
"allow": [
"model.call:openrouter_via_fal",
"bundle.write:proof_bundle"
],
"deny": [
"tools.elevated",
"egress.any"
]
}
},
"validation_rules": {
"fail_closed_on_missing_scope": true,
"fail_closed_on_wpc_mismatch": true,
"require_signed_receipts_for_model_calls": true
}
}
In practice, the “allow” list should map to concrete operations you can audit. If you need to reach external systems, do it explicitly via official API, via MCP server, or via enterprise buildout, then scope the CST to exactly those calls.
What proof do you get?
You get gateway receipts for model calls when traffic goes through clawproxy. Receipts are the unit you can verify later to confirm which model endpoint was called, when it was called, and what policy and job context the call was bound to.
You also get a proof bundle that packages those receipts with the related run metadata so an auditor can verify the run without reconstructing logs from multiple systems. If you publish it, Trust Pulse stores the artifact for audit/viewing, which is useful when multiple teams need to review the same run evidence.
Rollback posture
Rollback for agent execution should be procedural and fast. The objective is to stop further action (token invalidation and policy tightening), then preserve evidence (receipts and proof bundles) for incident review.
| Action | Safe rollback | Evidence |
|---|---|---|
| Revoke the CST | Stop the current run and invalidate the token so retries fail closed | CST issuance and revocation records from clawscope, plus the final proof bundle for what already happened |
| Pin a tighter WPC and re-mint a CST | Publish a new WPC with narrower permissions and require policy hash pinning for the replacement CST | WPC hashes (old and new) and proof bundle references showing which policy was in effect per run |
| Reduce local blast radius in OpenClaw | Switch sandbox mode to cover more sessions and tighten tool allow/deny; disable elevated where possible | OpenClaw security audit outputs and the tool policy configuration diff tied to the incident window |
| Force model traffic back through clawproxy | Block direct provider calls in your agent configuration so all model calls generate receipts | Gateway receipts continuity across runs, showing no gaps in receipted traffic |
Some controls, like egress allowlists enforced outside clawproxy and automatic cost budget enforcement, are optional or can be implemented depending on your environment. Treat those as part of an enterprise buildout plan rather than assumptions.
FAQ
Why is policy-as-code necessary instead of prompt-only instructions?
Prompts can be ignored, overwritten by later context, or exploited by injection. Policy-as-code makes enforcement happen at the execution layer, where CST validation and pinned WPC hashes can deny actions deterministically.
What is the difference between a WPC and a CST?
A WPC is the signed, hash-addressed policy artifact served by clawcontrols. A CST is the scoped token issued by clawscope that carries the approved scope hash and can optionally pin to the WPC hash so the runtime can verify the run is operating under the approved policy.
How does Claw EA prevent CST replay across jobs?
For marketplace runs, job-scoped CST binding provides anti-replay so a CST cannot be lifted from one job and reused for another. If the job binding does not match, validation should fail closed.
What does “gateway receipts” mean operationally?
Gateway receipts are signed receipts emitted by clawproxy for model calls. You store them in a proof bundle so you can later verify that specific model traffic happened under a specific token and policy context.
Does this replace OpenClaw sandboxing and tool policy?
No. OpenClaw’s sandbox and tool policy remain the local safety boundary, and CSTs add permissioned, auditable access for remote calls and approvals.