Enterprise agent workflows fail when “safety” lives only in prompts. Claw EA treats execution as a permissioned system: a Work Policy Contract (WPC) is the machine-enforced contract, a CST is the scoped token that binds a job to that policy, and model calls produce gateway receipts for later verification.

OpenClaw is the baseline agent runtime: it already has tool allow/deny profiles and optional Docker sandboxing, which you can pair with Claw Bureau primitives to get auditable, repeatable workflows. The goal is not to make agents smarter, it is to make their actions bounded, attributable, and reversible.

This hub covers the operational building blocks for “enterprise agent workflows” where security teams can answer: what was allowed, what actually happened, and what you can roll back quickly.

Workflow taxonomy (what teams usually standardize):

  • Production deploy with tool sandboxing: Run OpenClaw tools in Docker to reduce filesystem and process blast radius.
  • Permissioned tool access: Convert “agent can do X” into a WPC that can be fetched and verified before execution.
  • Model access control with receipts: Route model traffic through clawproxy so each call yields gateway receipts.
  • Job-scoped identity: Issue a CST per job, with a scope hash and optional policy hash pinning to prevent policy drift.
  • Secrets and credentials hygiene: Keep secrets out of prompts and logs; scope what the runtime can read.
  • High-risk action approvals: Add a human gate for actions like payments or user provisioning (can be implemented).
  • Audit and verification: Package gateway receipts into a proof bundle and store/share via Trust Pulse.
  • Incident response and rollback: Revoke CSTs, revert to a known-good WPC hash, and tighten OpenClaw tool policy.

How to get started checklist:

  • Pick one workflow and define “allowed tools, allowed model route, allowed data boundaries.”
  • Write and publish a WPC in clawcontrols and keep the hash in your change record.
  • Issue a CST from clawscope per job, with policy hash pinning where appropriate.
  • Run OpenClaw with tight tool policy and sandboxing, and route model calls through clawproxy.
  • Require proof bundles for promotion to production and store them in Trust Pulse.

Step-by-step runbook

  1. Define the workflow boundary. Write down the exact tools the agent may use (read/write/exec/browser) and what “done” means. If the workflow touches Microsoft systems, define the Microsoft Graph permissions/scopes you expect the integration to use, and gate access through Entra ID and Conditional Access where applicable (via official API or enterprise buildout).

  2. Create a WPC for the job type. Put tool allow/deny, model routing requirements, and any required human gates into the WPC, then publish it to clawcontrols. Treat the WPC hash as the immutable identifier, and reference that hash in your deployment and ticketing flow.

  3. Issue a CST bound to the job. Use clawscope to mint a CST with a scope hash that matches the job’s permitted actions, and optionally pin the WPC hash in the token claims. Use short TTLs for interactive workflows, and mint new CSTs for retries rather than reusing old ones.

  4. Configure OpenClaw defensively. Use OpenClaw tool policy (profiles plus allow/deny) to match the WPC intent, and enable Docker sandboxing for tools when possible. Run openclaw security audit regularly to catch configuration footguns around auth exposure, tool blast radius, and filesystem permissions.

  5. Route model traffic through clawproxy. Ensure the OpenClaw provider path sends model calls through clawproxy so you get gateway receipts for each call. If you use OpenRouter via fal, route that through clawproxy as well so the same receipt semantics apply.

  6. Collect and verify the proof bundle. At the end of the run, export the proof bundle that includes gateway receipts plus job metadata, then verify it in your audit workflow. Store the resulting artifact in Trust Pulse for later viewing and cross-team review.

Threat model

Threat What happens Control
Prompt injection triggers dangerous tools The model tries to turn untrusted content into file writes, shell exec, or browser actions. OpenClaw tool policy allow/deny plus Docker sandboxing; WPC defines permitted tools and denies “escape hatch” behaviors by default.
Policy drift between staging and prod A run uses broader permissions than the reviewer intended because configs changed. WPC is hash-addressed; CST can optionally pin the policy hash so the job fails closed if the policy is not the expected one.
Token replay across jobs An attacker reuses a token from one job to run another job or re-run the same job later. Marketplace anti-replay binding with job-scoped CST binding; keep CST TTLs short and issue per-job tokens.
Unreceipted model calls A component calls a model directly, bypassing auditability, and you cannot prove what was asked or returned. Route model calls through clawproxy to generate gateway receipts; treat “no receipts” as an invalid production run.
Sandbox boundary pierced by mounts or elevated exec Accidental bind mounts or elevated execution expose host filesystem or control surfaces. Prefer read-only mounts; avoid elevated execution unless explicitly justified; use OpenClaw sandbox explain and security audit to spot risky settings.
Over-permissioned Microsoft access An agent gets broad Graph scopes and can read or modify more than intended. Minimize Microsoft Graph permissions/scopes; use Entra ID Conditional Access and PIM where applicable; keep these permissions out of prompts and enforce via official API or enterprise buildout.

Policy-as-code example

This is an illustrative, JSON-like WPC shape to show how teams encode execution permissions. The point is determinism: reviewers can diff it, operators can pin it by hash, and jobs can fail closed if the contract is not the one you approved.

{
  "wpc_version": "v1",
  "purpose": "Invoice triage and draft response",
  "tool_policy": {
    "allow": ["read", "write", "http", "browser"],
    "deny": ["exec", "process", "elevated"]
  },
  "sandbox_expectations": {
    "tools_run_in_sandbox": true,
    "workspace_access": "ro"
  },
  "model_route": {
    "require_clawproxy": true,
    "allowed": ["OpenRouter_via_fal"]
  },
  "token_requirements": {
    "cst_ttl_seconds_max": 1800,
    "require_scope_hash": true,
    "policy_hash_pinning": "optional"
  },
  "approvals": {
    "required_for": ["external_send", "user_provisioning"],
    "status": "can be implemented"
  },
  "audit": {
    "require_gateway_receipts": true,
    "require_proof_bundle": true
  }
}

In practice you also map this to OpenClaw configuration: tool profiles, allow/deny lists, and sandbox mode. The WPC is the contract; OpenClaw settings are the local enforcement layer that should match it.

What proof do you get?

For production workflows, “logs” are not enough because they are easy to miss, redact incorrectly, or tamper with after an incident. Claw EA focuses on proof you can verify independently and attach to a ticket, incident, or audit package.

  • Gateway receipts: signed receipts emitted by clawproxy for model calls, so you can prove which calls were made through the approved gateway.
  • Proof bundle: a harness artifact bundling receipts and related metadata for audit and verification, including policy identifiers and job context needed for review.
  • CST binding signals: evidence that the run used the intended CST (scoped token) and respected job-scoped anti-replay binding.
  • Trust Pulse: marketplace-stored artifact storage/viewer to share proof bundles with auditors and stakeholders without emailing attachments around.

Rollback posture

Action Safe rollback Evidence to check
Stop an in-flight workflow Revoke the CST in clawscope and require a fresh CST for retries. Token revocation record plus proof bundle showing which calls completed before revocation.
Undo a permission expansion Revert to a prior WPC hash and re-issue CSTs with policy hash pinning to that hash. WPC hash history in your change record; proof bundles for runs before and after the revert.
Contain tool abuse Tighten OpenClaw tool allow/deny and increase sandboxing scope (for example, sandbox all sessions). OpenClaw security audit output and sandbox explain output for the affected agent sessions.
Contain model-route bypass Require clawproxy routing for production runs and reject runs without gateway receipts. Presence of gateway receipts in the proof bundle; absence is a policy violation.
Clamp network exposure Reduce inbound surfaces and tighten OpenClaw channel policies; egress allowlists can be implemented outside clawproxy (optional). Updated OpenClaw security audit results; WPC revision notes describing the new boundary.

Automatic cost budget enforcement is planned in some deployments, but you should not rely on it as your primary safety boundary today. Make “what can run” and “what must be receipted” the default controls, then add budgets as a secondary guardrail when available.

FAQ

Why is policy-as-code required instead of just prompting the agent to behave?

Prompts are not a permission system because they do not constrain tool availability, token scope, or network routes. A WPC plus CST makes the boundary machine-checkable, and it gives you a stable artifact you can review, diff, and pin by hash.

How does this relate to OpenClaw’s tool policy and sandboxing?

OpenClaw enforces the local boundary: which tools exist and whether tool execution runs on the host or in Docker. Claw EA adds remote authorization and audit primitives so the same workflow can be repeated across environments with verifiable receipts.

What do I require for a workflow to be considered “production”?

At minimum: a published WPC, a per-job CST with scope hash, and model calls routed through clawproxy so you get gateway receipts. Then require a proof bundle for every run and store it in Trust Pulse for review.

Can we integrate with Microsoft systems like Entra ID and Microsoft Graph?

Yes, typically via official API or via MCP server, with an enterprise buildout when you need strict controls. Keep Graph permissions/scopes minimal, and use Entra ID controls like Conditional Access and PIM where applicable.

What if we need strict egress control or hard spend caps?

Egress allowlists enforced outside clawproxy are optional and can be implemented, depending on your environment. Automatic cost budget enforcement is planned, so treat it as an add-on rather than a core safety mechanism today.

Sources