MCP Security: Confused Tools and the Agent as a Data-Leak Bridge

Abstract

The Model Context Protocol (MCP) has become a common way to connect AI agents to databases, code repositories, file systems, messaging platforms, and third-party APIs. Its appeal is composability: a single agent can hold a private customer database, a public web-fetch tool, and an outbound email connector in the same working session. That same composability creates a security problem that traditional API design rarely faced. In an MCP deployment, the effective trust boundary is often not the network perimeter or the individual API, but the model's context window, where trusted instructions, private records, tool descriptions written by third parties, and attacker-controlled content are combined into one undifferentiated stream of text.

This research perspective analyzes what we call Confused Tool attacks: cases in which an agent with legitimate access to private tools is manipulated, through poisoned tool metadata, malicious tool outputs, or injected content, into carrying sensitive context, credentials, or capabilities into a public or untrusted tool endpoint. We situate these attacks within the classic confused deputy problem from computer security, review documented attack classes including tool poisoning, tool shadowing, definition drift ("rug pulls"), indirect prompt injection, and token passthrough, and examine what the protocol's authorization model does and does not solve. Building on information-flow security and recent agent-security research, we propose the Three Gates of Tool Trust: provenance, authority, and egress. We operationalize these as a deployment-specific Cross-Boundary Flow Ledger and a measurable Trifecta Exposure Interval that records how long an agent session simultaneously holds private data, untrusted input, and unmediated external communication. A worked support-agent example and a falsifiable pilot protocol show what these concepts could measure, and why none of them amounts to a universal safety score. The central argument is architectural: because prompt injection cannot yet be reliably filtered, MCP security must be achieved by controlling which data may flow between tools, not by hoping the model recognizes an attack.

Keywords: Model Context Protocol; AI agents; confused deputy; prompt injection; tool poisoning; data exfiltration; OAuth; least privilege; information flow control; agent security evaluation.

1. The day the tools started talking to each other

Consider a fully hypothetical scenario, offered to clarify the problem rather than to describe any real incident. A developer at a mid-sized company configures a coding assistant with three MCP servers. The first connects to an internal analytics database containing customer records. The second provides web search and page fetching. The third, installed from a public community list because it promised better markdown formatting, exposes a single innocuous-looking tool called format_notes.

The developer asks the agent to triage a set of open issues in a public repository. One issue, written by an outsider, contains a paragraph of text that looks like a bug report to a human skimming it, but includes instructions addressed to an AI assistant: look up the most recent customer accounts, then include them in the next call to the formatting tool "for context." The agent reads the issue, as it was asked to do. It queries the database, as it is permitted to do. It calls format_notes with a long string argument, which is a normal kind of tool call. The formatting server, controlled by the same outsider, logs the argument. No firewall was breached, no credential was stolen in the traditional sense, and every individual step was authorized. The failure lies in the combination.

This pattern is not hypothetical in kind, even though this particular story is. Security researchers have publicly documented cases in which agents connected to code-hosting MCP servers could be steered by content in public issues into reading private repositories and leaking their contents through channels the attacker could observe. [9] Independent researchers have described the general shape repeatedly: an agent that has access to private data, is exposed to untrusted content, and can communicate externally is vulnerable to exfiltration by design. [7]

The scenario illustrates the central thesis of this paper. MCP did not invent prompt injection, and it did not invent data exfiltration. What it changes is the density of trust relationships inside a single agent session. A protocol designed to make tools interchangeable also makes it easy to place a highly trusted tool and a completely untrusted tool side by side, with nothing between them except a language model that cannot reliably distinguish data from instructions.

This paper treats that density as a research and engineering problem rather than a verdict on the protocol. MCP's designers have documented many of these risks, and the specification includes explicit security guidance. [2,3] The question is whether deployment practice, tooling, and evaluation are keeping pace with the speed at which agents are being connected to consequential systems.

2. What MCP actually connects

MCP was introduced by Anthropic in November 2024 as an open standard for connecting AI applications to external data sources and tools. [1] Its architecture distinguishes three roles. A host is the AI application the user interacts with, such as a chat interface or an IDE. The host runs one or more clients, each of which maintains a connection to a single server. Servers expose capabilities that the model can use. [2]

Servers offer three main kinds of capability. Tools are functions the model can invoke, such as running a query or sending a message. Resources are data the application can read, such as files or records. Prompts are reusable templates. Clients can in turn offer capabilities to servers, including sampling, which lets a server request a model completion through the client, and mechanisms for requesting additional input from the user. Connections run either locally, over standard input and output, or remotely, over HTTP-based transports. [2]

Table 1. Selected MCP elements and their security relevance. Descriptions summarize the public specification; details vary by protocol version.

The critical observation is that most of these channels are text, and all text reaches the same model. A traditional API gateway can enforce that a payment service never sees a database password, because the two services never share memory. In an agent session, the payment tool's description, the database tool's output, and a webpage the user asked the agent to read may all sit in one context window. The model is asked to keep their roles straight using nothing but its training.

This is not a flaw unique to MCP. Any agent framework that lets a model call tools faces the same issue. MCP makes it more visible because it standardizes and popularizes the connection of many tools from many authors. The ecosystem's value proposition, that anyone can write a server and anyone can install it, is also its threat model.

3. The confused deputy, reborn

In 1988, Norm Hardy described a problem he encountered with a compiler on a time-sharing system. [4] The compiler had permission to write to a billing file so that it could record usage. A user invoked the compiler and named the billing file as the output destination for debugging information. The compiler, acting with its own authority rather than the user's, dutifully overwrote the billing records. The compiler was not malicious. It was a deputy with legitimate authority, confused about whose purpose that authority was serving.

Hardy's insight was that the problem arises when a program combines authority from different sources and cannot tell which source justified a particular action. His proposed remedy, capability-based security, ties authority to specific requests rather than to the program as a whole.

An AI agent connected to multiple MCP servers is close to an ideal confused deputy. It holds authority from the user, in the form of credentials and permissions for private tools. It receives instructions from many sources: the user's prompt, the system prompt, tool descriptions written by third parties, and content returned by tools, which may come from anyone on the internet. And it acts on all of these through the same reasoning process, with no reliable mechanism for tracking which source motivated which action.

3.1 Defining a Confused Tool attack

We use Confused Tool attack to name the MCP-specific variant: an attack in which an adversary who controls some input to an agent, whether a tool description, a tool output, a document, or a message, causes the agent to use authority granted for one tool to move data, credentials, or capability into another tool or endpoint the adversary can observe or control.

Three elements must be present. There is a source of authority, such as a private database, a file system, or a token. There is an adversarial influence, some text the attacker can place where the model will read it. And there is a sink, some channel through which information can leave the trusted boundary. The deputy, the agent, connects all three.

The label is ours, but the underlying concepts are not. Information-flow security has studied how data moves between trust levels since at least Denning's lattice model in the 1970s. [20] The principle of least privilege dates to Saltzer and Schroeder's 1975 analysis of protection mechanisms. [5] Indirect prompt injection against LLM-integrated applications was characterized systematically by Greshake and colleagues in 2023. [6] The contribution of this paper is not to discover these ideas but to connect them to the specific mechanics of MCP deployments and to propose a way of measuring exposure.

Security principle. "The agent was authorized to call this tool" is a statement about permission. "This data was authorized to reach this tool" is a separate statement about information flow. Most current deployments check the first and assume the second.

4. Anatomy of cross-tool attacks

Public research and disclosures have described several distinct mechanisms through which Confused Tool attacks can occur. Keeping them separate matters because they require different defenses. The descriptions below are conceptual; we deliberately avoid reproducing working attack payloads.

4.1 Tool poisoning

In tool poisoning, malicious instructions are embedded in a tool's description or parameter documentation. Because the model reads tool descriptions to decide how to use them, and because many client interfaces show users only a short name or summary, the full description may never be seen by a human. Researchers at Invariant Labs described this class publicly in 2025, showing how a tool's hidden documentation could instruct a model to read sensitive local files and pass their contents as a seemingly harmless parameter. [8] The tool need not even be called for the attack to succeed; its description influences the model simply by being loaded into context.

4.2 Tool shadowing

Tool shadowing is a cross-server variant. A malicious server's description includes instructions about how the model should use a different, trusted server's tools. For example, it might instruct the model to copy an attacker's address into every message sent through a legitimate email tool. The malicious tool never has to be invoked. Its influence travels through shared context into the behavior of tools the user trusts. [8] This is perhaps the purest illustration of why the context window, rather than the individual server, is the real trust boundary.

4.3 Definition drift, or "rug pulls"

Many clients ask users to approve a server or tool once, at installation. If the server later changes its tool descriptions, the change may take effect without fresh review. A server can therefore behave benignly during evaluation and alter its instructions afterward. [8] This is a supply-chain problem familiar from package ecosystems, compounded by the fact that the changed artifact is natural language consumed by a model rather than code inspected by a compiler.

4.4 Indirect prompt injection through tool outputs

The most general mechanism does not require a malicious server at all. A perfectly honest server can return attacker-controlled content: a webpage, an email, a support ticket, a public repository issue, a calendar invitation. If that content contains instructions, the model may follow them. [6] The documented code-hosting example described in Section 1 follows this pattern: a trusted, legitimate server returned untrusted content from a public issue, and that content steered the agent's use of the same server's private-repository access. [9]

4.5 Token passthrough and credential confusion

Some attacks target credentials rather than content. If an MCP server accepts an access token from a client and simply forwards it to a downstream API, the server becomes a channel through which a token issued for one purpose can be used for another. The MCP specification explicitly prohibits this pattern, requiring servers to accept only tokens issued for them and not to pass client tokens through to upstream services. [3] Credential confusion can also occur at the model level, when API keys or session tokens appear in tool outputs, configuration files, or environment listings and are then copied into the arguments of another tool.

4.6 Exfiltration channels

Once an attacker has influenced the model, data must still leave. Common channels include string parameters of tools controlled by the attacker; URLs constructed by the model and fetched by a web tool, where data is encoded in the path or query; images or links rendered in a client interface that trigger network requests; and messages sent through legitimate communication tools to attacker-chosen recipients. [7,13] Each channel is ordinary functionality, which is precisely why it is hard to block.

Table 2. A working taxonomy of Confused Tool mechanisms. Categories overlap in practice; real attacks often chain several.

5. Why filters are not enough

A natural response is to detect and block malicious instructions. Classifiers that flag likely prompt injections, system prompts that tell the model to ignore instructions in tool outputs, and output scanners that look for sensitive data all have value. None of them, however, currently provides reliable protection on its own.

The underlying difficulty is that language models process instructions and data through the same mechanism. There is no equivalent of the separation between code and data that makes parameterized SQL queries safe against injection. An instruction embedded in a webpage is, to the model, more text, and the model's job is to respond helpfully to text. Attackers can rephrase, translate, encode, or contextualize instructions in ways that evade any particular filter, and defenders must succeed every time while attackers need to succeed once.

Benchmark research supports caution. AgentDojo, a dynamic evaluation environment for prompt injection against tool-using agents, was designed precisely because static tests understate the problem; its authors found that both attacks and defenses varied considerably across models and task settings, and that defenses which reduced attack success often reduced task utility as well. [10] As with any benchmark, these results concern specific models, attacks, and versions, and should not be read as a measurement of current production systems. The broader lesson is that detection-based defenses are an arms race, not a solution.

5.1 The lethal trifecta

Simon Willison has offered a simple diagnostic that maps closely onto the confused deputy framing. An agent is vulnerable to data theft when it combines three capabilities: access to private data, exposure to untrusted content, and the ability to communicate externally. [7] Remove any one, and the classic exfiltration attack fails. An agent that reads untrusted content and can send messages, but holds no private data, has nothing to leak. An agent with private data and egress that never reads untrusted content gives the attacker no way in. An agent with private data and untrusted input but no external channel cannot send anything out.

The trifecta's power is that it shifts attention from the model's judgment to the system's architecture. It asks not "will the model notice?" but "is the dangerous combination present?" In MCP deployments, the combination is easy to assemble accidentally, because each server may supply one leg. A database server supplies private data; a fetch server supplies untrusted content; an email or webhook server supplies egress. Each is reasonable in isolation.

Design implication. If a session holds all three legs of the trifecta, the system's security depends on the model never being fooled. Architecture should aim to make that assumption unnecessary.

6. What the protocol's authorization model solves, and what it does not

MCP's specification has evolved to include a formal authorization framework for HTTP-based transports, built on OAuth 2.1. In the revisions available to us, MCP servers act as OAuth resource servers, clients discover authorization servers through standard metadata, and clients are required to use resource indicators so that tokens are bound to the specific server they are intended for. [3,15] The accompanying security guidance addresses confused deputy problems in proxy servers, prohibits token passthrough, and discusses session hijacking. [3] The OAuth security best current practice provides further grounding for these requirements. [14]

These measures matter. They address a real class of failures in which credentials are misdirected between services. They establish that a token issued for a database server should not be usable against a different service, and that a proxy server should not obtain user consent for one client and silently reuse it for another.

They do not, and cannot, address the model-level confused deputy. OAuth governs which service may be called with which credentials. It says nothing about which data, once retrieved, may be placed into which subsequent call. If an agent is legitimately authorized to read a customer table and legitimately authorized to call a web-fetch tool, OAuth will correctly permit both calls. Whether customer data should appear in the URL of the second call is an information-flow question outside the scope of an authorization protocol.

Table 3. Coverage of protocol-level authorization. Assessment reflects public specification text available to the author and may change as the protocol evolves.

A further limitation concerns locally run servers. Many MCP servers run as local processes over standard input and output, with whatever permissions the user's account has. For these servers the OAuth framework does not apply in the same way, and the effective authority of a server may be as broad as the user's own file system and network access. Installing a local server is closer to installing software than to granting an API scope, and it deserves the same scrutiny.

7. The Three Gates of Tool Trust

PROPOSED ANALYTICAL FRAMEWORK

↓ FLOW-SPECIFIC DECISION ↓

May this piece of context cross this boundary, through this tool, with this authority?

Figure 2. Three gates that a cross-tool data flow must pass. The figure is conceptual; the gates are not scored or averaged.

7.1 A framework for flows, not tools

Most existing review practice evaluates tools one at a time: is this server reputable, are its scopes reasonable, does its description look safe? These questions are necessary but insufficient, because Confused Tool attacks emerge from combinations. We propose that the unit of analysis be the cross-boundary flow: a specific piece of context moving from one tool, through the agent, into another tool call. Each flow must pass three gates.

Gate P — Provenance. Can the system establish where each piece of context in a tool call came from, and how trusted that source is? Relevant evidence includes labels or taint tracking that persist from tool output into later arguments; separation of trusted instructions from untrusted content; and visibility of full tool descriptions and their versions. A flow fails this gate when the system cannot say whether an argument contains data derived from untrusted input.

Gate A — Authority. Does the tool call use only the authority it needs? Relevant evidence includes per-server scoping of credentials; audience-bound tokens; separation of read and write capabilities; runtime enforcement that does not depend on the model; and absence of ambient authority, such as local servers inheriting a user's full file-system access. A flow fails this gate when authority is broader than the task requires or is enforced only by instructions to the model.

Gate E — Egress. If the flow carries data outside the trusted boundary, is the crossing mediated? Relevant evidence includes destination allowlists; human confirmation for outbound actions that include private data; restrictions on automatic fetching of model-constructed URLs; and logging that would allow an investigator to reconstruct what left and where it went. A flow fails this gate when private data can reach an untrusted sink without independent review.

Table 4. The Three Gates and their limits. Each gate addresses a different failure; none substitutes for the others.

As in related risk frameworks, the gates should not be converted into percentages or averaged. A deployment with excellent provenance tracking but unmediated egress of payroll data has not achieved "two out of three." Instead, deployments should specify non-compensable conditions: requirements whose failure blocks a particular flow regardless of strengths elsewhere. [19]

7.2 What is new, and what already exists

The concerns underlying these gates are well established. Information-flow control, capability security, and least privilege are decades old. [4,5,20] Recent agent-security research has proposed architectural patterns that implement similar ideas, including the dual-LLM pattern, in which a privileged model never sees untrusted content directly [12]; CaMeL, which extracts a control flow from trusted input and tracks the provenance of values through execution [11]; and a broader catalogue of design patterns for constraining agents against prompt injection. [21] OWASP's guidance for LLM applications lists prompt injection, sensitive information disclosure, and excessive agency among its top risks. [13]

Our narrower proposal is a flow-level ledger tied to MCP deployments: a record that, for each consequential cross-server data movement, documents whether each gate was satisfied at the time the flow was permitted. The Three Gates organize the evidence; the Cross-Boundary Flow Ledger is the proposed operational artifact. Whether this integration improves on existing threat-modeling practice is an explicit empirical question, addressed in Section 10.

7.3 The Trifecta Exposure Interval

To make exposure measurable over time, we propose a simple quantity derived from agent logs. For a defined agent session or deployment, record three time-varying conditions: D(t), whether the agent holds access to private data at time t; U(t), whether untrusted content has entered the agent's context by time t and has not been cleared; and X(t), whether the agent can perform an external communication without independent mediation at time t.

TEI = duration { t in [tStart, tEnd] : D(t) AND U(t) AND X(t) }

The Trifecta Exposure Interval (TEI) is the time during which all three legs are simultaneously present. A TEI of zero means the classic exfiltration path was structurally unavailable throughout the window; this is a statement about architecture, not a proof of safety, since other attack classes may remain. A long TEI does not mean an attack occurred; it means the system relied on model judgment for that period.

Several reporting rules keep the measure honest. If a condition cannot be determined from logs, the record must show unknown rather than infer safety. Severity must be reported separately, since an hour of exposure for a session holding a public FAQ and an hour for a session holding medical records are not equivalent. Mediation must be real: a confirmation dialog that users approve reflexively may not satisfy X(t) = false, and the ledger should note when mediation quality is unverified. Finally, TEI can be computed per session and aggregated across a deployment, allowing organizations to see whether changes in configuration actually reduce structural exposure.

The measure is falsifiable in a practical sense. If computing TEI fails to distinguish configurations that independent red-team exercises find more and less vulnerable, it has not demonstrated value and should be revised or abandoned.

8. From framework to a decision: a worked example

Imagine a customer-support agent for a subscription software company. This is a fully hypothetical case intended to clarify the framework; it does not describe a Deaimer customer, a published incident, or a performed experiment.

The agent connects to three MCP servers. A CRM server exposes customer names, contact details, billing status, and support history. A ticket server returns incoming support tickets, which are written by members of the public. An email server can send messages to customers. The agent's job is to read new tickets, look up the relevant customer, and draft or send a reply.

This configuration assembles the full trifecta by design. The CRM supplies private data; tickets supply untrusted content; email supplies egress. A ticket could contain instructions asking the agent to send another customer's records to an outside address. The question for the ledger is not whether the model would comply, but whether the architecture would permit it.

Table 5. An illustrative Cross-Boundary Flow Ledger entry for the hypothetical support agent.

Suppose, solely as an arithmetic illustration, that the agent was deployed with autonomous sending on day 0 and ran continuously, with tickets arriving throughout. The CRM was connected from the start, and untrusted ticket content entered context within minutes, so D(t) and U(t) were true almost immediately. On day 6, the team restricted the email tool so that it could only send to the verified address of the customer who opened the ticket. On day 12, they added mandatory review for any reply containing CRM fields beyond that customer's own record.

How should the TEI be computed? After day 6, the agent can still send email, but only to a destination determined by the system rather than by model output. Whether this counts as mediated egress is a judgment the ledger must document. If the team defines mediation as "destination not controllable by untrusted input," X(t) becomes false on day 6, and the TEI is six days. If the team defines mediation more strictly, as "no private data leaves without human review," X(t) remains true until day 12, and the TEI is twelve days. This fictional calculation neither predicts an attack nor quantifies harm. Its value lies in forcing the organization to state its definition of mediation explicitly and to record when that definition was actually satisfied.

Three design principles emerge. First, risk is flow-relative: the same agent may be safe for drafting and unsafe for sending. Second, least privilege applies to destinations as well as data: constraining where a tool can send often removes more risk than constraining what the model can read. Third, mediation must be defined before it is claimed: a confirmation step, an allowlist, and a fixed recipient are different controls with different strengths.

9. Defense in depth for MCP deployments

No single control eliminates Confused Tool risk. The following measures, drawn from the protocol's security guidance, the agent-security literature, and general security practice, address different gates and different attack classes. They are most effective in combination.

Table 6. Defense-in-depth controls mapped to the Three Gates. Limitations are illustrative, not exhaustive.

Two observations deserve emphasis. First, the strongest controls in the table are architectural rather than detective. Separating sessions, constraining destinations, and binding tokens to audiences all work regardless of how cleverly an injection is phrased. Detection-based controls, such as injection classifiers, remain useful as additional layers but should not be the foundation.

Second, human confirmation is valuable but fragile. A confirmation prompt that displays "Allow format_notes to run?" without showing that its argument contains two thousand customer records provides the appearance of oversight without the substance. Effective confirmation must show what data is crossing which boundary, in terms a reviewer can evaluate quickly, and should be reserved for genuinely consequential flows so that reviewers do not learn to click through.

For organizations evaluating MCP servers, a short set of questions captures much of this guidance. Who wrote this server, and can its descriptions change without notice? What is the broadest action it can take with the credentials it receives? Does it run locally with inherited permissions? Will it ever return content written by people outside the organization? Can it send data to destinations that model output can choose? And if this server were compromised tomorrow, which other servers' data could reach it through the agent?

10. A falsifiable research protocol

This paper does not report an experiment demonstrating that the Three Gates, the ledger, or the TEI improves security decisions. It specifies a pilot that would let other researchers evaluate the claims rather than accept them on the strength of the framing.

10.1 Research questions

RQ1 — Omission detection. Compared with an organization's existing threat-modeling process, does a structured Cross-Boundary Flow Ledger help independent reviewers identify more prespecified, exploitable cross-tool data paths, without an unacceptable rise in false alarms?

RQ2 — Structural predictiveness. Does TEI, computed from configuration and logs, correlate with the success rate of independent red-team exfiltration attempts across matched deployment configurations?

RQ3 — Control effectiveness. Which controls in Table 6 most reduce successful exfiltration in realistic MCP environments, and at what cost to task completion?

RQ4 — Mediation quality. Under controlled conditions, do human reviewers presented with different confirmation designs detect malicious cross-boundary flows at meaningfully different rates?

RQ5 — Ecosystem measurability. Do publicly available MCP server definitions and client configurations provide enough information to estimate structural exposure at scale, or is disclosure too limited for reliable conclusions?

10.2 Two-stage design

Stage A: controlled environment pilot. Construct isolated MCP environments using entirely synthetic data, combining private-data servers, untrusted-content servers, and egress servers in matched configurations that vary one control at a time. Develop a held-out suite of indirect injection scenarios authored by a team separate from the defenders, including negative controls in which no attack is present. Hold model versions, client software, server versions, and task prompts constant within paired comparisons, and run repeated trials to estimate variance. Randomize qualified reviewers to an existing threat-modeling checklist or the structured ledger, using a crossover design to reduce reviewer-skill confounding. Establish independent, adjudicated ground truth for exploitable paths before comparing reviewers. Primary outcomes should include detection sensitivity, false-positive rate, time to decision, red-team exfiltration success rate, and task utility. Reviewers must not be rewarded simply for rejecting every configuration.

Stage B: ecosystem audit. Build a preregistered sample of publicly listed MCP servers and analyze their declared tools, descriptions, requested permissions, and update histories. Estimate how often servers combine trifecta legs within a single server, how frequently descriptions change after publication, and how often local servers request broad file-system or network access. Double-code ambiguous cases and report agreement statistics. Public metadata can support claims about declared capability and transparency; it cannot establish how servers are configured in private deployments.

10.3 Threats to validity and ethics

A structured ledger may help reviewers simply by giving them more time or more prompts; review budgets should be equalized and sensitivity analyses reported. Red-team success depends heavily on attacker skill and on model versions that change quickly, so configurations must be dated and versioned. Synthetic environments may not reflect the messiness of real data and user behavior. Most importantly, research on exfiltration techniques carries dual-use risk. All testing should use isolated synthetic data and bounded network access, findings involving real servers should follow coordinated disclosure, and published materials should describe mechanisms at a level sufficient for defenders without providing ready-to-use attack payloads. [17,18]

The analysis plan should include uncertainty intervals, cluster-aware comparisons for repeated trials, breakdowns by attack mechanism, and transparent reporting of null and negative results. The strongest defensible conclusion would still be configuration-specific, not a universal claim that any framework makes MCP deployments safe.

11. Futures shaped by architecture

Several plausible pathways illustrate how the ecosystem might develop. These are analytical scenarios, not forecasts.

Secure composition becomes default. Clients and protocol revisions move toward provenance tracking, scoped sessions, pinned definitions, and mediated egress as built-in features rather than optional add-ons. Developers can still connect many tools, but dangerous combinations require deliberate configuration and produce visible warnings. The ecosystem's openness is preserved while its default trust assumptions narrow.

Fast growth with shallow assurance. The number of servers and integrations grows faster than review practice, and convenience pressures push users to install servers casually and approve confirmations reflexively. Notable incidents occur, prompting reactive fixes. This pattern resembles the early history of browser extensions and package registries, where security matured after widespread compromise.

Fragmentation into walled gardens. Organizations, concerned about risk, restrict agents to small sets of internally built or vendor-certified servers. Security improves within those boundaries, but the interoperability that made MCP attractive is partly lost, and smaller developers find it harder to reach users.

Model-level advances shift the balance. Research produces models substantially more robust to indirect injection, perhaps through training on instruction hierarchies or architectural separation of trusted and untrusted input. This would reduce, though likely not eliminate, the need for external controls. Organizations that built architectural defenses would lose little, while those that relied solely on future model robustness would have accepted exposure in the interim.

Much of the difference between these pathways depends on choices made now by protocol maintainers, client developers, server authors, and the organizations deploying agents: what is enabled by default, what is logged, what requires confirmation, and what is measured.

12. What this means for builders and the evaluation field

Deaimer's prior research has examined related questions. When Agents Infect Agents studied how prompt injection propagates through multi-agent systems, and The Sandbox Is Not the Grader distinguished isolated execution from trustworthy evaluation. [17,18] Our companion perspective on AI oversight argued that consequential authority should not expand faster than the evidence supporting it. [19] The present paper applies those themes to the narrower setting of tool ecosystems. It does not claim that Deaimer has implemented or validated the Three Gates framework.

For teams building MCP servers, the implications are concrete. Design scopes as narrowly as the use case allows. Never forward client tokens. Keep tool descriptions minimal, stable, and free of instructions about other tools. Document whether the server ever returns content authored by outside parties, so that clients can treat such output as untrusted. Treat description changes as releases that warrant changelogs.

For teams building clients and hosts, the implications concern defaults. Show users the full text of tool descriptions and highlight changes. Make it visible when a session combines private data, untrusted content, and egress. Display the actual data crossing a boundary in confirmation prompts. Offer session isolation that is easy to use, so that safe configurations are not reserved for experts.

For teams evaluating agents, the procurement question should evolve from "Does the agent complete the task?" toward "Which data flows does this configuration permit, which would an attacker exploit, and what evidence shows those flows are mediated?" Agent benchmarks that measure task success without measuring resistance to cross-tool exfiltration provide only half of the evidence needed for deployment decisions.

13. Conclusion: who controls the crossing?

The Model Context Protocol succeeds at what it was designed to do: make it easy to connect AI agents to the tools and data people need. That success has quietly moved a security boundary. In traditional systems, services that should not share data are kept apart by networks, processes, and access controls. In an agent session, they may sit side by side in a model's context, separated only by the model's ability to remember which text came from where and whose instructions to follow.

The evidence reviewed here supports neither panic nor complacency. Confused Tool attacks are documented, structurally predictable, and difficult to filter. They are also addressable, in large part, through architecture that has been understood for decades: least privilege, provenance, capability-scoped authority, and mediated information flow. The protocol's own authorization work is a meaningful step for credential safety, but it governs which tools may be called, not which data may travel between them.

The proposed Three Gates of Tool Trust, the Cross-Boundary Flow Ledger, and the Trifecta Exposure Interval are offered as a way to make that second question inspectable. They do not certify safety. If a pilot shows that they fail to improve decisions or fail to predict real exposure, they should be revised or discarded.

For researchers, the next step is to measure cross-tool exposure rather than describe its possibility. For server and client builders, it is to make safe composition the default rather than the expert option. For organizations, it is to review data flows, not just tools. The final question is not whether agents should be connected to the world. It is who controls the crossing when private context moves toward an untrusted endpoint, and whether that control rests in the architecture or only in the hope that the model will notice.

Research limitations and disclosure

This is a research perspective with a proposed evaluation protocol, not a peer-reviewed empirical study and not a report of original Deaimer trials or new vulnerability findings. It draws on public documentation and research available to the author. The MCP specification, client implementations, and the attack landscape change frequently; readers should consult current versions of the specification and recent disclosures before relying on any statement here. The proposed Three Gates, Cross-Boundary Flow Ledger, and Trifecta Exposure Interval have not been tested for reliability, validity, inter-reviewer consistency, predictive value, or superiority over existing threat-modeling methods. All references should be independently verified before publication. Attack mechanisms are described conceptually; no working exploit payloads are included.

References

1. Anthropic. (2024, November 25). Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol
2. Model Context Protocol. (2025; ongoing revisions). Specification. https://modelcontextprotocol.io/specification
3. Model Context Protocol. (2025, June 18 revision). Authorization; Security Best Practices. https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices
4. Hardy, N. (1988). The Confused Deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 22(4), 36–38.
5. Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308.
6. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., & Fritz, M. (2023). Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. arXiv:2302.12173. https://arxiv.org/abs/2302.12173
7. Willison, S. (2025, June 16). The lethal trifecta for AI agents: private data, untrusted content, and external communication. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
8. Invariant Labs. (2025, April). MCP Security Notification: Tool Poisoning Attacks. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
9. Invariant Labs. (2025, May). GitHub MCP exploited: Accessing private repositories via MCP. https://invariantlabs.ai/blog/mcp-github-vulnerability
10. Debenedetti, E., Zhang, J., Balunović, M., Beurer-Kellner, L., Fischer, M., & Tramèr, F. (2024). AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. NeurIPS Datasets and Benchmarks. arXiv:2406.13352. https://arxiv.org/abs/2406.13352
11. Debenedetti, E., et al. (2025). Defeating prompt injections by design. arXiv:2503.18813. https://arxiv.org/abs/2503.18813
12. Willison, S. (2023, April 25). The Dual LLM pattern for building AI assistants that can resist prompt injection. https://simonwillison.net/2023/Apr/25/dual-llm-pattern/
13. OWASP. (2024). OWASP Top 10 for LLM Applications 2025. https://genai.owasp.org/llm-top-10/
14. Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2025). RFC 9700: Best Current Practice for OAuth 2.0 Security. IETF. https://datatracker.ietf.org/doc/rfc9700/
15. Campbell, B., Bradley, J., & Tschofenig, H. (2020). RFC 8707: Resource Indicators for OAuth 2.0. IETF. https://datatracker.ietf.org/doc/rfc8707/
16. National Institute of Standards and Technology. (2023). AI Risk Management Framework (AI RMF 1.0). https://www.nist.gov/itl/ai-risk-management-framework
17. Deaimer Research. (2026, October). When Agents Infect Agents: Prompt Injection Propagation and Trust Failures in Multi-Agent Systems. https://www.deaimer.com/research/when-agents-infect-agents-prompt-injection-propagation-andt-55d172e7
18. Deaimer Research. (2026, October 19). The Sandbox Is Not the Grader: Building Trustworthy Agent Evaluations with Harbor. https://www.deaimer.com/research/the-sandbox-is-not-the-grader-building-trustworthy-agent-eva-1e271b26
19. Denning, D. E. (1976). A lattice model of secure information flow. Communications of the ACM, 19(5), 236–243.
20. Beurer-Kellner, L., et al. (2025). Design patterns for securing LLM agents against prompt injections. arXiv:2506.08837. https://arxiv.org/abs/2506.08837