AI Agent Failure Modes: A Risk Taxonomy for Enterprise Teams

Why a Structured Taxonomy Matters

Risk teams evaluating AI agent deployments often default to generic AI risk language, treating agent failures as a subset of model risk. This framing is insufficient. Agents differ from standalone models because they take actions: invoking tools, calling APIs, writing to systems, and in multi-agent architectures, delegating tasks to other agents. Each of these action surfaces introduces failure mechanisms that do not exist in a passive text-generation system.

OWASP's Agentic AI guidance, MITRE ATLAS, and NIST's AI Risk Management Framework each document overlapping but not identical categorizations of these failures. No single standardized taxonomy has been adopted industry-wide, and quantified incident data across enterprise deployments remains limited. What does exist is consistent framework-level guidance on the technical mechanisms behind agent failures and the architectural controls that mitigate them. This guide organizes that guidance into four practitioner-oriented categories that risk teams can use to assess exposure and prioritize controls.

Category 1: Input Manipulation and Context Injection

Prompt injection, including indirect injection delivered through tool outputs or retrieved content, is a documented mechanism by which an agent's goals, instructions, or behavior can be altered at runtime without direct access to the underlying model or its configuration. Because agents frequently ingest external content (web pages, documents, API responses) as part of their operating context, any untrusted content source becomes a potential injection vector.

A related but distinct mechanism is context or memory poisoning, where persistent agent memory or retrieved context is manipulated so that it influences future agent behavior without a new, direct injection event occurring at the time of the failure. This makes root-cause analysis harder, since the manipulative input may have entered the system well before the resulting harmful action.

For risk assessment purposes, the relevant question is not whether an agent can theoretically be prompt-injected, but which of its input sources are untrusted or externally influenced, and whether those sources are segregated from persistent memory and decision-relevant context.

Category 2: Excessive Agency and Permission Misconfiguration

OWASP identifies excessive agency, meaning an agent granted more permissions, tool access, or autonomy than its task requires, as a core risk category. This is fundamentally an access control failure rather than a model failure: the underlying model may behave exactly as designed, but the blast radius of an error or manipulation is amplified by over-broad standing permissions.

Cloud provider guidance from AWS and Microsoft consistently recommends least-privilege identity and access scoping for each tool, API, or data source an agent can invoke, treating agent identities the same way enterprises treat service account identities: scoped narrowly, reviewed regularly, and never granted broad standing access by default.

Risk teams assessing this category should inventory every tool, API, and data source accessible to each deployed agent and compare that inventory against the minimum access the agent's task actually requires. Gaps between granted and required permissions represent direct exposure.

Category 3: Tool-Call Misuse

OWASP guidance distinguishes tool misuse from injection-based manipulation. In tool misuse, an agent invokes a legitimate tool or API, one it is authorized to use, but does so in an unintended or harmful sequence or context. This is a failure of action logic rather than a failure of access control or input integrity, and it can occur even when permissions are correctly scoped and no injection has taken place.

Because tool misuse originates from the agent's own reasoning or planning process, it cannot be fully addressed through permission scoping alone. Mitigation requires runtime policy enforcement that sits independent of the model's own output: allow-listing which tools can be called in which contexts, validating call arguments before execution, and constraining permissible action sequences.

Evaluation criteria for this category should focus on whether policy enforcement exists as a layer separate from model reasoning, since relying on the model to self-police its own tool use does not constitute a control.

Category 4: Orchestration Failures in Multi-Agent Systems

Multi-agent architectures introduce failure surfaces that do not exist in single-agent systems. Microsoft's agent security documentation describes additional risk arising from inter-agent communication and delegated task handoffs, where an error, manipulated output, or poisoned context in one agent can propagate to others through the handoff itself, without an external attacker needing to compromise each agent independently.

This cascading dynamic is compounded by a broader challenge NIST identifies: difficulty tracing AI system decision chains, which complicates both real-time detection and post-incident root-cause analysis. In a multi-agent workflow, tracing which agent introduced an error, and at what point in a chain of handoffs, is materially harder than diagnosing a single-agent failure.

Risk teams should map trust and data-flow boundaries between agents in any orchestrated workflow, identifying where isolation exists (or does not) and where a failure in one agent could propagate downstream without detection.

Model-Level vs. System-Level Failures

NIST's framework draws a useful distinction for accountability purposes: failures originating from the underlying model itself, such as hallucination or reasoning errors, are different in kind from failures originating from system-level integration, such as insecure tool orchestration or flawed data pipelines. This distinction matters for governance because accountability differs by layer. Model-level failure accountability typically sits with the model provider, while system-integration failure accountability sits with the deploying organization.

Governance processes that do not separate these layers tend to either over-attribute risk to the model (leading to under-investment in integration-layer controls) or under-attribute risk to integration decisions the organization directly controls. NIST's AI RMF further recommends that risk assessment be continuous, following a map-measure-manage cycle across the system lifecycle, rather than a one-time pre-deployment activity. This is particularly relevant for agents, since tool access, memory state, and orchestration logic can all change after initial deployment without triggering a formal re-review.

Where Runtime Governance Fits

The failure categories above share a common thread: each is difficult to fully address through model-level controls or pre-deployment testing alone. Excessive agency is an access control problem. Tool misuse and orchestration failures require enforcement that operates independent of the model's own reasoning. Context poisoning requires visibility into memory and state changes over time.

This is the operational gap that runtime governance is designed to address: enforcing least-privilege agent identity and permissions, applying policy enforcement to tool calls before execution, monitoring agent and inter-agent behavior continuously, and maintaining audit logs that support the traceability NIST identifies as a persistent challenge. Trussed AI provides runtime governance and security controls for enterprise AI agents, including agent identity and permission management, tool approval workflows, and runtime monitoring, aligned to the control categories described in this guide.