Incident Response When the Actor Is an Agent

Incident response was built around the assumption that the actor on the other end of the keyboard was a person. A person you could call. A person who could explain what they meant to do. A person whose intent, however garbled by panic or fatigue, was at least a thing that existed.

That assumption is quietly breaking. The first wave of incidents where the responsible party is an agent has started to land in IR queues, and the playbooks most organizations have do not contain useful instructions for what to do next.

What is different

Three things change when an agent is the actor in an incident.

The first is that intent is no longer a meaningful question. You cannot ask the model what it was trying to do, because the model does not have continuity of intent the way a person does. You can examine the prompt that was given to it, the tools it had available, the context it accumulated during the session, and the chain of actions that resulted. But "what were you thinking" is a question with no useful answer. The investigation has to focus on the inputs and the actions, not on the actor's state of mind.

The second is that timeline reconstruction depends entirely on logging that most organizations have not yet built. A human incident leaves traces in the systems the human touched — terminals, browsers, email, chat. An agent incident leaves traces only in the audit infrastructure that was specifically built to capture agent actions. If that infrastructure is incomplete, the timeline has gaps. If it does not exist, the timeline does not exist.

The third is that containment is a different operation. Disabling a human's account stops one actor. Disabling an agent's session stops one actor, but the underlying capability — the model, the credentials, the tooling — is still available and can be invoked again, by another session, by another prompt, possibly within minutes. Containment in the agent case is closer to disabling a build pipeline than to disabling an account.

What the playbook needs

A workable IR playbook for agentic incidents has a few additions to the human-actor version.

It assumes the prompt file, the session log, and the tool-call trace are the primary evidence. If those artifacts are not being generated as a matter of course, the IR function has to flag that as a control gap before the first incident, not during it. Reconstructing a session from API logs alone is possible and miserable.

It distinguishes between the immediate actor (the session), the authorizing party (the human who launched it, or the upstream agent that delegated to it), and the capability owner (the team that built or deployed the agent role). Each of these has different obligations during the response. The session is the thing to contain. The authorizing party is the source of context on what was supposed to happen. The capability owner is the only party who can prevent recurrence.

It includes a step for capability-level revocation, not just session-level revocation. If a particular agent role has produced an incident, the question is whether that role should continue to exist in its current form, not whether the specific session that misbehaved should be terminated. The session has probably already ended on its own by the time the alert fires.

It has a model-vendor branch. If the incident appears to involve unexpected model behavior — a jailbreak, a prompt injection, a hallucinated tool call that succeeded — the vendor is part of the response, with the response timelines and disclosure obligations that implies. Most IR playbooks have no entries for "call the foundation model provider," and they will need them.

The post-mortem question

The post-mortem after an agentic incident asks a question that the post-mortem after a human incident does not have to ask, which is: should this work have been delegated to an agent at all?

For some incidents the answer is straightforward — the agent did something a human would have done equally wrong, and the response is to fix the prompt or tighten the scope. For others the answer is harder. The agent did something a human would not have done, because the agent does not have the implicit context that kept the human from doing it. In that case the right answer might be to pull the capability back, not to refine it.

This is uncomfortable territory because the organizational pressure on AI capabilities is to ship more of them, not fewer. An IR function that periodically recommends rolling back an agent capability is doing its job, and is going to be unpopular for doing it. That tension needs to be acknowledged in the playbook before the first incident makes it acute.

The honest summary is that incident response for agents is a discipline that does not yet exist in mature form. Building it is mostly a matter of adapting the disciplines that already exist, with a clear-eyed view of where the analogies break and where new structures are needed. The work is in progress at most organizations that have agents in production. It is overdue at most that do.