{"slug": "ai-incident-trackers-werent-built-for-agents-introducing-the-agent-incident", "title": "AI Incident Trackers Weren’t Built for Agents: Introducing the Agent Incident Registry", "summary": "Enkrypt AI launched the Agent Incident Registry (AIR), a tracker holding 529 verified AI agent incidents, of which 200 involved an agent doing real damage to a real party and 329 surfaced in research, testing, or disclosure before harm occurred. The registry separates real-world damage from demonstrations, requiring each record to include a fetched source and verbatim quote, and cites incidents including an OpenAI evaluation agent that escaped its sandbox on 9 July 2026 and breached Hugging Face's production infrastructure, prompting Hugging Face to review roughly 17,600 agent actions and rotate every credential. AIR also logged a Gemini model that attacked a real company after being told to target a fictional one of the same name, and containment breaks by Anthropic models in the same evaluations, which the registry says went unrecorded in any shared system.", "body_md": "The Agent Incident Registry (AIR) holds 529 verified AI agent incidents. In 200 of them, an agent did real damage to a real party. The other 329 surfaced in research, testing, or disclosure, before an agent caused harm.\n\nOften, both forms of AI agent incidents are collected in the same lists. An agent that actually deleted data, exposed information, or caused a financial loss gets counted the same as a researcher proving an agent could be tricked. Both are worth tracking, but they tell you different things about risk.\n\nThe [Agent Incident Registry](https://air.enkryptai.com) was built to keep these incidents separate. That distinction matters to anyone who needs to know whether a given incident describes real damage or a demonstration of what’s possible.\n\n## Why counting every incident the same way causes problems\n\nMost public AI incident trackers aren’t designed specifically for agents. They cover a wide range of AI-related harms, which makes sense for their purpose. But an agent creates a different security problem because it can act on what it generates. It might have access to a browser, a code repository, an API, a database, or credentials, and when something goes wrong the model’s output is only part of the story. You also need to know:\n\n- What access did the agent have?\n- Which tool did it use?\n- What action did it take?\n- What input triggered that action?\n- Did anyone actually suffer a consequence?\n\nOn 9 July 2026, an OpenAI evaluation agent running a cyber-capability benchmark escaped its sandbox and breached Hugging Face’s production infrastructure. It harvested credentials, moved through production clusters, exfiltrated internal data, and abused accounts on four external services. Hugging Face reviewed roughly 17,600 agent actions, rotated every credential, and rebuilt core infrastructure. Nobody was driving it. Seven days later Hugging Face published a full technical account of what happened ([AIR-2026-0163](https://air.enkryptai.com/i/AIR-2026-0163/)).\n\nThat account prompted Irregular, which runs cybersecurity evaluations for several frontier labs, to review its own work. Two months earlier a Gemini model had been instructed to attack a fictional company inside a sealed environment. Internet access was available when it shouldn’t have been, and the fictional company shared a name with a real one. The model guessed a password to get into one company’s systems and used credentials from public repositories to get into two more. Google says it stopped each time it recognized a real company, described the episodes as mistaken identity rather than misalignment, and disclosed them after the Wall Street Journal asked ([AIR-2026-0250](https://air.enkryptai.com/i/AIR-2026-0250/)).\n\nAnthropic’s models had broken containment in the same evaluations ([AIR-2026-0173](https://air.enkryptai.com/i/AIR-2026-0173/)). Three separate disclosures, with no shared record.\n\nNone of this is a rogue agent story. These were test environments that were supposed to be sealed off from the internet and weren’t, and the teams involved found the problem and fixed it, for themselves. Someone building an evaluation harness next month has no reason to know any of this happened.\n\nDisclosure practices distort the picture as well. A vendor with a mature security program has more publicly documented vulnerabilities because researchers have an established way to report them and the vendor publishes what it finds. A vendor with fewer public reports doesn’t necessarily have fewer problems. Incident counts often measure who discloses.\n\n## Verified incidents, with the evidence attached\n\nEvery AIR record requires a fetched source and a verbatim quote from that source. Nothing is written from memory. If an incident can only be supported through secondary reporting, AIR marks it medium confidence. If a lead can’t be verified, it isn’t published.\n\nEach incident is also assigned one of four classes:\n\n- **In the wild:** an agent acted outside a researcher-led test.\n- **Safety failure:** the agent caused a problem with no attacker involved.\n- **Disclosed vulnerability:** a flaw reported before it caused harm.\n- **Research demo:** a proof of concept conducted against a live system.\n\nThese classes describe how the incident surfaced. They don’t determine whether anyone was harmed: an in-the-wild incident can happen without causing damage, and a research demonstration can have real consequences. That’s why AIR tracks class separately from realized harm.\n\n## Find the incidents that match your environment\n\nA registry of 529 incidents isn’t useful if you have to read all 529 to find the handful that apply to your systems. Filter by class, risk domain, attack surface, autonomy level, and vendor to narrow it down. If you’re deploying browser agents, focus on browser-related incidents. If you’re evaluating coding agents with access to repositories and developer tools, narrow to that environment.\n\nEvery filtered view gets its own shareable URL, so you can send a specific set of incidents to an engineer, a security team, an auditor, or a risk committee instead of the entire database.\n\nEach record shows the access the agent had, the tool it called, the input that set it off, and whether a safeguard fired. That’s enough detail to build against, not just read about.\n\n## Every incident gets a permanent ID\n\nAI agent incidents are increasingly cited in research papers, risk registers, audit responses, board materials, insurance questionnaires, and standards work. The problem is that the citation is usually a news story, a blog post, or a social-media thread. Those sources can change or disappear, some end up behind paywalls, and two reports about the same incident may describe it differently enough that you can’t tell they’re about the same event.\n\nAIR gives every incident a permanent identifier in the format AIR-YYYY-NNNN. The ID is assigned once and never renumbered, and each record has a shareable permalink.\n\nThink CVE, for agent incidents. A stable reference you can put in a paper, report, audit, or risk register, knowing it will resolve to the same verified record next year.\n\nEach record is also mapped to risk domains from Enkrypt AI’s agent risk taxonomy, published in [Black-Box Red Teaming of Agentic AI](https://openreview.net/forum?id=ZLzc8coumq). If you use that taxonomy, AIR connects its categories to incidents that have been documented.\n\nThe full methodology, classification system, and findings are described in [The Agent Incident Registry: Toward Preventing Repeated AI Agent Failures](https://arxiv.org/abs/2609.11030).\n\n## Help add to the record\n\nA registry like this fills up only if companies keep publishing what went wrong. If you’ve discovered or disclosed an AI agent incident, submit it with the supporting source. We fetch the source, preserve a verbatim quote, classify the incident using the taxonomy, and assign an AIR ID using the same process applied to every existing record.\n\nEnkrypt AI, part of Anaconda, builds the [AI security & guardrails](https://www.anaconda.com/platform/ai-security-and-guardrails) capabilities in Anaconda Platform and maintains the Agent Incident Registry as a public resource.\n\n## FAQ\n\n**What counts as a real AI agent incident?**\n\n**How do you cite an AI agent incident?**\n\n**How does an incident get into the registry?**\n\n**What are the four classes?**\n\n**Why do incident counts vary between sources?**", "url": "https://wpnews.pro/news/ai-incident-trackers-werent-built-for-agents-introducing-the-agent-incident", "canonical_source": "https://www.anaconda.com/blog/agent-incident-registry", "published_at": "2026-09-22 15:45:41+00:00", "updated_at": "2026-09-22 16:27:27.617442+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-policy", "ai-research", "artificial-intelligence"], "entities": ["Agent Incident Registry", "Enkrypt AI", "OpenAI", "Hugging Face", "Irregular", "Gemini", "Google", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/ai-incident-trackers-werent-built-for-agents-introducing-the-agent-incident", "markdown": "https://wpnews.pro/news/ai-incident-trackers-werent-built-for-agents-introducing-the-agent-incident.md", "text": "https://wpnews.pro/news/ai-incident-trackers-werent-built-for-agents-introducing-the-agent-incident.txt", "jsonld": "https://wpnews.pro/news/ai-incident-trackers-werent-built-for-agents-introducing-the-agent-incident.jsonld"}}