The Universal Run Manifest (URM) is a small, machine-validated manifest that binds an OpenClaw run to specific inputs, approvals, and expected outputs, so execution can be permissioned and auditable. In Claw EA, the URM is used alongside a WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols) and a CST = scoped token (issued by clawscope) to ensure the agent can only run work that was explicitly approved.
This is different from prompt-only controls: prompts can be edited, ignored, or injected, while a permissioned execution layer can fail closed based on hashes, scope rules, and verifiable Gateway receipts emitted by clawproxy for model calls.
Step-by-step runbook
-
Define the work boundary in a WPC and publish it to your WPC registry (served by clawcontrols). Keep the WPC narrow: allowed tool families, model/provider constraints, and any required logging/redaction expectations.
Record the WPC hash. Treat that hash as the stable approval handle used in the URM and in CST pinning.
-
Create a URM for the specific job. Include the WPC hash, the job identity, the expected artifacts, and the tool and model constraints you want enforced for this run.
Store the URM in your change-controlled system (repo, ticket attachment, or artifact store) and require an approval step that is external to the agent.
-
Issue a CST from clawscope for the run. Use CST scope hash and, when appropriate, optional policy hash pinning to bind the CST to the intended WPC and job context.
Prefer short TTL CSTs for interactive jobs and rotate CSTs between runs to limit replay value.
-
Run the agent using OpenClaw as the baseline agent runtime. Configure OpenClaw tool policy and sandboxing so the local blast radius is constrained even if a tool call is approved.
Route model traffic through clawproxy (for example, OpenRouter via fal routed through clawproxy) so model calls produce Gateway receipts.
-
Collect the proof outputs. At minimum, capture the URM, the referenced WPC hash, the CST scope hash, and Gateway receipts, then package them into a Proof bundle for audit and verification.
Optionally store the resulting artifact in Trust Pulse for viewing and later review.
-
Verify before accepting outputs. Verification should check that the WPC hash matches, the CST binding is correct, and the proof bundle’s receipts are present for the relevant model calls.
If anything is missing or mismatched, treat the run as unapproved and do not merge outputs into production workflows.
Threat model
URM is designed for the common failures you see when agents are connected to tools: prompt injection, drift in config, and “it ran on a different machine with different access.” The goal is not to claim perfect security, but to make approvals explicit and to make runs verifiable after the fact.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection changes what the agent attempts | The agent tries to call tools or models outside the approved plan, or tries to exfiltrate data through model prompts. | Permissioned execution checks: URM + WPC constraints, CST scope hash, and policy hash pinning. OpenClaw tool policy and sandboxing reduces what can be reached even when the model misbehaves. |
| Config drift between approval and execution | The run uses a different tool profile, a broader sandbox bind mount, or a different provider than the one reviewers assumed. | URM records intended policy hashes and run identity. OpenClaw includes concrete sandbox and tool policy controls, so the operator can lock to known-safe settings and audit them regularly. |
| Token replay or job confusion | A CST issued for one job is reused to run another job, or is replayed in a different environment. | Marketplace anti-replay binding (job-scoped CST binding) plus short TTLs. URM carries the job identifier that must match the CST binding and the proof bundle metadata. |
| Disputed model call history | You cannot prove which model/provider was called or whether a sensitive prompt was sent. | Gateway receipts emitted by clawproxy for model calls. A Proof bundle aggregates receipts and metadata so verification can be performed later. |
| Local tool execution overreach | An agent with shell access reads or modifies files, or uses elevated execution on the host. | Use OpenClaw sandboxing and tool allow/deny profiles; avoid elevated execution unless explicitly approved. Run OpenClaw security audit regularly to catch footguns. |
Policy-as-code example
A URM should be small and deterministic. Think “approval envelope”: it names the policy (WPC), the run identity, the allowed execution envelope, and the artifacts you expect back.
Below is a minimal schema-style snippet. Field names are illustrative; the important part is that the values are stable, hashable, and validated before execution and again at verification time.
{
"urm_version": "1",
"job": {
"job_id": "acct:finops|proj:close|run:2026-02-11T10:15Z",
"requested_by": "user:alice",
"approved_by": ["user:finops-lead"],
"approval_ref": "ticket:FIN-1842"
},
"policy": {
"wpc_hash_b64u": "WPC_HASH_HERE",
"cst_scope_hash": "SCOPE_HASH_HERE",
"policy_hash_pinning": true
},
"execution": {
"agent_runtime": "OpenClaw",
"tool_profile": "finops-readonly",
"sandbox_mode": "all",
"model_routing": "via clawproxy"
},
"inputs": [
{"name": "ledger_export.csv", "sha256": "INPUT_SHA256"}
],
"expected_outputs": [
{"name": "close_report.pdf", "sha256": null},
{"name": "recon_summary.json", "sha256": null}
],
"retention": {
"proof_bundle_days": 180,
"notes": "Align with your pipeline/run retention policy"
}
}
Validation rules should be fail closed. If the WPC hash cannot be fetched and verified, if the CST scope hash does not match, or if the run is missing required Gateway receipts, treat the execution as unapproved.
What proof do you get?
URM itself is not the proof; it is the approval and intent record. The proof is created by binding URM to real execution artifacts that are hard to fake after the fact.
In Claw EA, the core proof elements are:
-
Gateway receipts emitted by clawproxy for model calls. These are used to verify that specific model requests happened through the approved proxy path.
-
Proof bundle that packages the receipts and related metadata needed for audit and verification. This is what you hand to an auditor or to an internal incident review.
-
WPC reference by hash, so the verifier can retrieve and validate the signed policy artifact from clawcontrols and confirm which policy was in force.
-
CST binding evidence, including CST scope hash and, when used, policy hash pinning. This shows the token was intended for this policy and job context.
-
Trust Pulse storage/viewer (optional) to store the resulting artifact for later viewing and review.
Operationally, this gives you a clean separation: reviewers approve URM + WPC, operators run OpenClaw under those constraints, and verification checks that receipts and policy bindings match what was approved.
Rollback posture
URM is designed to make rollback boring. If a run is later deemed incorrect, you can identify exactly which job ID produced which outputs and which policy approvals were used.
| Action | Safe rollback | Evidence |
|---|---|---|
| Revoke future execution for the job | Revoke the CST and require a new URM approval for any rerun. | CST issuance and revocation records (from clawscope) plus the URM job_id referenced by the run. |
| Invalidate outputs from a suspect run | Quarantine artifacts produced by the run_id and block promotion to downstream systems. | Proof bundle ties outputs to URM metadata and Gateway receipts, so you can target the specific run. |
| Roll back to a prior approved behavior | Re-run with a previously approved WPC hash and a new CST, rather than editing prompts in place. | Hash-addressed WPC references in URM let you select a known prior policy without ambiguity. |
| Reduce blast radius after an incident | Tighten OpenClaw tool policy and sandbox mode, then require a new URM approval for the widened scope later. | OpenClaw configuration is auditable locally; URM documents the intended execution envelope for the job. |
Retention matters for rollback because you cannot investigate what you no longer have. Align proof bundle retention with your existing CI/CD or pipeline retention policies so evidence is available for the period your org expects to investigate incidents.
FAQ
Why do I need URM if I already have a prompt and a checklist?
A prompt and checklist are advisory and can be bypassed by injection or operator error. URM is a machine-checked artifact that binds the approval to a WPC hash, a CST scope hash, and the expected proof outputs.
Is URM a replacement for OpenClaw tool policy and sandboxing?
No. OpenClaw controls the local boundary: which tools exist and where they run (Docker vs host). URM complements that by binding approvals and producing verifiable proof when execution happens.
What is the minimum I should store for audit?
Store the URM, the referenced WPC hash, and the Proof bundle containing Gateway receipts. If you need a central viewer, store the artifact in Trust Pulse.
What fails closed in a URM workflow?
Typical fail-closed checks include: WPC cannot be fetched and verified, CST scope hash mismatch, missing Gateway receipts for model calls, or job-scoped binding mismatch. When a check fails, treat the run as unapproved and do not accept outputs.
How do approvals work for high-risk tools?
Put the approval in policy-as-code, not in the prompt. For high-risk tools, require a narrower WPC, shorter CST TTL, and stricter OpenClaw tool allow/deny profiles, then require a new URM when scope changes.