Token Scope Hash is a deterministic digest of what a CST is allowed to do, computed from a canonical “scope set” and optionally pinned to a WPC. It lets the execution layer approve or deny tool and model actions using policy-as-code, not prompt text, and it gives auditors a stable identifier to compare “what was allowed” across runs.

In Claw EA, OpenClaw is the baseline agent runtime, but the permission boundary must be enforced outside the model. A Token Scope Hash is how you bind “this run may do X” to a job-scoped CST and then verify, fail-closed, that every call stayed inside that boundary.

Step-by-step runbook

This is the operational flow for permissioned execution approvals using Token Scope Hash, WPC, CST, gateway receipts, and proof bundles. It assumes you run agents under OpenClaw and route model calls through clawproxy.

  1. Write a WPC that describes the allowed work. Keep it tool-oriented and environment-specific: which tools, which providers, and which data classes are permitted. Store the signed, hash-addressed policy artifact in the WPC registry (served by clawcontrols).

  2. Issue a CST for the job. Request a CST (issued by clawscope) with a scope set that matches the WPC intent. Turn on optional policy hash pinning so the CST is bound to a specific WPC hash when you need strict approvals.

  3. Compute the Token Scope Hash from canonical scope material. Canonicalize the scope set (sorting, stable JSON encoding, no implicit defaults) and hash it. Treat the resulting Token Scope Hash as the approval handle: it is what you check in logs, tickets, and change review.

  4. Configure OpenClaw to run with least privilege locally. Use tool policy allow/deny and sandbox settings so that even a compromised prompt cannot expand permissions on the host. Run OpenClaw’s security audit regularly to catch footguns like open inbound policies or elevated tool settings.

  5. Route model calls through clawproxy. The provider route emits gateway receipts for each model call. Receipts should be bound to the job-scoped CST to prevent replay across jobs (marketplace anti-replay binding).

  6. On completion, package and verify the proof bundle. Create a proof bundle that includes receipts and metadata required for audit. Verify that the Token Scope Hash in the run matches the CST claims and, if pinned, that the WPC hash matches what was approved.

Threat model

Token Scope Hash solves a specific class of problems: “the agent did something it was never approved to do” and “we cannot prove what permissions were in force.” It does not replace sandboxing or tool policy in OpenClaw; it complements them by making permissions explicit, hashed, and reviewable.

Threat What happens Control
Prompt-only approvals get bypassed A user or injected content convinces the model it is “allowed” to access extra tools or data. Enforce permissions via CST + Token Scope Hash and verify against WPC; deny if missing or mismatched (fail-closed).
Scope inflation via ambiguous representation Two “equivalent” scope documents serialize differently, leading to inconsistent approvals and weak auditability. Canonicalize scope material (sorted keys, explicit defaults) and hash the canonical bytes only.
Policy drift between approval and execution A policy is updated after approval; the run accidentally uses new permissions. Optional policy hash pinning: CST can be tied to a specific WPC hash, so drift causes a hard mismatch.
Token replay across jobs A CST from one run is reused to authorize a different run. Use marketplace anti-replay binding (job-scoped CST binding) and verify job identifiers in receipts and bundles.
Unprovable model calls You cannot prove which model saw which inputs, which breaks incident response and audit. Route through clawproxy and require gateway receipts for model calls; include them in the proof bundle.

Policy-as-code example

This snippet shows the minimum fields you should treat as “scope material” for hashing. The important rule is that the Token Scope Hash is derived from a canonical version of this material, not from free-form text or runtime interpretation.

{
  "version": "scope.v1",
  "job": {
    "job_id": "job_2026_02_11_001",
    "anti_replay": "job_scoped"
  },
  "policy": {
    "wpc_hash_b64u": "WPC_HASH_HERE",
    "pin_policy_hash": true
  },
  "scopes": [
    "models:openrouter/*",
    "tools:read",
    "tools:write:workspace",
    "tools:exec:sandbox_only"
  ],
  "limits": {
    "max_ttl_seconds": 3600
  },
  "hash": {
    "scope_hash_alg": "sha256",
    "scope_hash_b64u": "DERIVED_FROM_CANONICAL_SCOPE_MATERIAL"
  }
}

Validation rules (fail-closed): reject the run if the CST is missing required claims, if the computed Token Scope Hash does not match the CST scope hash, or if policy hash pinning is enabled and the WPC hash does not match. Also reject if the job binding is absent when anti-replay is required, or if TTL exceeds the approved maximum.

Why not prompt-only: prompts are mutable and not reliably enforceable at the execution boundary. Policy-as-code makes approvals machine-checkable, and hashing makes approvals comparable across systems, tickets, and audits.

What proof do you get?

You get two classes of proof: what permissions were granted, and what the agent actually did. The permission grant is represented by the CST (issued by clawscope) and its scope hash, optionally tied to a WPC hash from the WPC registry (served by clawcontrols).

The “what happened” proof comes from gateway receipts: signed receipts emitted by clawproxy for model calls. Receipts, plus job metadata and relevant config identifiers, are packaged into a proof bundle for audit and later verification.

For marketplace-facing workflows, you can store and view the resulting artifact as a Trust Pulse. Operationally, this gives you a single object to hand to reviewers: approved policy hash, Token Scope Hash, and the receipts that show model calls were made under that scope.

Rollback posture

Rollback in permissioned execution is about removing permissions quickly and proving that the rollback took effect. Because the approval handle is the Token Scope Hash and the runtime handle is the CST, rollback focuses on token revocation, policy pinning, and verifying that new runs cannot proceed with old grants.

Action Safe rollback Evidence
Policy mistake in WPC Publish a corrected WPC and require policy hash pinning for new CST issuance; do not “edit in place” for approvals. New CSTs show a different pinned WPC hash; proof bundles show which hash was used per run.
Over-broad scope in CST Revoke the CST and re-issue with a reduced scope set, producing a new Token Scope Hash. Revocation record plus proof bundles for subsequent runs that show the new scope hash.
Suspected token replay Invalidate job binding expectations and force job-scoped CST binding for the affected workflow. Receipts and proof bundle metadata show job identifiers and binding; mismatches fail verification.
Model routing incident Temporarily require all model calls to be routed through clawproxy for receipt coverage. Gateway receipts in proof bundles; missing receipts become a hard audit failure for high-trust runs.

FAQ

What is actually hashed in a Token Scope Hash?

Hash the canonical scope material: an ordered list of scopes plus any binding fields you require for approval, such as job binding mode and the pinned WPC hash. Do not hash free-form text, timestamps that vary run-to-run, or derived defaults that can change across versions.

Why do I need WPC if I already have CST scopes?

A WPC is the signed, hash-addressed policy artifact that you can review, approve, and reference independently of a token issuance event. CST scopes are the runtime grant; pinning them to a WPC hash is how you ensure the runtime grant matches the reviewed policy.

How does this relate to OpenClaw tool policy and sandboxing?

OpenClaw tool policy and sandboxing reduce local blast radius and decide which tools are callable and where they run. Token Scope Hash and CST constrain and prove the remote authorization envelope for the run, especially around model calls and cross-system approvals.

What does “fail-closed” mean here?

If the Token Scope Hash cannot be recomputed deterministically, or it does not match the CST claims, the run should be treated as unauthorized. Likewise, if policy hash pinning is required and the WPC hash cannot be verified, verification should fail rather than guess.

Can I integrate this with Microsoft approvals or access models?

Yes, but it is an enterprise buildout: you typically map internal approval events to “issue CST with scope hash X pinned to WPC hash Y” and then require proof bundles for completion. If you also use Microsoft systems, treat Microsoft Graph permissions/scopes and Entra ID Conditional Access as separate controls from Claw EA’s CST and WPC, and connect them via your approval workflow logic via official API.

Sources