A crosswalk mapping from MCP to the Open Verification / Proof-of-Control Standard
By Ken Huang, Comments wil be apprecited
This document maps the Model Context Protocol (MCP) against the six domains of verification, the System surface, the Verifiability Tiers, and the threat model defined in the Proof-of-Control standard.
It is informative. It adds no requirements to either specification. Its purpose is to answer three questions a reader of the standard will ask about the most widely deployed agent-integration protocol in the field:
Which Proof-of-Control control intents does MCP already implement?
Where does the evidence that those controls are implemented sit on the Verifiability Tiers, and why?
What would have to change — in the protocol, or around it — for an MCP deployment to clear the binary threshold?
A note on framing. Proof-of-Control verifies that the controls governing an agent system are implemented and verifiable — a present-tense property of the system, answerable before deployment. It is not a retrospective finding about whether an agent misbehaved. This document uses that framing throughout, and it is the reason the assessment below grades MCP’s controls and MCP’s evidence separately: a control can be thoroughly implemented and still not be independently verifiable, which is exactly MCP’s position.
Where this document states a protocol requirement, it uses the requirement language of the MCP specification itself (RFC 2119), and the requirement is MCP’s, not this document’s.
MCP is the point in a deployed agent stack where an agent crosses the boundary that the Verifiability Gap describes. It is where an agent reads data it did not author, calls a tool it does not own, and takes an action with an effect outside its own process. Every such crossing is a place evidence goes missing.
MCP is also a useful subject because it is well specified. It is not a case of absent controls. It is a case of thorough controls whose record is held by the party being checked — which is the exact condition the Verifiability Tiers were built to grade, and the exact condition the binary threshold was built to separate.
MCP is an open protocol, hosted by The Linux Foundation, that standardizes how LLM applications connect to external data sources and tools. It is built on JSON-RPC 2.0 and takes structural inspiration from the Language Server Protocol.
Figure 1: MCP Actor Roles & Proof-of-Control Alignment (Table Infographic)
MCP has no protocol-level concept corresponding to the Proof-of-Control Principal — the party on whose behalf the agent acts — except indirectly, through the OAuth resource owner on HTTP transports. This is treated in §5.5.
Servers offer: Resources (context and data), Prompts (templated workflows), Tools (functions the model can execute).
Clients offer: Elicitation (server-initiated requests for user input), Sampling, and Roots.
Utilities: logging, argument completion, pagination, caching, progress, cancellation.
Extensions are opt-in, additive, composable, and negotiated through the extensions field of capabilities. Notable ones: Tasks (asynchronous long-running operations), MCP Apps (inline interactive UI), and Skills over MCP.
Revision 2026-07-28 is a stateless protocol. There is no initialize handshake and no session. The specification is explicit:
Servers MUST NOT rely on prior requests over the same connection to establish context (e.g., capabilities, protocol version, client identity). Every request supplies this metadata in its _meta field.
Each request carries, in _meta:
Figure 2: _meta Field Specifications & Telemetry (Table Infographic)
Servers SHOULD return io.modelcontextprotocol/serverInfo on every result.
State that must span requests MUST be referenced by an explicit identifier the client passes on each request — a state handle, which the specification treats as a name, not a capability.
This design has a direct and favourable consequence for verification, developed in §4.
MCP defines the control surface. It specifies what an agent may reach, under what authority, with what schema, and with what consent.
Proof-of-Control defines the verification surface. It specifies evidence that those controls are implemented and in force, in a form a party other than the operator can check.
The two compose cleanly and do not overlap. MCP answers what is permitted; Proof-of-Control answers are those controls implemented, and can anyone verify that independently.
This is the same complementary shape the standard identifies with CSA’s AARM (enforcement vs. evidence), with one difference worth noting: AARM is a runtime gateway that intercepts actions inside one deployment, whereas MCP is a wire protocol spanning organizations. MCP therefore carries the evidence problem across trust boundaries by construction, which places it closer to the Portability domain than AARM sits.
Figure 1 resolves that relationship into three layers. A protocol foundation governs the specification; vendors and adopters secure their implementations; and an assurance layer supplies independent evidence about deployments. Read it bottom to top: each layer is evidenced by the one above it. The third layer must sit outside the operator to do its job, which is why a protocol body cannot fill it however well it governs the spec.
Figure 1: Protocol, implementation, and assurance
MCP’s statelessness is architecturally aligned with the Proof-of-Control contemporaneous evidence property, and MCP’s trust model caps it at Tier 2 by construction.
Both halves matter.
On alignment. Because every MCP request must be self-describing — version, capabilities, client identity, and authorization all present on the request itself — each request is already an independently interpretable unit of execution. That is precisely the shape a per-action evidence record requires. A session-oriented protocol would force an evidence layer to reconstruct context from connection state; MCP hands that context over on every call. The implementer guidance in the standard — generate the evidence while the action happens, not after a dispute — describes a record MCP’s wire format already approximates.
On the ceiling. Every control MCP specifies is enforced by the MCP server and recorded, if at all, by the operator who runs it. Token validation, scope enforcement, consent checks, schema conformance: all real, all normative, all attested by the party being checked. Under the Verifiability Tiers this is Tier 2 — Attestation: a signed operator record whose integrity rests on trusting a party. It is authenticated documentation, not cryptographic evidence.
The consequence is the sharpest statement this crosswalk can make:
Moving a spec-conformant MCP deployment from Tier 2 to Tier 3 requires no new controls. Every check is already normative. It requires changing who produces and holds the record.
MCP is therefore a clean worked example of the binary threshold — valuable to the standard because it is well designed, not despite it.
Verifiable facts: which model ran, and its lineage, artifact and supply-chain origin.
Figure 3: Domain 1 - Provenance Controls & Evidence Assessment (Table Infographic)
Assessment. MCP contributes one genuine provenance-grade guarantee — tool-set determinism, which makes “what was on offer” a checkable fact — and one explicit warning that its own metadata is untrusted. Both are useful inputs to the Provenance domain. Neither is a chain of custody.
Note the standard’s observation that Provenance is in some sense first: what came in? MCP is the wire on which “what came in” arrives, and it currently carries no provenance for it.
Verifiable facts: what data was read and written.
Figure 4: Domain 2 - Privacy Controls & Data Access Boundaries (Table Infographic)
Assessment. MCP’s privacy controls are substantial — the allow-list model, scope minimization, and the show-inputs-to-the-user requirement together implement much of the domain’s intent. The gap is exact and unchanging: enforcement without evidence. An operator can demonstrate the controls exist; no third party can confirm they held on a given call.
This is also the domain where the standard notes verification is itself a privacy problem. An MCP call log that proves what data was read may re-leak the data it was meant to protect — which is why the Proof-of-Control layer over MCP should commit to derived, hash-bound evidence rather than retaining raw payloads.
Verifiable facts: boundary crossings — organizational, jurisdictional, compute.
Figure 5: Domain 3 - Isolation Controls & Process Boundaries (Table Infographic)
Assessment. MCP’s connection-independence makes agent mobility a first-class property, which is good for the deployment and bad for the evidence: the protocol is designed so that consecutive actions need not share any substrate that could carry a chain.
Note for the Portability working group. The open issue on evidence continuity across attestation domains has a concrete, deployed test case here. MCP state handles cross server and vendor boundaries as ordinary tool arguments, and the specification already establishes that possession of a handle is not authority. The question the working group is debating in the abstract — whether an unbroken cryptographic chain across boundaries is a Portability fact, a fifth evidence property, or a domain of its own — can be posed concretely against this mechanism. The related question of disclosure continuity is also live here: baggage propagates freely across servers and jurisdictions today with no disclosure control at all.
Verifiable facts: authority granted, decisions within or against it, delegation validity.
This is MCP’s strongest domain and warrants the most detail.
MCP defines a full authorization framework for HTTP transports, based on OAuth 2.1 with a deliberately narrowed feature set. It is OPTIONAL to implement, but where implemented on HTTP, implementations SHOULD conform. On stdio, implementations SHOULD NOT follow it and instead retrieve credentials from the environment.
Figure 6: Domain 4 - Authorization & Resource Indicator Requirements (Table Infographic)
Assessment. MCP’s authorization model already satisfies much of the Authorization domain’s control intent, and does so normatively rather than as guidance. Two of its requirements are notably close to the standard’s own implementer guidance:
“Scope authority to the action, not the actor” — MCP’s audience binding and token-passthrough prohibition make an access token unusable outside the exact resource it was minted for. Authority cannot be replayed against a different server.
“Carrying a signal is not enforcing it” — MCP requires servers to validate, not merely receive. Tokens MUST be validated before processing the request.
What is missing is exclusively the evidence layer, plus the delegation chain. Every one of the MUSTs above is verified by the operator’s own server. An auditor asking “did the scope hold on the 14:32 refund call?” has only a log.
Verifiable facts: which agent and which principal ran.
Figure 7: Domain 5 - Identity Controls & Subject Verification (Table Infographic)
Assessment. The correction this domain needs is directional: Proof-of-Control over MCP must supply agent identity on top of an existing principal identity, not build both. That is a materially smaller lift than a blank slate, and it means the delegation-token mechanism the Identity domain calls for has an authenticated principal to anchor to on HTTP transports — and nothing to anchor to on stdio, which is worth stating plainly to adopters.
Note for the Identity and Authorization working groups. The open issue on whether identity-binding belongs to Identity or to Authorization has an empirical answer in a deployed protocol. MCP separates them exactly as the working group’s lean suggests: OAuth supplies the authenticated principal as an input, and the server evaluates runtime scope and action boundaries against it. MCP is evidence that the split survives contact with production.
Verifiable facts: integrity of the execution environment, that controls held, tools invoked.
Figure 8: Domain 6 - Security Mitigations & Input Sanitization (Table Infographic)
Assessment. MCP’s threat coverage is far broader than a transport protocol usually carries — it reads as a security specification with a protocol attached. What it does not have, and cannot have while the operator holds the record, is integrity of the record itself.
Where MCP sits in the agent stack, and what Proof-of-Control must add at each layer.
Figure 9: MAESTRO Layer Coverage & Proof-of-Control Additions (Table Infographic)
Concentration. MCP’s coverage clusters at L2, L3, L6, and L7 — the semantic layers of the agent stack. Its gaps cluster at L1, L4, and L5 — the layers where cryptographic evidence is actually produced. That is a coherent picture: MCP is a protocol, and the mechanisms that deliver Tier 3 evidence live below it (hardware, runtime) and beside it (transparency logs, attestation services).
Proof-of-Control over MCP is therefore not a protocol redesign. It is the addition of L1, L4, and L5 mechanisms whose outputs ride on the L2/L3 wire MCP already defines.
Figure 2 reads that assessment as a map of the agent stack. The label beside each layer states MCP’s contribution at that level; the left band marks the span of MCP’s control surface; the right band marks where Proof-of-Control mechanisms must attach.
Figure 2: MCP coverage across the MAESTRO layers
Against the 27 threats catalogued in the standard, plus the two evidence-model threats. Only rows where MCP contributes materially, or where its position is instructive, are listed.
Figure 10: Threat Model Crosswalk & Residual Verification Gaps (Table Infographic)
Four MCP-specific attack classes are worth folding into the standard’s threat work, because they are agent-integration threats that generalize beyond MCP:
Confused deputy via static client ID. A proxy server with a static upstream client ID plus dynamic downstream registration lets an attacker ride a consent cookie to obtain codes without user approval. Generalizes to any agent gateway fronting third-party APIs.
Token passthrough. Forwarding an inbound token downstream destroys the audit trail: the downstream log shows a different identity than the party that actually acted. This is an accountability failure mode, directly relevant to the standard’s deposition problem.
State-handle hijacking. Where a stateless protocol mints handles for continuity, possession of the handle must not confer authority. Generalizes to every long-running agent workflow with a durable handle — including the Tasks extension.
SSRF through metadata discovery. An agent induced to fetch attacker-chosen URLs during discovery can reach cloud metadata endpoints and exfiltrate IAM credentials. Generalizes to any agent that resolves configuration from a counterparty.
MCP’s security concerns divide into two families that call for different controls. The division determines where prevention is the right instrument and where verification is the only one left, and it is the reason a Proof-of-Control layer is additive rather than duplicative.
Family 1 — implementation defects. Remote code execution, command injection, authorization bypass, sandbox escape. Serious, frequent, and patchable. Prevention is the correct control, and the implementation-security layer owns it. Nothing in this family requires an evidence layer.
Family 2 — architectural and semantic gaps. Tool poisoning, indirect prompt injection through tool content, tool mutation after approval, and cross-server tool shadowing. These cannot be patched away at the…
