Concepts

The Governance Gap

Every major agent protocol defines how agents communicate. MCP defines how agents call tools. A2A defines how agents talk to each other. None of them answer the question that matters before any of that happens:

Should this worker be trusted with this job, under these conditions, with this data?

That's the governance gap. An agent can call any tool, dispatch any worker, access any data — and nothing in the protocol stack asks whether it should. WCP exists to answer that question. It sits between the capability request and the execution, not beside the transport.

Separation of Concerns

WCP separates what from who from how.

A capability describes what must be possible. Summarize a document. Write to a database. Fetch a URL. Capabilities are stable contracts — they never change meaning once published. They're verbs, not implementations.

A worker species describes the class of thing that does the work. A summarizer. A fetcher. An embedder. Species are taxonomy — they tell you what kind of worker you're looking at, not who owns it or whether you should trust it.

A control describes a condition that must be true before execution. Audit logging is append-only. Network egress is denied. Secrets access is deny-by-default. Controls are declared by the worker and verified by the router before dispatch.

A policy decides when to escalate, require human review, or block entirely. A profile bundles controls and policies into a named posture — swap from prof.dev.permissive to prof.prod.strict and the same worker fleet runs under completely different governance. No code changes.

Agents request capabilities. The router matches capabilities to workers. Policies decide whether the match is allowed. The caller never needs to know which worker answered — only that the governance layer approved it.

Identity & Trust

WCP defines a four-layer identity model. Each layer answers a different question:

The critical principle: trust comes from identity, not from taxonomy. A worker is trusted because of who stands behind it (org.acme), not because of what species it is (wrk.doc.summarizer). Two workers can be the same species but owned by different organizations with completely different trust levels.

WCP defines two authority namespace families: org.<name>.* for organizations, and x.<name>.* for individuals. These are the only namespaces that carry trust attribution.

Fail-Closed by Default

If the router doesn't recognize a capability, the answer is no. If a required control is missing, the answer is no. If the worker's attestation hash doesn't match, the answer is no. If the tenant isn't registered, the answer is no.

WCP is fail-closed. Unknown things are denied. Missing things are denied. Every decision produces one of three outcomes:

• DISPATCH — cleared for execution. All checks passed.
• DENY — blocked, with a specific reason code explaining why.
• STEWARD_HOLD — queued for human review. A supervisor must approve before the worker executes.

Routing is deterministic. Same inputs, same decision, every time. If you need to change routing behavior, you publish a new rule version. There are no silent changes.

Blast Radius

Before dispatching a worker, the router computes a blast score — the potential damage if the worker fails or behaves unexpectedly. The score is the sum of five dimensions:

• Data — does it read, write locally, or write to shared/external systems?
• Network — can it reach the internet? How broadly?
• Financial — can it spend money or trigger costs?
• Time — how long does it run? Can it block other work?
• Reversibility — if it goes wrong, can you undo it?

A read-only summarizer that runs locally scores low. A worker that writes to a production database with unrestricted network access and irreversible operations scores high. High scores trigger escalation or human review.

Blast radius is additive across worker chains. If one worker calls another, their scores combine. The router accounts for the full chain before approving the first dispatch.

Attestation

A worker is only as trustworthy as its code. If someone modifies a worker after it was approved, the modified version shouldn't be dispatched — but without verification, it will be. The router can't tell the difference between the original and the tampered copy.

WCP closes this with attestation. When a worker is registered, its code is hashed. At every dispatch, the router recomputes the hash and compares. A mismatch means the worker has been modified — dispatch is denied, the worker is flagged, and the evidence receipt records exactly what happened.

For production deployments under WCP-Full compliance, attestation must be performed by a third-party external authority — not self-certified. This means the attacker would need to compromise both the worker and the attestation authority. The authority also publishes a global ban list of known-compromised hashes that any router can subscribe to.

Evidence, Not Logs

Logs tell you what happened. Evidence proves it.

Every WCP dispatch produces an evidence receipt — a structured record of who requested what capability, when, under which policy, with which controls verified, at what blast score, and what the outcome was. Every receipt includes a correlation ID that threads through the entire chain of downstream calls.

For regulated environments, the evidence trail can be extended with hash chaining — each receipt incorporates the previous receipt's hash, creating a tamper-evident chain. Any modification to historical records breaks the chain and is immediately detectable.

WCP doesn't just control what happens. It proves what happened.