At 14:23 on a Tuesday afternoon, an alert fires in the AIGuard console of a mid-market financial services firm. The Agent Threat Prevention engine has scored a developer's Claude Code session at 0.91 — critical threshold. The session has been running for 47 minutes. The developer is still at their desk.
The security analyst on duty faces a problem that didn't exist three years ago: what just happened, and how do I investigate it? There's no malware binary to quarantine. There's no network connection to an obviously malicious IP. There's no file exfiltration alert from the DLP system. There's an AI agent that has been behaving suspiciously according to a behavioural scoring model, and a developer who may or may not know anything about it.
This scenario is increasingly common in organisations that have deployed AI security infrastructure. And the incident response discipline required to investigate it correctly is genuinely different from traditional security IR — different enough that applying standard IR frameworks without adaptation will consistently lead to incorrect conclusions and incomplete remediation.
Why Traditional IR Playbooks Don't Apply
Traditional incident response is built on a set of assumptions that don't hold for AI incidents.
Assumption 1: There are logs by default. In traditional enterprise security, the primary challenge is often log volume and correlation, not log existence. Operating systems, network devices, and enterprise applications all generate logs as a matter of course. AI systems generate logs only if you've configured them to — and most organisations haven't. An AI agent session without session-level logging is a black box after the fact.
Assumption 2: You can do memory forensics. Traditional IR frequently involves capturing and analysing process memory to reconstruct what happened. An LLM's "memory" — its context window at a given moment — is ephemeral. It's not stored in any format that's amenable to forensic analysis after the session ends. Once an agent session completes, the information that was in its context window is gone unless it was logged.
Assumption 3: Malicious and benign actions look different. Traditional IR can often identify malicious actions by their anomalous nature — unusual process trees, unexpected registry modifications, suspicious network connections. AI agent actions that constitute an attack often look identical to legitimate agent actions. An agent reading an environment file and making a network connection is exactly what legitimate agents do. The attack is in the sequence and the causation, not in any individual action.
Assumption 4: You can contain and eradicate. Traditional IR follows Detect → Contain → Eradicate → Recover. With AI incidents, "contain" is often premature termination of a session that may or may not be malicious, with significant risk of disrupting legitimate work. "Eradicate" has no clear meaning for an LLM that has no persistent state. The IR model needs to be adapted accordingly.
What an AI Incident Looks Like
An "AI security incident" is not a well-defined category yet — the field is too young. Based on our incident response work with enterprise customers, we've identified three primary incident types:
- Exfiltration attempt — an agent session, whether through prompt injection or insider threat, attempts to transmit sensitive data to an external endpoint. The data in transit may be credentials, source code, customer records, or any other sensitive information the agent had access to.
- Jailbreak success — a user or external input has successfully caused a customer-facing or internal AI application to produce output that violates its operational policy: generating harmful content, circumventing business logic, producing disinformation, or bypassing safety controls.
- Data leak via prompt — sensitive data has been submitted to an AI service that has no contractual basis to receive it (e.g., PHI submitted to a non-BAA-covered service, trade secrets submitted to a consumer AI interface). Often not malicious intent — inadvertent exposure through shadow AI use.
The Six-Step AI IR Process
Detect: Identify the Triggering Signal
What fired the alert? ATP threat score spike, DLP detection in a prompt or response, anomalous network connection from an agent process, or human report from the developer? The triggering signal determines which evidence sources to prioritise in subsequent steps. Different signal types point to different investigation paths.
Contain: Pause Before Terminating
The instinct to immediately terminate the agent session is understandable but often counterproductive. If the session is still running, it's generating evidence. A premature termination destroys context that would have clarified whether the activity was actually malicious. Unless there's evidence of active exfiltration in progress, contain by monitoring closely rather than terminating immediately. Block the specific suspicious network connection if possible while preserving session logging.
Collect: Build the Session Timeline
The session timeline is the primary forensic artefact for AI incident investigation. From AIGuard's session logs (or equivalent), reconstruct the complete tool call sequence: what the agent read, what it wrote, what external calls it made, what it was instructed to do at each step, and what the ATP risk score was at each point. The timeline should show the causal chain, not just the individual events.
Analyse: Identify the Causal Chain
Using the session timeline, identify the specific event or content that caused the behavioural anomaly. In injection attacks, there will typically be a discrete inflection point: a specific file read, URL fetch, or tool call result that preceded the shift in agent behaviour. Identifying this inflection point is crucial both for understanding what happened and for remediating the source of the injection.
Remediate: Address Source and Effect
Remediation in AI incidents has two components. First, address the source: if the incident was caused by injected content in a repository file, remove or neutralise the injection payload and audit the repository for other potentially injected content. If it was caused by a malicious MCP server, remove the server from the agent configuration and block it at the network level. Second, assess the effect: what data was exposed or potentially exfiltrated? Initiate the appropriate regulatory notification process if sensitive data was involved.
Post-Incident: Update Detections and Policies
Every AI incident provides intelligence for improving detection capability. The specific injection technique, exfiltration method, or jailbreak pattern used in the incident should be codified as a detection signature or policy update. The AIGuard review process includes a structured post-incident workflow that translates incident findings directly into updated ATP behavioural signatures and DLP detection rules.
Session Timelines in Practice: A Walkthrough
Returning to our opening scenario — a Claude Code session scored at 0.91 critical — here's what the session timeline investigation looks like in practice:
The session timeline makes the causal chain visible in a way that no individual log entry could. The injection point is identifiable (the external URL fetch at 14:21), the mechanism is clear (injection via documentation page content), and the attempted exfiltration channel is documented (HTTP request to external domain). Remediation is now straightforward: identify and patch the injected README, audit other project documentation for similar payloads, and review the external URL's full content for additional injection attempts.
- Traditional IR assumptions (logs by default, memory forensics, anomalous-looking attacks, clear contain-eradicate) don't hold for AI incidents — the discipline needs adaptation.
- Three primary AI incident types: exfiltration attempt, jailbreak success, and data leak via prompt (often inadvertent).
- The six-step AI IR process: Detect → Contain (pause, don't terminate) → Collect session timeline → Analyse causal chain → Remediate source and effect → Post-incident detection updates.
- The session timeline is the primary forensic artefact — it must be logged in real time during the session; it cannot be reconstructed after the fact if logging was not configured.
- The inflection point in the causal chain (the specific event that triggered behavioural change) is the key finding that makes remediation possible.
Build your AI incident response capability with AIGuard
AIGuard's session logging, behavioural timeline, and ATP scoring provide the forensic infrastructure that AI incident response requires. See it in action in a 30-minute demo.
Request a Demo