How real AI assistants and agents were hijacked
In 50 of 52 hijacks of shipped AI assistants and agents, the instruction that took over came from text the user never wrote: a repo issue, a web page, a shared document or an email.
Figure 1. Where the injected instruction entered, for the 52 of 59 cases that had one (the other 7 were tool-path flaws or malicious code without an injected prompt). White: content written by someone other than the user; grey: typed by the attacker directly.
Headline numbers
- 50 of 52 (96%) hijacks with an injected instruction were steered by text the user never wrote: a repo issue or file, a web page, a shared document, an email, a ticket. Only 2 were typed by the attacker directly.
- 39 of 59 (66%) would have been blocked by an injection-safe tool gate: least-privilege tools, risky calls held while untrusted content is in context, and an outbound allow-list. That is 75% of the 52 injection cases and 64% of the 45 vendor-confirmed cases.
- 56 of 59 (95%) if the allow-list is destination-strict. In 17 cases the data left through a domain a normal allow-list trusts, such as Microsoft’s Teams proxy, GitHub’s image proxy, a Google Form or an expired domain still on Salesforce’s allow-list.
- 3 of 59 could not be blocked at the gate: the harm happened outside the agent’s tool calls (malicious code in a released extension, a poisoned npm package, a UI token leak).
- 39 days was the median from private report to fix (interquartile range 13–50, range 3–140), across the 19 cases where both dates are published.
- 49 of 59 (83%) needed no click beyond normal use: the victim asked a normal question, ran a normal task, or did nothing at all (8 zero-click).
- 37 leaked data (63%) and 18 gave code execution (31%) on a developer machine, CI runner or agent VM; 5 exposed credentials or tokens.
- 2 documented in the wild, 2 partial. The rest are researcher findings, fixed or disclosed before any known abuse.
What a tool gate would have done
A gateway between the agent and its tools does four things: it allows only allow-listed, pinned tools and MCP servers; it holds high-risk calls (shell, config writes, privileged record writes, sending messages) for approval whenever untrusted content is in the agent’s context; it runs each tool with least-privilege scopes; and it lets outbound data go only to allow-listed destinations. We judged each case against that rule.
| Gate verdict | Cases | What it means |
|---|---|---|
| Blocked | 39 | The harm needed a step the gateway stops |
| Blocked if destination-strict | 17 | Stopped only if outbound data may go only to destinations the attacker cannot write to, or tool provenance is checked |
| Not blockable at the gate | 3 | The harmful step happened outside the agent’s tool calls |
Table 1. Gate verdict for all 59 cases. Allow-listing by domain is not enough on its own: destinations must be ones the attacker cannot write to.
Cases
1. EchoLeak, Microsoft 365 Copilot (CVE-2025-32711, June 2025)
One crafted email sat in the mailbox. When the user later asked an ordinary question, Copilot pulled it into context, and the email’s instructions made Copilot put sensitive context into an image URL routed through an allow-listed Microsoft domain.
Microsoft fixed it server-side and rated it critical (9.3). Its record calls it “AI command injection in M365 Copilot”.
Sources: MSRC · Researchers’ paper
2. ForcedLeak, Salesforce Agentforce (September 2025)
The instruction was planted in a public Web-to-Lead form. When an employee asked Agentforce to process the lead, CRM data left in an image URL. The URL pointed to a domain still on Salesforce’s allow-list that had expired; the researchers bought it for $5.
Salesforce shipped Trusted URLs Enforcement 42 days after the report.
Sources: Noma Security
3. GitHub MCP server (May 2025)
A malicious issue in a public repo told the user’s agent to read the user’s private repos. The agent wrote what it found into a public pull request. The token could read private repos and write public ones, and nothing scoped it to the task.
No change to the server code was needed; the cheapest control is least-privilege tool scopes.
Sources: Invariant Labs
4. GitHub Copilot in VS Code (CVE-2025-53773, August 2025)
Injected text in a project made the agent edit its own settings file to turn on auto-approval, then run shell commands.
Fixed 44 days after the report. Writing the agent’s own configuration is the textbook call a tool gate holds for approval.
Sources: MSRC · Embrace The Red
5. Supabase MCP with Cursor (July 2025)
A customer support ticket carried the instruction. A developer asked the agent to look at open tickets; the agent ran SQL with a role that bypasses row-level security and wrote a table of integration tokens back into the ticket thread.
Sources: General Analysis
6. postmark-mcp (September 2025, exploited in the wild)
A fake “Postmark” MCP server on npm added one line that blind-copied every email an agent sent to the attacker. Postmark warned customers it had nothing to do with the package.
Pinning tools to verified publishers, the gate’s allow-list, is the control.
Sources: Postmark
What this means for a buyer
- Untrusted content is the entry point. The pattern repeats across vendors and years: content someone else wrote reaches an agent that holds real permissions (mailbox, CRM, repos, shell), and the agent can send data out.
- Many of the published fixes closed the path at the tool layer. Vendors stopped rendering images and links, enforced trusted URLs, required approval for configuration writes and narrowed allow-lists.
- A gate covers most of the set. Least-privilege tools, risky calls held while untrusted content is in context, and outbound data only to strict destinations cover 56 of 59 cases. Red-team testing before launch finds the rest, before an outside researcher spends 39 days waiting for a fix.
How we measured
Scope. Publicly disclosed prompt-injection, tool-abuse and agent-hijack cases in shipped AI products, disclosed between 1 January 2023 and 12 November 2026. Inclusion criteria were written before collection: a shipped product or official package, a public disclosure in the window, at least one primary source that we fetched and read (vendor advisory or statement, CVE, NVD or GHSA record, or the original researcher’s write-up), and an AI assistant or agent steered by instructions it should not have followed, or an agent tool path abused. Five research passes screened 79 candidates; 59 cases from 31 vendors are included, and the 20 exclusions are listed with reasons in excluded.csv.
Sources and checks. 102 sources, each with a verbatim quote of 25 words or fewer. On 12 November 2026 every source URL was fetched again and every quote matched word for word (102 of 102). For each case in the time-to-fix figure, both the report date and the fix date were found on one of the case’s own source pages. Descriptive fields (attack path, abused capability, vendor fix) were written from the fetched pages; each row links its primary source.
Tiers. 45 cases have a vendor fix, CVE, advisory or vendor statement on record (tier A); 14 rest on the researcher’s account (tier B). Headline gate figures are also given for tier A alone. 22 cases carry a CVE.
Coding and second coder. Each case records where the instruction entered, how much user interaction was needed, what was lost, exploitation in the wild (only where a source says so), the gate verdict and the cheapest control. A second coder, Claude Opus 5.5 at temperature 0, coded the two control fields blind to our coding, from the case’s factual fields only: 98.3% agreement on the cheapest control (κ = 0.85) and 91.5% on the gate verdict (κ = 0.82). Every fact comes from the sources; the model coded only the control fields.
What the numbers cover. The set is disclosed cases, most of them found by security researchers and fixed before public disclosure, so it shows which attack paths work against shipped products rather than how often attackers use them. Time to fix is published for 19 cases, so the median describes coordinated disclosures. No source states a money cost for any case, so the study reports access gained, not cost. Gate verdicts follow the written rule above and were checked by the blind second coder.
Data
- cases.csv (90 KB): one row per case (59): dates, product, attack path, impact, vendor fix, time to fix, gate verdict, both coders’ control codes
- sources.csv (26 KB): 102 sources: URL, publisher, date, type and a verbatim quote of 25 words or fewer
- excluded.csv (4 KB): the 20 of 79 screened candidates left out of the 59 cases, each with the reason
- summary.json (8 KB): every number on this page