This playbook is for a different kind of incident than a single bad response: an AI agent itself appears compromised, showing sustained abnormal or attacker-influenced behavior across a session or multiple sessions rather than one bad output a person can dismiss and move on from. That might look like a memory store poisoned with content designed to steer future behavior, a plugin or tool dependency that's been tampered with, leaked credentials the agent holds, or an extended manipulation that gradually shifted its behavior over many turns. The response has to treat the agent itself, not just its most recent output, as the thing under investigation. Isolating it comes first, but rebuilding trust to put it back into production takes real, deliberate work afterward, not just a restart.
Isolate the agent immediately
Whatever the eventual root cause turns out to be, the first move is the same: cut the agent off from anything it could still act on. Use the kill switch, suspend the credentials it holds, and revoke its tool access rather than trying to gently wind it down. If the compromise involves manipulated memory or session state, don't let the agent keep running on that state while you investigate; a compromised agent that's still active can keep acting on attacker-influenced instructions while you're looking at logs. Isolation doesn't need to wait for certainty. A sustained pattern of abnormal behavior across multiple interactions is justification enough, and isolating an agent that turns out fine costs far less than leaving a genuinely compromised one running.
Assess the compromise vector
Once the agent is isolated, work out what actually happened to it. Was its memory or context poisoned by content it retrieved, is a tool or plugin it depends on compromised, did a credential leak, or did sustained manipulation across a long session gradually walk it past its intended constraints. Each points to a different fix, and conflating them leads to a fix aimed at the wrong layer. Look at what changed right before the abnormal behavior started, a new document in its retrieval scope, a dependency update, a new pattern in the conversation, since the vector is usually visible in what changed just before things went wrong.
Determine blast radius through the audit trail
With a working theory of the vector, use the audit trail to figure out exactly what the agent did while compromised, not what it might theoretically have been able to do. Pull every tool call, action, and other identity or system it interacted with during the window you believe it was compromised, treating that window generously rather than assuming the compromise started exactly when someone first noticed. This is where you learn whether it stayed contained to bad outputs nobody acted on, or touched real systems, other agents, or actual data. Everything downstream, credential rotation, notification, remediation, depends on getting this part right rather than estimated.
Rebuild trust deliberately, don't just resume
It's tempting to fix the obvious problem and put the same agent instance back to work, but its memory and session state shouldn't be trusted just because the vector has been patched. Treat stored memory and session state as suspect, and either discard it or review it directly rather than carrying it forward. Rotate every credential and key the agent held during the compromised window, even ones that don't look directly implicated, since you often can't be fully certain what an attacker-influenced agent did with access it had. A fresh instance with reviewed configuration is usually safer than trying to sanitize a compromised one.
Fix the root vector
Whatever assessment identified as the actual vector needs a direct fix, not just a workaround for this instance. A poisoned memory source needs its ingestion path reviewed and restricted. A compromised tool or dependency needs to be patched, replaced, or have its access narrowed. A leaked credential needs rotation everywhere it was used, not just where the compromise surfaced. Sustained multi-turn manipulation usually points to a gap in how the agent evaluates instructions gathered over a long session, which calls for tightening what parts of conversation history it treats as trusted instruction versus data.
Verify before returning to production
Before the agent, or its replacement, goes back into production, test directly against the specific vector identified, confirming the fix actually closes it rather than assuming a code change worked. If the vector was a poisoned content source, confirm it's now excluded. If it was an over-permissive tool grant, confirm the narrower grant still lets the agent do its legitimate job. Run this with the same scrutiny as testing a new agent for the first time, since reinstating a compromised agent without real verification is a common way for the same incident to happen again within weeks.
Communicate and report internally
Once containment, assessment, and the fix are in hand, make sure the people who need to know actually know: the agent's owner, whoever depends on its output, and security leadership if the blast radius touched real systems or data. Write up the vector, what the agent did during the compromised window, and what changed to prevent a repeat, specific enough that someone handling a similar incident later can use it. If the blast radius affected another party's data, loop in legal and communications on any notification that's warranted, based on what the audit trail showed rather than a preliminary guess.
Where TELEON fits
TELEON's audit trail, kept through the gateway or supported middleware between the agent and its tools and model calls, makes blast radius determination possible with real evidence, showing exactly which tool calls and interactions happened during the compromised window. Its runtime policy enforcement at the tool-call boundary is also where a narrowed permission grant gets implemented once the vector points to a tool or credential with more access than it should have had.
Working out the compromise vector and writing the internal report are direct work for the responding team; TELEON's logging and enforcement give that team evidence and a lever, not the analysis.
A short checklist
- Isolate the agent immediately: kill switch, suspended credentials, revoked tool access.
- Assess the compromise vector: poisoned memory, compromised tool, leaked credential, or sustained manipulation.
- Determine blast radius using the audit trail, covering a generously wide time window.
- Treat stored memory and session state as suspect rather than resuming the same instance.
- Rotate every credential and key the agent held during the compromised window.
- Fix the root vector directly, not just the symptom that surfaced.
- Verify the fix against the specific vector before returning to production.
- Communicate the vector, impact, and fix internally, and loop in legal if warranted.
A compromised agent is a different problem from a single bad output. Isolating first, understanding the vector, tracing what it actually did, and rebuilding trust deliberately rather than just resuming is what keeps one incident from becoming a repeat a few weeks later. The instinct to patch quickly and get the agent back online is understandable, but skipping verification and trust-rebuilding is exactly how the same compromise resurfaces against an agent everyone assumed was already fixed.