A Failure Taxonomy for Production Agents

LLM agents fail differently from conventional software. They rarely crash. Instead they complete the wrong task with confidence, call the right tool with the wrong arguments, follow instructions hidden in a document they were asked to summarize, or succeed on Tuesday and fail on the identical task on Wednesday. Security bodies, standards organizations, and academic researchers have each produced partial maps of these failures. This article consolidates them into a single working taxonomy for production teams, with a description, a documented example, a detection method, and a mitigation for each category, followed by guidance on severity ranking and an explanation of why certain failures consistently survive internal testing.

The existing maps, and why teams need a combined view

Each major framework describes the problem from a different angle.

• OWASP Top 10 for LLM Applications (2025) lists application-level risks: Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption¹.
• OWASP Top 10 for Agentic Applications (2026), released in December 2025, addresses autonomy directly: agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain compromise, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents²³.
• NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework published in July 2024, defines 12 risks that are unique to or exacerbated by generative AI, including confabulation, data privacy, information security, human-AI configuration, harmful bias, and value chain and component integration⁴.
• MITRE ATLAS catalogs adversary tactics and techniques against AI-enabled systems, modeled on MITRE ATT&CK, and is most useful for threat modeling and red-team planning⁵.
• Microsoft's taxonomy of failure modes in agentic AI systems separates security failures from safety failures and novel agent-specific modes from existing modes that agents amplify⁶. Its 2026 update added seven categories after a year of red teaming, including goal hijacking, inter-agent trust escalation, session context contamination, and MCP and plugin abuse⁷.
• MAST, from UC Berkeley researchers, is an empirical taxonomy of why multi-agent systems fail, built from more than 1,600 annotated traces across seven frameworks, with 14 failure modes grouped into system design issues, inter-agent misalignment, and task verification⁸.

The security frameworks focus on adversaries. The empirical research focuses on agents failing unaided. Production incidents involve both, often in the same trace. A useful operational taxonomy needs to cover each, and it needs to tell an engineer how a failure will be noticed and what to do about it.

What the empirical research shows about unaided failure

Before considering attackers, it is worth establishing how often agents fail on their own.

Reliability across repeated runs is low. τ-bench evaluates agents that interact with a simulated user and domain APIs under policy rules. Its authors reported that GPT-4o achieved roughly 61% task success on the retail domain and 35% on the airline domain, and that the probability of solving the same task consistently across eight trials (pass^8) fell to about 25% in retail⁹. A single successful demo says little about the second, fifth, or eighth run.

Multi-agent systems fail in recurring, classifiable ways. MAST's distribution of failures is instructive for anyone designing orchestration:

Source: Cemri et al., "Why Do Multi-Agent LLM Systems Fail?"⁸

The authors also found that existing verifier agents perform only superficial checks, and that structural changes, not model changes, produced gains: a workflow adjustment to ChatDev improved success by 9.4% with the same model and prompts⁸.

Confabulation persists even with retrieval. Stanford researchers found that leading AI legal research tools, which use retrieval-augmented generation, produced hallucinated responses between 17% and 33% of the time¹⁰. On grounded summarization, Vectara's leaderboard reports hallucination rates ranging from 1.8% to 24.2% across models¹¹. Retrieval reduces confabulation; it does not eliminate it.

Hard tasks remain hard. When SWE-bench was introduced with 2,294 real GitHub issues, the best model resolved 1.96% of them¹². Scores have risen dramatically since, but the benchmark remains a reminder that realistic multi-file tasks expose failures that toy tasks do not.

Most production agent failures are not exotic attacks. They are loops, skipped checks, misread instructions, and inconsistent runs, and they happen without any adversary present.

The taxonomy

The taxonomy below consolidates the frameworks above into twelve categories. Each maps to one or more source frameworks so that findings can be reported in the vocabulary that security, risk, and engineering teams already use.

Two cross-cutting dimensions apply to every category. The first is language and population parity: Microsoft's taxonomy explicitly treats unequal quality of service as a safety failure⁶, and any category above can occur at different rates for different user groups. The second is drift: model updates, prompt edits, and data changes can move a system between categories without any code change.

Severity ranking

Not every failure deserves the same response. We recommend scoring each observed failure on four factors and using the combination to assign a severity tier.

1. Impact. What is the worst realistic outcome: inconvenience, financial loss, regulatory exposure, or harm to a person?
2. Reversibility. Can the action be undone? A misleading answer can be corrected; a sent payment or deleted record may not be recoverable.
3. Blast radius. Does the failure affect one session, one user, one tenant, or all users? Memory poisoning and supply chain compromise tend to have wide radius.
4. Detectability. Will anyone notice? A failure that is silent in logs and invisible to users is more severe than an equally harmful failure that triggers an alert.

The ranking should be applied per use case. Confabulation in a marketing draft is low severity; the same failure in a dosage instruction or a legal filing is high or critical.

Which failures survive internal testing, and why

Internal test suites catch many failures. Certain categories, however, reliably reach production. The reasons are structural rather than a matter of effort.

Inconsistency survives single-run evaluation

Most internal evaluations run each test case once. τ-bench shows how misleading that is: a task solved on the first attempt may have only a minority chance of being solved on every one of eight attempts⁹. At production volume, the tail of that distribution is a daily event.

Indirect injection survives clean test data

Test corpora are usually curated documents, written by the team. Production retrieval pulls in emails, web pages, tickets, and uploaded files written by anyone. EchoLeak required only that an attacker send an email that Copilot would later retrieve¹⁶. Unless test data deliberately includes adversarial content in tool outputs and retrieved documents, this class is untested.

Memory and long-horizon failures survive short sessions

Test cases tend to be single sessions of a few turns. Memory poisoning and session contamination play out across sessions and days. Microsoft's red team noted that incremental escalation was difficult to detect because each step appeared benign in isolation⁷.

Verification failure survives because the verifier is also under test

If the same team, model, or context that produced an output is also checking it, shared blind spots pass through. MAST's finding that verifiers perform superficial checks is a direct description of this effect⁸. Seeding known defects is the most reliable way to measure whether verification works at all.

Human oversight failures survive because testers are attentive

During testing, the people approving actions are engineers who are watching closely. In production, approvers are busy, approvals become routine, and attackers deliberately target the approval step. Microsoft's report that human-in-the-loop bypass was the most consistently exploited failure mode reflects this gap between designed and actual oversight⁷.

Distribution shift survives representative-looking test sets

Real users write in other languages, mix languages, paste unusual formats, and pursue goals the designers did not anticipate. A test set built by the team that built the system reflects that team's assumptions.

The failures that reach production are rarely the ones nobody imagined. They are the ones the test setup was structurally unable to provoke.

How we apply the taxonomy in our engagements

The taxonomy is a working tool rather than a reference document. In our evaluation and red-teaming work, we use it in four steps; the resulting findings are specific to each system and are reported to the client, not aggregated into public statistics.

1. Coverage mapping. For each of the twelve categories, we record whether a test exists, whether a production signal exists, and who owns the response. Gaps in this map set the priorities for the assessment.
2. Provocation. We design tests to trigger each relevant category under realistic conditions: repeated trials for consistency, adversarial content placed in tool outputs and documents, multi-session scenarios for memory, seeded defects for verification, and approval-bypass attempts for oversight.
3. Independent review. Domain experts who did not build the system review sampled outputs, which addresses the shared-blind-spot problem in verification and grounding.
4. Severity and controls. Each finding is scored on impact, reversibility, blast radius, and detectability, mapped to OWASP, NIST, and MITRE ATLAS identifiers, and paired with a control and a regression test that remains in the release pipeline.

Conclusion

The public frameworks now provide good coverage of how LLM agents fail. OWASP and MITRE describe the adversarial surface, NIST frames the organizational risks, Microsoft documents what red teams actually exploit, and empirical studies such as MAST and τ-bench quantify how often agents fail without any adversary at all. Combining them into one taxonomy gives production teams a shared vocabulary and a checklist. The decisive question for any agent is not whether it can succeed, but whether each category of failure has a test that provokes it, a signal that reveals it, and a control that contains it.