Identity failures, not credential theft, lead AI agent breaches in 385-incident analysis

A year-long public catalog of 385 disclosed AI agent security incidents has been tagged against a layered model of where failures originate, and the result cuts against the usual assumptions: identity and run-boundary problems, not stolen credentials or injected prompts, were the most common first point of failure.

According to the analysis by D. Grice, published on dev.to and originally posted on AgentProv, the catalog has been maintained for about a year, with every entry naming a target, a stated root cause and at least one verifiable source. Each entry was recently sorted against an eight-layer model that records which boundary gave way first: Credential, Instruction, Tool, Code/Package, Config, Identity/Run, Build/Approval and Output/Destination.

What the numbers show

Of the 385 entries, 270 qualify as in-model, meaning the agent's own tooling was the thing that failed. The other 115 — cases where the agent served as the weapon, the stolen resource or the subject of a policy story — appear in the totals but are excluded from the layer analysis.

Within the 270, Identity/Run broke first in 103 incidents, or 38%. Instruction-layer failures followed at 57, Config at 37 and Credential at 29. That ordering inverts what a keyword search suggests: the terms "credential" or "secret" appear in 198 of the 385 entries, more than any other. Grice explains the contradiction by noting that the tagging looks for the cause of a breach, not its effect. Credentials are usually what gets exfiltrated, but the opening that let them leave was almost always an identity problem — endpoints left unauthenticated, tenant namespaces never verified, sandboxes that failed to contain the agent, or actions authorized once per session instead of once per call.

Credential loss is the leading secondary layer, present in 86 of the 270 incident chains, with Output/Destination second at 71. Read together, the two tables sketch a typical breach: an identity failure provides the opening, credentials pass through it, and the data ends up at a destination nobody approved.

The shift from injection to identity

The mix has shifted over time. Among 2024 and 2025 entries, Instruction led, accounting for 20 of the 48 in-model incidents — the period when prompt injection dominated the field's attention. In 2026, the Identity/Run count rose from 6 in the first quarter to 21 in the second and 48 in the third. Injection did not disappear, Grice writes; identity failures accumulated alongside it as the ecosystem moved from single-user command-line tools to multi-tenant agent platforms, gateways and hosted runtimes without adding equivalent boundaries.

Breaches without an attacker

Of the 103 Identity/Run incidents, 26 involved no attacker at all. In these cases a vendor's own evaluation or research agent, handed a task and network access with no gating on its actions, reached live third-party systems — among them a Medicare portal, a state parks system, a university and a government database. OpenAI alone has disclosed more than a hundred affected organizations, according to the analysis. These qualify as in-model because the model asks what ought to have blocked the action, and the answer is the same control that stops a deliberate adversary.

Where patches fall short

For 92 of the 270 in-model incidents — 34% — Grice finds no vendor code fix that closes the class of problem. The behavior is architectural: the agent obeyed instructions from content it should not have trusted, carrying authority it should not have had. Ten of these drew an explicit "not a vulnerability" verdict from the vendor. That figure, Grice argues, is the data-backed case for runtime controls over patching, and the project's next component will be an enforcement mechanism rather than another scanner. A report built on the dataset is scheduled for January.

Caveats to the data

The catalog is curated rather than exhaustive, and it skews toward open-source projects and vendor self-disclosures because those produce public root causes; quiet enterprise breaches are likely underrepresented. The tags reflect a single curator's judgment, made under written rules that are themselves public, and the dataset is downloadable so that disagreement can be specific. Vendor response is unknown for 91 in-model rows, a gap the author plans to close through weekly updates.

Why it matters

For teams building or operating agent platforms, this is rare quantified evidence about where agent security actually breaks — and it points away from the priorities that dominate most discussions. Credential hygiene and prompt-injection defenses still matter, but the data suggests unauthenticated endpoints, unchecked tenant isolation and session-wide authorization are where breaches now begin. The 26 attacker-free incidents make per-call authorization and action gating practical concerns rather than theoretical ones: an ungated research agent and a live system reachable over the network were enough. The dataset is single-curator and disclosure-biased, so it should be read as directional rather than definitive — but as a map of where disclosed failures originate, it tells platform maintainers where to look first: their identity and run boundaries.