Agent supply chain security is about making skills, plugins, and MCP servers behave like production dependencies: pinned, permissioned, and auditable. In OpenClaw, prompts and skills are easy to change, but the risk lives in executable tools and extensions, so you need a permissioned execution layer backed by policy-as-code, not prompt-only rules.
Claw EA adds an enforcement and proof layer around OpenClaw: a WPC (Work Policy Contract) defines what is allowed, a CST (scoped token) limits what the runtime can call, clawproxy emits gateway receipts for model calls, and each job can produce a proof bundle for later verification.
Step-by-step runbook
-
Inventory what can execute. Split inputs into three buckets: (1) skills (docs and guidance), (2) plugins/extensions (code that runs), and (3) MCP servers (local or remote tool providers via MCP server).
Treat skills as changeable text and treat plugins and MCP servers as code dependencies that can exfiltrate data or expand tool reach.
-
Set a baseline OpenClaw safety posture. Run OpenClaw’s security audit regularly and treat any “open room + elevated tools” finding as a release blocker for enterprise environments.
Confirm sandbox mode and tool policy are explicit, not inherited defaults, and ensure plugins are not implicitly enabled without an allowlist.
-
Define a WPC for your agent job class. Put concrete constraints in the WPC: allowed tool families, model routing expectations, and any required redaction posture.
Store the signed WPC in the WPC registry and use hash addressing so you can pin exactly what policy was used for any run.
-
Issue a CST for the run and pin the policy hash when needed. The CST (from clawscope) carries a scope hash and can include optional policy hash pinning so the runtime cannot swap policies mid-flight.
Use job-scoped CST binding to reduce replay risk if a token leaks or is copied between runs.
-
Route model calls through clawproxy. Configure the OpenClaw provider so model traffic goes through clawproxy, which emits gateway receipts for model calls.
If you use OpenRouter via fal, route it through clawproxy so receipts cover the model call boundary you actually depend on.
-
Lock down plugin and MCP permissions with policy-as-code. Prompt-only controls fail because a compromised plugin or MCP server can ignore instructions and directly call tools; you need machine-enforced allow/deny and sandbox boundaries.
As a rule: permissions come from the WPC and OpenClaw tool policy, not from what a skill says is “allowed”.
-
Produce and store proof. For each job, emit a proof bundle that includes gateway receipts and binding metadata, then store or publish a Trust Pulse for audit viewing when appropriate.
Make proof retention a deployment decision: keep full bundles for incident response, and keep lightweight indices for routine compliance checks.
Threat model
Supply chain issues in agent systems rarely look like classic package compromise only. They also show up as tool surface drift, silent permission creep, and context misbinding where the model or tool thinks it is operating under one policy while execution actually happens under another.
The table below focuses on skills, plugins, and MCP servers because they are where “helpful” updates can become executable behavior changes.
| Threat | What happens | Control |
|---|---|---|
| Malicious plugin update | A plugin release adds hidden network calls or expands tool invocation patterns. The agent still “looks normal” in chat while behavior changes under the hood. | Pin plugin versions in deployment and require a WPC that explicitly limits tool families. Use sandboxing for tool execution to reduce host access, and keep an allowlist for enabled extensions. |
| MCP server dependency tampering | An MCP server (or its dependencies) changes protocol semantics or tool outputs, leading to unsafe actions or data leakage. | Treat MCP servers as code: deploy from controlled artifacts, restrict which tools are exposed, and require policy-as-code enforcement. Track MCP-related supply chain risks using OWASP MCP guidance. |
| Prompt injection into “skill” content | A skill or retrieved doc includes instructions that cause the model to request dangerous tools or bypass normal review patterns. | Do not encode permissions in skills. Enforce tool allow/deny in OpenClaw tool policy plus a WPC, and ensure dangerous tools remain unavailable even if the model requests them. |
| Policy swap or config drift | A run starts under one intended policy but ends up executing with looser tool settings after a config change, restart, or operator mistake. | Use a WPC hash address and optional policy hash pinning in the CST so the execution context is bound to the expected policy artifact. |
| Token replay across jobs | A leaked token is reused to perform actions outside the original run context. | Use marketplace anti-replay binding with job-scoped CST binding, and rotate CSTs per job rather than per environment. |
| Unintended host execution | Sandbox is disabled or “elevated” execution is enabled, turning a tool call into host-level file or process access. | Use OpenClaw sandbox mode intentionally and audit elevated usage. Require a WPC that forbids elevated tools for high-risk channels and enforce a minimal tool profile. |
Policy-as-code example
This example shows the intent: a single policy artifact (WPC) defines the job’s allowed capabilities, and the CST is pinned to that policy hash. Keep the policy small, explicit, and stable enough that a reviewer can reason about it.
{
"wpc_ref": "wpc:sha256:BASE64URL_HASH",
"job": {
"id": "job_2026_02_11_001",
"purpose": "triage support tickets and draft replies"
},
"execution": {
"sandbox_required": true,
"tools": {
"allow": ["read", "write", "http", "ticketing.lookup"],
"deny": ["exec", "process", "browser.control", "secrets.dump"]
},
"models": {
"route_via": "clawproxy",
"provider": "openrouter_via_fal"
}
},
"auth": {
"cst": {
"scope_hash": "BASE64URL_SCOPE_HASH",
"policy_hash_pinning": "wpc:sha256:BASE64URL_HASH",
"job_scoped_binding": true
}
},
"audit": {
"require_gateway_receipts": true,
"emit_proof_bundle": true
}
}
Prompt-only rules cannot guarantee enforcement when a plugin, MCP server, or tool wrapper is compromised. Policy-as-code is evaluated by the execution layer, so the same run either can or cannot call a tool regardless of what the model is persuaded to do.
What proof do you get?
For model calls routed through clawproxy, you get gateway receipts that are signed and can be verified later. These receipts are designed to let you answer operational questions like: which model endpoint was called, under which job context, and whether the call was made under the expected policy constraints.
Claw EA can package receipts and related metadata into a proof bundle per job. Proof bundles are what you hand to internal audit, incident response, or a customer security review, and they can be stored or surfaced as a Trust Pulse for viewing.
In practice, teams use proof in three ways: (1) spot checks during rollout, (2) post-incident reconstruction when a plugin or MCP server behaved unexpectedly, and (3) change control evidence when updating tool permissions. If you need additional guarantees like transparency log inclusion proofs, that is planned and should be treated as a separate rollout item.
Rollback posture
Supply chain safety depends on having a rollback that is fast and evidence-backed. The goal is to revert to a known-good policy and tool surface quickly, then use proof to determine whether any runs occurred under the bad state.
| Action | Safe rollback | Evidence |
|---|---|---|
| Plugin or extension update causes unexpected behavior | Revert to last pinned plugin artifact and reapply the previous tool allowlist. If needed, tighten the WPC to remove the affected tool family until you complete review. | Proof bundle timelines plus gateway receipts show when behavior changed and which model calls happened during the suspect window. |
| MCP server shows suspicious outputs or tool expansion | Disable the MCP server in deployment and remove its tools from allowlists. Re-run OpenClaw security audit to catch implicit plugin enablement. | Gateway receipts confirm whether model calls continued; internal logs plus proof bundle metadata help correlate which sessions invoked affected tools. |
| Policy drift or wrong config pushed | Pin the CST to the intended WPC hash for subsequent runs and revert configs to the last known-good policy file. Treat any run without the expected policy hash as non-compliant. | WPC hash addressing plus CST policy hash pinning make it straightforward to identify which jobs used the wrong policy. |
| Suspected CST leakage | Rotate CSTs per job, invalidate the suspect run context, and rely on job-scoped CST binding to reduce replay. Consider reducing TTL and scoping further for high-risk jobs. | Receipts and proof bundles provide a bounded view of what actions were performed with the token during its validity window. |
FAQ
What is the difference between skills, plugins, and MCP servers?
Skills are guidance text that gets injected into an agent’s context; they should not be trusted as enforcement. Plugins and MCP servers expose executable capabilities, so treat them like dependencies with explicit permissions and review.
Why is prompt-only safety not enough for supply chain security?
Because supply chain compromise lives below the prompt: a plugin or MCP server can execute code or call tools regardless of instructions. Policy-as-code places the decision in the execution layer, so the action is blocked even if the model is manipulated.
How do WPC and CST work together during a run?
The WPC is the signed, hash-addressed policy artifact that defines what is allowed. The CST is the scoped token that carries the scope hash and can optionally pin the policy hash, binding the run to the intended policy.
What do gateway receipts actually cover?
Gateway receipts cover model calls routed through clawproxy. They are useful for verifying what calls occurred and for building a proof bundle that can be independently checked later.
Can I use this with an existing MCP setup?
Yes, typically via MCP server deployment controls plus routing model calls through clawproxy for receipting. If you need deeper enforcement at the MCP layer, that is usually an enterprise buildout based on how your MCP servers are hosted and authenticated.