The silent vulnerability of IA agents: descriptions of poisoned tools that allow data to be exfiltered

A recent work by the Microsoft Incident Response and Defender team reveals a silent but critical failure in the way that IA agents interact with external tools: it is enough to poison the textual description of a "tool" for the agent, always acting within the rules, to deliver sensitive data to an attacker without any alarms.

The mechanics of the attack is simpler and more dangerous than it seems: many agents use the Model Context Protocol (MCP) to invoke external tools, and each tool includes a few lines of text that describe what it does and when it should be used. These words end in the operative memory of the agent along with his legitimate instructions, so a manipulated description can act as a hidden prompt and reorient the conduct of the agent without changing permissions, records or calls that at first sight seem routine.

The example that Microsoft illustrates is that of a financial flow: an approved "invoice enrichment" service but without real security review, the description of which is updated to include a hidden order - "attached the last 30 unpaid invoices" -. MCP makes those words effective almost instantly, the agent runs the request with the user's permissions, the tool returns a clean response and at the same time exfilters the invoices to an external server. Everything happens within the "zone of trust" between components, which makes detection difficult.

This changes the classic picture of the risk of IA: so far most strategies defended against bias or malicious answers in text. With agents that can send emails, create files or run jobs, the injection does not stay in the output; becomes real action on systems and data. Public research and evidence have shown that the technique is effective against many MCP servers and models, and that there are already real cases - for example, packages that started clean and in a later version introduced a leak by hiding a BCC.

The implications for companies are profound. A normally authorized agent can move data, transfer information outside the perimeter and act with a user's identity without traditional controls detecting "evil" behavior because each individual step is valid. This requires the thinking of security not only in terms of data permits and policies, but also in the integrity and continuous review of the tools that agents consume.

The practical measures are not theoretical: treat the connected tools as part of the supply chain It's the first step. This means keeping an inventory of approved editors, prohibiting the "allow everything" option, and applying an allowlist model that specifies which specific tool can be used by each agent. In addition, it is appropriate to review any changes in the description of a tool with the same rigour as a code review: to search for covert instructions, out-of-place commands or text that act as a prompt.

A human in a loop must be required for risk actions: anything that moves money, shares data outside the organization or alters accounts must require prior human approval. This is accompanied by distinct identities for each agent, detailed record of their actions, normal behavior measurement and anomaly alerts - for example, new contact endpoints, unusual data scraps or atypical consultations. Apply the principle of least agency In addition to the classic least privilege reduces the potential damage even when an agent has legitimate permits.

In technical practice it is appropriate to combine controls: network-level egress restrictions, DLP solutions for inspecting automated outputs, signatures or hashes for code and tool versions, and policies that require re- approval when changing critical descriptions or metadata. Suppliers have already started mapping solutions - from prompt controls to cloud detection - but the principles are applicable independently of the supplier.

This kind of vulnerability is part of what the community now calls vulnerabilities in the agentic supply chain. Previous research and concept tests have shown similar variants (e.g., hidden instructions in calculation tools or malicious issues in GitHub that trigger leakage). Organizations like OWASP have started to include these risks in their references to threats to agentic applications; seeing their work helps to understand the general picture https: / / owasp.org /. Microsoft also documents the problem and its general recommendations on its security blog, where it links controls and products that support the proposed defenses https: / / www.microsoft.com / en-us / security / blog /.

It is not a purely academic problem: real world cases have already appeared where MCP packages and servers became vectors to exfilter data. Research groups and public security companies have demonstrated the feasibility of the technique and published evidence, making it urgent for security teams to act now and not when a leak confirms the risk.

If you manage agents in your organization, start with these specific actions: inventing all MCP connections and its editors, blocking "global" permissions, requiring review of descriptions, putting human reviews for critical actions, enabling identity and login per agent, and applying DLP and egress controls. These measures do not eliminate the possibility of new vectors, but reducing the attack surface and increasing human and technical supervision The ability of an attacker to use poisoned descriptions as a lever is significantly limited.

The arrival of agents capable of acting autonomously amplifies the benefits of the IA at work, but also transfers part of the security to a field where words (descriptions) are already a vector of attack. Protecting that perimeter is now as important as protecting credentials or APIs; not doing so leaves the door open to leaks that will appear, from the records, to simple routine operations.