Work Policy Contracts (WPC) are signed, hash-addressed policy artifacts that let you permission agent execution with policy-as-code, not prompt text. In Claw EA, a WPC is fetched and verified at run time and can be pinned to a CST so the job only runs under the intended contract.

This matters because OpenClaw is a baseline agent runtime built to run real tools, and prompt-only guardrails are not enforceable when the model is under pressure from tool output, prompt injection, or user instructions. A WPC turns “should” into “must” by defining what tool calls, model routing, and approval gates are allowed before execution proceeds.

Step-by-step runbook

  1. Write a minimal WPC for the job type you want to allow. Start with tool allow/deny, sandbox expectations, and model routing rules that match your OpenClaw configuration.

  2. Publish the WPC to the WPC registry (WPC = Work Policy Contract; signed, hash-addressed policy artifact; served by clawcontrols). Record the resulting policy hash and treat it as the immutable identifier for that contract.

  3. Issue a CST (CST = scoped token, issued by clawscope) for the agent job. Include a scope hash and, when you need strict binding, pin the WPC policy hash so the token is only valid under that exact policy.

  4. Configure the OpenClaw runtime to route model calls through clawproxy. This produces Gateway receipts (signed receipts emitted by clawproxy for model calls) for each model request made during the run.

  5. Start the job with the CST and the policy hash reference. The execution path should fail closed if the WPC cannot be fetched or verified, or if the CST policy hash pin does not match.

  6. At completion, collect the proof bundle (a harness artifact bundling receipts and related metadata for audit/verification). Store it internally and, when you need a marketplace-viewable record, publish the relevant artifact to Trust Pulse.

Threat model

A WPC is designed for operational failure modes, not theoretical ones. The goal is to ensure the agent cannot expand its authority just by producing different text.

Threat What happens Control
Prompt injection via tool output Tool returns hostile instructions that try to trigger file access, credential reads, or new network calls. WPC constrains tool availability and sensitive operations; OpenClaw tool policy and sandboxing reduce blast radius, and the run should fail if the contract does not allow the attempted tool call.
Policy drift between runs An operator changes local config or a skill, and the agent silently gains new capability. Pin the policy hash in the CST so a job cannot run under a different WPC; treat the policy hash as the approval boundary.
Replay of a previously valid token A captured token is reused to run a second job with the same permissions. Marketplace anti-replay binding (job-scoped CST binding) reduces reuse at the job boundary and helps ensure a CST is not accepted outside its intended run context.
Model call dispute or missing audit trail You cannot prove which prompts, tool outputs, or model routes were used for a decision. Route model calls through clawproxy to produce Gateway receipts, then package them into a proof bundle for verification and audit.
Over-permissioned escape hatch Agent switches to elevated execution or a broader tool profile than intended. Make elevated tool use explicitly disallowed unless the WPC declares it; align WPC intent with OpenClaw’s sandbox vs tool policy vs elevated separation.

Some controls are outside the proxy layer. For example, egress allowlists enforced outside clawproxy can be implemented as an additional guard, but should be treated as optional design work, not assumed.

Policy-as-code example

This is a compact, JSON-like example of the shape teams tend to use. Your internal schema can differ, but keep the same principles: explicit tool allowlists, explicit model routing, and a clear approval boundary.

{
  "wpc_version": "1",
  "policy_hash": "b64u:...",
  "issuer": "security-team",
  "purpose": "permissioned execution approvals for agent jobs",
  "runtime": {
    "baseline": "OpenClaw",
    "sandbox_mode": "all",
    "allow_elevated": false
  },
  "tools": {
    "allow": ["read", "write", "exec", "http"],
    "deny": ["docker_socket", "host_browser_control"]
  },
  "model_calls": {
    "route_via": "clawproxy",
    "allowed_providers": ["OpenRouter via fal"]
  },
  "approvals": {
    "required_for": [
      {"action": "exec", "when": "workspaceAccess=rw and path_matches=/prod/"},
      {"action": "http", "when": "host_not_in_allowlist"}
    ]
  },
  "token_binding": {
    "cst_scope_hash_required": true,
    "cst_policy_hash_pinning": "recommended"
  },
  "validation": {
    "fail_closed_on_missing_wpc": true,
    "fail_closed_on_hash_mismatch": true
  }
}

The important part is validation behavior. A missing WPC, an invalid signature, or a hash mismatch should stop execution before the agent is allowed to make model calls or touch tools.

What proof do you get?

Each model call routed through clawproxy can emit Gateway receipts. These receipts are designed to be collected, checked, and later used to answer “what did the model see and produce” for the calls that mattered.

At the run level, Claw EA can produce a proof bundle that aggregates the run metadata and the Gateway receipts. The proof bundle is the artifact you hand to audit, incident response, or verification workflows.

For workflows that need a durable viewer and sharing surface, you can store artifacts in Trust Pulse. Use it as the place to point reviewers to the specific run evidence, rather than trying to reconstruct intent from logs.

Rollback posture

WPC-based permissioning is meant to be reversible under pressure. The core rollback move is to tighten policy and force new jobs to re-auth under a new policy hash, rather than trying to edit prompt instructions mid-incident.

Action Safe rollback Evidence
Stop a risky capability (for example, outbound HTTP tool use) Publish a new WPC revision that removes the tool or adds approvals; require CST policy hash pinning to the new hash for new jobs. New proof bundles show the new policy hash reference and the absence of disallowed tool calls; Gateway receipts show reduced model activity if calls are blocked.
Contain a suspected token leak Rotate issuance and revoke CSTs in clawscope; rely on job-scoped CST binding to reduce replay at the job boundary. CST issuance and revocation records, plus proof bundles that show which CST was used for which job.
Prove what happened after an incident Freeze the relevant proof bundles and publish the audit view in Trust Pulse for reviewers. Proof bundle contents including Gateway receipts and run metadata; Trust Pulse provides a stable reference for review.
Reduce host exposure Align OpenClaw settings to sandbox more sessions and remove elevated paths; ensure the WPC forbids elevated unless explicitly approved. OpenClaw configuration and sandbox explanation output, plus proof bundles after the change that show expected execution behavior.

Automatic cost budget enforcement can be implemented, but it should be treated as planned or an enterprise buildout item. Do not rely on it as your only safety net.

FAQ

Why is prompt-only policy not enough for permissioned execution approvals?

Prompt text is not an enforcement boundary because the model can be convinced to ignore it, especially when tool output contains hostile instructions. Permissioned execution requires machine-enforced checks that run before a tool call or model route is allowed.

How does a WPC relate to OpenClaw tool policy and sandboxing?

OpenClaw provides local controls like tool allow/deny and Docker sandboxing, and those remain your immediate safety boundary. A WPC makes those constraints portable and auditable across jobs and environments by anchoring them to a signed, hash-addressed policy artifact.

What does CST policy hash pinning actually prevent?

It prevents a job from silently running under a different policy than the one that was approved. If the CST is pinned to a specific WPC hash, attempts to substitute a different policy can be detected and blocked.

Do I get evidence of the model calls that happened during the run?

Yes, when model traffic is routed through clawproxy, you get Gateway receipts for model calls. Those receipts are packaged with metadata into a proof bundle for audit and later verification.

Can WPCs express human approvals like the ones used in CI/CD?

Yes at the policy layer, as an approvals gate that must be satisfied before proceeding, but the integration that collects approvals is environment-specific. If you want to map it to enterprise approval systems, do it via official API or an MCP server, and keep the WPC as the enforcement contract that the runtime checks.

Sources