AI Agent Incident Taxonomy for Security Operations Teams
Security teams need a new classification framework tailored to AI agent failures.

AI agent incident taxonomy gives security operations teams a way to classify failures by where they originate and how long they take to manifest. Those two coordinates, architectural layer and timescale, determine the evidence, ownership, and response an incident needs. Traditional event categories remain useful for describing damage, but they cannot explain the agent behavior that produced it.
Why traditional SOC categories fail when applied to AI agent incidents
An analyst following a standard playbook may find an authorized tool call, no malware alert, and no obviously malicious log entry. The ticket appears ready to close. Yet the agent may have followed a poisoned memory entry or combined individually permitted actions into an unauthorized outcome. Categories such as credential abuse, malware execution, data exfiltration, and denial of service describe possible results without locating the failure that caused them.
Traditional categories assume fixed logic, separate input and processing boundaries, and deterministic behavior, while agents retain state, formulate plans, invoke tools, and coordinate with peers. Kexin Chu’s Layered Attack Surface Model (LASM) survey identifies emergent, compositional, and temporally extended attacks that cross these boundaries. Harm can arise from an action sequence rather than one malicious event, and a payload can remain dormant for weeks. Consequently, triage centered on what fired and when can mistake the visible consequence for the incident’s origin.
The agentic stack as a map of incident origin points
The map has five operational zones. Input surfaces bring untrusted content into context, while planning and reasoning set the goals and the order of actions. Tool execution carries out those decisions through APIs, file systems, credentials, and infrastructure. Memory and state keep context across turns and sessions. Inter-agent communication connects delegation, peer messages, and inherited trust.
These zones simplify a broader architectural model. Chu’s survey defines seven layers, which are Foundation, Cognitive, Memory, Tool Execution, Multi-Agent Coordination, Ecosystem, and Governance. The five-zone operational grouping links that structure to who handles detection and response, while ecosystem and governance risks remain. Each zone is a different place to look for the cause. A technique such as prompt injection does not identify that place by itself, because its incident signature depends on where it enters and what it influences.
Timescale supplies the map’s second coordinate. The survey defines instantaneous threats as T1, session-persistent threats as T2, cross-session cumulative threats as T3, and sub-session-stack threats as T4. Input and tool incidents often fall into T1 or T2, while failures in persistent memory and coordination call for looking beyond a single session. Across this map, attacks on the agent compromise its behavior, whereas attacks through the agent use it to reach downstream systems. That distinction separates work to restore agent integrity from work to contain the effects in databases, APIs, and infrastructure.
Input surface incidents: prompt injection as the entry point, not the full event
Indirect prompt injection places attacker-controlled instructions in retrieved web content, documents, email, or tool outputs. The detection gap follows that same boundary. Monitoring only what the user submitted leaves the agent’s other inputs outside the investigation. Most input-surface injections fall into T1 or T2, making them relatively accessible to detection, but only when monitoring includes the material the agent retrieves.
Johann Rehberger demonstrated the consequences against Devin AI, a production agentic coding assistant. His research showed that indirect prompt injection could instruct the agent to expose server ports, leak access tokens, and install command-and-control malware during an apparently routine coding task. This was a demonstration. Its operational significance is the distance between a suspicious piece of content and the tool actions that establish the security impact.
For SOC triage, the injection is therefore an entry point rather than a complete incident record. Detection must connect retrieved instructions to subsequent tool calls, because a content anomaly alone does not establish what the agent did. Closing at the input boundary can leave downstream consequences unexamined. Before those consequences appear, however, the injected instruction may change the goal the agent is pursuing.
Planning and reasoning incidents: goal hijacking and objective drift
The authors of Securing Agentic AI: A Comprehensive Threat Model and Mitigation Framework for Generative AI Agents distinguish goal hijacking from objective drift. Goal hijacking redirects a plan through a discrete instruction, while objective drift gradually changes priorities across reasoning cycles. Both affect the agent’s choice of actions. Neither necessarily produces a malicious event at the point where the goal changes, so input and output monitoring alone cannot explain the transition.
Chu’s survey describes why component-by-component analysis misses this class of failure. An attack chain can cross input, retrieval, planning, and tool invocation while appearing benign at each component in isolation. OWASP’s Excessive Agency risk names excessive functionality, excessive permissions, and excessive autonomy, but these conditions do not on their own trigger a planning-step alert. Processing alerts faster cannot help when there is no alert. The relevant sensor is workflow comparison, namely the divergence between an approved task and the agent’s actual action sequence.
Planning incidents are predominantly T2, but serialized goal state can extend them into T3. Detection thus depends on whether the changed objective ends with the session or stays in memory. For SecOps teams, deviation without a corresponding user instruction is the investigative signal. Tool execution is where that changed objective becomes action against the environment.
Tool execution incidents: where model mistakes become operational damage
Tool execution is the agent’s actuator surface, where attacker-influenced decisions can become credential exfiltration, unauthorized API calls, file system modification, or lateral movement. Upstream origin does not limit downstream impact. An injection, hijacked goal, or corrupted memory can all reach this layer through a tool call that appears authorized. The investigation must therefore distinguish permission to invoke a tool from legitimate authority for the instruction driving that invocation.
Chu’s survey finds that every Tool Execution attack it surveyed comes down to principal trust inversion. The agent treats attacker-supplied instructions as though they came from the legitimate principal authorizing the action. This finding makes the trust boundary concrete. An allowed connector does not establish that the agent is using it for the approved purpose, and model input/output logs alone do not describe the resulting operations across the environment.
For SOC teams, the required evidence is connector-level runtime telemetry, including API call logs tagged to the issuing agent session. Without that linkage, the incident record cannot connect a model decision to its operational effect. Default trust in tool invocations, absent pre-execution risk scoring, connector policy enforcement, or audit trails, leaves that boundary exposed. Yet the cause may predate the visible action. Some damage at execution time was set up earlier through state that the agent later trusted as memory.
Memory and state incidents: the slow attack that looks like nothing happened
Persistent memory allows an agent to continue work across sessions, but it also allows malicious state to outlive the interaction that introduced it. A retrieved document can corrupt long-term memory and influence an unrelated session weeks later. The first session may show no damage to operations. By the time the agent acts, the relevant instruction may no longer be present in its current prompt.
FARMA-style attacks document a specific memory-forgery mechanism. Fabricated reasoning-memory entries claim that a required safety step has already been completed, causing the agent to skip it. Memory becomes an adversarial input in its own right. Detection requires checking whether a remembered action really happened as well as looking for suspicious language in the current session.
Shapira et al.’s 2026 Agents of Chaos red-team study examined autonomous agents in a live environment over two weeks. The agents had persistent memory, email, Discord access, file systems, and shell execution, and the study documented sensitive data disclosure, destructive actions, identity spoofing, non-owner instruction compliance, and cross-agent propagation of unsafe practices. For incident response, memory provenance must link stored claims to actions that ran, because session logs alone cannot show that history. Containment becomes harder when compromised state or unsafe practices pass to other agents.
Inter-agent and multi-agent incidents: trust propagation as the multiplier
Multi-agent incidents expand the unit of investigation from one agent to the orchestration network. A compromised sub-agent can propagate malicious intent through inherited trust, turning one entry point into a wider failure. Topology determines the potential blast radius. The original injection technique explains less about severity than which peers accept the sub-agent’s messages and what authority delegation gives them.
Chu’s survey puts Multi-Agent Coordination, Ecosystem, and Governance in a zone that has had little study but has the most severe documented threats. It also describes a production incident pattern in which compromise propagates through peer-to-peer trust across an orchestration network. Separately, a state-sponsored campaign used hijacked coding agents to execute an estimated 80–90% of an espionage operation against multiple targets, including reconnaissance, exfiltration, and persistence. That example establishes operational-scale coordination without proving that every multi-agent failure follows the same path.
Single-agent logs cannot reconstruct a network-wide trust failure. SOC investigations need a graph-level view of agent communications, delegated permissions, and inherited authority to follow the incident across boundaries. Orchestrator opacity remains an emerging blind spot. Where delegation is not visible, the investigation cannot assume that the apparent endpoint of one agent’s activity marks the endpoint of the attack.
Mapping the taxonomy to SOC workflow: triage, assignment, and timescale-aware response
Incidents should be assigned by origin layer and timescale independently of the first alert’s label. Input-surface cases in T1 or T2 need a link between retrieved content and downstream tool calls, while planning cases need to be checked against approved workflow baselines. Tool-execution cases need connector-level API records linked to agent session IDs so that investigators can tell which agent took the action they see.
T3 or T4 memory investigations need write provenance and evidence that claimed past actions actually executed. Multi-agent cases spanning T2, T3, or T4 need orchestration records covering message routing and delegated permissions. Those records support escalation beyond the first affected agent. A fast response to the latest tool call cannot substitute for investigating persistent state or propagated trust.
Chu’s non-transferability result formalizes why layer assignment is consequential. Under the model’s disjoint boundaries, a control at one layer has zero detection power against an attack localized at another. Misassignment therefore produces both wasted response effort and false confidence. Limited verifier roles, guardrail layers, and human review points further constrain the architectural hooks available for investigation.
For evidence-based closure, a confirmed incident should remain open until its origin layer and timescale are assigned, affected memory or state is audited, and downstream tool calls in the session are reviewed. An opinion that nothing harmful happened cannot replace the missing record of what the agent changed or caused.
Where the taxonomy currently has gaps and what SecOps teams should not assume it covers
The five-zone taxonomy is an operational map. Chu’s survey finds seven layer-by-timescale cells with zero defense coverage, and three of them have documented attacks. No surveyed benchmark evaluates T3 or T4 threats. That leaves progress on cross-session cumulative and sub-session-stack defenses unmeasurable within the surveyed benchmark landscape, particularly in the under-studied coordination, ecosystem, and governance layers.
The OWASP Agentic Security Initiative’s AIUC-1 crosswalk, published May 2026, identifies eight priority areas where requirements may need expansion, including agent identity, runtime containment, and supply chain attestation. Naming an incident origin does not establish a certifiable control for it. The MATRA case study on OpenClaw likewise shows that using a structured threat model on a production system can reveal attack paths for which no mitigations are available. An acknowledged gap is a valid output of analysis.
The strongest objection to an imperfect taxonomy is that its apparent order can create false confidence. That objection applies when classification is mistaken for coverage. Without a structured map, teams still face the same attacks but are more likely to misattribute them to familiar application events. SecOps teams adopting this framework should maintain a live gap register naming the layer-by-timescale combinations with no detection coverage and update it as tooling and research mature. That register makes the limits of the response model actionable.
Sources
- MATRA: Modeling the Attack Surface of Agentic AI Systems -- OpenClaw Case Study
- A Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents:A Layered Attack Surface Framework
- [2604.23338] A Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents: A Layered Attack Surface Framework
- Securing Agentic AI: A Comprehensive Threat Model and Mitigation Framework for Generative AI Agents


