When your SOC lead calls at 2 a.m. to say an AI agent just made 300 unauthorized API calls in the last hour, you don't have time to review your governance framework. You need answers to specific questions, right now. Here are the questions I hear most often from incident response teams handling their first AI agent compromise, and the answers I wish someone had given me before I ran my first one.
Real-World Scenarios
These questions aren't hypothetical. They're pulled from post-incident debriefs, Slack threads during active containment, and the painful lessons teams learn when traditional incident response playbooks don't apply to AI agents. The scenarios are real: agents exfiltrating data through zero-click prompt injection, compromised OAuth tokens cascading across SaaS environments, and state-sponsored campaigns using AI to scale infiltration attempts across dozens of organizations with minimal human involvement.
Do I Isolate the Host or Kill the Credentials First?
Kill the credentials. This is the biggest mistake I see teams make, and it costs hours.
When you isolate a host running traditional malware, you stop lateral movement. But isolating a host running a compromised AI agent does nothing, because the damage already happened through API calls that executed three systems away before you even got paged.
Revoke or suspend the agent's credentials, API keys, and OAuth tokens immediately. Treat it like a compromised service account, not like an infected laptop. If the agent runs through an orchestration layer or gateway, disable its registered tools there instead of chasing individual downstream systems. Then freeze the agent's memory store and tool-call history without deleting it. You'll need that evidence to reconstruct what happened and why the model decided to do it.
How Do I Know if This is One Bad Session or a Systemic Problem?
Pull the tool-call logs and look for the entry vector.
If it's indirect prompt injection, you're probably looking at a systemic issue. A single poisoned document ingested during routine summarization can affect every agent session that touches it. EchoLeak, the zero-click flaw in Microsoft 365 Copilot with a CVSS score of 9.3, worked exactly this way: one crafted email triggered data exfiltration from OneDrive, SharePoint, and Teams with no user interaction required.
Check whether other agents built from the same base configuration or tool integration have access to the same poisoned content. If they do, pause them as a precaution while you scope the full blast radius. This is rarely a single-victim event.
What Alerts Should I Be Watching For?
Your SOC's standard alerts won't catch most agent incidents. They're tuned for human attackers or fixed-instruction malware, and agents break both patterns.
Watch for tool-call volume from a single agent identity that's statistically abnormal compared to its baseline. Look for agents acting outside their declared task scope: an email-summarization agent suddenly querying a file share, or a customer-support bot accessing internal HR systems. Monitor outputs that reference instructions no human operator gave, especially if those instructions appear in the reasoning chain but not in the authorized prompt template.
The OWASP LLM Top 10 ranks prompt injection as the number one threat facing these systems, and it's the hardest to detect because the malicious input looks like legitimate content the agent was designed to read.
When Do I Notify Legal and Leadership?
Before you're certain. Waiting for forensic certainty is how AI incidents turn into disclosure failures.
Give leadership a first briefing within four hours of detection, even if you don't have the full picture yet. Tell them three things: what the agent could access based on its entitlements, what the evidence currently shows it did access, and what's still unknown. Loop in legal early if the agent touched regulated data, because Breach Notification Requirements have timelines that don't pause while you finish root-cause analysis.
If the agent's actions created new artifacts along the way (a scheduled task, a forwarding rule, a new API key), that's material for the notification because it signals persistence risk.
How Do I Figure Out Why the Agent Did What It Did?
Walk the full prompt and response chain, including everything the agent retrieved before the anomalous action.
You're not just rebuilding what happened on disk. You're rebuilding the decision chain: what instruction, visible or hidden, redirected the agent's behavior? Check whether the agent's own reasoning output shows it recognized the instruction as suspicious and proceeded anyway (that's a guardrail gap) versus never flagging it at all (that's a detection gap). The fix looks different depending on which one you find.
This forensics work takes longer than traditional breach analysis because you're reverse-engineering model behavior, not just tracing file access or network connections. Budget 8-16 hours for this phase if you want actionable findings.
Can I Just Restore the Agent to Its Prior Configuration Once I Patch the Vulnerability?
No. That's how these incidents come back within a week.
Patch the specific vector, but also tighten the tool scope, sanitize the ingestion path, or add an approval gate for whatever action class was abused. Re-issue credentials with narrower entitlements than before, never identical ones. If the agent had write access to a file share but only needed read access for its task, fix that before you restore service.
Document the configuration changes in your 24-hour incident summary while the timeline is still fresh. That summary becomes the input for your post-incident review and, often, a regulatory or customer notification.
Prepare for the Next Incident
Run a tabletop exercise against the clock before you need it. The teams that handle AI agent incidents well aren't the ones with the most detailed risk taxonomy. They're the ones who've already rehearsed the first 24 hours: contain by identity, freeze evidence, notify early, and never restore to the exact configuration that just failed. The next incident won't wait for your policy to catch up.
