This page defines the security and policy terms teams use when they run enterprise AI agents, with OpenClaw as the baseline agent runtime. The focus is on permissioned execution: machine-enforced policy-as-code that constrains tools, tokens, and model traffic, instead of relying on prompt instructions that can be bypassed.

Claw EA applies this by binding runs to a WPC (Work Policy Contract), authenticating components with CST (scoped token), and producing gateway receipts and proof bundles so you can verify what actually happened after the fact.

Step-by-step runbook

Use this runbook when you need a shared language across security, platform engineering, and compliance. It is also a practical checklist for setting up a controlled agent execution path.

  1. Define the work boundary. Write down what the agent is allowed to do, what it must never do, and what data classes it can touch. Convert that into a WPC so policy is a signed, hash-addressed artifact instead of a wiki page.

  2. Bind identity and scope to the job. Issue a CST (scoped token) for the agent job, and keep its scope minimal for the tools and services required. Where appropriate, pin the CST to a specific policy hash so the run cannot silently “upgrade” its permissions.

  3. Constrain tool execution locally. In OpenClaw, set tool allow/deny profiles and decide where tools run (Docker sandbox vs host) so the local blast radius is bounded even if the model is tricked. Run the OpenClaw security audit regularly, especially after config or plugin changes.

  4. Receipt model calls. Route model traffic through clawproxy so you get gateway receipts for each model call. Treat receipts as evidence, not logs, and ensure your operations workflow knows how to retrieve and store them.

  5. Package evidence for review. Produce a proof bundle at the end of the run so audit and incident response can verify constraints, model calls, and metadata without scraping multiple systems. If you need centralized viewing, store the artifact as a Trust Pulse.

  6. Operationalize “stop the bleeding”. Decide ahead of time which switches you can pull during an incident: disabling tools, rotating CST issuance, and forcing policy hash changes. Make sure the on-call path can execute these changes without editing prompts or redeploying the whole runtime.

How to get started checklist:

  • Pick one agent workflow and write a first-cut WPC for it (tools, data, approvals, time limits).
  • Run OpenClaw in sandbox mode for that workflow and tighten tool policy until it still works.
  • Enable clawproxy in the model path so every call emits gateway receipts.
  • Require CST per job, not a long-lived token shared across agents.
  • Make “proof bundle required” a release gate for production agent runs.

Threat model

Enterprise agents fail in repeatable ways: they take actions outside intent, they leak data, or they become hard to audit after an incident. Prompt-only controls are not stable under adversarial input because the same channel that carries instructions also carries attacks.

Permissioned execution moves control into the execution layer: WPC defines allowed actions, CST gates access at call time, and gateway receipts plus proof bundles give you verifiable records.

Threat What happens Control you want in place
Prompt injection into tool use An attacker convinces the agent to call a sensitive tool (shell, file write, browser automation) using malicious inputs. OpenClaw tool policy allow/deny and sandboxing to reduce blast radius, plus a WPC that explicitly enumerates allowed tool classes for the job.
Scope creep across runs A token or config intended for one workflow is reused, granting broader access than expected in later jobs. Per-job CST issuance and marketplace anti-replay binding (job-scoped CST binding). Optionally pin CST to a policy hash so the run’s authority is tied to a specific WPC.
Unverifiable model behavior after incident You cannot prove which model calls occurred, with what inputs/outputs, or whether traffic bypassed controls. Route model calls through clawproxy to emit gateway receipts, then package them into a proof bundle for audit and verification.
Hidden plugin or config drift An operator changes a plugin, tool profile, or sandbox mode and unintentionally exposes new capabilities. Run OpenClaw security audit and review effective sandbox and tool policy settings. Treat WPC updates as controlled change with signed artifacts that are fetched and verified.
Over-broad external data access The agent can pull or exfiltrate sensitive data because network and tool permissions were not bounded. Use policy-as-code to restrict which tools can access which data classes and require approvals for high-risk actions. Egress allowlists enforced outside clawproxy can be implemented as an additional layer (optional).

Policy-as-code example

A policy is useful only if it is enforceable and reviewable. A WPC (Work Policy Contract) is a signed, hash-addressed policy artifact served by clawcontrols, designed to be fetched and verified rather than copied into prompts.

Below is a JSON-like example showing the intent you should capture; treat field names as illustrative and adapt to your internal policy conventions.

{
  "policy_name": "invoice-triage-prod",
  "policy_hash": "b64u:...hash...",
  "allowed_tools": [
    "read_only_repo",
    "ticket_comment",
    "model_call_via_clawproxy"
  ],
  "denied_tools": [
    "shell_exec",
    "write_filesystem",
    "browser_remote_control"
  ],
  "data_classes_allowed": ["internal", "confidential"],
  "data_classes_denied": ["regulated_pii"],
  "approvals": [
    { "action": "send_external_email", "required": true }
  ],
  "token_requirements": {
    "require_cst": true,
    "pin_cst_to_policy_hash": true,
    "max_ttl_minutes": 30
  },
  "evidence_requirements": {
    "require_gateway_receipts": true,
    "require_proof_bundle": true
  }
}

The key idea is separation of concerns: prompts explain how to do the work, while the execution layer decides what is permitted. If the model is manipulated, the policy still blocks forbidden tool calls and forces evidence capture.

What proof do you get?

Claw EA produces evidence designed for verification workflows. You should assume the question after any incident will be: “Show me exactly what the agent did, and prove it ran under the intended constraints.”

  • Gateway receipts. Signed receipts emitted by clawproxy for model calls. Use these to verify that model traffic went through the approved gateway and to correlate calls to a specific job context.

  • Proof bundle. A harness artifact bundling receipts and related metadata for audit/verification. This is the unit you can hand to another team for review without giving them access to your runtime.

  • Trust Pulse. A marketplace-stored artifact for audit/viewing. Use it when you want a durable place to view and share the evidence, separate from operational logs.

  • WPC linkage. Runs can reference a WPC by hash, so reviewers can confirm which policy was intended. When paired with CST policy hash pinning, the run’s authority and its declared policy stay aligned.

Rollback posture

Rollback for agent systems is not just “deploy the previous version.” You need a posture that safely stops actions, constrains further access, and preserves evidence so you can understand impact.

Action Safe rollback Evidence you keep
Suspected prompt injection in a live channel Disable or deny the affected tool set via policy, and force subsequent runs to use a tighter WPC hash. Keep the agent online only in read-only or no-tool mode until review is complete. Gateway receipts for the suspect model calls and a proof bundle for the job window.
Token exposure or misuse Revoke and re-issue CST for the job, and stop accepting long-lived tokens for agent execution. Require job-scoped CST binding to prevent replay in other jobs. Token issuance and job metadata references inside the proof bundle (plus receipts for calls made with the exposed token).
Unexpected tool capability discovered Tighten OpenClaw tool policy (deny list or profile change) and, if needed, move execution into sandbox mode for that agent. Re-run OpenClaw security audit and record the configuration delta. Proof bundle plus the before/after policy hashes and the OpenClaw audit output in your change record.
Model route bypass suspected Force model calls through clawproxy only, and treat any direct-to-vendor model path as non-compliant for production. Require “proof bundle required” for job completion. Gateway receipts provide the verification anchor that traffic took the intended path.

If you need network-level containment, egress allowlists enforced outside clawproxy can be implemented as an additional control (optional). Keep that change separate from application logic so rollback is fast and predictable.

FAQ

Why is prompt-only control not enough for enterprise agents?

Prompts are part of the same input stream an attacker can manipulate. Policy-as-code puts the decision in the execution layer, so forbidden tool calls fail even when the model is persuaded to attempt them.

How do WPC and CST relate during a run?

A WPC defines what is allowed, and a CST is the credential the runtime presents when it tries to do work. With optional policy hash pinning, the CST can be tied to a specific WPC hash so scope and policy cannot drift mid-run.

What is the practical value of gateway receipts?

They let you verify that model calls went through clawproxy and were associated with a specific job context. This reduces ambiguity during incident response, vendor escalation, and internal audits.

How does OpenClaw fit into this glossary?

OpenClaw is the baseline agent runtime where tool policy and sandboxing are enforced locally. Claw EA complements that with portable policy artifacts (WPC), job-scoped authorization (CST), and verifiable evidence (gateway receipts and proof bundles).

Does this replace Microsoft Purview or other compliance tooling?

No. Treat it as execution control and evidence capture for agent runs, which can complement broader compliance and data governance programs.

Sources