A Taxonomy for Agentic Failure: Separating Causes, Risk Events, and Impacts
Operational Risk for Agentic AI (Part 3 of 5)
As discussed in Part 1 of this series, the transition from predictive AI (e.g. chatbots) to agentic AI moves the primary risk from prediction error to execution risk. Part 2 extended this with a tiering and exposure framework based on autonomy, blast radius, and irreversibility.
These frameworks are the starting point. Once an agent is deployed, its risk profile must be monitored, reassessed, and governed on an ongoing basis. In financial institutions, this is typically implemented through processes such as Risk and Control Self-Assessments (RCSA), incident reporting, and periodic reviews. These processes rely on a risk register: an inventory of risks that can be tracked, assessed, and controlled over time.
This raises a question: how should agentic risks be represented in such a register?
Many AI risk registers conflate technical causes with operational risk events. Failure modes such as prompt injection or model hallucination are causes, not events. The risk is the outcome they enable: unauthorized actions, data exfiltration, or unintended financial positions. Operational risk frameworks address this by separating cause, event, and impact. The separation is necessary for control design, incident classification, and escalation.
This article applies that structure to agentic AI. It introduces a MECE (Mutually Exclusive, Collectively Exhaustive) taxonomy of causes, events, and impacts, with decision rules for consistent classification. The structure supports clearer accountability, consistent loss measurement, and alignment with risk appetite.
1. The Framework: Cause ≠ Event ≠ Impact
Every incident should be structured along three dimensions: Cause, Event, and Impact:
Cause: The technical vulnerability, control failure, or external trigger that initiates the sequence. Example: a prompt injection attack or compromised third-party dependency.
Risk Event: The operational failure where the agent acts incorrectly or fails to act. This must be observable and classifiable. Example: unauthorized transaction or data exfiltration.
Impact: The resulting business consequence. Example: financial loss, regulatory breach, or customer harm.
The taxonomy follows a MECE logic (Mutually Exclusive, Collectively Exhaustive):
Causes may overlap. A single event can be triggered by multiple technical failures or threat vectors.
Risk Events are mutually exclusive. The incident itself must be classified under a single primary event (e.g. “Unauthorized Execution”) to avoid double counting, even if multiple causes are present.
Impacts are collectively exhaustive. All material loss channels should be captured to support aggregation and reporting.
2. Anchoring the “Cause” Layer
To anchor the Cause layer, this article uses the OWASP Top 10 for Agentic Applications (2026) as a reference set. This set is non-exhaustive, but serves as a reasonable starting point.
OWASP lists common technical vulnerabilities in agentic systems. These are causes, not risks: they describe how failures are triggered. The risk is the resulting event (e.g. unauthorized execution, data exfiltration). The mapping proposed is therefore:
Technical Causes (e.g. OWASP) → Operational Risk Events → Business Impacts
This separation clarifies ownership: technical causes sit with engineering and security, while events and impacts sit within business and risk governance.
The table below maps representative technical causes1 (using OWASP as a reference) to distinct operational risk events and their corresponding business impacts.
The table below applies this mapping, linking representative causes to distinct events and impacts. The objective is not to enumerate all vulnerabilities, but to provide a consistent structure for classification and reporting. Complex incidents may involve multiple contributing causes; the classification requires judgment, but a single primary event must be assigned to support consistent aggregation and reporting2.
3. Worked Examples: From Tech Bug to Business Risk
To illustrate how to apply this taxonomy in a Risk Control Self-Assessment (RCSA), we analyze two specific scenarios.
Example A: The "Poisoned" Customer Service Agent
Scenario: An attacker feeds false information into the customer support database. Over time, the agent “learns” that a specific competitor’s product is superior and begins recommending it to users.
Cause (ASI06, Memory Poisoning): The agent’s long-term memory lacks integrity checks. This is also a case of provenance loss: the agent cannot distinguish verified product information from injected content because no lineage metadata was retained.
Risk Event (Incorrect Customer Guidance): The agent provides systematically incorrect or misleading recommendations to customers based on corrupted data.
Impact: Customer harm, loss of revenue, and reputational damage. In regulated contexts (e.g. financial advice), this may escalate to conduct risk and potential regulatory action.
Example B: The "Over-Helpful" Refund Agent
Scenario: A user exploits weak identity verification to request a high-value refund. The agent, relying on insufficient authentication checks, processes the request using its legitimate API access.
Cause (ASI03, Identity & Privilege Abuse): The agent does not enforce identity verification proportional to the transaction’s sensitivity, violating least-privilege and authorization controls.
Risk Event (External Fraud): The agent executes a transaction that was not properly authorized.
Impact: Direct financial loss and potential customer disputes.
4. Downstream Use: How the Taxonomy Feeds Risk Assessment
The taxonomy identifies what can go wrong. Two downstream processes address how it happens and how often.
Reverse Stress-Testing (Part 4) takes each Risk Event as a Top Event and works backward using Fault Tree Analysis to isolate the causal chain: the specific combination of permission gaps, control failures, and triggers that must all be present for the event to materialize.
Scenario Analysis (Part 5) assesses each Risk Event for frequency (how often could this plausibly occur?) and severity (what is the realistic loss range?). These estimates feed directly into the Inherent Risk Rating column of the RCSA template in Part 5. Firms should conduct scenario analysis workshops for each Tier-1 or Tier-2 agent’s material risk events, using the taxonomy as the event list and the fault trees as the causal maps.
Both processes depend on the taxonomy’s MECE structure.
5. Reusable Taxonomy Template
Firms can use the following template for their Agentic AI Risk Register. The “Key Controls” column follows the Chapelle Control Classification (Directive, Preventive, Detective, Corrective), which Part 5 defines in full and applies as the organizing principle for the governance layer.
This template is a simplified version of established operational risk taxonomies. The Basel Committee on Banking Supervision provides a more comprehensive event-type classification, which firms can use as a reference and adapt to agentic AI contexts.
Conclusion
This article produces an auditable Cause–Risk–Impact Taxonomy Table (Section 2) and a Reusable Taxonomy Template (Section 5) structured around the control classification defined in Part 5. Each can be adopted directly into a firm’s risk register.
The three lines of defense apply straightforwardly here. Engineering and security own the technical causes; business lines own the operational risk events arising from deployed agents; senior management and the board govern through risk appetite.
These lines were not designed with agentic AI in mind, but the structure holds. By separating causes from events, firms can design controls against the failure itself rather than its trigger, and aggregate losses consistently across technically heterogeneous scenarios.
Classifying “prompt injection” as the risk obscures the exposure. The operational risk is unauthorized execution of an action (a payment, an API call, a data access) regardless of whether it was triggered by prompt injection, tool misuse, or another failure mode.
If you found this useful, I write about agentic systems, model risk, and governance under uncertainty. Subscribe if you want to stay close to that work, or connect with me on LinkedIn if you’d like to discuss these topics further.
Two event pairs require explicit decision boundaries to preserve mutual exclusivity:
Unauthorized Execution vs. Autonomous Policy Violation
Distinguished by the presence of an external adversarial trigger. If agent behavior is redirected by adversarial input (e.g. prompt injection) → Unauthorized Execution. If the agent exceeds its boundaries without external manipulation → Autonomous Policy ViolationData Exfiltration vs. Data Leakage
Distinguished by whether the trust boundary is crossed. If data leaves the boundary (e.g. external system, third party) → Data Exfiltration. If data is disclosed internally to an unauthorized recipient → Data Leakage
These rules enforce a single primary event classification even when multiple causes are present.
Note on Complementary Taxonomies: The Berkeley Agentic AI Risk-Management Standards Profile (February 2026) independently categorizes agentic safety failures — including deceptive alignment, oversight subversion, and self-proliferation. These map primarily to ASI10 (Rogue Agents) and ASI09 (Trust Exploitation) in this taxonomy. Firms conducting a comprehensive risk identification exercise may use the Berkeley profile as a cross-check to confirm no material failure modes have been excluded from their OWASP-based cause column.
References
[1] Beyond Hallucinations: How Agentic AI Turns Execution Errors into Operational Failure, Andrea Politano, Substack (March 2026)
[2] Sizing Risk in Agentic AI: From Tiering to Constraints, Andrea Politano, Substack (March 2026)
[3] “OWASP Top 10 For Agentic Applications 2026” OWASP Gen AI Security Project”, December 2025.
[4] “Operational Risk Management – Best Practices in the Financial Services Industry”, Ariane Chapelle, Wiley Finance Series, 2018.
[5] “Agentic AI Risk-Management Standards Profile”, Madkour, N., Newman, J., Raman, D., Jackson, K., Murphy, E. R., & Yuan, C., UC Berkeley Center for Long-Term Cybersecurity (CLTC), February 2026.
[6] BIS (Basel Committee), Operational Risk QIS Note
[7] Basel III: A global regulatory framework for more resilient banks and banking systems, December 2010