Agent supply chain security is about controlling what “skills”, plugins, dependencies, and MCP servers an agent can load, and proving what it actually used during a run. In Claw EA, OpenClaw is the baseline agent runtime, and Claw Bureau primitives add permissioned execution: WPC = Work Policy Contract, CST = scoped token, gateway receipts, and proof bundles.

Prompt-only controls are not enough because compromised tools can ignore instructions while still appearing compliant. You need machine-enforced policy-as-code that gates tool loading, model egress, and job identity, then produces evidence you can verify later.

Step-by-step runbook

Use this runbook when you are introducing a new skill, plugin, or MCP server into an OpenClaw deployment managed under Claw EA. The goal is to keep changes small, permissioned, and auditable.

  1. Inventory what can execute. List OpenClaw extensions (plugins), skills (prompt docs), and any MCP servers used by tools. Include transitive dependencies and where they are installed from (registry, git, internal artifact store).

  2. Define a WPC for the job class. Create a WPC = Work Policy Contract that expresses allowed tool families, allowed providers, required sandbox posture, and any policy hash pinning expectations for the run. Keep it specific to the workflow, not “general agent use”.

  3. Issue a CST bound to that WPC. Use clawscope to issue a CST = scoped token whose scope hash matches the intended permissions, with optional policy hash pinning to the WPC. Treat this as the runtime “capability envelope” for the agent job, not a user login token.

  4. Route model calls through clawproxy. Configure the agent so model traffic goes via clawproxy to obtain gateway receipts for each model call. If you use OpenRouter via fal, route it through clawproxy so the same receipt format covers those calls.

  5. Constrain execution locally in OpenClaw. Apply OpenClaw tool allow/deny and sandbox configuration so that even a compromised prompt cannot access tools you did not intend. Re-run OpenClaw’s security audit after changing configs or enabling new extensions.

  6. Run in a canary lane first. Execute the job in a low-privilege environment with production-like inputs but no production credentials. Collect the proof bundle and review what tools were invoked and what model calls occurred.

  7. Promote with evidence. Promote the skill/plugin/MCP server to broader use only after you can consistently produce a proof bundle, and you can explain each permission in the WPC. Store the resulting audit artifacts in Trust Pulse for later review.

Threat model

Skills, plugins, and MCP servers expand the trusted computing base of an agent. The common failure mode is that a compromised component runs inside a trusted path and performs actions that your prompt would never authorize.

Threat What happens Control in Claw EA
Dependency tampering in a plugin or MCP server A malicious update adds hidden tool calls, exfiltration, or policy bypass behavior during normal operation. Permissioned execution via WPC constraints plus CST scope hash, and post-run verification using gateway receipts and the proof bundle. Treat new versions as new supply chain entries and re-approve.
Prompt injection that requests extra tools Model is tricked into calling tools that are present but should not be reachable for that job. OpenClaw tool policy and sandboxing to reduce tool blast radius, backed by WPC that specifies what is allowed for the job. Prompt text is advisory; the policy gates execution.
MCP server misbinding or tool spoofing The agent believes it is calling one tool, but it is routed to a different server or a different implementation with broader behavior. Pin expected tool surfaces in policy-as-code, and require that the CST used for the job is job-scoped (anti-replay binding). Review proof bundles for unexpected tool names or unexpected call patterns.
Over-broad credentials embedded in runtime A plugin obtains long-lived credentials from disk or environment and uses them outside intended scope. Use CST for Claw Bureau access and keep enterprise credentials out of the agent where possible. For external systems, prefer short-lived tokens via official API flows and limit what the tool can request.
Silent policy drift Config changes expand permissions over time and nobody notices until an incident. Hash-addressed WPC and optional policy hash pinning in the CST to make drift detectable. Use OpenClaw security audit as a recurring control after config changes.

Policy-as-code example

This example shows the shape of a permissioned execution contract for a job that uses a small toolset, sandboxed execution, and model calls routed through clawproxy. The point is that the agent cannot “talk its way” into additional capability because the WPC is enforced outside the prompt.

{
  "wpc_version": "1",
  "policy_name": "invoice-reconcile-canary",
  "policy_hash": "hash-addressed-by-clawcontrols",
  "tools": {
    "allow": ["read", "write", "exec", "http"],
    "deny": ["browser_control", "docker_socket", "host_elevated_exec"]
  },
  "sandbox": {
    "mode": "all",
    "workspace_access": "ro"
  },
  "model_egress": {
    "route_via": "clawproxy",
    "receipts_required": true
  },
  "token": {
    "type": "CST",
    "scope_hash_required": true,
    "policy_hash_pinning": "optional"
  },
  "job_binding": {
    "anti_replay": "job-scoped CST binding"
  }
}

What proof do you get?

For model traffic routed through clawproxy, you get gateway receipts: signed receipts emitted by clawproxy for model calls. These receipts can be verified later to confirm which model endpoint was called, when it was called, and that the call flowed through the expected gateway.

Claw EA packages those receipts with run metadata into a proof bundle, which is the unit you hand to audit, incident response, or a customer security review. When you need a durable place for review and sharing, store the proof bundle (or its references) as a Trust Pulse artifact.

Operationally, this lets you answer two questions that matter in incidents: what permissions were granted (WPC + CST scope hash), and what actually happened (gateway receipts inside the proof bundle). You can also compare canary and production runs to detect drift in tool use.

Rollback posture

Supply chain incidents are usually time-sensitive, so rollback needs to be mechanical. Aim for rollbacks that remove capability first, then fix code, then reintroduce capability with a new WPC and new CST issuance rules.

Action Safe rollback Evidence to capture
Plugin version suspected compromised Disable the extension in OpenClaw allowlists and redeploy with the last known good version. Keep the WPC tightened until you finish root cause analysis. Proof bundle from the last good run and the first bad run, plus the WPC hashes used in each.
MCP server behavior changed Stop using that MCP server and switch the agent workflow to a minimal alternative path (or no tool path) via policy-as-code. Treat the MCP server as untrusted until you can re-validate. Gateway receipts around the time of change, including tool invocation patterns that indicate misbinding or spoofing.
Over-permissioned job class discovered Issue a new WPC that removes the extra tools and pin the policy hash in new CST issuance. Expire or revoke old CST where operationally feasible. Diff of WPCs by hash, and a proof bundle showing the job still completes with reduced permissions.
Unexpected model routing or provider drift Require clawproxy routing for the job class and reject runs that cannot produce gateway receipts. Re-run canary with the same inputs to confirm stable behavior. Gateway receipts that show the provider path, correlated to the CST scope hash used for that job.

FAQ

What is the difference between a skill and a plugin in OpenClaw?

A skill is prompt-injected documentation intended to guide the agent, while a plugin is executable code that can add tools or providers. Supply chain risk is higher for plugins and MCP servers, but skills can still introduce unsafe behavior if they change operational procedures.

Why not rely on prompts like “do not exfiltrate data”?

Prompts are not an execution boundary, and compromised dependencies can ignore them. Policy-as-code in a WPC plus enforced scoping in a CST makes the allowed actions explicit and machine-checkable.

How do WPC and CST work together during a run?

The WPC defines the allowed work policy as a signed, hash-addressed artifact served by clawcontrols. The CST is issued by clawscope with a scope hash that represents the permitted capability, with optional policy hash pinning to ensure the token is used only under the intended WPC.

What do gateway receipts tell me that logs do not?

Gateway receipts are signed receipts emitted by clawproxy for model calls, designed for later verification. Logs are useful, but they are easier to omit, alter, or mis-correlate across systems compared to a proof bundle that packages receipts with run metadata.

How should we think about MCP servers in enterprise environments?

Treat an MCP server like an internal microservice that exposes tools to an agent, and apply the same change control you would to production services. Use minimal permissions, explicit tool allowlists, and require verifiable model egress via clawproxy when possible.

Sources