AI Agent Breach Investigation: Forensics Playbook 2026

AI agent forensics demands a different investigative approach than traditional digital forensics. In an AI agent breach investigation, the attack vector is natural language, and the core forensic problem is immediate: a malicious prompt is syntactically identical to a legitimate query in every log that most enterprises currently collect. There is no binary payload, no CVE signature, and no network packet that flags the injection.

This playbook is for security teams investigating breaches where an AI agent was the target, the vector, or the amplifier. In practice, we see all three patterns. Sometimes an agent is compromised via prompt injection and used to exfiltrate data. Sometimes a legitimate agent is manipulated via a poisoned document in its retrieval context. Sometimes an attacker uses an LLM as the post-exploitation engine after gaining an initial foothold via a conventional vulnerability. All three demand different evidence collection priorities but share a common challenge: agent audit trails are sparse, tool calls span multiple systems, and the logs that matter most often expire before the investigation starts.

Why AI Agent Forensics Is Different from Traditional IR

Traditional incident response rests on well-understood artifact categories: memory dumps, disk images, network packet captures, Windows Event logs, and process creation events. These exist because attackers interact with systems through code, and code leaves traces.

AI agents interact with systems through natural language and tool calls. When an attacker injects a malicious instruction into an agent's context, that instruction passes through the LLM's context window, influences the model's next-token predictions, and causes a tool call that would otherwise never have been triggered. At no point does any component in that chain raise a detection alert. The sentence was syntactically valid. The tool call was authorized. The sequence was the anomaly, and detecting a sequence anomaly requires that the complete sequence was collected in the first place.

Three structural properties of agentic systems make AI agent forensics materially harder than conventional IR:

No packet-capture attribution. When a human attacker runs a command, the command appears in system call logs tied to a process and user. When an injected prompt causes an agent to run the same command, the system call log shows the agent process as the caller with no record of the injected prompt that caused it, unless you collected LLM invocation logs with full prompt-response pairs.

Multi-hop tool execution across systems. A single injected instruction can trigger a chain: retrieve document, read file, call external API, send HTTP request. Each hop is individually authorized. Each hop appears in a different log owned by a different team. Reconstructing the causal chain requires joining across LLM invocation logs, tool execution traces, MCP server records, and egress network logs, typically spanning two or three separate systems.

Adaptive attacker behavior. CVE-2026-39987, covered in detail below, documented an LLM agent that paused and retried with alternative approaches when rate-limited during an exfiltration operation. No static script exhibits this behavior. The adaptive behavior is an indicator of compromise (IOC), but it only appears as an IOC if you have the complete sequence of tool calls with timestamps to identify the pattern.

What Logs to Collect and in What Order

Speed is critical because default retention windows are short. Many LLM API providers retain invocation logs for 30 days or less. MCP server logs may not persist at all unless retention was explicitly configured. Collect in this order:

1. LLM invocation logs. These are the most critical artifact and the most at risk of expiring. You need the full prompt-response pairs, including system prompts and any injected context, not just token counts. Without this, you cannot determine what the model was told to do or what instruction preceded the anomalous action.

2. Tool execution traces. Tool name, input arguments, return values, and the session identifier that triggered the call. Cross-reference against the LLM invocation log to map each model output to the specific tool call it caused.

3. MCP server logs. If the agent used the Model Context Protocol, the MCP server is the authoritative record of every tool invocation and result exchanged between the model and the underlying capability. The NSA's May 2026 Cybersecurity Information Sheet on MCP Security mandates that these logs include exact parameters, session identities, and cryptographic hashes of results. Deployments lacking this configuration now have a compliance gap under EU AI Act Article 12, which took full effect August 2, 2026.

4. Vector store retrieval logs. For RAG-enabled agents: query text, document identifiers and chunks returned, relevance scores, and which chunks were injected into context. This is the primary evidence source for identifying which document carried an injection payload.

5. Agent orchestration traces. Step-by-step reasoning chain, sub-agent spawning events, and handoff payloads between agents. In LangGraph or similar orchestration frameworks, these are the graph execution traces. They show the decision path that led to the anomalous action.

6. OAuth and API token issuance records. Which OAuth applications had grants from which users, when those grants were issued, and what scopes they carried. The Vercel April 2026 breach (covered below) traced directly to an OAuth grant that the security team had no visibility into.

7. Egress network logs. HTTP requests made by tool calls, destination IPs, payload sizes, and timing. In many cases, this is the only artifact that identifies the exfiltration endpoint. Look for elevated request volume to external hosts immediately following a retrieval event or a behavioral shift in the agent's output log.

Attack Pattern Recognition: Reading the Evidence

Three attack patterns account for the majority of AI agent security incidents. Knowing what each looks like in the log record accelerates triage significantly.

Prompt injection via retrieved content. The attacker plants a malicious instruction in a document the agent will retrieve. In the logs, this appears as a retrieval event where a specific document chunk enters the context window, followed immediately by a shift in the agent's output or tool call behavior, with no corresponding change in the user's stated instruction. The anomaly is the correlation: agent behavior changed at the moment a specific external document entered context. Cross-reference the vector store retrieval log with the LLM invocation log to identify the candidate document.

Exfiltration via tool call chaining. The attacker causes the agent to iterate through a data source and encode results into outbound calls formatted as normal agent activity. A documented case from March 2026 involved an agent with CRM access iterating through a customer database and embedding results in outbound API calls formatted as analytics events. Individual tool calls appeared legitimate. The attack ran undetected for three hours. Detection required reviewing the sequence: the same API endpoint called 2,300 times in 180 minutes with monotonically increasing offset parameters. No single call was anomalous; the volume and pattern were.

Credential and OAuth theft via AI tool access. The Vercel April 2026 breach is the canonical case. The attack chain began not with a vulnerability in Vercel's infrastructure but with an OAuth grant from an employee's Google Workspace account to a third-party AI productivity tool. When that tool's OAuth infrastructure was compromised, the attacker had a path into Vercel. The forensic indicator is the set of OAuth tokens active for AI tools at the time of the incident, particularly for tools with broad Google Workspace read scopes.

Recent research (arXiv 2606.04141, "Caught in the Act(ivation)") demonstrates that activation-level monitoring can detect credential exfiltration by LLM agents before the output token is generated, by analyzing the model's internal feature states during tool call construction. This is not yet widely deployed but represents the direction of detection tooling for agentic systems.

Case Study: CVE-2026-39987 and the First LLM Post-Exploitation Chain

In May 2026, attackers exploited CVE-2026-39987 in Marimo, an AI notebook platform, to demonstrate what LLM agent post-exploitation looks like operationally. The root cause was CWE-306: the terminal WebSocket endpoint at /terminal/ws accepted connections with no authentication. The vulnerability was fixed in Marimo v0.23.0.

The post-exploitation chain ran in four steps:

Pre-authentication RCE via the unauthenticated WebSocket gave the attacker an initial foothold on the Marimo host.

An LLM agent enumerated the filesystem and extracted two sets of cloud credentials from configuration files.

The agent used those credentials to retrieve an SSH private key from AWS Secrets Manager. To evade rate limiting, it distributed outbound requests across a pool of egress IPs.

The agent conducted eight short SSH sessions to a downstream bastion host and exfiltrated the full schema and contents of an internal PostgreSQL database. Elapsed time: under two minutes.

The forensic significance of this case is the behavior that traditional tooling missed entirely. The agent inspected its environment, discovered the credential storage location from directory structure alone, adjusted its exfiltration approach when rate-limited, and executed a multi-system chain without any pre-written script. Mandiant flagged two IOCs after the fact: anomalous operational velocity (credential retrieval and SSH sessions completed in a 90-second window) and deep product API knowledge (internal paths accessed consistent with the specific software version deployed).

If your organization runs AI notebooks or agentic compute environments, this case updates the threat model. An attacker with initial access can hand off post-exploitation to an LLM agent, and the agent will move faster and adapt more effectively than most human operators expect.

BeyondScale's AI penetration testing methodology tests agentic post-exploitation paths before attackers find them, including credential discovery patterns and tool call exfiltration chains.

Case Study: The Vercel Breach (April 2026) and OAuth Sprawl

On April 19, 2026, Vercel disclosed a breach in which an employee's Google Workspace account was compromised via a third-party AI productivity tool. The tool, Context.ai, had legitimate OAuth access to the employee's Workspace. When Context.ai's OAuth infrastructure was compromised in a wider supply chain attack, the attacker used that OAuth access to pivot into the employee's Vercel account and move laterally across connected environments.

Data exposed included API keys, source code snippets, and 580 employee records. Vercel engaged Google Mandiant within hours of detection.

The AI-specific lessons from this breach apply directly to enterprise security teams:

Shadow AI and OAuth sprawl are the enabling preconditions. The compromised employee had authorized Context.ai through standard Google OAuth. The authorization was legitimate, the grant was real, the employee access was valid. No perimeter control detected the chain because every step looked like normal authorized activity. Push Security's post-mortem analysis of the breach found that organizations typically carry three to seven AI tool OAuth grants per employee that the security team cannot enumerate without dedicated tooling.

OAuth grant enumeration is now a standing security procedure. Before and after any AI tool deployment, enumerate which AI tools have active OAuth grants from which employees, what scopes those grants carry, and whether those tools carry independent security certifications. Quarterly OAuth sprawl reviews are now baseline hygiene for any organization where employees adopt AI productivity tools.

Lateral movement through AI tool access chains is distinct from conventional lateral movement. Standard east-west detection looks for privilege escalation and credential reuse. In the Vercel case, the attacker moved from an AI tool OAuth grant to a Vercel environment through a legitimate session. No credential was stolen; the OAuth grant was the credential. Detection requires visibility into which AI tools have active grants and whether those tools' own security posture is sound.

For assessing your organization's AI tool OAuth exposure, BeyondScale's AI security assessment covers OAuth grant enumeration and AI tool supply chain risk as standard components.

Building Forensic Readiness Before the Breach

Forensic readiness is the configuration you put in place before an incident so that the evidence you need actually exists when you need it. For AI agent environments, three areas require deliberate attention.

Log completeness. The default logging configuration for most LLM API integrations captures token counts and latency, not full prompt-response pairs. Enable full request-response logging at the API layer. For self-hosted inference (Ollama, vLLM, LocalAI), this requires configuring a logging middleware because the model inference server logs nothing by default. For MCP deployments, follow the NSA's May 2026 guidance: every tool invocation and result, with session identity and cryptographic hash of result content.

Tamper-evident log storage. OWASP recommends WORM storage with cryptographic signing per log entry for AI agent audit trails. An LLM with write access to its own log sink can in principle manipulate its logged outputs. Out-of-band log collection, where the log transport path is entirely separate from the agent's execution environment, is the minimal acceptable design for any high-risk agentic deployment.

Retention policy alignment. EU AI Act Article 12, in full effect as of August 2, 2026, requires that records of AI system outputs and decisions be retained for a period consistent with the risk classification of the system. Review your LLM provider's default retention settings against this requirement. For many enterprise deployments, the provider's default 30-day retention is shorter than the mandated period for a high-risk AI system.

Pre-incident OAuth audit. Run a quarterly scan of all OAuth grants from corporate accounts to third-party AI tools. Flag grants with broad scopes (full Google Drive read, full calendar access, email read-write) from tools without documented security certifications. This is the control that would have reduced the Vercel blast radius if it had been in place.

Incident Containment for Agentic Systems

Containment for AI agent incidents differs from host isolation because agents operate across multiple systems simultaneously via tool calls. Pulling the network cable does not stop an agent that has already triggered downstream tool executions or stored credentials in an external system.

Containment steps specific to agentic incidents:

Revoke tool authorizations before isolating the host. If the agent has active OAuth tokens or API keys, revoke them at the authorization server before taking any other containment action. An isolated host with live credentials is still an active threat if those credentials are accessible in memory, configuration, or the agent's memory state.

Disable the agent endpoint. If the agent is invoked via an API endpoint or orchestration platform, disable that endpoint to prevent re-invocation during the investigation. Restarting the host does not prevent re-invocation if the endpoint remains live.

Freeze vector store and memory state. Create a snapshot of the agent's vector store and any persistent memory state before further agent invocations overwrite them. This is both evidence and a volatile artifact. In LangGraph and similar frameworks, this means capturing the thread state before any further runs execute against the same thread.

Enumerate connected tool servers. For MCP-based deployments, identify all tool servers that received calls from the compromised agent session. Notify those systems' owners for log preservation. Tool servers may have their own logs that predate what the orchestration platform captured.

Check for spawned sub-agents. In multi-agent architectures, a compromised orchestrator agent may have spawned sub-agents that are still running. Enumerate active agent sessions on the orchestration platform and treat any session spawned from the compromised parent as potentially compromised until the log record can be reviewed.

The OWASP GenAI Incident Response Guide 1.0 and NIST IR 8596 both address containment at the framework level. Neither provides the operational sequence above, which comes from what the IR community has observed in active investigations during the first half of 2026.

Building the Capability

AI agent forensics is not a conventional digital forensics problem with a new data source. It is a new evidence category requiring different collection procedures, different analysis methods, and different containment approaches.

The enterprises positioned to respond effectively are those that built forensic readiness into their agentic deployments before the first incident: full prompt-response logging enabled, tamper-evident log transport in place, OAuth grants audited quarterly, agent execution records retained to EU AI Act risk tier requirements, and a containment runbook that starts with credential revocation rather than host isolation.

1 in 8 enterprise security breaches now involves an agentic system as a primary target, contributing vector, or amplifier (Digital Applied, 2026). The investigative capability to handle those breaches is not keeping pace.

If your organization is deploying AI agents and has not yet reviewed the logging and forensic readiness posture of those deployments, that review is overdue. Contact BeyondScale to assess your AI agent forensic readiness, or run a Securetom scan to identify exposed AI agent endpoints and audit trail gaps in your current environment.