This is the playbook for the moment an AI agent is visibly misbehaving right now, looping on the same action, taking steps outside what looks reasonable, or producing bad output at a volume that's causing real damage while you're still figuring out why. It's deliberately narrower than a full incident response process, because the priority in this exact moment isn't understanding root cause, it's stopping the behavior before it does more damage. Root-causing what went wrong, tracing its full impact, and deciding how to fix the underlying gap all matter, but they come after containment, not before it. Trying to fully understand the problem before acting on it is how a fast-moving incident turns into a slow-moving one.
Recognize the signal that warrants containment
Don't wait for full certainty that something is actually wrong before acting. A looping action, an agent repeating a tool call well past what any normal task would need, output at a volume or rate that doesn't match its usual pattern, or an action landing outside its apparent intended scope, are all signals worth acting on immediately rather than watching for a few more minutes to confirm. The cost of containing an agent that turns out to have been fine is small, a pause, maybe a delayed task. The cost of continuing to watch a genuinely misbehaving agent while it keeps acting is not. Treat an ambiguous signal as sufficient rather than waiting for an unambiguous one.
Use the fastest available stop mechanism
Once you've decided to act, use whichever containment mechanism actually stops the agent fastest for this specific case, not necessarily the most thorough one. That might be a dedicated kill switch, suspending the credentials the agent is currently using, or revoking the specific tool permission behind the behavior you're seeing, whichever of those is fastest to execute for this particular agent and this particular deployment. Don't spend time deciding on the theoretically cleanest containment approach while the agent keeps running. A slightly blunt stop applied in seconds beats a precise one applied five minutes later.
Contain without wiping what you'll need later
Stopping the agent doesn't mean erasing it. Preserve the session state, the conversation history, and the logs of what it was doing right up until containment took effect, since that's exactly what the deeper investigation will need to work out why this happened. A kill switch or credential suspension should stop the agent from taking further action without deleting its recent state or resetting its logs. If your fastest containment option happens to also wipe session data as a side effect, that's worth flagging as a gap in the tooling itself, because containment and evidence preservation shouldn't be in tension with each other.
Verify the containment actually worked
Don't assume the stop mechanism worked just because you triggered it. Check that the looping action has actually stopped, that no further output is being produced, and that the tool or capability you revoked is genuinely no longer reachable, rather than just marked as revoked somewhere in a configuration. Agents with cached credentials, retry logic, or multiple paths to the same tool can sometimes keep acting for a short window after containment looks like it should have taken effect. A quick, direct check, watching the next few seconds of logs or trying the blocked action yourself, is worth the extra minute before you consider the situation stable.
Set resumption criteria before turning it back on
Before the agent goes back into service, decide explicitly what needs to be true for that to be safe, rather than resuming it as soon as things look calm. That usually means, at minimum, a working theory of what caused the behavior, confirmation the specific trigger won't immediately recur, and someone with the authority to make that call actually signing off. Resuming an agent because the immediate symptom stopped, without any of that, tends to produce a second incident shortly after the first, often the exact same one.
Hand off to deeper investigation
Containment's job is done once the behavior has stopped and the situation is stable. Root-causing exactly why it happened, tracing what the agent actually touched while misbehaving, and fixing the underlying gap are a separate piece of work that starts right after this. Hand off what you preserved, logs, session state, the sequence of events you observed, to whoever runs that investigation, with enough detail that they don't have to reconstruct the timeline from scratch. Containment and investigation are different jobs with different urgency, and treating them as one continuous task is how the person doing containment ends up rushing it or the investigator ends up starting from an incomplete picture.
Where TELEON fits
TELEON's audit trail, kept through the gateway or supported middleware between the agent and its tools and model calls, gives the handoff in this playbook something concrete to work from: a record of exactly what the agent did up to the moment containment took effect. Its runtime policy enforcement at the tool-call boundary can also serve as one of the fastest containment mechanisms available, since revoking a specific tool permission there can stop a misbehaving action without needing to tear down the whole agent.
Recognizing the signal that something's wrong, choosing which containment mechanism to use, and deciding when it's actually safe to resume are judgment calls the responding team makes in the moment. TELEON's enforcement point and logging give that team a fast lever to pull and a record to hand off, not the decision itself.
A short checklist
- Act on an ambiguous signal rather than waiting for certainty.
- Use whichever stop mechanism is fastest for this specific agent.
- Preserve session state and logs rather than wiping them during containment.
- Verify directly that the behavior has actually stopped.
- Set explicit resumption criteria before turning the agent back on.
- Hand off preserved evidence and a clear timeline to the deeper investigation.
Containing a misbehaving agent is a speed problem first and an understanding problem second, and mixing up that order is the most common way this kind of incident gets worse than it needed to. Act on the signal you already have, stop the behavior with whatever mechanism is fastest, confirm it actually worked, and preserve what the next stage of work will need. Root cause and full impact come later, in a process built for that, not in the first few minutes when the only goal is making the bleeding stop.