MCP (Model Context Protocol) is a standard way to expose tools and context to an agent, but in enterprise environments MCP alone is not a security boundary. Claw EA treats MCP as a tool transport and adds permissioned execution around it using WPC (Work Policy Contract), CST (scoped token), gateway receipts, and proof bundles.
OpenClaw is the baseline agent runtime: it runs the agent, loads tools, and can sandbox tool execution. Claw EA focuses on making MCP tool use verifiable and constrained by policy-as-code instead of relying on prompt-only instructions.
Step-by-step runbook
This runbook assumes you already have an MCP server (vendor-hosted, self-hosted, or an internal service exposed via MCP server). The goal is to make every MCP tool call auditable and tied to an explicit policy artifact.
-
Inventory MCP tools and classify them. List each tool, its data access, and its side effects (read-only lookup vs write vs money movement). Decide which tools must be blocked by default until reviewed.
-
Author a WPC for the job type. Write a Work Policy Contract (WPC) that names which MCP tools are allowed, which arguments are constrained, and what data classes are permitted. Store the signed, hash-addressed WPC in the WPC registry (served by clawcontrols).
-
Issue a CST bound to the WPC. Use clawscope to issue a CST (scoped token) that includes a scope hash and, when you want fail-closed behavior, policy hash pinning to the WPC. This makes “correct policy, correct token” a machine check, not a prompt suggestion.
-
Route model traffic through clawproxy for receipts. Configure the agent so model calls are routed through clawproxy, which emits gateway receipts for model calls. If you use OpenRouter via fal, keep it routed through clawproxy so you still get receipts.
-
Run the agent with OpenClaw tool policy and sandboxing. Use OpenClaw tool allow/deny lists and sandbox configuration to reduce local blast radius. Treat MCP tools as “external capabilities” and still keep local exec and file tools tightly gated.
-
Collect the proof bundle and publish what you need. After each run, export a proof bundle that includes gateway receipts and metadata needed for verification. Optionally store a Trust Pulse artifact for reviewers and auditors to view.
Threat model
MCP introduces a clean interface for tools, but the main enterprise risk is not the protocol itself. The risk is unpermissioned execution: an agent can be induced to call tools with unsafe parameters, against the wrong tenant, or at the wrong time.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection into MCP tool calls | The agent is coerced into calling a sensitive MCP tool (or a safe tool with unsafe arguments) after seeing untrusted content. | Enforce allowlists and argument constraints in WPC (policy-as-code). Pair with OpenClaw tool policy so only approved tools exist at runtime. |
| Confused deputy across identities | The agent uses a high-privilege credential to serve a lower-privilege request, or crosses tenant boundaries. | Use CST scoping and optional policy hash pinning so the token is only valid for the intended job policy. Keep identity separation per agent or per job, not per prompt. |
| Tool substitution or server swap | An operator or attacker points the agent at a different MCP server that implements the same tool names but different behavior. | Bind runs to a specific WPC and record the tool endpoint metadata inside the proof bundle. Make “approved server list” part of policy review (can be implemented via MCP server governance). |
| Undetected model-side changes | A model call produces unexpected tool selection or parameterization, and you cannot reconstruct why it happened. | Gateway receipts from clawproxy provide signed evidence of model calls. Proof bundles package receipts with run metadata for later verification. |
| Local host compromise via tool execution | If the agent can execute shell or modify files, a single bad action can change the host or exfiltrate secrets. | Use OpenClaw sandboxing to move tool execution into Docker where appropriate, and avoid elevated tool modes except when explicitly required. |
| Replay of prior approvals or tokens | A previously valid token is reused to run an unapproved job, or the same “approved action” is executed twice. | Marketplace anti-replay binding (job-scoped CST binding) reduces replay risk by tying authorization to a job context. Preserve proof bundles so replay investigations have concrete evidence. |
Why policy-as-code and not prompt-only: a prompt can ask the model to “only use Tool A,” but the model can still be induced to ignore that instruction. A WPC is a signed artifact that the execution layer can verify and enforce, even when the model is wrong or manipulated.
If your MCP tools touch Microsoft systems, treat the identity plane as part of the threat model. Use Entra ID app registrations and explicit Microsoft Graph permissions/scopes, and consider Conditional Access and PIM for administrative paths; enforcement happens in Microsoft and your MCP server, not in the prompt.
Policy-as-code example
This is a simplified, JSON-like sketch of what teams typically capture in a WPC for MCP tool use. The key is that the WPC is signed and hash-addressed, and the run can be pinned to its policy hash.
{
"wpc_version": "v1",
"policy_name": "mcp-enterprise-agent-baseline",
"allowed_tools": [
{
"tool": "mcp://crm/search_accounts",
"constraints": {
"tenant": "contoso",
"fields_allowlist": ["id", "name", "status"],
"max_results": 25
}
},
{
"tool": "mcp://tickets/create",
"constraints": {
"project_allowlist": ["IT-HELPDESK"],
"priority_allowlist": ["low", "medium"],
"no_secrets_in_description": true
}
}
],
"deny_tools": [
"mcp://payments/*",
"mcp://admin/*"
],
"model_routing": {
"require_clawproxy_receipts": true
},
"token_requirements": {
"require_cst_scope_hash": true,
"policy_hash_pinning": "optional"
}
}
Operationally, you use this WPC to drive two checks: can the tool be called at all, and do the arguments match constraints. When policy hash pinning is enabled, a CST that is not tied to this WPC will fail closed.
What proof do you get?
Claw EA produces evidence you can hand to security and compliance without asking them to “trust the prompt.” You get gateway receipts (signed receipts emitted by clawproxy for model calls) and a proof bundle (a harness artifact bundling receipts and related metadata for audit/verification).
In practice, that means you can answer: which model was called, when, with what request metadata, and which run that call belonged to. For workflows that need a reviewer-friendly artifact, you can store a Trust Pulse so auditors can view the run evidence in a consistent place.
-
Gateway receipts: signed evidence of model calls routed through clawproxy.
-
Proof bundle: package of receipts plus run metadata (policy references, token binding context, and other verification inputs).
-
WPC references: a hash-addressed pointer to the exact Work Policy Contract used for the run, fetched and verified from the WPC registry.
-
CST binding signals: scope hash and optional policy hash pinning details, so you can show the run was authorized under a specific policy context.
Rollback posture
MCP adoption often starts with “add tools quickly,” but enterprise rollback needs to be mechanical. You want a small number of levers that can disable capabilities without editing prompts or redeploying every agent.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop a risky MCP tool across all agents | Update the WPC to deny the tool and require policy hash pinning for new CST issuance. | WPC hash change plus proof bundles showing which runs used which policy hash. |
| Reduce scope for a job type | Issue new CSTs with narrower scope hash; rotate short TTL CSTs and stop minting old scopes. | CST issuance and revocation records, and proof bundles tied to the new CST scope hash. |
| Cut off unreceipted model calls | Enforce “require clawproxy receipts” at the routing layer; runs without gateway receipts fail compliance review. | Presence or absence of gateway receipts in the proof bundle. |
| Contain host impact | Switch OpenClaw sessions to sandboxed execution and tighten tool allowlists; avoid elevated tools. | OpenClaw configuration diffs plus audit output from the OpenClaw security audit process. |
Some rollback levers are environment-specific, like network egress allowlists outside clawproxy. Those controls are optional and can be implemented, but you should not rely on them as your only containment.
FAQ
What is MCP and what does it change for enterprise agents?
MCP standardizes how an agent discovers and calls tools exposed by an MCP server. For enterprises, the change is that tool surface area expands quickly, so you need policy and evidence around tool calls, not just a client SDK.
Why is prompt-only governance insufficient for MCP tool security?
Prompts are advisory and can be overridden by injection, tool descriptions, or model behavior. Policy-as-code via a signed WPC lets the execution layer enforce allowlists and constraints even when the model is wrong.
How do WPC and CST work together during an MCP-driven run?
The WPC defines what is permitted, and the CST carries the scoped authorization to execute under that policy context. With optional policy hash pinning, the CST becomes invalid if it is not tied to the intended WPC hash.
What can auditors verify from gateway receipts and proof bundles?
They can verify that model calls were routed through clawproxy and were receipted, and that those receipts are bundled with run metadata. They can also verify which WPC hash and CST binding context applied to the run.
Do you support Microsoft MCP scenarios?
Yes, but enforcement depends on the identity plane and the MCP server implementation. Use Entra ID identities and Microsoft Graph permissions/scopes as the underlying authorization, then wrap agent execution with WPC, CST, gateway receipts, and proof bundles for governance and audit.