Incident Response for Agent-Driven Events
What changes when the incident moves at machine speed: containment, forensics without a hosted model, and four rehearsal scenarios.
19.1 What Is Different #
Four properties change the response.
Speed. Thousands of actions in the time a conventional intrusion produces dozens. Containment measured in minutes, not hours.
Volume as concealment. Genuine malicious actions hide inside legitimate automation. Decoy activity may be present, deliberately or emergently.
Ephemerality. Execution contexts are destroyed on completion. Evidence is lost by design unless preservation is automatic.
Distinguishing a compromised agent, a prompt-injected agent, a misconfigured agent, and an agent behaving correctly toward a badly specified goal is genuinely hard, and the response differs in each case.
19.2 Phase Actions #
Anomaly signals on the action stream—velocity spikes, destination diversity, unusual tool sequences, authorization denials clustering, credential use outside baseline. Correlate immediately with identity and network telemetry.
Halt the agent. Halt the agent class if the vector may be shared. Revoke credentials issued to the execution context. Cut egress at the network layer, not only at the orchestrator—an agent that reached the host may not respect the orchestrator. Preserve runtime state before destruction.
Reconstruct the action sequence from decision records and telemetry. Determine which authorization verdicts permitted each step; those are your control failures. Enumerate credentials touched and assume all are compromised. Separate genuine impact from decoy or incidental activity. Use your staged self-hosted forensic capability—the artifacts you need to analyze are exactly the artifacts hosted providers will refuse.
Internal escalation per severity. Regulatory assessment. Third-party notification if your agent affected an external party—including a plan for how you make contact with another organization’s security team quickly, which is a genuinely hard problem that is easier to solve before you need it.
Rotate everything the agent could reach, not merely what you can prove it used. Rebuild compromised nodes rather than cleaning them. Close the root vulnerability. Re-verify isolation before restarting the agent class.
Review the authorization decisions, not just the entry point. Ask which ceiling would have halted this earlier and why it was not configured. Update tiering for the affected agent class.
19.3 Rehearsal Scenarios #
Rehearsal fails as a program when every scenario is scoped as a full cross-functional tabletop, because ten annual tabletops is not a plan anyone executes. Split the work. A small number of scenarios genuinely require the whole response function in a room for half a day. Most are drills a single team can run in an afternoon, and drills are where the surprising results come from.
Scoped, single-team, executable within a few hours. Run these first and run them often; several will fail on the first attempt, which is the point.
| ID | Scenario | What it exercises |
|---|---|---|
| DR-1 | Forensic guardrail lockout | Hand the IR team genuine exploit payloads, command-and-control artifacts, and captured attacker commands, and have them attempt triage using whatever model the runbook actually assumes. Measure whether the analysis completes or the provider’s classifiers refuse it. This is the fastest, cheapest test in the framework and the one almost nobody has run. Treat it as the first rehearsal a new program conducts, ahead of any tabletop. |
| DR-2 | Delegation chain trace | Take a representative multi-agent workflow in which a high-privilege agent invokes a lower-privilege one, and reconstruct after the fact exactly what authority passed across the boundary and who authorized it. The drill is not really about prevention; it is about whether accountability is resolvable at all. Where the trace cannot be reconstructed, Path D is unmitigated regardless of what the controls documentation says. |
| DR-3 | Rogue agent kill | Identify an agent operating outside the registry—in a low-code platform, a SaaS feature, or a developer environment—and attempt to halt it, revoke its credentials, and attribute ownership. Everything in Sections 6 through 16 assumes a managed agent; this measures what happens where those assumptions do not reach. |
| DR-4 | Approval erosion probe | Route a realistic volume of approval requests through a human-in-the-loop control with one clearly malicious request seeded among them. Record whether it was caught, and the median review time across the batch. This tests people rather than systems, which is exactly why it gets skipped and exactly why the control degrades unnoticed. |
Full cross-functional exercises. Three or four per year is a realistic cadence for most organizations.
| ID | Scenario | What it exercises |
|---|---|---|
| TT-1 | Prompt-injected agent exfiltrating data using entirely legitimate permissions | No exploit, no anomalous credential use—the agent does exactly what its grants allow. Tests whether detection depends on catching a technical violation that never occurs. |
| TT-2 | Compromised agent execution context with lateral movement via standing credentials | The Path B scenario, and the shape of the July 2026 incident. Exercises egress containment, credential revocation timing, and evidence preservation from an ephemeral runtime. |
| TT-3 | Detection saturation | Introduce a genuine malicious action sequence during a period of elevated legitimate agent volume and measure whether it surfaces at all. This is the mechanism that produced a week of operator blindness in the anchor incident, and it is the scenario most likely to expose that the telemetry pipeline is recording rather than detecting. |
| TT-4 | Compromised MCP server or tool affecting multiple agents simultaneously | One supply-chain compromise, many agents, no user-visible change. Tests fleet-wide containment and whether the tool inventory is complete enough to scope the blast radius. |
| TT-5 | Your agent causes an incident at a third party | Outbound notification, including the practical problem of reaching another organization’s security team quickly. Rehearse the disclosure decision, not just the technical response. |
| TT-6 | A vendor’s agent causes an incident in your environment | The reciprocal of TT-5, and the one that exercises the contractual commitments behind procurement questions 23 and 24. Most organizations discover during this exercise that no such commitments exist. |
19.4 Optional Depth #
Add these where agents operate at T3–T4 autonomy or on critical systems.
Memory poisoning with delayed detonation. Context is poisoned in one session and exploited several sessions later. Tests whether containment extends to persisted state or halts only running processes—a distinction most kill switches do not make.
The benign-but-wrong agent. An agent behaving correctly toward a badly specified goal, causing real damage with no compromise anywhere. Tests the attribution ambiguity named in 8.1. Teams handle this case worst, because the correct response—change the specification, preserve the agent—is the opposite of the compromise playbook they have been drilling.