Secure agent execution means the agent can only act through a permissioned runtime that enforces machine-checkable rules, not just “be careful” instructions in a prompt. OpenClaw is a strong baseline agent runtime, and Claw EA layers policy binding, scoped authorization, and verifiable receipts so you can prove what the agent was allowed to do and what it actually did.

Prompt-only controls fail because an attacker can steer the model around them, or a benign mistake can still trigger an unsafe tool call. A permissioned execution layer uses policy-as-code plus fail-closed verification so the agent cannot exceed the allowed tool surface, token scope, or policy hash.

Step-by-step runbook

Use this runbook when you want enterprise AI agents that can run jobs with auditable boundaries and predictable rollback. The steps assume OpenClaw runs the agent and Claw Bureau primitives provide the enforcement and evidence.

  1. Start with a minimal OpenClaw tool surface. Enable sandboxing for tool execution where possible, and explicitly set tool allow and deny rules per agent. Run the built-in OpenClaw security audit regularly, especially after config changes or when exposing new inbound channels.

  2. Write a WPC and publish it. A WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols). Treat the WPC hash as a release artifact: reviewed, change-controlled, and referenced by job configuration.

  3. Issue a CST for the job and pin policy if needed. A CST = scoped token (issued by clawscope). Use a job-scoped CST and, when you need strict change control, pin the policy hash so the runtime fails closed if the policy changes.

  4. Route model calls through clawproxy for receipts. Gateway receipts are signed receipts emitted by clawproxy for model calls, giving you verifiable evidence of what was sent to and returned by the model. If you use OpenRouter via fal, route that traffic through clawproxy so the same receipt mechanism applies.

  5. Execute jobs under the permissioned runtime. Enforce tool policy in OpenClaw (what tools exist) and sandboxing (where tools run), then bind remote calls to the CST and WPC constraints. Avoid “prompt grants” like “you may access production” without a corresponding policy rule and scoped token.

  6. Collect a proof bundle and verify it. A proof bundle is a harness artifact bundling receipts and related metadata for audit/verification. Store the bundle per job and verify it during incident review, vendor review, or deployment promotion gates.

  7. Operationalize change and incident controls. Rotate CST issuance policies, keep WPC changes in a controlled pipeline, and review OpenClaw sandbox and bind mounts as part of every change window. If you need enterprise identity alignment (for example, Entra ID user and app identity), integrate via official API or an MCP server and keep Graph permissions minimal and explicit.

Threat model

Enterprise AI agents fail in predictable ways: prompt injection, excessive tool permissions, leaked tokens, and silent drift in configuration. Secure execution is about forcing those failures to become blocked requests with evidence, not “best effort” behavior.

Threat What happens Control (fail-closed when possible)
Prompt injection triggers high-impact tools The model is persuaded to run shell, write files, or call external systems beyond the intended workflow. OpenClaw tool policy allowlists and sandboxing reduce blast radius; WPC defines what is allowed; CST scope constrains what remote services accept even if the model asks.
Misconfigured inbound access (open rooms, weak auth) Untrusted users can trigger the agent and drive it toward unsafe tool calls or data exposure. Use OpenClaw security audit to catch common footguns; require allowlists and mention gates where appropriate; keep high-risk agents off public channels.
Token leakage or over-broad scopes A leaked token becomes a standing capability that can be reused to call tools or model providers. Issue job-scoped CST; keep TTL short; use scope hashes and optional policy hash pinning so tokens cannot be reused outside the intended policy context.
Replay of a prior “approved” job An attacker replays a previously valid request pattern to get the same effect again. Marketplace anti-replay binding (job-scoped CST binding) prevents reuse across jobs; store proof bundles per job so you can detect duplicates and drift.
Sandbox pierced by unsafe mounts or elevated exec A containerized tool gains host-level control via bind mounts, sensitive directories, or elevated tool escape hatches. Prefer workspaceAccess=none/ro, avoid docker.sock mounts, and tightly gate elevated tools; use OpenClaw “sandbox explain” and configuration reviews to validate effective policy.
Disputed model calls and “who said what?” You cannot prove what prompt or response led to an action, or whether content was altered in transit. Route model calls via clawproxy to obtain gateway receipts; package them into a proof bundle for later verification and audit.

Policy-as-code example

A permissioned runtime needs rules the system can enforce without trusting the model’s intentions. In practice, that means a WPC that the runtime can fetch and verify by hash, plus a CST whose scope and optional policy hash pinning match the job.

The snippet below is JSON-like and intentionally compact. It shows a policy that limits tool categories, blocks elevated execution, and requires model calls to be receipted through clawproxy.

{
  "wpc_version": "v1",
  "policy_hash": "b64u:... (hash-addressed)",
  "job": {
    "id": "job-2026-02-11-001",
    "anti_replay": { "bind_job_scoped_cst": true }
  },
  "tools": {
    "allow": ["read", "write:workspace", "http:approved_hosts"],
    "deny": ["exec", "process", "docker_socket", "browser:host_control"],
    "elevated": { "enabled": false }
  },
  "models": {
    "require_gateway_receipts": true,
    "route_via": ["clawproxy"],
    "providers": ["openrouter_via_fal"]
  },
  "tokens": {
    "require_cst": true,
    "cst_scope_hash": "b64u:...",
    "pin_wpc_hash": true
  }
}

What proof do you get?

For every model call routed through clawproxy, you get gateway receipts: signed receipts emitted by clawproxy for model calls. These receipts are designed to be verifiable artifacts you can tie back to a job run, the active CST constraints, and the policy hash you intended.

Claw EA packages receipts and related job metadata into a proof bundle. The proof bundle is what you archive, hand to internal audit, attach to a change ticket, or use in post-incident review to validate what happened without relying on ad hoc logs.

When you need a durable place to store and view audit artifacts, you can store the result as a Trust Pulse artifact for audit/viewing. Retention is an operational decision: many teams keep proof bundles for the same duration as CI logs for low-risk jobs, and longer for production-impacting automations.

Rollback posture

Rollback for agents is not just “turn it off.” You want a small set of deterministic levers that stop execution safely, prevent repeats, and preserve evidence for triage.

Action Safe rollback Evidence to capture
Stop new work immediately Revoke or expire the CST for the job so calls fail closed at the boundary. CST issuance and revocation records; job id and timestamps.
Freeze permissions at last known-good Pin the policy hash to the previous reviewed WPC and reject runs with newer hashes until reviewed. WPC hash used per job; diff of policy artifacts in your change system.
Reduce local blast radius Disable elevated tools and tighten OpenClaw tool allowlists and sandbox mounts, then re-run “security audit” and “sandbox explain.” OpenClaw audit output, effective sandbox configuration, and updated tool policy state.
Dispute or investigate a specific run Quarantine the proof bundle and verify receipts to confirm the exact model calls that occurred. Proof bundle, gateway receipts, and verification results from your review process.
Prevent replay and “same job again” Require job-scoped CST binding for future runs of that workflow and rotate any long-lived credentials used by tools. Job scoping configuration, rotated secret references, and a record of scope changes.

FAQ

Why is prompt-only safety not enough?

A prompt is not an enforcement point. If the model is manipulated or simply makes a mistake, it can still call tools unless the runtime blocks the call based on policy-as-code and scoped authorization.

How do WPC and CST work together in a permissioned runtime?

The WPC defines what is allowed in a portable, signed, hash-addressed artifact. The CST is the job’s scoped token, and its scope hash and optional policy hash pinning ensure the job cannot quietly run under different permissions.

What do gateway receipts cover, and what do they not cover?

Gateway receipts cover model calls routed through clawproxy, including verifiable evidence that a specific request and response occurred under the proxy boundary. They do not automatically prove what happened inside third-party systems your tools call, unless those systems provide their own verifiable logs via official API or an MCP server.

How does this relate to Microsoft enterprise controls like Entra ID and Conditional Access?

Use Entra ID for identity, apply least-privilege Microsoft Graph permissions/scopes for any agent-operated app registration, and rely on Conditional Access and PIM to limit standing access. Claw EA focuses on execution constraints and verifiable evidence; identity integration can be implemented via official API as part of an enterprise buildout.

Can we enforce network egress allowlists and cost budgets?

Egress allowlists enforced outside clawproxy and automatic cost budget enforcement are optional or planned capabilities. If you need them now, they can be implemented with existing network controls and job orchestration policies, while still using WPC, CST, receipts, and proof bundles for auditable execution.

Sources