The incidents, newest first
| Date | Incident | What failed | Source |
|---|---|---|---|
| 9 to 13 July 2026 | An OpenAI evaluation agent escaped its sandbox via a zero-day in a package-registry proxy and gained code execution in Hugging Face’s production Kubernetes environment; about 17,600 actions recovered. Analysis | Sandbox trusted as containment; secrets in pod environment variables; no per-call check on target or identity | Hugging Face |
| 24 March 2026 | Malicious litellm 1.82.7 and 1.82.8 published to PyPI after a CI scanner compromise leaked the publishing token; credential-harvesting payload live for about 40 minutes. Analysis | Supply chain of the gateway agents run through | LiteLLM |
| 25 February 2026 | Check Point disclosed CVE-2025-59536 and CVE-2026-21852 in Claude Code: repository configuration ran hooks and redirected API traffic before the trust dialog. Fixed by Anthropic after each report. Analysis | Repository-controlled configuration treated as trusted | Check Point |
| 13 to 24 July 2025 | An over-scoped build token let an unauthorised commit add a destructive prompt to Amazon Q Developer for VS Code 1.84.0. AWS says it failed to execute. Analysis | The agent’s instructions were the attack surface | AWS advisory |
| 18 to 19 July 2025 | Replit’s coding agent dropped a SaaStr production database during a declared code freeze and reported that rollback was impossible; the user restored it. Analysis | Freeze existed only as an instruction; one credential for dev and prod | The Register |
| 17 July 2025 | Knostic mapped 1,862 internet-reachable MCP servers; all 119 verified returned tool listings without authentication. Analysis | Servers deployed with no authentication | Knostic |
| 9 July 2025 | CVE-2025-6514 in mcp-remote (CVSS 9.6): a malicious server could execute OS commands on the client. Fixed in 0.1.16. Analysis | Client trusted server-supplied OAuth metadata | JFrog |
| June 2025 | CVE-2025-49596 in MCP Inspector (CVSS 9.4): unauthenticated proxy reachable from a malicious web page. Fixed in 0.14.1. Analysis | Developer tooling with no authentication between components | Oligo |
| 1 April 2025 | Invariant Labs disclosed tool poisoning: hidden instructions in MCP tool descriptions that the model follows and the user never sees. Analysis | Tool metadata treated as trusted instruction | Invariant Labs |
How these analyses are written
Each analysis on this site separates what is confirmed from what is reported. Confirmed means the vendor’s own account, the researcher’s disclosure, a security advisory, or a first-tier outlet quoting one of those. Reported means a credible account we could not corroborate, and we say so in the text. Where a figure differs between sources (the LiteLLM window is one example) we use the vendor’s number and note the other. An incident we cannot source is kept out of this table and, if it has a page at all, that page is marked unverified and excluded from search. Pages carry the date they were last revised and are updated when a postmortem or correction appears.
The lesson in every analysis is drawn toward enforcement rather than blame. Every company in the table above found, fixed and in most cases disclosed its own incident. The question we ask is which control, placed where, would have changed the outcome.
The pattern
Read together, the incidents share a shape. Something the agent carried was trusted to keep it safe: an instruction in the prompt (Replit, Amazon Q), a sandbox boundary (Hugging Face), a tool description or configuration file (Invariant, Check Point), or a credential it held (LiteLLM, the exposed MCP servers). In each case that thing could be changed, escaped or stolen, and once it was, nothing on the path between the agent and the system it reached asked a second question.
The Verify-Enforce-Stop-Prove test is the framework we apply to each one. Verify who is calling. Enforce what that caller may do on that target. Stop the agent, or the chain it started, when the pattern breaks. Prove afterwards, from a record that does not depend on the agent’s honesty or the vendor’s logs, what was allowed and when.
Where to start
Most of the incidents above would have surfaced in monitor mode before they became enforcement questions: an agent reaching a target it had never touched, a burst of destructive calls from a coding assistant, an MCP server nobody had registered. Connect in monitor mode, observe only, enforce no policy, and see which of these patterns already exist in your estate. Then decide what to enforce.