AI Agent Incident Classification Beyond Manipulation Signals
Security incidents in AI agents span tool execution, memory.

To secure enterprise AI agent tool calls, teams must keep OAuth credentials outside agent runtimes, enforce access policy on every MCP tool call, and tie each action to a human-authorized identity. But credential controls alone cannot classify every incident. AI agent incident classification must cover tool execution, memory, identity, multi-agent coordination, and supply chain, because each needs its own detection and response logic.
Why prompt injection is an incomplete model of AI agent risk
Prompt injection dominates the enterprise conversation about agent security. Content filtering, system-prompt hardening, and input sanitization follow naturally from that focus. Yet those controls are limited to instructions presented to a model. An agent retains state, invokes privileged tools, remembers information across sessions, and coordinates with peers.
The distinction changes what counts as an incident. Harm can emerge from a chain of authorized actions, pass through a component that another component’s defenses cannot inspect, or remain dormant across sessions. A payload can cause damage without producing a suspicious prompt at that moment. Responders who look only for manipulation signals can therefore mistake the visible action for the original failure, or miss the incident altogether.
What a layered classification framework actually maps
The Layered Attack Surface Model (LASM) separates the agent stack into seven architectural layers, each with its own trust boundaries and places where detection can work. It also classifies attacks by time. It has four classes based on time: instantaneous (T1), session-persistent (T2), cross-session cumulative (T3), and sub-session-stack (T4). This gives responders two different questions to answer, which are where the failure occurred and how it unfolded.
The LASM survey identifies seven of the 28 layer-by-temporality cells with zero defense coverage, including three containing documented attacks. Its non-transferability result explains the practical risk. A control at one layer has zero detection power against an attack localized at another. The under-studied intersection of coordination, ecosystem, and governance with T3 and T4 is therefore not an extension of prompt filtering but a separate coverage problem.
Research from TU Berlin and Max Planck draws a useful analogy with an operating system. The runtime acts as a kernel mediating access, tools resemble system calls, skills resemble programs, and the gateway resembles network egress. Isolation, privilege separation, and least privilege belong at the boundaries where resources and authority change hands.
Tool execution as the highest-leverage attack layer
At Tool Execution, instructions that have been manipulated turn into privileged actions. The LASM survey finds that every surveyed attack at this layer reduces to principal trust inversion. MCP tool metadata creates one such route. Servers supply names and descriptions directly to the model’s context, where hidden instructions can acquire authority the user never granted.
Invariant Labs demonstrated this against Cursor IDE. A malicious MCP server embedded an instruction in its tool description and exfiltrated a user’s SSH private key through normal-looking tool invocations, without a visible anomaly. Related attacks can cross server boundaries by replacing trusted tool definitions, or evade registration-time review by swapping a benign definition after access is granted.
Not every failure here begins with poisoning. The Replit DROP DATABASE event in July 2025, Cursor destructive-shell-command incident in August 2025, and Claude Code DataTalks.Club infrastructure-destruction event in February 2026 resulted from excessive agency at the tool layer.
The defensive consequence is specific to execution. Teams should set alerts for tool definitions that change, scopes that grow, unusual numbers of calls, and access to sensitive data. Changes to tool definitions need the same review as a deployment, and teams need a way to disable individual tools and servers quickly. Using separate credentials for development, testing, and production limits which environments a compromised tool can reach.
Memory as an attack surface that spans sessions and defeats event-based detection
Memory poisoning separates the injection from the damage. An adversarial document retrieved during a routine web search can corrupt long-term memory and influence an unrelated session weeks later. The retrieval and the later action can each look normal when viewed on their own. A detector watching individual prompts or tool calls lacks the history needed to connect them. This is a T3 threat.
The LASM framework finds that no current benchmark evaluates T3 or T4 threats. That leaves a measurement gap as well as a detection gap. An incident may first appear as unexpected data access even though its cause lies in an earlier memory write. Starting the investigation at the final tool call risks assigning the incident to the wrong layer.
The detection record must therefore span sessions. Teams should log memory reads and writes, track behavioral drift over time, and apply write-integrity checks to persistent stores. Access control answers who may write. Tamper detection addresses whether stored content has been corrupted, which is a different question.
How do enterprises secure MCP OAuth credentials and close agent identity gaps?
Reliable identity is a prerequisite for explaining authorization. Without it, responders cannot establish which principal authorized a tool call, whether a token was legitimately delegated, or whether an action stayed within its scoped rights. An internet scan in July 2025 found at least 1,862 MCP server instances that were open to the public and responded to unauthenticated requests. Missing authentication leaves that authorization question unanswered at the outset.
Overpermissioning creates a different version of the problem. When integration approval defaults to full read/write access, agents can receive maximally permissive credentials indefinitely. A valid token then says little about whether a particular destructive action was appropriate. Token theft, credential overpermissioning, token audience confusion, and broken delegation chains consequently need an identity incident class.
The practical credential pattern is a token vault. Teams should keep credentials entirely outside agent runtimes, with the vault storing, retrieving, and refreshing OAuth tokens for external services while isolating them from agent code. Least-privilege scopes and task-limited credentials address what access is granted and for how long. Resource Indicators (RFC 8707) and audience validation on every call address which MCP server a token is intended for. Those controls complement authentication rather than treating it as proof of unrestricted authority.
Multi-agent coordination as a trust propagation problem
A compromised sub-agent can pass malicious intent to peers that trust it. Each downstream agent may stay within its own rights while the workflow as a whole serves an attacker. The individual actions can look authorized throughout. Single-agent defenses cannot explain that chain because the failure lies in how authority propagates between agents.
The state-sponsored GTG-1002 campaign demonstrated the scale of this problem. A jailbroken Claude Code agent executed the majority of an espionage operation against a substantial number of targets. Agents trusted peer instructions without independently verifying their integrity. A compromised sub-agent’s instructions could therefore function like legitimate orchestrator commands, allowing trust to move the attack through the workflow.
Classification at this layer must preserve trust provenance. Responders need to know which agent issued an instruction, how authority was delegated, and whether each step had explicit human authorization or merely inherited trust from an earlier output. Teams should trace tool calls through the full agent call graph and flag effective permissions that go beyond those of the original human-authorized session. Agent-to-agent messages are trust boundaries requiring scrutiny. The operating-system principle of confinement provides the corresponding rule that a process cannot grant privileges beyond its own.
Supply chain as the layer where threats enter before an agent runs its first task
Supply-chain attacks distribute the weakness before runtime detection begins. A compromised package or server definition can reach every downstream deployment that trusts it. OX Security’s April 2026 STDIO finding illustrates a design-level version of that exposure. The command execution vulnerability was embedded in Anthropic’s official MCP SDKs for Python, TypeScript, Java, and Rust, exposing hundreds of thousands of vulnerable instances across a supply chain exceeding 150 million package downloads.
Anthropic described the behavior as intentional and declined to modify the protocol architecture, leaving remediation to downstream developers. That distinguishes the class from an isolated coding mistake. A local patch leaves the design default in place in the reference implementations that share it. Classification must record that origin so response does not stop at the first affected application.
The same layer also includes compromised server provenance, malicious skills, and unapproved dynamic capabilities. Trend Micro found 492 internet-exposed MCP servers with zero authentication, illustrating the risk of treating available servers as trusted dependencies. Teams should pin approved packages, versions, and signed artifacts, audit marketplaces before onboarding skills, and block unapproved dynamic tool additions. A server registry should record owner, version, data classification, permissions, and approval, with review on every MCP specification revision or material SDK upgrade.
Why current incident reporting fails to capture what actually happened
Correct classification is useless without evidence of the chain. Agents compose tools, sub-agents, APIs, and external data at runtime, creating conditions that may never have existed during testing. Debug logs were not designed to reconstruct that authority chain. The destructive incidents already described leave a central governance question unanswered by any single available record. Under what scoped authority was the action taken?
A sufficient record has to join independently logged layers. Tool records need the server identity and the version of the definition, while memory records need reads and writes with timestamps across sessions. Identity records need to show token issuance, audience validation, and the history of delegation. Coordination records need the call graph and effective scope at each node, connected to the package version, hash, and provenance recorded at deployment.
The EU AI Act’s December 2027 enforcement for high-risk AI systems requires lineage-backed auditability and human oversight. Without structured records that span layers, deployments have no evidence with which to answer a lineage query. Structured incident reporting also captures novel attack patterns that appear only in production, allowing the classification framework to develop as agents compose new workflows.
The governance gap between deployment velocity and classification maturity
Deloitte’s 2026 survey finds that a large majority of enterprises have deployed or are actively planning agents, while only a minority believe their agent governance model is mature. Deployment is outrunning the ability to govern actions. Most organizations’ lack of means to enforce purpose limitations or terminate a misbehaving agent once it is running directly weakens response to tool execution and coordination incidents.
Static policies and annual audits cannot follow workflows that change in real time. Agents act, iterate, and invoke external services between review cycles, so retrospective documents cannot serve as execution controls. Model governance checks whether a model is fair and has been documented. Agent governance checks whether an agent acted within its scoped rights and in environments that had been approved.
Agent identity, app-aware permissions, MCP gateway controls, and shadow AI discovery support governance over actions. High-impact actions, including payments, customer communications, and infrastructure mutations, require human review before execution. That review has to operate at the tool and coordination layers where the action can still be stopped.
What a working incident classification program looks like across the full stack
Security and platform teams should build detection and response logic for each attack surface and link them through a shared identity and audit system. Tool alerts need fast server-level or tool-level shutdown. Memory monitoring needs history across sessions, identity controls need checks on tokens and delegation, coordination needs tracing through the whole chain, and supply-chain review needs provenance to be approved before deployment.
For enterprise MCP access policies, enforcement must reach beyond a firewall seeing the resulting HTTP request to the point where the agent invokes a tool. SSO and SCIM integration should tie actions to human-authorized identities, while just-in-time credentials should exist only for the task and prevent reuse or pivoting. Audience validation and least-privilege scoping then constrain the authority available to each call.
The audit trail that teams share must be tamper-proof. It should capture server identity, tool-definition version, caller, user, scopes, arguments, result, and approval, with full OTEL tracing to reconstruct cross-layer causes. Records need to answer lineage queries as well as explain why a request failed. That is where a unified control approach improves on disconnected tools and manual reconstruction.
The program’s test is whether it can explain and stop an action. It must connect a tool call to the person who authorized it, the scope they granted, and the chain that produced it. With that foundation, security teams make adoption possible without asking every deployment team to rebuild governance from scratch.
Sources
- A Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents: A Layered Attack Surface Framework
- MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure
- Toward Securing AI Agents Like Operating Systems
- Beyond Predictable Paths: Redefining AI Security Incident Reporting for Agents
- ASTELD: A Six-Axis Classification Framework for Autonomous AI Agents —


