Agentic AI Attack Paths

The short version

An AI agent is an identity with a language model attached. It holds credentials, reads content it did not write, calls tools and decides what to do next. An attacker does not have to break any of that. They have to place instructions where the agent will read them and let the agent’s own access do the work.

The paths below come from published vendor research, a public disclosure and one first-party threat report. None of them depends on a flaw in a model. Each depends on a trust decision made when the agent was connected to data and tools.

Why the attack path changes

In a conventional intrusion the attacker has to obtain access first: a stolen credential, an exploited service, a phished user. An agent already has legitimate access. It holds a token, a mailbox grant or a repository scope, and it acts on instructions it finds in natural language. The boundary that matters moves from who can log in to what content can influence an identity that is already logged in.

Three conditions create the path. The agent reads content from sources the organization does not control: issues, emails, documents, web pages, tool descriptions. It holds privileges wider than the task in front of it. And it can send data somewhere, through a pull request, an email or an outbound call. With all three present, the path is open. Removing any one closes it. This is our analytical framing, not a published standard, but every case below fits it.

Five documented paths

What the logs will show

Every hop in paths one to four is authorized. The agent authenticates as itself, calls tools it may call and writes to places it may write. Microsoft makes the same point about its invoice scenario: each step looks legitimate, so nothing alarms, and the weakness sits in the trust boundary, not in a product bug.

That is why rule-based detection struggles. The signal is in sequence and context. An agent reads a public issue and then enumerates private repositories. An invoice query ends in a call to an endpoint the agent has never used. A security team that logs only authentication and API success will see nothing unusual.

Two situations that are easy to confuse

Path five is a different problem from the other four. In the first four the organization’s agent is the victim and the attacker’s instructions arrive inside content. In the case Anthropic reported, the attacker built the agent.

According to Anthropic, the operators posed as staff of a legitimate security firm and split the work into requests that each looked harmless. The model carried out an estimated 80 to 90 percent of tactical operations. Humans contributed an estimated 10 to 20 percent of effort, at decision points such as approving exploitation or deciding what to exfiltrate. About 30 entities were targeted and a small number of intrusions succeeded. The attackers relied mostly on commodity open-source tools rather than custom malware.

Two cautions. The figures are the provider’s own estimates. And the report says the model overstated findings and sometimes fabricated data, which slowed the operators. That is a limit today, not a guarantee about tomorrow. For defenders the practical change is tempo: reconnaissance and credential testing at sustained machine speed, driven by tools they already know how to detect.

How the OWASP list maps

The OWASP Top 10 for Agentic Applications, built with input from more than 100 practitioners, names ten risk categories. Five line up with the paths above: Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain Vulnerabilities, and Memory and Context Poisoning. The last is the persistence risk. If an agent stores what it reads, one injected instruction can shape behavior well after the session that received it.

What should change

1. Give every agent its own identity. Not a shared service account and not an engineer’s personal token. Microsoft recommends a distinct identity per agent, with its actions logged and a behavioral baseline that flags new endpoints, large data pulls and unusual queries.

2. Scope to the task, not the user. Microsoft frames this as least agency: limit what the agent may decide, not only what it may reach.

3. Break the three conditions. For each agent, list the untrusted content it reads, the private data it can reach and the places it can send output. If all three are present, redesign before adding controls.

4. Treat tools as supply chain. Keep an approved publisher list, turn off allow-all, pin versions and review tool description changes.

5. Put human approval on irreversible actions, and make it count. In the GitHub case the victim had set tool calls to run without per-action confirmation. Blanket approval is no approval.

6. Log at the action level. Capture tool calls, arguments, destinations and the content that preceded them, so an investigator can reconstruct why the agent acted.

7. Plan revocation. Know how to cut an agent’s credentials and tool access within minutes.

What the evidence does not show

Public evidence of production breaches through an organization’s own agents is thin. Most documented paths are researcher demonstrations, benchmarks or vendor-observed cases, and no reliable public count of affected organizations exists. Read the paths as credible and reproducible, not as a measure of prevalence. The mitigations Microsoft recommends are architectural for the same reason: design should assume an injection will sometimes succeed.

Next step

A practical starting point is an inventory of every agent in production or pilot: the identity it runs as, the tools it can call, the data it can reach and the content it reads. Then run the three conditions against each one.

Sources

• OWASP Gen AI Security Project: OWASP Top 10 for Agentic Applications genai.owasp.org

• Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign anthropic.com

• The Hacker News: Microsoft warns of poisoned MCP tool descriptions (reporting guidance from Microsoft Incident Response and Defender research) thehackernews.com

• Docker: MCP Horror Stories: The GitHub Prompt Injection Data Heist (summarizing research by Invariant Labs) docker.com