1. What are the MCP security risks TikTok researchers describe?
Researchers at TikTok's Privacy Innovation Lab have warned that tools connected to AI agents through the Model Context Protocol can be used to quietly turn those agents against the people they serve. In a paper titled "When Tools Become Prompts: Why Multi-Turn MCP Systems Break Traditional Security Assumptions," authors Sirat Samyoun and Jian Du argue that MCP security risks emerge across the course of a conversation and are easy to miss when each step is examined alone.
The central claim is that once an AI agent uses tools over several turns, those tools stop being isolated components. Their descriptions and outputs become part of the text the model reads, part of its working memory, and part of how it makes decisions. That makes them a channel through which an attacker, or simply a careless design, can influence behavior and expose data.
The paper describes three main patterns: tool poisoning, persistent sensitive data, and indirect exposure of personal information. Each is examined below, along with the authors' criticism of how such systems are currently assessed.
The warning comes from a corporate privacy research group, which frames the problem as one of system design rather than a flaw in a single product. That framing is important for readers who may assume the risk lies with a specific vendor: the concern applies to the way agents and tools are combined, regardless of who built the individual parts.
In short, the work asks security teams to change the unit of analysis from the single request to the whole interaction.
2. What is the Model Context Protocol?
The Model Context Protocol, known as MCP, is a standard that lets AI models connect to external tools and data sources, such as databases, files, payment services and software applications. An MCP server exposes a set of tools, each with a written description that tells the model what the tool does and how to use it. The model reads those descriptions and decides which tools to call.
The protocol emerged in late 2024 and has since been adopted in developer tools and desktop assistants, including Cursor and Claude Desktop. Its appeal is convenience: an agent can be given new abilities by connecting another server instead of by custom integration work. That convenience is also the source of the concern, because every connected server contributes text that the model treats as part of its instructions.
A useful comparison is with software libraries. A developer who installs a package trusts its authors and its updates. A person who connects an MCP server to an agent makes a similar decision, except that the server's text can directly shape what the model does, which gives it an influence closer to that of an instruction than of a passive library.
3. How does tool poisoning work?
Tool poisoning is an attack in which a malicious tool description steers an agent into behavior its user never approved. In the scenario the researchers describe, a poisoned description can lead a language model to send the user's queries, and the model's own responses, to a logging tool controlled by an attacker.
The mechanism rests on a simple fact the authors stress: tool descriptions are text that models read. Anyone who writes a description is therefore in a position to inject instructions, and the model may follow them because it has no reliable way to distinguish a legitimate usage note from a hidden command.
Earlier research in 2025 had already flagged tool-description poisoning and supply-chain risks in the MCP ecosystem. The TikTok paper builds on that concern by showing how the problem behaves in extended conversations that involve several servers, rather than in a single exchange.
Because the model reads the description as part of its normal operation, the manipulation can be invisible to the user. The person sees a helpful answer, while behind the scenes the agent may also have forwarded their question to a destination they never chose. This is why the researchers describe such tools as quietly turning agents against their users.
4. Why can sensitive data keep leaking over multiple turns?
A second finding concerns data that persists. Sensitive fields such as Social Security numbers can remain in a conversation's context over many turns and leak across server boundaries, even when the agent has been told to leave them out. An instruction to exclude a field in one turn does not guarantee that the information stops circulating later, because it remains available to the model and can be passed along when the model calls another tool.
This matters because agents often work with several servers at once, each run by a different party. Information that one server was entitled to see can reach another that was not, simply because the model carries it forward and includes it in later tool calls.
For organizations that handle regulated or confidential records, the implication is that a safeguard applied at one moment may not hold for the rest of the session.
The practical consequence is a mismatch between what an instruction says and what a system does. Telling a model to exclude a data field is a request expressed in language, and language-based controls are weaker than technical barriers that physically prevent information from reaching a given server.
5. Can harmless tool responses reveal personal information?
The third pattern involves indirect exposure of personally identifiable information. In controlled experiments on public MCP servers, the researchers found that legitimate tool responses could be combined to reconstruct personal details, even though no single server supplied a complete profile. Each response looked benign by itself, but together they allowed an observer to piece a person's identity back together.
This resembles a long-standing privacy problem known as aggregation, in which separate pieces of information that are individually harmless become revealing once joined. What is new in the agent setting is that the model itself performs the joining, automatically and across several services, as part of ordinary task execution.
The experiments covered database-backed servers, record-based tools and payment-style interfaces, the kinds of integrations that are common in business use and that often touch sensitive information.
Privacy specialists have long distinguished between direct identifiers, such as a government number, and quasi-identifiers, such as a postal code or birth date, which become identifying when combined. The paper's experiments suggest that agents working across servers can assemble such combinations without anyone intending it.
6. Why do single-turn security checks fall short?
The authors direct their sharpest criticism at current assessment practice. Most security reviews of MCP systems check each turn in isolation, asking whether a particular request or response is safe. That approach misses the cumulative risk that builds up across turns and across tools, which is where the failures the paper describes appear.
Their point is that evaluating MCP systems one turn at a time will overlook problems that only emerge across turns, especially when multiple servers participate. A test that passes at every individual step can still describe a system that leaks data after ten steps.
The finding has relevance for the growing number of companies, including those in finance and crypto, that are building agents able to read account data, prepare transactions or interact with payment services. Such agents may combine many tools, and the more tools involved, the more routes exist for instructions and data to cross boundaries.
Security teams commonly test software by checking whether individual inputs produce safe outputs. Conversations with agents are sequential, and the state built up in earlier turns affects later ones. A realistic evaluation therefore has to replay or simulate extended sessions, tracking what information has been seen and where it has been sent at each stage.
7. What do the researchers recommend?
The paper's recommendations are straightforward. Tool descriptions should be treated as untrusted input rather than as reliable instructions, since anyone who controls a description can attempt to shape the model's behavior. Risk should be evaluated across the full conversation instead of turn by turn, so that accumulated exposure is taken into account.
The authors also underline that every third-party MCP server is a potential entry point for poisoned instructions. Organizations that connect external servers to agents with access to sensitive data are, in effect, extending trust to the authors of those servers and to anyone who can alter their descriptions.
In practice, this points toward measures such as limiting which servers an agent can reach, restricting which data can flow between tools, and reviewing tool descriptions as carefully as software dependencies.
None of these steps removes the risk entirely, but they reduce the number of paths an attacker can use. Treating tool descriptions as untrusted also encourages designs in which the model's access is limited to what a given task requires, a principle security engineers refer to as least privilege.
8. What to watch next
The findings add to a growing body of work on the security of AI agents and will likely feed into how developers and standards groups think about testing. Evaluations that follow whole conversations, rather than isolated prompts, are the direction the paper advocates, and adoption of such methods would show whether the research is shaping practice.
No specific deadlines or product changes accompanied the paper. Readers tracking the area may look for responses from MCP client developers and server operators on how they handle tool descriptions and data persistence in multi-turn sessions.
Over time, the debate may also influence how buyers choose between agent platforms. Companies that manage sensitive customer information are likely to ask vendors how their products separate tool descriptions from trusted instructions and how long data stays in an agent's working context, questions that were less common when agents handled only single-step tasks.