A recent finding from Microsoft's security research exposes a subtle but serious vulnerability in how AI agents interact with external tools. Rather than relying on traditional code injection or rule violations, attackers can poison tool descriptions themselves—the metadata that tells an agent what a tool does—to orchestrate quiet data exfiltration.
The Attack Surface: Tool Descriptions as a Weapon
Model Context Protocol (MCP) tools allow AI agents to perform actions on behalf of users: querying databases, calling APIs, reading files. Each tool has a description that explains its purpose to the agent. Microsoft's research shows that an attacker controlling a tool description can craft it to appear benign while actually instructing the agent to exfiltrate sensitive data.
The elegance of this approach lies in its invisibility. The agent doesn't break any explicit rules. It doesn't execute unauthorised commands or bypass access controls. Instead, it follows the attacker's instructions embedded in what looks like ordinary documentation. The agent's normal reasoning process—interpreting the tool description and deciding how to use it—becomes the vector for compromise.
This is not a code vulnerability in the traditional sense. It's an outcome of how language models interpret natural language instructions, even when those instructions come from untrusted sources.
Why Default Protections Miss It
Standard security monitoring often looks for anomalous API calls, unusual data flows, or attempts to access restricted resources. But if the tool description itself is deceptive—framing a data exfiltration request as a routine operation—baseline anomaly detection may not flag it.
The risk scales with agent autonomy. A human reviewing each action before execution catches the problem. But as organisations push toward fully autonomous agents for cost and speed, the window for human review shrinks or closes entirely.
Infrastructure and security teams responsible for hosting AI applications or providing API endpoints need to consider that third-party tool integrations can become attack entry points, even if those integrations appear to be read-only or limited in scope.
What This Means for Hosted Environments
If your organisation runs AI agents or offers hosting for AI workloads, several layers of control become relevant:
- Tool registry validation. Don't trust tool descriptions provided by external sources. Require explicit approval and review of tool metadata before an agent can access it.
- Least-privilege tool design. Tools should return only the data absolutely necessary for their declared purpose. A metadata lookup tool should not have permission to read sensitive files or dump entire databases.
- Agent segmentation. Isolate agents handling sensitive data from those that interact with third-party integrations. Use network policies and database access controls to enforce this at the infrastructure level.
- Audit logging. Log not just API calls but also the tool descriptions and parameters the agent received. This creates an audit trail if something goes wrong.
- Rate limiting and resource caps. Limit the volume of data a single agent interaction can retrieve or transmit. This doesn't prevent exfiltration but makes large-scale theft harder.
Broader Implications
This research underscores a broader shift in attack surface. As organisations integrate AI more deeply into infrastructure and automate high-stakes decisions, the focus of security moves away from preventing code execution and toward managing the flow of information and the correctness of agent reasoning.
Traditional perimeter security, firewalls, and access controls become less effective when the threat isn't a compromised user or service, but rather a clever manipulation of how a trusted agent interprets its instructions.
Teams deploying autonomous agents—particularly those that interact with databases, internal APIs, or cloud services—should treat tool descriptions as security-critical. Validate them, version them, and monitor their changes as carefully as you would any other part of your authentication or authorisation system. The agent is only as trustworthy as the information it's given about what it's allowed to do.
