AI Agent Incident Teardowns: Anatomy of Real Prompt-Injection and Exfiltration Breaches

When an AI agent gets breached, the post-mortem rarely reads like a classic hack. There is no exploited buffer, no stolen password, no malware dropped on a host. Instead, the agent does exactly what it was told to do — by an attacker who slipped instructions into content the agent was trusting. That is what makes a breach teardown of an AI agent incident so useful: the failure lives in the design, not the code.

This piece tears down three publicly documented incidents — EchoLeak in Microsoft 365 Copilot, the Slack AI data-exfiltration disclosure, and the GitHub MCP server hijack — and pulls out the lessons learned that apply to every agent you ship. They are concrete instances of the broader patterns we survey in the 2026 AI agent threat landscape. No invented victims, no made-up numbers. Just what happened, why it worked, and what to do differently.

What do AI agent breaches actually have in common?

Across nearly every public AI agent incident, the breach follows the same three-beat rhythm: untrusted content reaches the model’s context, the model treats that content as instructions, and a tool the agent can call turns those instructions into action in the real world. Prompt injection is the entry, tool access is the amplifier, and exfiltration is the payout. Remove any one of the three and most of these incidents collapse into a non-event.

That is the single most important takeaway, and it holds whether the attacker emails a victim, posts in a public Slack channel, or files a GitHub issue. The agent is not “tricked” in some exotic way. It reads attacker-controlled text, cannot reliably tell that text apart from its legitimate task, and then exercises capabilities — sending links, fetching URLs, reading private repositories — that it was granted for benign reasons.

The corollary matters just as much: the more capable the agent, the larger the blast radius. An agent that can only answer questions leaks at most what it was given. An agent that can browse, call APIs, write to a repository, or render Markdown that auto-fetches a URL can be turned into an exfiltration channel without the user ever clicking anything. Capability is not free; every tool you connect is a new line in the attacker’s playbook.

Teardown 1: EchoLeak — the zero-click exfiltration of Copilot

What it was. EchoLeak (CVE-2025-32711) was responsibly disclosed by researchers at Aim Security and publicly detailed in June 2025; Microsoft had already patched it server-side in May 2025, before public disclosure. It carried a CVSS score of 9.3 and is widely described as the first real-world zero-click prompt-injection exploit against a production LLM system. Microsoft stated there was no evidence of exploitation in the wild.

The attack chain. The attacker sent the victim an ordinary-looking email. The victim never had to open or click anything. Later, when the user asked Microsoft 365 Copilot a normal question, the retrieval layer pulled the malicious email into the model’s context as a relevant source. Hidden instructions in that email then redirected the agent — a pattern the researchers named an “LLM Scope Violation,” where untrusted external input causes the model to reach across a trust boundary into privileged organizational data.

Why it worked. EchoLeak is a teardown of layered controls failing in sequence. The payload evaded Microsoft’s cross-prompt-injection (XPIA) classifier, slipped past link redaction by using reference-style Markdown, and used auto-fetched images plus a permitted Microsoft Teams proxy to push data out without tripping the content-security policy. Each control was reasonable on its own; the chain defeated all of them because they were guarding the symptom (suspicious-looking output) rather than the root condition (untrusted content blended directly with trusted context).

The lesson learned. Classifier-based prompt-injection filters are speed bumps, not walls. If your agent’s retrieval pipeline can pull external, attacker-influenced content into the same context window as privileged data, you have an exfiltration risk no amount of keyword filtering closes. The durable fix is structural: isolate untrusted context, and lock down the egress paths — Markdown rendering, auto-fetched images, redirect proxies — that an injected instruction could use to phone home.

Teardown 2: Slack AI — when a public message reads your private channels

What it was. In August 2024, the PromptArmor team disclosed an indirect prompt-injection flaw in Slack AI that allowed data to be exfiltrated from private channels and direct messages the attacker had no access to. Slack deployed a patch and said it had no evidence of unauthorized access to customer data.

The attack chain. The attacker needed only the ability to post in a public Slack channel — including a public channel they had not joined and that no one else was watching. They planted a message containing adversarial instructions. When a legitimate user later asked Slack AI a question, the assistant searched across channels, retrieved the attacker’s planted message, and followed its embedded instructions. The kicker: Slack AI would render the exfiltration path as a clickable link, with private-channel content (an API key pasted into a DM, for example) encoded into the URL. One click by the victim, and the secret left the building.

Why it worked. This was a search-scope problem dressed up as an AI problem. Slack AI was permitted to fetch data from both public and private channels — including public channels the querying user had never joined — and to fold all of it into one answer. The attacker did not need to know the secret or even be in the workspace’s private spaces. A later update that pulled files from channels and DMs into answers widened the surface further, turning an uploaded PDF into a fresh injection vector.

The lesson learned. Your agent’s authority is the union of everything it can read and everything it can write. If retrieval crosses a permission boundary the user would not cross manually, the agent has effectively granted attackers that crossing. Scope retrieval to what the requesting user can legitimately see, treat every retrieved message as untrusted, and never let model output render an attacker-controllable link that smuggles data in its parameters.

Teardown 3: GitHub MCP — tool abuse by way of a filed issue

What it was. In May 2025, Invariant Labs demonstrated a critical issue affecting the official GitHub MCP integration — the connector that lets AI coding agents act on GitHub through the Model Context Protocol. The official server is widely deployed and featured across major AI-platform integration guides, which is precisely why the finding landed hard.

The attack chain. Picture a developer who works across public and private repositories, using an AI agent wired to GitHub with a personal access token. An attacker files a malicious issue on one of the developer’s public repositories. The issue text contains instructions: go read the private repositories, then post what you find back here in the public repo. When the developer innocently asks their agent to “look at the open issues,” the agent ingests the poisoned issue, follows the embedded commands, reads private data its token can reach, and writes it into a place the attacker can see. Salary files, unreleased project details, internal business data — all exfiltrated through the agent’s own legitimate tools.

Why it worked. Invariant was explicit that this is not a bug in the GitHub MCP server code. It is an architectural condition. Developers hand agents broad personal access tokens that span every repository they touch. The agent has no notion that “the public issue I’m reading” and “the private repo I can write from” sit on opposite sides of a trust boundary. The injection is the trigger; the over-scoped token is the loaded weapon — the same identity-shaped failure that recurs across the OWASP Top 10 for Agentic Applications.

The lesson learned. Least privilege is the control that actually moves the needle here, because there is no clean filter for “is this issue text malicious.” The researchers’ own mitigations are operational: give agents narrowly scoped, least-privilege tokens, and constrain a session to a single repository so a poisoned public issue cannot reach across into private code. When you cannot reliably detect the injection, you contain what the injection can do.

How do these three incidents compare?

Incident	Injection vector	Tool abused	Data exfiltrated	Root cause
EchoLeak (CVE-2025-32711)	Crafted email pulled in via retrieval (zero-click)	Markdown render, auto-fetched image, allowed proxy	Org data in Copilot’s scope (chats, files)	Untrusted content blended with privileged context
Slack AI (PromptArmor)	Message in a public channel	Answer rendering as a clickable link	Private channel / DM secrets	Retrieval crossed user permission boundaries
GitHub MCP (Invariant Labs)	Malicious GitHub issue	MCP read/write tools on repos	Private repository contents	Over-scoped access token, no session isolation

Read the table top to bottom and the pattern is unmistakable: different products, different vectors, identical anatomy. Untrusted input becomes instruction; a granted capability becomes the exfiltration channel.

What should defenders actually change?

The honest, uncomfortable answer from every teardown is that you cannot filter your way out of prompt injection. Treat detection as defense-in-depth, then build the controls that hold even when detection fails:

• Treat all retrieved and tool-returned content as untrusted. Email bodies, channel messages, issue text, fetched web pages — none of it is a trustworthy instruction source, no matter how relevant the retriever scored it.
• Scope retrieval to the requesting user’s real permissions. If the human cannot read it manually, the agent should not silently read it on their behalf and fold it into an answer.
• Apply least privilege to every token and tool. Narrow scopes, per-session repository limits, and short-lived credentials shrink the blast radius of an injection that does land.
• Lock down egress. Most of these breaches needed an outbound path — a rendered link, an auto-fetched image, a write to a public location. Restrict where agent output and agent actions can send data.
• Separate untrusted context from privileged context. The EchoLeak “scope violation” is the canonical failure: keep external content from sharing a trust boundary with sensitive internal data.
• Log and review agent actions, not just prompts. The breach shows up in what the tool did, so make tool calls auditable and alert on cross-boundary reads or writes.

None of these are exotic. They are the same containment instincts security teams already apply to service accounts and supply chains, pointed at a new kind of confused-deputy problem. For the attacker’s-eye view of how these chains are constructed in the first place, see our breakdown of the agent attack surface and threat model. The agent is the deputy; the attacker supplies the orders; least privilege and egress control decide how much damage the orders can do.

The teardowns converge on one sentence worth keeping: an AI agent is exactly as dangerous as the most sensitive tool it can call combined with the most untrusted content it will read. Design as if both halves of that equation are already compromised, because in every incident above, they were.

Sources

• EchoLeak / CVE-2025-32711: Aim Security disclosure coverage and analysis, arXiv research write-up, SOC Prime
• Slack AI exfiltration: PromptArmor disclosure, Simon Willison analysis, The Register
• GitHub MCP hijack: Invariant Labs research, DevClass coverage