In the first hour of an AI agent incident, stop the agent from acting, not just from talking: revoke its credentials or switch its tools off. Then freeze the evidence: prompts, tool calls and the model and prompt versions in use. Name one incident owner, tell affected teams early, and only restore the agent once you know why it happened.
Why agent incidents need their own plan
Most companies already have an incident response plan for outages and security breaches. It assumes a system either works or fails, and that a person made the changes being investigated. An AI agent breaks both assumptions. It can keep running normally while doing the wrong thing, and every change it makes was made by software acting on a person's behalf.
Agent incidents also take forms your existing runbooks do not name. An agent can act on incomplete context, follow an instruction hidden in a document it retrieved, drift outside the scope it was given, or chain several reasonable steps into one harmful outcome. Security practitioners writing about agent incidents in 2026 make the same point: few organisations have a mature playbook for them yet.
The practical answer is not a separate process. It is an AI agent section added to the plan you already run, so the same on-call people, severity levels and communication channels apply, with agent-specific steps where they differ.
Contain the agent before anything else
The first instinct is to start investigating. Resist it until the agent can no longer act.
Stop the actions, not only the conversation
Closing a chat window or pausing a user-facing assistant does not stop an agent that runs scheduled jobs, works through a queue or is called by other agents. Containment has to remove its ability to change anything:
- Revoke or suspend its credentials. If the agent has its own identity, as it should, disabling that identity stops every tool call at once. This is one of the reasons to keep track of every AI agent you run.
- Switch off its write tools. A kill switch per tool lets you leave read-only lookups working while blocking refunds, emails or record updates.
- Drain or hold its queue. Pending tasks should wait, not be dropped, so you can replay or cancel them once you understand the fault.
- Check for delegated work. If the agent hands tasks to other agents, those may still be acting on its bad output. See who is accountable when agents delegate to agents.
Decide who is allowed to pull the switch
Write down in advance who can stop an agent without asking anyone: the on-call engineer, the product owner and the security team at minimum. Waiting for approval while an agent keeps sending messages is the most common way a small incident becomes a large one. The guardrails in how to stop an AI agent taking a wrong action reduce how often you need this, but they do not replace it.
Preserve the evidence while it still exists
Agent behaviour depends on more than the code. To explain what happened you need the full picture at the moment it happened, and some of it disappears quickly.
What to freeze straight away
- The prompts and system instructions the agent was running, with their version identifiers.
- The model name and version, and whether the provider changed anything recently.
- Every tool call, its inputs and outputs, and the identity it ran under.
- The documents or data the agent retrieved, since an injected instruction usually arrives this way.
- The user requests or upstream events that started each affected task.
If your agent already keeps an audit trail, this step is a matter of exporting and protecting it. The contents of an AI agent audit trail cover what should be there before you need it. If it does not, the incident will show you exactly what is missing.
Do not destroy the evidence while containing it
Some containment steps erase what you need. Redeploying the agent can replace the prompt version you are trying to examine. Clearing a queue loses the tasks that show the pattern. Rotating logs on a normal schedule can remove the first bad action. Snapshot first, then change things.
Work out the blast radius
Once the agent is stopped and the evidence is safe, find out what it touched. Start from its tool call log, not from complaints, because affected customers or systems may not have noticed yet.
Questions that size the incident
- Which records did it create, change or delete, and can each change be reversed?
- Which messages went to customers, partners or staff, and what did they say?
- Did any personal or restricted data leave the place it should have stayed?
- Did any other system or agent act on its output?
Auditing what an AI agent did walks through tracing actions back to their cause. The answer to the personal data question decides whether legal and data protection teams need to be involved, and how quickly.
Tell the right people early
Agent incidents tend to surface as a business problem, not a technical alert: a customer complaint, an unusual refund, a confused colleague. That means the people who need to know are often outside engineering.
Name one incident owner who coordinates and speaks for the response. Tell the business owner of the workflow, customer support, security, and legal or data protection where personal data may be involved. Give support teams a short, accurate statement they can use, even if the cause is still unknown. Saying an automated assistant made an error and has been paused is better than silence while people guess.
Decide when the agent can go back to work
Restoring the agent is a decision, not a default. Agree the conditions before you need them:
- The cause is understood. You can point to the prompt, data, tool, model change or missing check that produced the behaviour.
- The fix is tested. A test case that reproduces the incident now passes, and it joins your regression suite. What AI agent evals catch explains how to keep it there.
- The damage is dealt with. Changes are reversed or corrected, and affected people have been told.
- Monitoring would catch a repeat. The signal that should have raised the alarm is now in place. See how to monitor an AI agent in production.
Bring it back in stages where you can, starting with read-only tools or a small share of traffic. If you can version an AI agent for rollback, returning to the last known good version is often the quickest safe option while the full fix is prepared.
Learn from it without blaming the model
A review afterwards should ask why the system allowed the agent to cause harm, not only why the model made a mistake. Models will make mistakes. The useful findings are usually about missing permissions limits, missing output checks, missing approval steps or missing alerts. Each finding should end as a change to the agent, its tools or its runbook.
If you want help writing an AI agent section for your incident response plan, or testing it against your own agents, talk to CodeDTX.
Frequently asked questions
Is an AI agent incident a security incident?
Sometimes. If the agent was manipulated, for example by an injected instruction in a document, or if restricted data was exposed, treat it as a security incident and involve the security team. Many agent incidents are quality failures instead, such as wrong records or wrong messages. Use the same incident process for both, but let the cause decide which teams lead the investigation and whether regulators or customers must be told.
Who should be able to stop an AI agent in an emergency?
At least the on-call engineer, the business owner of the workflow and the security team should be able to stop an agent without asking for approval first. The switch should be simple and tested, for example disabling the agent's own identity or turning off its write tools. If only one person can do it, an incident outside their working hours will run for longer than it should.
What evidence do we need to investigate an agent incident?
You need the prompts and instructions in use, the model and its version, every tool call with its inputs, outputs and identity, the data the agent retrieved, and the requests that started each task. Export and protect these before redeploying or clearing queues, because both can erase them. If your agent does not record all of this today, adding it is worth doing before the first incident.
When is it safe to switch the agent back on?
Switch it back on once you understand the cause, a test that reproduces the incident passes, the damage has been corrected and monitoring would catch a repeat. Restore it in stages where possible, for example read-only first or a small share of traffic. Rolling back to the last known good version can be a safe interim step while the full fix is built and tested.
