A sysadmin wrote on Reddit about a request from leadership (exhibit 37). It sounded simple: connect a language model to internal data. They did. Before long, the model started showing sensitive documents to people who should not see them.
But the model broke nothing. The permissions were already wrong, and nobody had fixed them. The top comment said most organizations have loose data governance.
A little over a month later, the same sysadmin was back (exhibit 48). Now leadership wanted agents that trigger workflows and send emails. The top advice was to get something in writing before giving the agent actions. The business or legal had to accept the risk.
Connecting a model to internal data is an integration job and nothing more.
Verdict: No: the model inherits permissions that were already wrong. A team connected an assistant to internal data. The assistant showed sensitive documents to people who should not see them. This happened because nobody had fixed those permissions. A NIST draft adds an open question. May the user see the answer that combines everything the agent gathered?
Rule
Before connecting a model to internal data, review who can see what and fix it. If the business wants to go ahead anyway, ask it to accept the risk in writing.
Why low confidence. The case comes from Reddit, without measurement. But the top comment says weak data governance is common. The NIST document is a draft with questions, not controls. No source argues that integration is enough.
Show the 3 exhibits in detailHide the detail0 for, 1 against, 2 qualify
Leadership asked to connect a language model to internal data. The assistant began showing sensitive documents to people who should not see them, because nobody had fixed permissions that were already wrong. The most upvoted comment says most organizations have weak data governance in SharePoint, Teams and OneDrive. Another proposes a data readiness and governance project before turning on the assistant.
Numbers
1,351 points and 198 commentsSize of the thread according to the archive. The quoted comment has 500 points.
Limitation Experience from people who run IT, without measurement. It was read in the public Arctic Shift archive because reddit.com blocks automated reading. The quote was compared letter by letter with the original.
“the LLM tool has access to what you give it/your people access to”
This is the same author as the thread on connecting a model to internal data. Leadership now wants agents that trigger workflows and send emails. The most upvoted advice: get the business or legal to accept the risk in writing before giving the agent actions. In contrast, another describes a narrow agent that routes about 5,000 faxes a day to the right person, with no power to do harm.
Numbers
about 5,000 faxes a dayVolume a narrow agent routes, according to one commenter.
338 points and 129 commentsSize of the thread according to the archive. The quoted comment has 376 points.
Limitation Experience from people who run IT, without measurement. It was read in the public Arctic Shift archive because reddit.com blocks automated reading. The quote was compared letter by letter with the original.
“get it in writing from legal that you're not liable”
Booth, H., Fisher, B., Galluzzo, R., Roberts, J. NIST, NCCoE
It is a NIST draft for a demonstration project that applies identity standards to agents. It proposes to identify the agent as distinct from a person, and to authenticate and authorize it with OAuth 2.0 and policies. It also proposes to bind each agent to the person who delegates to it, and to log its actions. It asks how to know the sensitivity of the data the agent gathers, and whether the user may see the combined answer. It also asks how to set least privilege (only the permissions needed) when the agent's actions are not predictable.
Numbers
6 groups of questionsGeneral, identification, authentication, authorization, auditing and prompt injection. Comments from February 5 to April 2, 2026.
Limitation It is a draft for consultation, with questions rather than controls. It leaves RAG out of scope. The PDF (11 pages) was read; the project page returned 403.
“How do we establish "least privilege" for an agent”
Quote checked against the original
Read at the source. Checked on Nov 2, 2026.
Today that jump does not need a custom integration. MCP (Model Context Protocol) is the protocol that connects an agent to tools and data. An MCP server offers tools. Each tool has a name and a description, and the agent reads them to decide when to use it.
A2A is the agent-to-agent protocol. Google created it and the Linux Foundation now hosts it. Someone finds an MCP server for a system and installs it. That same afternoon, the agent has new tools.
The thesis going around has two parts. The first: MCP and A2A are already mature standards. The second goes further: if MCP is a standard, connecting an MCP server is safe. And once you approve the server, you can trust its tools.
A2A reached version 1.0, its first stable specification, according to a Linux Foundation press release (exhibit 78). It brings signed Agent Cards. These are records that describe each agent and can be verified. A2A is already built into Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore. Over 150 organizations back it, up from over 50 in April 2025.
over 150 organizations
Organizations supporting the protocol (over 50 in April 2025). Exhibit 78
MCP also gained stability. The 2026-07-28 revision of the specification (exhibit 121) set a minimum of 12 months before deprecating features. To deprecate is to announce that a feature will be removed. If you build on a feature, you know it will not vanish from one month to the next.
MCP’s defenders on Hacker News add a security argument (exhibit 136). They say that in enterprise integrations MCP works as a boundary:
Credentials stay on the server.
Telemetry, the usage data, is measured server-side.
One integration serves many clients.
Another thread discussed an article that declared MCP dead next to the command line (exhibit 61). The answer was similar. In a shared or production agent, scoped tools beat a shell, the terminal with free access to commands. That is least privilege: only the access the task needs. With a shell, it is much harder to isolate credentials.
With MCP and A2A there are already mature standards for connecting agents in the enterprise.
Verdict: Mature as protocols, not as a guarantee. A2A released version 1.0, its first stable one, backed by more than 150 organizations. MCP set a minimum 12-month period before removing features. But in an agentic code editor, a web page made the agent register a malicious MCP server. And between agents, an instruction planted as data can reach the next one as a trusted request.
Rule
Use the standards to avoid vendor lock-in. Design security on top of them: which agent talks to which, with what data and what permissions. Write down the version of the specification you use and review it before each change.
Why medium confidence. A2A adoption comes from a promotional press release that names no concrete deployments. The MCP specification is primary, but it changes often. The editor flaw is an official record. The hop between agents comes from a preprint, a paper without peer review. NIST is still building its agent standards, with no deliverables.
Show the 5 exhibits in detailHide the detail2 for, 2 against, 1 qualifies
A2A, the agent-to-agent protocol created by Google, released version 1.0, its first stable specification. The Linux Foundation now hosts it, and it is already built into Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore. It brings signed Agent Cards (the profile of each agent) and multi-tenant support. It is presented as a complement to MCP: A2A connects agents with each other and MCP connects an agent with tools and data.
Numbers
over 150 organizationsOrganizations supporting the protocol (over 50 in April 2025).
over 22,000 starsStars on GitHub. There are SDKs in 5 languages.
Limitation It is a promotional press release. It shows adoption of the standard, not business value, and names no specific deployments.
A revision of the MCP specification, the protocol that connects agents with tools and data. MCP becomes stateless: the revision removes protocol sessions and the initial handshake (initialize), and adds server/discover. Authorization is optional. When used over HTTP, it is based on OAuth 2.1, and the server must check that the token was issued for it. The specification says tool descriptions are untrusted unless they come from a trusted server. The host must ask for consent before using a tool, and the protocol cannot enforce these principles.
Numbers
12 monthsMinimum period of the new deprecation policy.
Limitation Security depends on whoever implements the server and the client. It is the current revision as of November 1, 2026 (the previous one is 2025-11-25). Specifications change: check the version before citing it.
Windsurf 1.9544.26 is an agentic editor that uses MCP, the protocol that connects the agent to tools. Attacker HTML content can make the agent change the local MCP configuration and register a malicious MCP server. That server runs commands with no further user interaction. The flaw joins prompt injection (orders hidden in content) with MCP as a path to code execution.
Numbers
8.0 out of 10 (high)CVSS 3.1 severity, with no user interaction. CISA added it inside the record; MITRE, which assigned it, gave no score.
Limitation Official record; the original report is by OX Security. The record says what fails, not how often it was exploited.
Peters-Gill, J., Semler, A., Bartsch, H., Shumailov, I., Schroeder de Witt, C. arXiv
A co-author of CaMeL, a defense against planted instructions, shows that its guarantees do not compose on their own across agents. An instruction planted in a database is data, but the orchestrator summarizes it and another agent receives it as a trusted request. In the measurements, CaMeL in each agent cuts attack success sharply. A version that tracks data provenance across agents closes that path. The cost is usefulness, and more capable models lose less of it.
Numbers
12.9%, 0.2% and 0.0%Attack success rate without CaMeL, with CaMeL in each agent and with provenance across agents (average of 5 models, 949 cases per model and setup).
21.6 and 13.4 pointsUsefulness lost by per-agent CaMeL on 112 tasks: on average and in the two strongest models. The cross-agent version takes off another 3.2 points on average.
Limitation Preprint. One model refused 53.6% of benign tasks even without CaMeL, which lowers its baseline usefulness.
NIST launches a standards initiative for agents with three pillars. They are support for industry-led standards, open protocols for agents, and research on agent security and identity. It promises guidance in the coming months, but the announcement includes no guidance and no concrete deadline.
Numbers
3 pillarsWorkstreams of the initiative.
Limitation Government announcement. Everything is voluntary and there are no deliverables yet.
The MCP specification itself puts the first limits on the thesis:
Authorization is optional.
Tool descriptions are untrusted unless they come from a trusted server.
The host, the program where the agent runs, has to ask for consent before using a tool.
The protocol cannot enforce those principles.
Security rests with whoever implements the server and the client.
The official records show what happens when that fails. Windsurf is an agentic editor. There, attacker HTML could get the agent to register a malicious MCP server (exhibit 80). That server runs commands. In Flowise, an authenticated user could add a local MCP server with any command. It was rated 10 out of 10 (exhibit 84).
OX Security, which sells security, described a command injection across 17 products (exhibit 82). It is tied to MCP’s local transport. The official MCP kit is among those that will not be patched. Its maintainers see it as expected behavior.
Is this lab material? Several benchmarks, standard tests to compare models, say no. MCP-SafetyBench used real MCP servers (exhibit 34). Every model stayed vulnerable, with attack success from 29.80% to 48.16%. In “When the Manual Lies” (exhibit 105), a poisoned description worked close to 100% of the time against GPT-4o.
MCP Pitfall Lab measured servers with common development mistakes (exhibit 88). Attacks succeeded 31.9% of the time across 2,579 runs. These are preprints, studies not yet peer reviewed, read from their abstracts and with 2025 models.
The same pattern shows up in skills, packages of instructions and code for agents. Snyk, which sells a scanner, confirmed a malicious payload in 76 of 3,984 (exhibit 54).
MCP is a standard, so connecting an MCP server is safe.
Verdict: No. The specification itself says the protocol cannot enforce its security principles. In a benchmark with real MCP servers, every model stayed vulnerable. Attack success ranged from 29.80% to 48.16%. In Flowise, adding a local MCP server allowed code execution, with a severity of 10 out of 10. The official MCP kit has a command injection flaw that will not be patched. Its maintainers see it as expected behavior.
Rule
Treat every MCP server as third-party code. Read each tool's full description and pin the version with a hash. Keep it out of the same session as servers with sensitive data.
Why high confidence. The official specification, an official flaw record and several independent benchmarks agree. Also, the official kit has a flaw that will not be patched. The benchmarks are preprints, without peer review, with 2025 models. The kit flaw is published by a company that sells security. Another security company publishes an audit of skills, which are another way of adding tools. It shows the same. On the favorable side there are only Hacker News opinions.
Show the 8 exhibits in detailHide the detail1 for, 6 against, 1 qualifies
A thread on whether MCP, a protocol that connects agents with tools, is useful or a reinvented OpenAPI. For supporters, MCP is already the default in enterprise integrations because it works as a security and authentication boundary. They give three reasons: server-side telemetry (usage data), credentials held on the server and one integration for many clients. Critics see it as one more layer over APIs that already existed.
Numbers
687 points and 363 commentsSize of the thread.
Limitation Technical opinions, without adoption data. It was read on news.ycombinator.com and through the public Algolia API. Quotes from the thread were not checked word by word in the source verification, so none is used.
A benchmark (a standard test set) with real MCP servers in five domains: browser, finance, maps, repositories and web search. It tests 20 attack types on the server, host and user side. Every model tested is still vulnerable, and the ones that do the task best resist attacks worst.
Numbers
from 29.80% to 48.16%Attack success rate across 13 models and 245 cases (GPT-5: 37.55%; Claude 4.0 Sonnet: 31.43%).
r = -0,572Correlation between task success and defense (p = 0.041, with only 13 models).
Limitation Preprint. There is a version 2 (March 5, 2026) that does not say what changed; the figures are from version 1. 2025 models. Task success is low (9% to 21%).
“models with higher task performance tend to be less resistant to attacks”
Liu, S., Tang, X., Yang, X., Lin, L., Zhou, B., Xiao, W., Liu, W. arXiv
It is a benchmark in an isolated environment on MCP poisoning (MCP is the protocol that connects tools to an agent). In this attack, the tool description carries the trap. The authors say leading models such as GPT-4o are highly vulnerable. They also say that common prompt-based defenses barely help and sometimes make things worse.
Numbers
nearly 100%Attack success against GPT-4o in six high-risk scenarios, according to the abstract (32 cases, 6 categories, 8 models).
Limitation Preprint; the abstract was read, and it gives no figures for the other models.
It measures attacks against MCP tool servers with common development mistakes. They propose treating MCP servers as supply chain dependencies and keeping an inventory of what each one does.
Numbers
31.9% and 38.7%Attack success overall and with multimodal injection, across 2,579 runs with 4 models.
Limitation Preprint; the abstract was read, and it does not name the models. There is a version 2 (July 14, 2026) that does not say what changed.
In Flowise before version 3.1.0, an authenticated user could add a local MCP server with any command and run it. The user could bypass the allowed-command filters with an allowed command plus arguments that run code. Filtering commands is not enough.
Numbers
10 out of 10 (critical)CVSS 3.1 severity according to the CNA (GitHub).
Limitation Official record. It requires an authenticated user.
Siman Tov Bustan, M., Naamnih, M., Zadok, N. OX Security
It describes a command injection (making a system run someone else's commands) that repeats in MCP's local transport. Many applications pass the command and arguments from the configuration to a process without validating them. It lists affected products and failure families. The official MCP SDK is among those that will not be patched, because its maintainers treated it as expected behavior.
Numbers
17 products and 14 CVEsAffected products and CVEs they had assigned, in 4 failure families.
Limitation Published by a company that sells security; "systemic" is its word. It argues over whether the transport design is to blame.
Beurer-Kellner, L., Kudrinskii, A., Milanta, M., Nielsen, K. B., Sarkar, H., Tal, L. Snyk
It is an audit of the skills published in two open catalogs, with a scanner and human review. A skill is a package of instructions and code added to an agent. The skill inherits every permission of the agent: shell, files and credentials. Publishing takes one file and a new account, with no signing, no review and no isolation by default. Tool poisoning stops being a demonstration and is measured in a real ecosystem.
Numbers
76 of 3,984Skills with a malicious payload confirmed by people, out of those scanned. 8 were still published at the time of writing.
534 (13.4%) and 1,467 (36.82%)Skills with at least one critical issue and with any issue.
Limitation Published by the company that sells the scanner. The title speaks of 1,467 malicious payloads, but the body says 1,467 are skills with any issue and 76 the confirmed malicious ones: the base uses the body. Skills are not exactly MCP servers.
“Agent Skills operate with the full permissions of the AI agent they extend”
A revision of the MCP specification, the protocol that connects agents with tools and data. MCP becomes stateless: the revision removes protocol sessions and the initial handshake (initialize), and adds server/discover. Authorization is optional. When used over HTTP, it is based on OAuth 2.1, and the server must check that the token was issued for it. The specification says tool descriptions are untrusted unless they come from a trusted server. The host must ask for consent before using a tool, and the protocol cannot enforce these principles.
Numbers
12 monthsMinimum period of the new deprecation policy.
Limitation Security depends on whoever implements the server and the client. It is the current revision as of November 1, 2026 (the previous one is 2025-11-25). Specifications change: check the version before citing it.
Read at the source. Checked on Nov 1, 2026.
That leaves the belief that approving a server once is enough. Record MAL-2026-4069 documents a legitimate MCP server published on npm, the public registry of JavaScript packages (exhibit 103). With a new version, it turned malicious. It was part of a campaign of 631 versions of 314 packages in 22 minutes. Each version stole cloud, GitHub and npm credentials on install. What you approved on Monday may not be what runs on Thursday.
A tool can do damage without anyone calling it. In MCP-ITP (exhibit 41), a poisoned tool’s description was enough to change how the agent behaved. The agent used a different, legitimate tool with more permissions. The attack succeeded up to 84.2% of the time. A detector caught those descriptions at most 0.3% of the time.
OWASP, a software security foundation, puts the supply chain among its ten risks for agents (exhibit 33). The supply chain is all the third-party code you use. MCP Pitfall Lab proposes treating servers as dependencies, with an inventory of what each one does.
If I approved an MCP server once, I can trust its tools from then on.
Verdict: No. A legitimate MCP server published on npm turned malicious with a new version. It was part of a campaign of 631 versions of 314 packages in 22 minutes. On top of that, one tool's description can make the agent use another tool to do the damage. That other tool is legitimate and has more permissions. The specification says tool descriptions are untrusted, unless they come from a trusted server.
Rule
Keep an inventory of MCP servers, each with an owner, and treat them as dependencies. Enable tools one by one and pin the version. Ask for approval again if the description or the package changes.
Why medium confidence. The malicious package is listed in a public registry and the specification is primary. The cross-tool attack comes from a preprint, without peer review, read from its abstract. There is no data on how often it happens in the real world. OWASP lists the supply chain among the ten agent risks, but does not measure it. On the favorable side there are only Hacker News opinions.
Show the 6 exhibits in detailHide the detail1 for, 3 against, 2 qualify
A thread on whether MCP, a protocol that connects agents with tools, is useful or a reinvented OpenAPI. For supporters, MCP is already the default in enterprise integrations because it works as a security and authentication boundary. They give three reasons: server-side telemetry (usage data), credentials held on the server and one integration for many clients. Critics see it as one more layer over APIs that already existed.
Numbers
687 points and 363 commentsSize of the thread.
Limitation Technical opinions, without adoption data. It was read on news.ycombinator.com and through the public Algolia API. Quotes from the thread were not checked word by word in the source verification, so none is used.
It is a record of malicious code in an MCP server (a program that gives tools to an agent) published on npm. It is part of a campaign: attackers took over an npm account and published hundreds of malicious versions in minutes. Each version runs a script at install time and steals cloud, GitHub and npm credentials, among others. A legitimate MCP package became malicious with a new version.
Numbers
631 versions of 314 packages in 22 minutesSize of the campaign.
Limitation Public record from the OSV database, read through its API. It describes the package, not how many installs there were.
The agent never calls the poisoned tool. Its description is enough to make the agent use another, legitimate tool with more permissions to do the damage. The authors generate those descriptions automatically. They optimize them both for the attack to work and for a detector to miss it.
Numbers
up to 84.2%Attack success on the MCPTox set, with 12 agents.
A revision of the MCP specification, the protocol that connects agents with tools and data. MCP becomes stateless: the revision removes protocol sessions and the initial handshake (initialize), and adds server/discover. Authorization is optional. When used over HTTP, it is based on OAuth 2.1, and the server must check that the token was issued for it. The specification says tool descriptions are untrusted unless they come from a trusted server. The host must ask for consent before using a tool, and the protocol cannot enforce these principles.
Numbers
12 monthsMinimum period of the new deprecation policy.
Limitation Security depends on whoever implements the server and the client. It is the current revision as of November 1, 2026 (the previous one is 2025-11-25). Specifications change: check the version before citing it.
It is OWASP's first consensus list built for agents. The ten risks run from agent goal hijacking (ASI01) to rogue agents (ASI10). They include tool misuse (ASI02) and identity and privilege abuse (ASI03). They also include the agentic supply chain (ASI04) and cascading failures (ASI08). It adds the principle of least agency: do not grant autonomy that is not needed. Its mitigations include least-privilege profiles per tool, human approval for destructive actions and controls outside the model. It also asks for cost, rate or token caps with automatic cutoff.
Numbers
10 risks (ASI01 to ASI10)Size of the list. ASI02 and ASI03 extend excessive agency (LLM06) from the 2025 list to multi-step flows.
Limitation It is a voluntary consensus framework: it binds no one and measures nothing. In the agent list, unbounded consumption is no longer an item of its own: it appears as a scenario and mitigation inside ASI02. The full PDF (57 pages) was read.
“deploying agentic behavior where it is not needed expands the attack surface”
It measures attacks against MCP tool servers with common development mistakes. They propose treating MCP servers as supply chain dependencies and keeping an inventory of what each one does.
Numbers
31.9% and 38.7%Attack success overall and with multimodal injection, across 2,579 runs with 4 models.
Limitation Preprint; the abstract was read, and it does not name the models. There is a version 2 (July 14, 2026) that does not say what changed.
Read at the source. Checked on Nov 2, 2026.
Between agents, the problem takes another shape. CaMeL is a design that separates what the user asks from the data the agent reads. A preprint with a CaMeL coauthor showed that an instruction planted in a database travels as data (exhibit 139). The orchestrator, the agent that splits up the work, summarizes it into its request to another agent. There the instruction becomes a trusted request.
An agent-to-agent standard does not close that path. A design that keeps track of where each piece of data came from does.
MCP and A2A are mature as protocols.They have stable versions, a policy for removing features and adoption on large platforms. Using them saves you custom integrations. It also lets you switch vendors without rebuilding everything.
They are not a security guarantee, and the specification says so itself. A standard decides how parties talk. It does not decide what data the agent combines, which server is trustworthy or whether a package changed. Treat an MCP server like a library you download from the internet: third-party code that runs with your permissions.
NIST, the US standards institute, launched an agent standards initiative with 3 pillars (exhibit 59). But the announcement brings no guidance and no deadline.
MCP’s defenders are right about security. A narrow tool with credentials kept server-side is easier to control than a shell. Performance is a different calculation.
Anthropic, which sells the model, showed that 58 tools from 5 servers take up about 55,000 tokens before work starts (exhibit 23). A token is a unit of text that the model processes and that you pay for. With on-demand tool search, Opus 4.5 raised its accuracy on those MCP evaluations from 79.5% to 88.1%.
In another post, Anthropic proposes giving the agent servers as code in a sandbox, an isolated environment (exhibit 15). In its example, usage fell from 150,000 to 2,000 tokens. These are the vendor’s own examples. Still, they suggest that performance depends on how you load tools, not only on how many there are.
from 150,000 to 2,000 tokens
Savings in one example from the post (98.7%). Exhibit 15
The evidence has limits. A2A’s adoption comes from a promotional press release. The benchmarks are preprints, and several flaws are published by companies that sell security. No source says how often these attacks happen in production. All of them agree on the mechanism.
Narrow tools are safer and perform better than giving the agent a shell or the whole API.
Verdict: Safer, yes, but performing better depends on how they are loaded. In a shared or production agent, narrow tools let you apply least privilege and isolate credentials. Least privilege means giving only the permission the task needs. But a model vendor proposes giving the agent its tools as code in a sandbox, an isolated environment. In one example, usage fell from 150,000 to 2,000 tokens. And narrow does not mean trustworthy.
Rule
In production, give the agent narrow tools, with credentials kept on the server side. Load them when needed instead of all at the start. If you give it code, run it in a sandbox with limits and monitoring.
Why low confidence. The security part rests on opinions in a Hacker News thread, without data. The performance part is a model vendor's own examples. A preprint read from its abstract adds a risk: one tool's description can make the agent misuse another. A preprint is a paper without peer review.
Show the 4 exhibits in detailHide the detail1 for, 1 against, 2 qualify
A thread about an article that declares MCP (a protocol that connects agents with tools) dead in favor of the command line. For supporters, in a shared or production agent, scoped tools are better than a shell. It is least privilege: giving only the access needed. With a shell it is much harder to isolate credentials. For most people, who are not technical, MCP offers security guardrails and simple, consistent authentication.
Numbers
447 points and 284 commentsSize of the thread.
Limitation Technical opinions, without adoption data. It was read on news.ycombinator.com and through the public Algolia API. Quotes from the thread were not checked in the source verification, so none is used.
Loading every tool definition up front and passing each intermediate result through the model uses many tokens. The post proposes presenting MCP servers, which connect the agent to tools, as a code API. The agent loads only what it uses, filters data in the execution environment and returns only what is needed to the model. It warns that running agent code requires a sandbox, limits and monitoring.
Numbers
from 150,000 to 2,000 tokensSavings in one example from the post (98.7%).
5 rows instead of 10,000What the model sees of a spreadsheet when the filter runs in code.
Limitation Published by the model vendor; the figures are its own examples. The token cost of many tools is real, but the fix it proposes looks more like giving the agent code than a few narrow tools.
“Note that code execution introduces its own complexity.”
Anthropic adds three features: searching tools on demand, calling them from code and adding usage examples to the definition. The code runs in a sandbox, an isolated environment. It shows that many tool definitions use up context and lower accuracy. It proposes loading tools when they are needed, not having few tools.
Numbers
about 55,000 tokensWhat 58 tools from 5 MCP servers take up before starting.
about 8,700 versus 77,000 tokensContext used with and without tool search (85% less).
from 79.5% to 88.1%Opus 4.5 accuracy on MCP evaluations without and with tool search (Opus 4: from 49% to 74%).
Limitation Vendor product announcement; the evaluations are internal.
The agent never calls the poisoned tool. Its description is enough to make the agent use another, legitimate tool with more permissions to do the damage. The authors generate those descriptions automatically. They optimize them both for the attack to work and for a detector to miss it.
Numbers
up to 84.2%Attack success on the MCPTox set, with 12 agents.
Use the standards to avoid vendor lock-in, and design security on top of them. Now:
Before you connect a model to internal data, review who can see what and fix it. If the business wants to go ahead anyway, get it to accept the risk in writing.
Build an inventory of MCP servers. For each one, write down an owner, its version pinned with a hash and the date of its last review. A hash is a fingerprint that changes if the package changes.
Read each tool’s full description and enable tools one by one. Ask for approval again if the description or the package changes.
Do not put a third-party server in the same session as servers with sensitive data. That is the Rule of Two from chapter 5 applied to connections.
In production, give the agent narrow tools, with credentials kept server-side. Load them when needed. If you give it code, run the code in a sandbox with limits.
Write down the specification version you use. With A2A, write down which agent talks to which, with what data and with what permissions.
The design review has these points in order. The threat map shows you which servers cannot share a session.