385 宗 AI 智能體安全事故分析：Identity/Run 層最常是首個失效環節

For about a year I have kept a public catalog of disclosed AI agent security incidents: 385 entries as of this week, each with a named target, a stated root cause, and at least one verifiable source. Until now the catalog was a list. This month I tagged every entry against a model that asks one question per incident: which link in the chain of custody broke first?

The model has eight layers, each named for the question it answers. Credential (should this run hold this key?), Instruction (who actually said "do this"?), Tool (is this tool what it claims?), Code/Package (where did this code come from?), Config (who wrote the file that runs on open?), Identity/Run (which agent, run, or tenant is this?), Build/Approval (was this approved as what it claims to be?), and Output/Destination (where is this data going, and who chose that?). The full definitions and the tagging rules are on the model page and the methodology page. Every rule, every exclusion, and every judgment call is written down there, because the numbers below are only worth what the rules behind them are worth.

The finding

Of the 385 entries, 270 are in-model: agent tooling was the attack surface. The other 115 are counted and charted but not layered, because the agent was the weapon, the capability, the stolen resource, or the subject of a policy story rather than the thing that failed. Saying which is which is most of the work.

Among the 270, the layer that broke first is Identity/Run in 103 cases, 38 percent. The next layer, Instruction, is at 57. Config is at 37. Credential, the one everybody expects to lead, is at 29.

Chart and data table: (https://agentprov.com/stats#layer-primaries)

That ordering surprised me. A keyword pass over the same data says the opposite: "credential" or "secret" appears in 198 of 385 entries, more than any other term. The tagging rule resolves the contradiction. It asks for the cause, not the effect. Credentials are what walks out the door. The door that was open was almost always an identity boundary: an endpoint with no authentication, a tenant namespace that was not checked, a sandbox that did not hold, an action authorized at the session level that should have been authorized one call at a time.

Credential is the leading secondary layer, present in 86 of the 270 cascades. Output/Destination is second at 71. Read the two tables together and the shape of a typical agent breach is clear: it starts at identity, runs through credentials, and ends at a destination the user never chose.

The trend

The layer mix is not static. In the 2024 and 2025 entries, Instruction leads: 20 of 48 in-model incidents broke first at the prompt. Those were the injection years. In 2026 the Identity/Run count went from 6 in the first quarter to 21 in the second to 48 in the third. Injection did not go away; the orange band in the chart is still there. Identity failures grew on top of it, because the ecosystem moved from single-user CLIs to multi-tenant agent platforms, gateways, and hosted runtimes faster than those platforms grew boundaries.

Chart and data table: agentprov.com/stats#layer-by-quarter

The part nobody has quantified

Of the 103 Identity/Run incidents, 26 were caused by a vendor's own evaluation or research agent reaching a live third-party system. No attacker. The agent was given a task, a network connection, and no action gating, and it found its way into a Medicare portal, a state parks system, a university, a government database. OpenAI alone has disclosed more than a hundred affected organizations. These are in-model because the question the model asks does not require an attacker; it asks which control should have stopped the action, and the answer is the same control that stops the attacker case.

Chart and data table: agentprov.com/stats#l6-by-actor

What a patch can and cannot fix

For 92 of the 270 in-model incidents, 34 percent, no vendor code fix closes the class. The behavior is architectural: the agent did what it was told, by content it should not have been taking orders from, with authority it should not have been carrying. Ten of those drew an explicit "not a vulnerability" from the vendor. That number is the quantitative case for runtime controls over patches, and it is why the next piece of this program is an enforcement point rather than another scanner.

What this is not

The catalog is curated, not exhaustive. It covers disclosed incidents affecting agent tooling, with a bias toward open-source projects and vendor self-disclosures, because those are the ones with public root causes. Quiet enterprise breaches are underrepresented. The tagging is one person's judgment applied under written rules; the rules are public, the tags are public, and the dataset is downloadable, so disagreement can be specific. Vendor response is unknown for 91 in-model rows, which is a gap I intend to close in the weekly updates.

What is next

The model is version 1.0 as of today. The 2026 AI Agent Attack Report, built on this dataset, ships in January. A provenance proxy, a sidecar that labels content at every boundary and checks the labels at every sink, is the enforcement piece; AgentLock is its Instruction-layer core today and runwarden is its Identity/Run probe. The related-work table on the model page places CaMeL, AARM, NVIDIA's layered architecture, and the decode-time binding work from Yocam et al. alongside it, so you can see where each stops and this starts.

If you maintain an agent platform, the single most useful thing you can do with this data is open the Identity/Run layer and read the three most recent incidents. They are probably about something you ship.

Originally published at agentprov.com. Cite as: Grice, D. (2026). Where agent breaches actually start: 385 incidents, eight layers, one surprise. AgentProv.