Independent Attestation for the MCP Servers AWS Won't Cover

Last week Ox Security disclosed a design flaw in the Model Context Protocol that puts up to 200,000 MCP servers at risk of remote code execution. Anthropic responded that the behaviour is "expected." Five days earlier, AWS launched Bedrock Agent Registry, a centralised governance catalogue for the agents and MCP servers running inside its own walled garden. The juxtaposition tells you exactly where the trust gap lives — and who is going to have to fill it.

What Ox Found

The Ox Security report — titled, with admirable bluntness, "The Mother of All AI Supply Chains" — traces the issue back to STDIO, the local transport that MCP uses to spawn server processes as subprocesses of the AI host. The protocol-level handshake assumes that whatever command was passed in will dutifully start an MCP-speaking server. The implementations Ox audited do not enforce that assumption. If the command happens to be an MCP server, the handle is returned. If it's anything else — a shell command, a payload dropper, a credential exfiltrator — the system runs it first and only returns an error afterwards.

Execute first, validate never. The phrase comes from one of the security blogs covering the disclosure and it captures the shape of the problem better than any CVE number. The MCP supply chain has 150 million SDK downloads behind it, more than seven thousand publicly accessible servers, and an estimated 200,000 vulnerable instances when private deployments are included. None of those numbers are speculative; they are the numbers the protocol's own ecosystem celebrates as evidence of adoption.

Anthropic's reply is the part that should make every agent operator sit up. The behaviour, they say, is expected. The protocol is doing what it was designed to do; the responsibility for what command gets passed in lies with the implementer. From a protocol-author's standpoint that is defensible. From a security-engineering standpoint it is a disclaimer, not a fix.

What AWS Shipped The Same Week

Two days before the Ox post went live, AWS pushed the preview release of Bedrock Agent Registry — a unified discovery, governance, and lifecycle layer for agents, tools, and MCP servers running inside Bedrock AgentCore. It is, by any honest read, an excellent product. Centralised inventory. Consistent permission boundaries. Audit trails that flow into AWS-native security tooling. If you build agents on Bedrock and only on Bedrock, the Agent Registry probably solves your governance problem.

The phrase "and only on Bedrock" is doing all the work in that sentence. The MCP ecosystem does not live inside one hyperscaler. It is a deliberately interoperable protocol, donated to the Linux Foundation alongside ACP and A2A, with reference implementations in TypeScript, Python, Rust, and Go. Most agents that matter pull tools from a half-dozen MCP servers — some maintained by the agent's own team, some grabbed from a directory, some hosted by partners, some run as community side projects. The Bedrock registry sees the ones AWS is hosting. The other 199,000-and-change are someone else's problem.

Why Independent Attestation Has To Be The Answer

The first impulse, when a protocol-level vulnerability hits the news, is to wait for the protocol to be patched. That impulse is wrong here for two reasons. The first is that Anthropic has explicitly declined to patch it; their position is that the implementer carries the responsibility. The second is structural: even if every reference implementation tightened the STDIO contract tomorrow, the supply chain is large enough and old enough that compromised servers will continue to circulate for years. The attack surface persists past the fix.

What changes that picture is independent attestation: a third party who is neither the agent operator nor the server author signs a time-limited certificate stating that an MCP server's behaviour matches its declared spec. Crucially, the attester does not have to be Anthropic, AWS, or any other party with a stake in the protocol's reputation. The trust comes from cryptographic verifiability and from the fact that the attester has nothing to gain by lying. Every consumer of the certificate can check it against a known public key without contacting the attestation service at all.

This is the same architectural pattern that solved the analogous problem in the certificate authority world. We do not trust websites because the websites tell us to. We trust them because an independent party signed a certificate stating they are who they claim to be, and our browsers can verify that signature without phoning home. The public-key infrastructure is older than HTTPS itself and the design is well understood. Applying it to MCP servers — and to the agents that consume them — is mostly a matter of deciding to do it.

What Attestation For An MCP Server Actually Looks Like

The mechanism we have been using for agent compliance translates almost directly. Each MCP server publishes a manifest declaring its capabilities, its version, the host it runs on, and the public key it signs with. The attestation service ingests runtime evidence over a short window — tool invocations, request/response pairs, error patterns, command surfaces — and grades the server against a defined behavioural framework. If the evidence matches the manifest and no anomalous behaviour is observed, the server gets a signed certificate stating so, valid for a fixed period.

The certificate is short-lived on purpose. A weekly attestation tells you the server was behaving correctly seven days ago, which is not the same thing as telling you it is behaving correctly right now. A 24-hour expiry creates a tighter loop, raises the cost of compromise, and makes "we have a current cert" a useful real-time signal rather than a stale promise. The continuous-attestation argument is the same one we made for agents themselves in our earlier piece on why annual audits fail; it is even more obviously correct for tool servers, which are simpler to instrument and easier to bound.

Consuming a certificate is the cheap side. An agent that wants to call an MCP server reads the server's current attestation, verifies the signature against a known public key, checks the expiry, and proceeds — or refuses. The attestation service does not need to be reachable for the verification step. The cryptography travels with the certificate. This is the property that makes the architecture survive when the attestation service itself is unavailable, partitioned, or under attack.

What We Are Doing About It

AgentApproved already issues attestations for AI agents — the runtime evidence chain, the multi-framework grading, the Ed25519 signatures, the 24-hour expiry. The MCP RCE disclosure has moved up the timeline on extending the same machinery to attest the MCP servers themselves. The protocol fit is natural: we already operate an MCP server, we already speak Streamable HTTP, and the evidence schema we use for agent actions covers tool invocations as a first-class event. The behavioural framework needs to be written down and the manifest spec needs to be agreed, but the cryptography is already there.

The work we want to do publicly, in the open, with feedback from the people running production MCP deployments. If you operate an MCP server — whether you wrote it, forked it, or are hosting someone else's — and you want a signed certificate stating that your server behaves as claimed, get in touch. The first attestation will be free, the same as it is for agents, and the rate after that will be the same fractional cent we charge today. Operators of widely-used community servers will get free attestations for the foreseeable future on the same logic that drives the first-thousand-agents promotion: ecosystem health is the product.

The Trust Stack After This Week

The week of April 14th to April 20th will probably be remembered as the week the MCP ecosystem was forced to grow up. AWS shipped a registry that proves the hyperscalers have noticed; Ox shipped a disclosure that proves the existing implementations are not safe by default; Anthropic shipped a response that proves the protocol itself is not going to be the layer that fixes it. The next move belongs to whoever builds the independent trust layer that the long tail of MCP servers — and the agents that depend on them — actually need.

We think that layer should be cryptographically verifiable, time-limited, framework-agnostic, and operated by a party with no stake in any one hyperscaler's commercial outcome. We have built most of it already. The MCP-specific extension is what comes next, and the timeline now reads in weeks, not quarters.