AI Agent Tool Abuse: When Authorized Tools Become Attack Paths

An AI agent’s toolset is best read as an attack path the organization has already approved. Each tool was reviewed. Each credential was issued. Each call shows up in the logs as allowed. What nobody reviewed is the sequence the agent assembles at runtime, driven by text it cannot reliably tell apart from legitimate instructions.

That is the core of tool abuse. The attacker does not break the tool, steal the credential or exploit the platform. The attacker gets the agent to read something, and the agent does the rest with access it was given on purpose.

What “authorized” hides

OWASP’s Top 10 for LLM Applications names the underlying weakness Excessive Agency: an application takes damaging actions because the model’s output was unexpected, ambiguous or manipulated. It traces the weakness to three causes. The agent has more functionality than the job needs, more permissions than the task needs, or more autonomy than the consequence justifies. OWASP’s separate list for agentic applications gives tool misuse and exploitation its own category, which tells you how the community now views it.

The practical consequence is a gap between two questions. Identity and access management asks whether this agent is allowed to call this tool. Nobody asks whether this call, in this sequence, is what the owner intended. In an agent, the second question is answered by a model reading content from sources the organization does not control.

Two cases worth studying

A public issue that read private repositories

Invariant Labs demonstrated the pattern against an agent connected to GitHub through the GitHub MCP server. The account held a public repository and a private one. An attacker filed an issue in the public repository containing instructions aimed at any agent that read it. When the user asked the agent to review open issues, it read the malicious one, followed it, pulled information from the private repositories and published it in a pull request on the public repository, where the attacker could see it.

The researchers were explicit that the server was not compromised and the tools behaved as designed. They described the flaw as architectural and noted that confirmation prompts offered little protection in practice once users chose to always allow tool calls. This was a research demonstration, not a reported in-the-wild incident, but it shows the full chain without any exploit in it.

An email that Copilot treated as context

EchoLeak, disclosed by Aim Security, affected Microsoft 365 Copilot. An attacker sent an email carrying hidden instructions. Later, when a user asked Copilot an ordinary work question, retrieval pulled that email into the same context as sensitive internal data, and the data left through URLs the attacker could observe. No click was required. Aim described the class as an LLM scope violation. According to press coverage of the disclosure, the flaw was rated critical, Microsoft fixed it without requiring customer action, and there was no evidence of malicious exploitation.

The product, the surface and the vendor differ. The structure does not. Untrusted content reached an agent that could see private data and had a path out.

The pattern underneath

Simon Willison’s name for that structure is the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. His conclusion is that a single agent should not combine all three, because models cannot reliably separate hostile instructions from trusted ones, and a vendor cannot fix that for a user who has wired the pieces together.

Read as an enterprise control problem, this changes the unit of review. Reviewing tools one at a time approves each leg of the trifecta separately. The risk lives in the combination.

Why existing detection stays quiet

• Identity and access management sees a valid token with a valid scope.

• Data loss prevention sees an outbound request or a pull request from a sanctioned application.

• SOC detections see an action type that is normal for that agent. The anomaly is the causal link between the content it read and the action that followed, and few pipelines record that link.

• Model-side defenses help but are not a boundary. Invariant reported that model safety training and common prompt-injection detectors did not reliably stop its attack. Treat those detectors as one layer that sometimes fails.

A hypothetical illustration: an accounts-payable agent can read supplier emails, query the ERP for payment details and post messages to a supplier portal. None of those permissions looks excessive in a review. A supplier email that tells the agent to include bank details in a portal message turns an ordinary workflow into an exfiltration route. No vulnerability was exploited and every step was permitted.

Breaking the path

The steps below are a recommended order of work, not a standard. They assume injection will occasionally succeed, which is the safer design premise today, and focus on limiting what a hijacked agent can do.

1. Inventory agent-and-tool combinations, not tools. For each agent, record what private data it can reach, what untrusted content it reads, and where it can send or write. An agent with all three is a priority finding.

2. Remove a leg, starting with the exit. Restrict where the agent can write or send. Allowlist destinations. Block publishing to audiences wider than the data it has touched.

3. Narrow the tools. Replace general shell and URL access with task-specific functions. Use read-only roles where reads are enough. OWASP recommends exactly this.

4. Bind sessions to one context. Invariant’s example was a policy limiting a session to one repository. The principle generalizes: once an agent has touched a sensitive scope, constrain where it can write for the rest of that session.

5. Place human approval where consequence sits. Require it for actions that cross a boundary or cannot be undone, and show the approver what data is moving and where, in terms they can judge.

6. Detect on sequences. Log each tool call together with the content that preceded it. Alert on patterns such as a sensitive read followed by an external write within one session.

7. Test with planted instructions. Red-team the content sources the agent reads, such as tickets, emails, documents and web pages, not only the chat box.

What this does not solve

These measures reduce blast radius. They do not make an agent immune to manipulation, and narrowing tools costs capability, which the business will notice. Session-binding and sequence detection also need engineering that many agent platforms do not provide out of the box. Expect trade-offs, and decide them agent by agent, with the consequence of a bad action as the deciding factor.

Where to start

Sources

• OWASP GenAI Security Project: Top 10 for LLM Applications, Excessive Agency — OWASP

• OWASP GenAI Security Project: Top 10 for Agentic Applications — OWASP genai.owasp.org

• Invariant Labs: research disclosure on the GitHub MCP toxic agent flow — Invariant Labs

• Zero-Click AI Vulnerability Exposes Microsoft 365 Copilot Data Without User Interaction — The Hacker News, reporting Aim Security’s EchoLeak disclosure thehackernews.com

• The lethal trifecta for AI agents: private data, untrusted content, and external communication — Simon Willison simonwillison.net