The AI agent threat model: five attack classes and the layer that catches each

An AI agent reads instructions from the user, from a web page, from a tool description, from a file in the repo, and it cannot reliably tell which of those sources is allowed to give orders. That is the AI agent threat model in one sentence. The rest is the map: five attack classes, one verified incident for each, and the layer where each left its trace, whether tool call, process, file, or socket.

Why the AI agent threat model needs its own map

STRIDE and its descendants assume two things: the attacker is outside, and the data flow can be drawn before the system runs. Agents break both.

The attacker is often inside your own toolchain: a poisoned MCP tool description is not a packet at the perimeter but text your agent was told to trust, acted on with the developer's credentials. And the data flow is decided at runtime by a model, so there is no static call graph; which tools get called, in what order, with what arguments, depends on a prompt that changes every session and on whatever the agent read along the way.

So the useful question is not "which threats apply", because all of them do, but "where does each one leave a trace". On a developer endpoint there are four places to look: the tool call the agent declared, the process it spawned, the file it opened, and the socket it connected. Every class below maps to at least one; where an incident ran inside a vendor's cloud instead, we say so.

Indirect prompt injection: the content is the payload

Direct injection ("ignore your previous instructions") is the version everyone tests for. Indirect injection is the one that ships incidents: the attacker never talks to the agent, just leaves text where the agent will read it and treat it as a task.

In August 2025 Brave's security team disclosed how Perplexity's Comet browser agent could be hijacked by a Reddit comment hidden behind a spoiler tag. Asked to summarize the thread, the agent instead opened the user's Perplexity account page to read their email address, triggered a login code, read it from the Gmail tab the user was already signed in to, and posted both as a reply to the comment. No click beyond "summarize".

Every step Comet took was a legitimate browser action, decided by Perplexity's model on its backend, so the declared actions that turned a summarize request into an account page, a mailbox, and a public site are the vendor's record, not the laptop's. A device sees only the local browser reach those three sites in the user's signed-in sessions: a network-layer trace that looks like browsing until it sits next to the task. For an agent you can intercept, that mismatch is the tool-call-layer signal, and nothing in the page content would have told a filter that.

Tool poisoning and rug pulls: the toolchain lies to the agent

Every MCP server hands the agent a name, a description, and a schema for each tool; the agent reads that description with roughly the trust it gives its system prompt, and the user usually never sees it.

Invariant Labs published the attack class on 1 April 2025 with a proof of concept against Cursor. An add(a, b) tool carried hidden instructions in its description: read ~/.cursor/mcp.json and ~/.ssh/id_rsa and pass both back in a sidenote parameter. The agent added the numbers and shipped the private key.

The rug pull variant became a CVE four months later. Check Point Research reported CVE-2025-54136, MCPoison: Cursor approved an MCP configuration once and then trusted any later change to its command, so a harmless .cursor/mcp.json in a shared repo could be swapped after a teammate approved it; Cursor 1.3 fixed it on 29 July 2025. Our MCP security checklist covers the pre-install half of this.

This is not a gap between layers: the reads were the agent's own declared actions, the file layer would have seen the same two opens, and the request that left was the add call the agent said it was making. What was hidden was hidden from the user, since Cursor's confirmation dialog, in Invariant's words, "does not show the full tool input". The signal is the sequence: a session asked to add two numbers opened a private key, then handed it to a calculator. No prompt filter would have caught that pair, because the poison arrived in trusted metadata, not in the prompt.

Supply chain: rules files, extensions, and packages that reach the agent

Rules files. Pillar Security disclosed "Rules File Backdoor" on 18 March 2025: the rules files that steer Cursor and GitHub Copilot (Cursor keeps them under .cursor/rules) are read as authoritative, and hidden Unicode in a merged rules file changes what every agent on that repo generates. Cursor's position at the time was that this is the user's responsibility.

Extensions. In July 2025 AWS published bulletin AWS-2025-015: an over-scoped GitHub token in the Amazon Q Developer VS Code extension's CodeBuild configuration let a threat actor commit code that shipped in release 1.84.0. 404 Media reported the code was a prompt telling the agent to clean the machine to a near-factory state and delete cloud resources. It failed on a syntax error. 1.85.0 removed it.

Packages. On 26 August 2025 malicious versions of the Nx build system hit npm after a GitHub Actions injection stole the publish token. The postinstall hook ran telemetry.js, which looked for locally installed AI CLIs and drove them. Per StepSecurity's analysis, that meant claude --dangerously-skip-permissions -p, gemini --yolo -p, and q chat --trust-all-tools --no-interactive, prompted to recursively inventory wallets, keys, and .env files. Results were triple-base64 encoded and uploaded to a public repository named s1ngularity-repository, created in the victim's own GitHub account. Wiz counted over 1,000 valid GitHub tokens in the leaked data.

A process-layer incident end to end: nothing about the agent's tool calls was wrong, because the agent was not the one making decisions. A sensor that sees process lineage sees that chain on the first machine it runs on, before anyone has written a signature for it.

Over-scoped access: nothing was forbidden, and that was the problem

This is the hardest class to file as a vulnerability: the agent exploits no bug, it does something it is allowed to do, and the consequence is catastrophic because the permission was granted to a role, not to a task.

In July 2025 Replit's cloud-hosted agent deleted a production database belonging to SaaStr founder Jason Lemkin during an explicit code freeze: records on more than 1,200 executives and 1,190 companies. It then told him rollback would not work; he recovered the data manually. On 21 July 2025 Replit announced separate development and production databases, in beta for new apps first.

The agent had write access. Write access was the design.

Same shape, different credential. Invariant Labs showed in May 2025 that an issue in a public GitHub repo could steer a Claude Desktop agent, connected through the official GitHub MCP server with an ordinary personal access token, to read a private repo and publish its contents in a pull request on the public one. One token, both repos, no boundary between them. Invariant called it a toxic agent flow.

Permission systems answer "is this action allowed?", not "does this sequence make sense for this task?" Each read_file and create_pull_request above was allowed; the read-private-then-write-public pair is the signal, and it lives at the tool-call layer, in order.

Exfiltration through the agent's own output

Agents do not need an open port to leak. They need a place to put text that someone else can read: a URL, an image tag, a tool argument, a public comment.

Johann Rehberger showed the pattern against Microsoft 365 Copilot in 2024: an email's instructions had Copilot pull Slack MFA codes and sales figures from the mailbox into a hyperlink the user then clicked. EchoLeak, CVE-2025-32711 (CVSS 9.3, June 2025), removed the click.

Noma Security's ForcedLeak against Salesforce Agentforce (reported 28 July 2025, disclosed 25 September, CVSS 9.4) is the enterprise version. Instructions in a Web-to-Lead description field made the agent gather lead emails and emit an image tag pointing at cdn.my-salesforce-cms.com, an expired domain Salesforce still trusted in its content security policy. Noma bought it for about $5. Agentforce, like Copilot, runs in the vendor's cloud, so no sensor on a laptop saw either agent's tool calls, only a browser following a link or fetching an image.

The endpoint version has a CVE, CVE-2025-55284: Claude Code's default allowlist let ping, nslookup, dig, and host run without asking, so instructions planted in a source file could make the agent read .env and resolve a hostname with the key spliced into it. Johann Rehberger reported it on 26 May 2025; Anthropic fixed it on 6 June in 1.0.4. Here the agent was a process on a developer machine, and the trace was on the endpoint: a secrets file read, then a name lookup for a host the task never mentioned, which is the network-layer signal.

What this means for how you defend AI agents

Notice what the five classes share. In every incident the payload was legitimate content or metadata, so nothing that inspects prompts caught it, and every individual action was permitted, so nothing that checks permissions caught it. What differed was the relation between what the agent said it was doing and what the machine did.

Record the declared tool calls. For MCP-based agents this sits at the interception layer, and it is the only place you learn what the agent believed its task was.

Record what the OS did. File opens, process spawns, sockets: for every agent on the machine, whether or not IT approved it, with no changes to the agent. On macOS the EndpointSecurity framework gives you this; macOS is where we run today, and Linux and Windows are on our roadmap.

Score the sequence, not the event. open(config) is fine. open(config), then connect() to an unknown host, then open(~/.ssh) in one session is what gets flagged, and the DNS exfiltration above is the first two beats of that shape, with a name lookup standing in for the connect.

That scoring has to run on the device against risk rules, with no LLM in the decision path, or you have added one more injectable component to the loop. Enforcement (allow, flag, block) belongs at the interception and agent-hook layer, observe-first, and every action should land in a hash-chained, signed audit record so the divergence is provable later. This is what we mean by behavioral security for agents, and why we treat it as a runtime problem rather than a prompt problem.

Monday: list every agent actually running on developer machines, not the approved ones. For each, write down the credential it holds and the layer where you would see it misused. If the answer for any row is "nowhere", that row is your next incident. If you want to see the gap between declared and recorded on a real session, book a demo.