In April 2026, a startup founder reported that a coding agent deleted the company's production database and its backups in nine seconds. Hold on the number. Nine seconds is faster than a human attacker can type a single command, let alone find the credential, decide to use it, and run it. That is the part your incident response plan is not ready for.
Most IR runbooks are mature about the incidents security teams have seen for years. There are steps for a compromised laptop, a leaked API key, a malicious dependency. There is an on-call rotation, a severity scale, a communications template.
There is usually nothing for "an agent session did something we cannot explain." No step for containing a process that reasons and improvises. No procedure that assumes the evidence is spread across a model's context window, a sequence of tool calls, and a stream of outbound requests rather than a single host.
This is a runbook for that gap. It assumes you can observe and act on an agent session, which is itself a prerequisite worth auditing before you need it.
Agent incidents are different in three ways
Before the steps, understand why your existing instincts partly mislead you here.
Speed. An agent acts in seconds, across many systems, without pausing to think the way an attacker weighing risk would. By the time a human notices, the session may have done more than a person could in an hour.
Autonomy. The session may have taken actions nobody prompted. It reasoned its way to a step that was never in the instructions, which means "what was it told to do" does not bound "what it did."
Scattered evidence. The record of what happened is not in one place. It lives in the model's context window, in the tool calls the agent made, and in the network requests those calls produced. Reconstruction means correlating across all three, not grepping one log.
Those three properties shape every step that follows.
Step 1: Stop the session, keep the volume
The first instinct in a containment is to kill the thing. Resist the version of that instinct that also destroys your evidence.
Stop the session so it stops acting. Do not delete the workspace, the container or the volume as your first move, because that is where the record of what the agent did lives. Containment that erases the evidence is not containment, it is cleanup, and you will regret it the moment leadership asks what happened. The correct first action is to halt execution while preserving the session's state for inspection.
On the public site, Marshal describes this as the ability to stop any Space with its volume preserved. That is the capability this step needs: a hard stop that keeps the disk.
Step 2: Scope the blast radius by reachability
With the session stopped, the next question is not "what did it do" but "what could it have reached." Reachability bounds the investigation.
Enumerate what this session had a path to: the destinations its egress policy allowed, the credentials it could use (by reference, you should never need to handle the secret itself to answer this), the databases it could connect to, and the MCP servers and tools it had loaded. That set is the maximum blast radius. Everything outside it you can rule out quickly, which is as valuable under pressure as confirming what is in scope.
This step is dramatically easier if credentials were never held by the agent in the first place, because then "which secrets leaked" collapses to "which references were used," and the secrets themselves were never in the session to take.
Step 3: Rebuild the timeline
Now reconstruct what actually happened, in order.
Correlate three streams by session and timestamp: the egress verdicts (every outbound request the session made, allowed or denied, and where it went), the tool calls (what the agent invoked, with what arguments), and the database statements (what it sent over the wire to each engine). Laid on one timeline, these tell the story: the agent read this, decided that, called this tool, reached this destination, ran this statement. This is the artifact your post-incident review is built on, and it is why the audit trail has to be complete and queryable before an incident, not assembled hopefully after one.
Step 4: Rotate in the right order
Rotation seems simple, revoke the exposed credentials, and in the agent era it has a trap.
Some malware punishes revocation. A compromised dependency can plant a dead-man's-switch monitor that wipes a developer's home directory if its stolen token is revoked before the monitor itself is removed, a pattern covered in the post on agent config files as an attack surface. So the order matters: remove persistence first, then revoke. Find and remove any planted monitors, hooks or config writes the session left behind, confirm the environment is clean, and only then rotate the credentials. Revoking first can trigger exactly the destructive payload you are trying to prevent.
Step 5: Change the policy, live
Containing one session does not protect the others. The last operational step is to close the path for everyone.
If the incident revealed a destination that should never have been reachable, or a verb that should never have been allowed, change the policy and have that change take effect for every running session, without restarting them. Marshal describes this on the public site as the ability to revoke a rule live. The goal is that the window between "we understand the path" and "the path is closed for the whole fleet" is measured in moments, not in a redeploy cycle.
Post-incident: what to tell leadership
Close the loop with a short written summary that a non-specialist can act on. A generic template, every field filled from the evidence and never from memory:
- What the session was triggered to do - the ticket, schedule, or request behind the run.
- What it actually did - the ordered timeline rebuilt in step 3.
- What it could have reached but did not - the blast radius bounded in step 2.
- What was rotated, and in what order - persistence removed first, then credentials.
- What policy changed - the destination or verb now denied across the fleet, so it cannot recur.
- Residual risk and owner - what remains open and who is accountable for it.
An incident summary that guesses at any of these is worse than none; if a field cannot be filled from the timeline, say so plainly.
Agent incidents are faster, more autonomous, and more scattered across evidence than the incidents your runbook was written for. Five steps make them tractable: stop the session but keep the volume, scope the blast radius by reachability, rebuild the timeline from egress verdicts and tool calls and database statements, rotate in the right order by removing persistence before revoking, and change the policy live for every other session. The common thread is that all five depend on having observability and control over agent sessions before the incident starts.
The persistence trap in step 4 comes from your agent's config files, now an attack surface →
Marshal lets you stop any agent session with its volume preserved, trace every request from one audit trail, and revoke a rule live across the fleet. Book a demo →