Enterprise compliance for AI agents fails when “policy” lives only in prompts. Claw EA makes execution permissioned by enforcing policy-as-code for what tools can run, under which identities, and with verifiable evidence from each run.

OpenClaw is the baseline agent runtime, and Claw Bureau primitives (WPC, CST, gateway receipts, proof bundle) give you enforceable constraints plus audit-grade artifacts that can be reviewed after the fact.

Step-by-step runbook

  1. Define what the agent is allowed to do as a Work Policy Contract (WPC). Keep it narrow: specific tools, specific data classes, and explicit escalation paths for anything risky.

    Store the signed WPC in the WPC registry so it is hash-addressed and fetchable for verification.

  2. Issue a CST (scoped token) for the job from clawscope. Bind it to the job scope, and optionally pin the policy hash so the token is only valid under the intended WPC.

    This prevents “same token, different task” drift when agents get reused across workflows.

  3. Route model traffic through clawproxy. This produces gateway receipts for each model call so you can later prove what was sent and what came back, under which CST and policy context.

    If you use OpenRouter via fal, route it through clawproxy so the receipts are emitted consistently.

  4. Run the agent in OpenClaw with tool policy and sandboxing turned on for the right sessions. Use OpenClaw’s tool allow/deny controls to keep local execution tight, and use sandboxing to reduce the impact of mistakes.

    Do not rely on “the prompt says don’t do X” when X is a tool call or filesystem access.

  5. Collect a proof bundle after the job completes. The proof bundle bundles gateway receipts and run metadata into one harness artifact suitable for audit and verification.

    Store the proof bundle and, when you need a human-friendly view, publish the relevant artifact into Trust Pulse for audit viewing.

  6. Map the controls to your compliance target and evidence expectations. For SOC 2 Type II, focus on access control, change management of WPCs, and evidencing execution via receipts and proof bundles.

    For HIPAA and GDPR, focus on data minimization, redaction posture, and provable boundaries around where PHI or personal data can flow.

How to get started checklist: pick one agent workflow, write one WPC, enforce it via CST pinning, route model calls through clawproxy, and require a proof bundle as the only acceptable completion artifact for production runs.

Threat model

Compliance issues show up as concrete failure modes: a prompt-injected tool call, an agent using the wrong identity, or an unreviewable action path. Permissioned execution shifts the control point from “what the model claims” to “what the runtime allows.”

Threat What happens Control
Prompt injection triggers an unintended tool The agent follows adversarial instructions and calls a high-impact tool (shell, file write, data export). WPC defines tool allowlist; OpenClaw tool policy and sandboxing constrain local execution; CST scope hash ensures the job cannot “grow” permissions mid-run.
Policy drift across environments Dev policy differs from prod, but prompts and behaviors look similar, so mistakes ship. Use a hash-addressed WPC and optionally pin the policy hash in the CST so runs can be rejected if the wrong policy is loaded.
Model call disputes (who said what?) You cannot prove the prompts, tool arguments, or outputs that led to an action. Route calls through clawproxy to emit gateway receipts, then package them into a proof bundle for audits and incident response.
Token replay across jobs A token issued for one workflow gets reused to run a different workflow. Marketplace anti-replay binding with job-scoped CST binding reduces cross-job reuse risk, and policy hash pinning tightens it further.
Excessive autonomy and unclear boundaries The agent expands actions beyond the intended purpose, especially under vague prompts. Least privilege in WPC and CST scope design; separate “read-only” and “write” workflows into different policies and tokens.

Compliance mapping, operationally: SOC 2 Type II is mostly about repeatable controls and evidence, HIPAA is about protecting PHI and restricting disclosures, and GDPR is about lawful processing plus minimization and accountability. Claw EA focuses on controlling and proving execution, not just documenting intent.

Common subtopics this hub covers: SOC 2 Type II (control effectiveness evidence), HIPAA (PHI boundaries), GDPR (data minimization and accountability), FedRAMP (evidence discipline and boundary definition), ISO 27001 (risk treatment and operational control), vendor risk reviews (repeatable questionnaires plus proof), incident response (reconstructing actions), and change control (WPC lifecycle).

Policy-as-code example

Prompt text is not enforceable. A WPC is policy-as-code that the execution layer can fetch and verify, and the CST can optionally pin by hash so the agent cannot silently switch policies.

{
  "wpc_version": "v1",
  "policy_hash": "b64u:...",
  "job": {
    "purpose": "support_ticket_triage",
    "data_classification": ["internal", "pii_limited"]
  },
  "tools": {
    "allow": [
      {"name": "ticket.read", "constraints": {"project": "SUPPORT"}},
      {"name": "ticket.comment", "constraints": {"max_chars": 1200}},
      {"name": "kb.search", "constraints": {"sources": ["approved_kb"]}}
    ],
    "deny": [
      {"name": "shell.exec"},
      {"name": "file.write"},
      {"name": "email.send"}
    ]
  },
  "model_routing": {
    "require_proxy_receipts": true,
    "provider": "openrouter_via_fal"
  },
  "token": {
    "require_cst_scope_hash": true,
    "optional_pin_policy_hash": true,
    "job_scoped_binding": true
  },
  "audit": {
    "require_proof_bundle": true,
    "publish_to_trust_pulse": "on_release"
  }
}

This style forces an explicit decision: if you want email sending or file writes, you add them to policy, assign a narrower CST, and accept the audit footprint. That is the difference between permissioned execution and prompt-only control.

What proof do you get?

Every model call routed through clawproxy yields gateway receipts. Those receipts are designed to be machine-verifiable evidence that a specific request/response occurred under a specific CST and policy context.

A proof bundle is the run artifact that packages receipts plus related metadata so audits are not a pile of logs. When you need a durable audit view, you can store and view a Trust Pulse artifact, keeping evidence review separate from the runtime.

In practice, this means you can answer: which policy was in force (WPC hash), which token scope was used (CST scope hash and any pinning), what model calls happened (gateway receipts), and which run produced the output (proof bundle identifier and metadata).

Rollback posture

Agent rollbacks need to be fast and boring. Permissioned execution helps because the primary rollback is often “tighten policy and re-issue tokens,” not “rewrite prompts and hope.”

Action Safe rollback Evidence
Agent starts taking unexpected actions Revoke CST issuance for the workflow, then issue a new CST with narrower scope and policy hash pinning. CST issuance and revocation trail plus proof bundle showing the last known-good run.
Suspected prompt injection via an external channel Disable the risky tools in WPC, keep read-only tools, and force sandboxed execution for non-main sessions in OpenClaw. Updated WPC hash, and gateway receipts showing tool and model behavior before and after the change.
Compliance scope changes (PII allowed becomes not allowed) Split policy into two WPCs (PII-free default, PII-approved exception) and require different CSTs per workflow. Proof bundles for each run, with policy hashes demonstrating which rules applied.
Provider dispute or incident review Quarantine outputs, freeze the proof bundle set for the incident window, and verify receipts for the relevant jobs. Gateway receipts and proof bundles suitable for independent verification.
Need tighter outbound controls Egress allowlists enforced outside clawproxy can be implemented as an environment control if required by policy. Documented boundary and network control evidence (implementation-dependent).

FAQ

Why isn’t a “do not exfiltrate data” prompt enough?

Prompts are not enforcement and are not stable under adversarial input. Compliance needs hard boundaries: tool allow/deny, scoped identity via CST, and evidence via gateway receipts and proof bundles.

How does this help with SOC 2 Type II evidence?

SOC 2 Type II asks whether controls are operating over time. WPCs give you a controlled, hash-addressed policy artifact, and proof bundles plus gateway receipts provide repeatable evidence that runs followed the intended execution path.

What changes for HIPAA workflows?

You treat PHI as a distinct data class with tighter WPC constraints and narrower CST scopes. You also design workflows so PHI handling is explicit and produces proof bundles that can be audited for disclosures and access patterns.

What changes for GDPR workflows?

You separate lawful processing purposes into distinct WPCs and keep default policies data-minimal. Proof bundles support accountability by showing which policy was in force and what model calls occurred for a given processing purpose.

Can we use Microsoft controls like Entra ID and Purview with this?

Yes, typically via official API or via an MCP server in an enterprise buildout. Use Microsoft terminology and boundaries: Entra ID identities, Microsoft Graph permissions/scopes, Conditional Access, and PIM for access governance, and use Purview guidance for managing compliance for AI interactions.

Sources