First 24 Hours: Responding to an AI Agent Incident

The clock starts ticking the moment an AI agent does something nobody authorized. Whether it's a prompt injection, a hijacked session, or an agent operating outside its intended scope, the first day is critical. This playbook walks through what to do, hour by hour, drawing on real-world incidents like Anthropic's GTG-1002 campaign and the EchoLeak vulnerability in Microsoft 365 Copilot.

Why Agent Incidents Differ

Traditional incident response is built around human attackers moving at human speed, or malware executing a fixed set of instructions. AI agents break both assumptions. They can act autonomously, chaining together tool calls and making decisions at machine speed, often with little human oversight.

Anthropic's account of the GTG-1002 campaign is a stark example. A Chinese state-sponsored group manipulated Claude Code into attempting infiltration against roughly 30 organizations, and the AI reportedly carried out most of the tactical work with minimal human involvement. The tempo is the scary part: this isn't a phishing email sitting in an inbox for a day before someone clicks it. It's a compromise that scales itself while your team is still getting paged.

The EchoLeak Example

Earlier, researchers at Aim Security disclosed EchoLeak, a zero-click prompt injection flaw in Microsoft 365 Copilot with a CVSS score of 9.3. A single crafted email, ingested during routine summarization, was enough to trigger data exfiltration from OneDrive, SharePoint, and Teams with no user interaction at all. No link to sandbox. No attachment to detonate. Just content the agent was designed to read.

This is exactly the class of risk that OWASP's LLM Top 10 now ranks as the number one threat facing these systems.

Blast Radius in the Wild

Obsidian Security's analysis of the Salesloft-Drift OAuth compromise shows how a single compromised connected app cascaded into hundreds of downstream SaaS environments. When agents are the ones holding the tokens and chaining tool calls across systems, that pattern is likely to get worse, not better.

What these incidents share is a structural feature that rewires how you run the first day: the attacker may be a set of instructions embedded in a document, a poisoned tool response, or a manipulated memory store — not a person sitting behind a keyboard.

Hour 0: Recognize What You're Looking At

Detection is often where time is lost. Agent incidents rarely trip alerts tuned for traditional threats. Look for tool-call volume from a single agent identity that's statistically abnormal, an agent acting outside its declared task scope (like an email-summarization agent suddenly querying a file share), or outputs that reference instructions no human operator gave. The job at this point is triage, not diagnosis: is this one compromised session, a shared credential, or a systemic prompt-injection vector sitting in a document that any agent might ingest?

Hours 0-1: Contain by Identity, Not by Host

Traditional IR playbooks often get this wrong for agents. Pulling a network cable does nothing if the damage already happened through an API call three systems away. Revoke or suspend the agent's credentials, API keys, and OAuth tokens immediately, the same way you would treat a compromised service account. Kill the active session if the orchestration layer supports it. Freeze, but don't delete, the agent's memory store and tool-call history, because you will need every bit of it later. If the agent runs through a broker or gateway, disable its registered tools there rather than chasing individual downstream systems one at a time.

Hours 1-4: Scope the Blast Radius

Now answer what the agent actually touched. Pull the full tool-call log, every API invoked, every parameter passed, every response received, and cross-reference it against the agent's entitlements to see what it could reach versus what it did reach. Also check whether the agent's own actions created new artifacts along the way: a scheduled task, a forwarding rule, a new API key. Autonomous agents are often better at persistence than the people who built them. If the entry vector looks like indirect prompt injection, try to identify every other session that ingested the same poisoned content. This is rarely a single-victim event.

Hours 4-8: Notify Before Certainty

Legal, privacy, and executive stakeholders need a first briefing well before forensics is complete. Waiting for certainty is how AI incidents turn into disclosure failures. Give leadership three things: what the agent could access, what the evidence currently shows it did access, and what's still unknown. Loop in legal early if the agent touched regulated data. And make an explicit call on whether other agents built from the same base configuration or tool integration need to be paused as a precaution, since a single vulnerable pattern can be replicated across an entire agent fleet before anyone notices.

Hours 8-16: Reconstruct the Decision Chain

This forensics work is genuinely different from a traditional breach. You're not just rebuilding what happened on disk; you're rebuilding why the model decided to do it. Walk the full prompt and response chain, including anything the agent retrieved before the anomalous action, and try to find the specific instruction, visible or hidden, that redirected its behavior. Check whether the agent's own reasoning output shows it recognized the instruction as suspicious and proceeded anyway (points to a guardrail gap) versus never flagging it at all (points to a detection gap). The fix looks different depending on which one you find.

Hours 16-24: Restore, but Change Something First

Don't restore an agent to its prior configuration by default. That's how these incidents come back within a week. Patch the specific vector, sanitize the ingestion path, tighten the tool scope, or add an approval gate for whatever action class was abused. Re-issue credentials with narrower entitlements than before, never identical ones. And write the 24-hour incident summary while the timeline is still fresh, because it becomes the input for both the post-incident review and, often, a regulatory or customer notification.

The Takeaway: Rehearse the First Day

Risk frameworks tell us agents need least-privilege access and human oversight. That's true, but it's not actionable at hour one when you're the one being paged. What you actually need in the room is operational sequencing: contain by identity before you contain by host, freeze evidence before you patch, notify before you are certain, and never restore to the exact configuration that just failed.

This could mean the industry's missing piece is not another governance framework, but rehearsed, time-constrained operational practice. The next incident won't wait for policy to catch up.