Your incident response plan probably wasn't built for something that moves at agent speed. Here's what actually needs to change.
TL;DR: Most incident response plans assume the thing going wrong is a person, and hardly any of them have been tested against an agent that can act faster than anyone can react. This piece gets into what actually needs to change once agents are part of the picture: someone named with the authority to pull the plug fast, a credential cutoff that's actually been tried before it's needed, and a real way to figure out how far things got. Bottom line, a plan nobody's rehearsed against this exact scenario isn't much of a plan when the moment actually shows up.
Most businesses have a plan for what happens when a person makes a bad call at work. Someone sends the wrong file to the wrong client, and there's a process for that. A laptop gets stolen, and IT knows which steps come next. None of that preparation carries over cleanly to an AI agent, because the whole shape of the problem is different once the thing acting isn't a person anymore.
Think about a fire drill. Everyone knows the evacuation route, where to meet outside, and who does the headcount, and that only works because somebody walked the building, planned it, and actually ran the drill before smoke ever showed up. Now imagine the fire can also lock the doors behind it, and it moves before the alarm finishes its first ring. That's closer to what an AI agent incident actually looks like. By the time anyone notices something's wrong, the agent's already three steps past where a person would still be deciding what to do, and a plan nobody's rehearsed is just a document.
This isn't a hypothetical. 2026 has already produced a case where an AI agent ran a ransomware attack with no human directing it step by step, and a separate incident where a containment effort on a misbehaving agent didn't hold the way the team assumed it would. Both make the same point: an incident response plan built around human-speed mistakes doesn't automatically work on agent-speed ones.
We've spent this series building the pieces that are supposed to keep things from getting here in the first place: knowing what agents you're running, limiting what each one can touch, and checking what you're trusting before you deploy it. None of that removes the need for a plan covering the moment something still goes wrong anyway.
A real incident response plan for AI agents comes down to who can pull the plug, how fast the credentials actually cut off, and whether you can tell how far things got. We'll get into what each of those looks like in practice.
Ask most businesses what happens the moment an AI agent does something it shouldn't, and you'll get a shrug followed by "we'd shut it down." That answer sounds fine until you ask the follow-up questions. Shut down how? Who actually has the access to do that at two in the morning? How long would it take, realistically, not in theory?
Most incident response plans, if they exist at all, were written with a person in mind. A disgruntled employee, a phishing click, a stolen laptop. Those scenarios share one quality that makes them manageable: a human being is driving, and humans operate at a pace other humans can keep up with. Someone notices, someone calls someone else, and there's a window to react before the damage compounds much further.
An AI agent doesn't give you that window. It can execute hundreds of actions in the time it takes a person to read a Slack alert, and it doesn't pause to second-guess itself the way a nervous employee might. We touched on this when we covered what actually counts as an AI agent in your environment, and the same thing holds true here: the tools acting fastest in your business are often the ones with the least oversight built around them.
A plan built for human-speed mistakes isn't wrong, exactly. It's just solving a different problem than the ones AI agents are causing.
Here's a question worth asking at your next team meeting: if an AI agent started doing something it shouldn't right now, who in the building has the authority to shut it off without checking with anyone else first? If the honest answer is "we'd figure that out," that's the gap this section fixes.
Most businesses can tell you who handles a server outage or a phishing report without blinking. Ask who owns an agent going off the rails, and you'll get a lot more silence. That's not because nobody's capable. It's because this is more of an authority question than a technical one, and authority questions have a way of getting punted down the hall because nobody wants to be the one who pulled the plug on something that turned out fine.
That hesitation is the whole problem, right there. CISA's guidance on agentic AI says the call on when to shut an agent down needs to belong to a named person, decided ahead of time, not hashed out in a group chat while the thing's still running. Waiting for everyone to agree while an agent keeps doing its thing is how a small mistake turns into a Tuesday-afternoon headline.
So pick one person. Give them standing authority to kill any agent, no vote needed, and make sure the rest of the team actually knows who that is. It'll feel like overkill right up until the one day it isn't, and that's the day you'll be glad someone already had the keys.
Knowing who can pull the plug only matters if pulling it actually works. Plenty of businesses assume they could cut an agent's access in a pinch, right up until the moment they try and discover the credential's tangled up with three other things nobody remembered.
This goes back to how most agents get set up in the first place. We covered this in our piece on scoping agent access down to what the job actually needs: when an agent runs on a shared login instead of its own dedicated account, shutting it off means disabling something a person or another system might also depend on. Pull that credential in a hurry and you could knock out a legitimate tool right along with the misbehaving one, which is exactly the kind of collateral damage that makes people hesitate at the worst possible moment.
A credential cutoff you've never tested isn't really a credential cutoff. It's a guess with good intentions. Run the drill before you need it for real. Pick an agent, revoke its access the way you would in an actual incident, and time how long it takes and what else it touches on the way down.
Do that once a quarter, and you'll know two things cold: exactly how fast you can cut an agent off, and exactly what else needs a backup plan when you do. Both of those are a lot better to learn during a test run than in the middle of an actual mess.
Cutting an agent off stops the bleeding. It doesn't tell you what already happened, and that's the part most businesses haven't thought through at all. Once access is revoked, you're left asking the harder question: what did it actually touch before you caught it?
This is where logs either save you or leave you guessing. NIST's guidance on log management, laid out in Special Publication 800-92, exists for exactly this reason, and it applies just as much to an agent as it does to a person. If you can't see what an agent read, wrote, sent, or deleted, you're stuck reconstructing the story from memory and hoping nobody's memory is wrong.
That's also why the inventory work matters here in a way that isn't obvious until you need it. Knowing what an agent is authorized to touch gives you a boundary to check against. Without that boundary, you're not investigating an incident so much as searching a haystack with no idea what the needle looks like.
Before an agent goes live, confirm its activity actually gets logged somewhere you can search, and confirm someone on your team knows how to search it under pressure, not just in a calm demo. The blog this whole series grew out of, on the AI agent that ran a ransomware attack by itself, made this exact point: the businesses that recovered fastest were the ones who could answer "how far did it get" within hours, not days.
Every business that takes fire safety seriously runs its own evacuation drills, separate from whatever a fire inspector checks off on a clipboard. Nobody waits for an actual fire to find out if the plan works. Most businesses haven't gotten around to doing the same for their AI agent incident plan, and that's exactly what this last piece fixes.
A tabletop exercise doesn't need to be a production. Get the right people in a room for an hour, walk through a scenario where an agent starts doing something it shouldn't, and talk through it step by step. Who notices first? Who has the authority to cut it off? How fast does the credential cutoff actually happen, and who checks the logs to see how far things got? You already have answers to each of those from the sections above. A tabletop is just where you find out if those answers hold up when people are put on the spot.
This connects directly to two things we've covered elsewhere in this series. Good monitoring is what gets you to "something's wrong" fast enough for any of this to matter, and understanding agents as an insider threat reframes why this drill deserves the same seriousness as any other security exercise on your calendar.
Run it twice a year. It's an hour that costs you nothing compared to what the real version costs when nobody's rehearsed it.
This post has been about one uncomfortable truth: the incident response plans most businesses already have weren't built for something that moves at agent speed. Knowing who can pull the plug, having a credential cutoff you've actually tried, being able to tell how far things got, and running the drill before you need it, none of that is complicated. What it requires is doing the work before the moment arrives, not during it.
That's the part that trips people up. It's easy to nod along with all of this and still not get around to naming a person, testing a cutoff, or booking an hour for a tabletop exercise, because none of it feels urgent until the day it very suddenly is. By then, the business paying the price isn't the one that didn't understand the risk. It's the one that understood it and never got around to building the plan.
This is exactly where Heroic Technologies comes in. We build incident response planning into the Secure work we do for clients, specifically because so many businesses we talk to have a plan on paper that's never been pressure-tested against anything resembling an AI agent moving at full speed. Whether you're coming to us through the Clean Break program after another MSP left this undone, or you're building a security program for the first time, this is the kind of gap we close before it costs you something real.
If your incident response plan hasn't been tested against what an AI agent can actually do, now is the time to fix that. Reach out to Heroic's team and let's get it handled before you need it.
1. We're a small business. Do we really need all of this?
Yes, maybe even more so, since a small team usually means fewer people available to notice something's wrong and react fast. You don't need a large committee or a formal department to pull this off. One named person with clear authority and a credential cutoff that's actually been tested covers most of what matters, even at a small scale.
2. What if we don't have the staff to run a tabletop exercise?
It doesn't need to be elaborate. An hour with two or three key people walking through a single scenario out loud is enough to surface the gaps that matter, and that's a realistic ask for almost any team. The goal is finding the sticking points before a real incident does, not building a polished training program.
3. How does this fit with the rest of what we've covered in this series?
Incident response is the backstop for everything else: the inventory, the access scoping, and the vendor vetting. Those earlier steps reduce how often something goes wrong and how much damage it can do, while this piece covers what happens on the day something still gets through anyway.