Enterprise AI agents need controls that are enforced by the execution layer, not just requested in a prompt. Claw EA runs OpenClaw as the baseline agent runtime, then adds permissioned execution using WPC = Work Policy Contract, CST = scoped token, gateway receipts, and proof bundles so you can prove what the agent was allowed to do and what it actually did.

Prompt-only guardrails fail when the agent is tool-calling, long-running, or exposed to untrusted inputs. Policy-as-code makes the allowed actions machine-checkable and verifiable at runtime, and it gives you artifacts you can audit after the fact.

Step-by-step runbook

  1. Define the job boundary and identity. Decide what a “job” is for your org (ticket, alert, incident, or workflow instance) and what data classification it may touch. If you use Microsoft, align this to Entra ID app identities, Microsoft Graph permissions/scopes, Conditional Access posture, and PIM for operator actions, via official APIs and enterprise buildout where needed.

  2. Write a WPC and treat it as the source of truth. Create a WPC = Work Policy Contract that states which tools, providers, and data classes are allowed. Store it as a signed, hash-addressed policy artifact served by clawcontrols, and reference the policy hash in your run configuration.

  3. Configure OpenClaw tool policy and sandboxing to match the WPC. Use OpenClaw tool allow/deny lists and sandbox modes to reduce blast radius, then keep any host-level “elevated” paths tightly gated. Validate the effective configuration using OpenClaw’s built-in inspection and security audit guidance.

  4. Issue a CST that is job-scoped and policy-pinned. Obtain a CST = scoped token issued by clawscope for the specific job, with a scope hash and optional policy hash pinning. Prefer short TTLs and one job per CST to support marketplace anti-replay binding (job-scoped CST binding).

  5. Route model traffic through clawproxy for receipts. Run model calls through clawproxy so you get gateway receipts (signed receipts emitted by clawproxy for model calls). If you use OpenRouter, it is supported via fal routed through clawproxy.

  6. Collect a proof bundle for every run and store it where auditors can find it. Archive the proof bundle (the harness artifact bundling receipts and metadata for audit/verification). If you use Trust Pulse, store the artifact there for viewing and later review.

Quick start checklist: (1) smallest tool allowlist that still works, (2) sandbox “all” for untrusted channels, (3) WPC hash pinned, (4) job-scoped CST, (5) clawproxy receipts on, (6) proof bundle archived.

Threat model

Agent controls should assume the agent can be coerced by prompt injection, can make mistakes, and can be triggered unexpectedly in real channels. The goal is to constrain execution, then generate evidence that those constraints were applied.

Threat What happens Control (operational)
Prompt injection causes unsafe tool use The model attempts shell, file, or network actions outside intended scope OpenClaw tool allow/deny lists plus sandboxing; WPC defines allowed tool classes and is enforced as a policy artifact, not a prompt suggestion
Credential or token replay A copied token is reused to run extra work after the job ends Job-scoped CST binding (marketplace anti-replay binding) and short-lived CST issuance from clawscope
Unverifiable model activity You cannot prove which model calls were made, with what policy context Route calls through clawproxy to emit gateway receipts; bundle receipts into a proof bundle tied to the job and policy hash
Overbroad provider access The agent can switch to a different provider or model class than expected WPC constrains allowed providers and models; enforce routing through clawproxy where model calls are receipted and policy context can be checked
Data exfiltration via allowed tools The agent sends sensitive data to external endpoints using legitimate tools Minimize tool surface area; require explicit tool-by-tool justification in the WPC; egress allowlists enforced outside clawproxy are planned or can be implemented as an enterprise buildout

Policy-as-code example

This is a compact example of how teams express “what is allowed” as a signed WPC and then bind execution to it. Keep it small and explicit, and treat every expansion as a reviewed change.

{
  "wpc_version": "1",
  "policy_name": "ops-triage-agent",
  "policy_intent": "Triage alerts, summarize logs, open a ticket",
  "constraints": {
    "tools": {
      "allow": ["read", "write", "http", "ticket_create"],
      "deny": ["exec", "process", "browser_control", "elevated_exec"]
    },
    "sandbox": {
      "mode": "all",
      "workspace_access": "ro"
    },
    "models": {
      "allowed_routes": ["openrouter_via_fal_via_clawproxy"],
      "deny_legacy": true
    },
    "data": {
      "max_classification": "internal",
      "redaction_required": true
    }
  },
  "token_binding": {
    "cst_scope_hash_required": true,
    "policy_hash_pinning": "required"
  }
}

In practice, the WPC is stored as a signed, hash-addressed artifact served by clawcontrols, and the run uses that policy hash as the binding reference. The CST is issued by clawscope with scope hash and optional policy hash pinning so a token cannot be reused under a different policy.

What proof do you get?

Claw EA is designed so you can answer two audit questions: what was permitted, and what occurred. You get both, and they are cryptographically linkable at the job level.

  • WPC reference: the hash-addressed WPC stored in the registry (served by clawcontrols), used as the canonical statement of allowed behavior for the run.

  • CST binding: a CST issued by clawscope with a scope hash, with optional policy hash pinning, so the token context matches the intended job and policy.

  • Gateway receipts: signed receipts emitted by clawproxy for each model call, suitable for later verification and correlation.

  • Proof bundle: a single harness artifact bundling receipts and related metadata for audit/verification, suitable for storage alongside the ticket, incident record, or run log.

  • Trust Pulse (optional storage/viewing): store the artifact in Trust Pulse so reviewers can view the run evidence without reassembling it from multiple systems.

Rollback posture

Controls are only useful if you can unwind changes safely after a bad run. Treat rollback as part of the control plane, with a defined evidence trail for what was reverted and why.

Action Safe rollback Evidence to retain
Policy change expands tool access Revert to prior WPC hash and redeploy agent config pinned to the earlier hash Old and new WPC hashes, change approval record, proof bundles from runs under each hash
Token misuse suspected Revoke the CST issuance path and rotate affected secrets; issue new job-scoped CSTs only CST issuance and revocation records (from clawscope) plus associated proof bundles
Unsafe model behavior observed Temporarily restrict allowed routes in the WPC; keep routing through clawproxy for receipts Gateway receipts around the incident window and the policy hash that governed the run
Sandbox escape concern Disable elevated paths and force sandbox “all” while investigating; reduce workspace mounts OpenClaw config diff, OpenClaw security audit output, and proof bundles for affected jobs

Automatic cost budget enforcement is planned or can be implemented, but do not treat it as a substitute for tool policy. Start by limiting what the agent can do, then meter and review what it did using receipts and proof bundles.

FAQ

Why is prompt-only control insufficient for enterprise agents?

Prompts are not enforcement. Once an agent can call tools, a single bad instruction can trigger real side effects unless the execution layer rejects the action.

Policy-as-code creates a deterministic allow/deny boundary, and the evidence (receipts and proof bundles) lets you verify compliance after the run.

How does this relate to OpenClaw tool policy and sandboxing?

OpenClaw provides local controls like sandboxing, tool policy, and elevated execution gates. Claw EA complements that with portable policy artifacts (WPC) and verifiable model-call evidence (gateway receipts and proof bundles).

What do we pin: the token, the policy, or both?

Pin both when you can. Use a job-scoped CST with a scope hash, and enable optional policy hash pinning so a token cannot be reused under a different WPC.

Can we use Microsoft Entra ID and Microsoft Graph with this?

Yes, typically by aligning job identity and approvals to Entra ID and using Microsoft Graph permissions/scopes for downstream access, via official API and enterprise buildout. Keep Graph scopes narrow, and use Conditional Access and PIM for privileged operations.

What is the minimum evidence package we should store per job?

Store the WPC hash reference, the CST context (job-scoped binding), and the proof bundle containing gateway receipts. That set is usually enough to reconstruct what was allowed and what model calls occurred.

Sources