Containing a Compromised AI Agent Without Killing the Workflow

IDC projects enterprise AI agents will grow from 28.6 million active deployments in 2025 to more than 2.2 billion by 2030, a figure Microsoft's security team has highlighted in its security research. At that scale, an agent stops being a tool you can watch closely. It gets woven into invoice approvals, vendor emails, data enrichment, customer service tickets, the actual fabric of a business.

So when one gets compromised, the instinct is obvious: pull the plug, revoke the token, kill the process. That instinct is wrong more often than it's right. Killing the agent kills every legitimate task it had in flight too. SLA breaches, broken pipelines, a human team scrambling to pick up work an agent was doing thirty seconds earlier. The kill switch treats agent access as binary, on or off, when the actual discipline is graduated containment: isolate the threat at the tool-call and credential level while the rest of the workflow keeps running. That takes detection precise enough to separate a compromised tool call from a normal one, and a response narrow enough to act on the difference instead of torching the whole thing.

Speed of a compromised agent before detection

Speed is the whole problem, and the numbers say it's getting worse, not better. CrowdStrike's 2026 Global Threat Report clocked average attacker breakout time at 29 minutes. IBM's 2026 breach research found that 1 in 4 malicious breaches were AI-enabled, up 56% from the year before, and CrowdStrike recorded an 89% jump in attacks carried out by AI-enabled adversaries over the same period.

Agents don't just move fast. They move fast with permissions that look completely normal to whoever's watching. A single workflow might query a database, send an email, and hit three external APIs in a few seconds, all under credentials nobody would flag on sight. And there's a decent chance nobody's watching closely anyway: Gravitee's State of AI Agent Security report found that only 47.1% of deployed AI agents are actively monitored or secured. Worse, a joint study from the Cloud Security Alliance and Aembit found that 68% of organizations can't tell human activity apart from AI agent activity in their own logs.

Putting those three numbers next to each other makes the picture turn uncomfortable fast. Attackers move in under half an hour. Fewer than half of agents are even watched. And when something does go wrong, most companies can't tell it apart from business as usual. The window between "this agent is compromised" and "the damage is done" runs in minutes. There's no time to investigate fully before acting, but there's also no excuse for torching an entire workflow just to feel safe.

The attack patterns that compromise agents in production

They're the specific ways a running agent turns into a live threat inside a real environment, and each one leaves a different fingerprint. They're the specific ways a running agent turns into a live threat inside a real environment, and each one leaves a different fingerprint.

Tool poisoning moves through a sequence of stages, as detailed in a walkthrough Microsoft's security team published. The agent has no idea it's been turned. It just executes faithfully against instructions that attackers swap out underneath it, which is the deeper cause: a running agent has no way to detect that its instructions have been altered, so it carries out the swapped instructions as if they were legitimate. The tell is a tool description that changed without review, or behavior that no longer matches what's on file.

Prompt injection has held a persistent spot on the OWASP Top 10 for LLM Applications, and HackerOne's 9th Annual Hacker-Powered Security Report recorded a 540% surge in prompt-injection vulnerability reports. Black Hat 2026 demos showed zero-click chains where an email triggers an injection, the injection reaches into a connected Google Drive, and the malicious instruction persists across future sessions as stored memory. Watch for intent that drifts from what the user actually asked, especially when the drift traces back to content the agent was just told to read or summarize.

Supply chain attacks ride in through malicious tool descriptors. OX Security's research, titled "The Mother of All AI Supply Chains," found a command execution vulnerability inside Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust: the STDIO transport passed parameters straight to the host operating system's shell without sanitizing them. OX estimated roughly 200,000 vulnerable instances sitting inside a supply chain built on more than 150 million package downloads. Watch for an agent calling a tool outside its approved registry, or OS-level activity that has no business coming from an agent process.

Excessive agency jumped from sixth to third in the 2026 OWASP LLM Top 10, one of the more significant single-year moves the list has seen. The mechanism is plain: an agent with broad standing permissions can do more damage, faster, the moment it's compromised. The blast radius gets set the day someone provisions the agent, not the day it gets attacked. Watch for tool calls that are technically allowed but have nothing to do with the current task.

Four attack classes, four different signal profiles. No single detection rule catches all of them, and no single containment action addresses all of them either. Most playbooks miss this and try to build one lever for every threat.

The authentication and credential foundation for containment

One API token with broad scopes, copied into every agent that needs it, is the antipattern that appears across deployments. It turns into a de facto master key, and nobody can tell which agent used it or why. Fail to tell agents apart at the credential layer, and you can't revoke one agent's access without taking down every agent sharing that key.

The scale of the problem isn't small. A 2026 security audit found that 53% of public MCP servers still run on long-lived static API keys or personal access tokens, and 25% have no authentication. It gets worse when agents inherit a human's own credentials. The agent runs under the user's token, the audit log can't separate agent actions from human ones, and the scope granted is the user's entire scope, not the narrow slice the task needed.

The protocol itself is catching up. The MCP revision from July 28, 2026, described by its maintainers as a major update to the protocol, introduced OAuth and OIDC hardening to strengthen token security. The intent is to prevent tokens from being misused across servers, addressed at the protocol level rather than left to convention.

Adoption hasn't caught up with the protocol, though. Only 8.5% of MCP servers actually use OAuth. 38% of organizations say security concerns are actively blocking their MCP rollout, and half of MCP builders name access control as their single biggest headache.

The pattern that works: give the agent its own standing identity, issue a separate delegation token for each invocation that carries the user's authority just for that task, and bind the scope to what the user agreed to. Get that right, and "revoke this agent's access to this one tool" becomes a button you can actually click. Get it wrong, and containment only has one setting: off.

Reading the signals: what a compromised agent looks like before it finishes doing damage

Agents act autonomously across many steps by design, so "unexpected behavior" doesn't jump out without a baseline to measure against. Detection has to be built around specific signal types.

Intent drift occurs when the agent's tool calls stop matching the task it was given: touching a data store the task never called for, or shipping output somewhere outside the workflow plan.

Tool call anomalies include a call to a tool outside the agent's approved registry, a tool description that has changed since its last reviewed version (exactly the kind of early signal Microsoft's June 30, 2026 tool poisoning walkthrough describes), and calls that stay technically within permissions but spike in volume or scope, like querying an entire table instead of the three records the task needed.

Credential signals cover a token used against a resource it was never minted for, catchable only once token binding is enforced under the new MCP spec, plus a credential turning up somewhere it shouldn't (an execution trace, a memory dump, a downstream tool's output), or a credential reused across multiple agents or sessions past its intended scope.

Context integrity signals include agent reasoning that cites instructions absent from the original prompt or the approved tool descriptions, a strong hallmark of prompt injection, along with output landing somewhere outside the workflow definition.

None of this matters if the logs can't distinguish agent activity from human activity, and the Cloud Security Alliance and Aembit study already put that failure rate at 68%. A generic SIEM rule built for human behavior won't catch these signals. What's needed instead is per-action attribution tied to a specific agent's identity, full tracing of tool calls, and logs that can't be altered after the fact, capturing both the instruction the agent received and the action it actually took.

The graduated containment response: matching the intervention to the signal

The governing idea is simple to state and harder to build: contain the threat without taking down the workflow. Use the smallest intervention that actually neutralizes the specific risk in front of you, and nothing bigger than that.

Level 1, tool-call suspension, is the narrowest lever available. It's triggered by an anomalous call to a specific tool, a mismatched tool description, or a call reaching outside the workflow's approved scope. The action is to cut off the agent's access to that one tool or MCP server while every other call keeps running. This only works if permissions get enforced at the individual tool-call layer, not just once at session start.

Level 2, credential revocation, triggers when a credential appears somewhere it shouldn't or gets used past the scope it was minted for. The action is to kill that specific invocation token or JIT credential and force re-authentication before the next action runs. This only works with short-lived, per-invocation credentials. Running on a long-lived shared key takes this level off the table entirely, and the only option left is killing the whole session.

Level 3, scope step-down, triggers when an agent is still operating inside its permissions but pushing at the edges, pulling more data than the task calls for, or showing early signs of intent drift. The action is to tighten the scope on the fly: restrict data access to the specific records the task needs, allow reads but block writes, or force a human approval step before the next high-risk call. The MCP spec's July 2026 revision clarified scope accumulation behavior relevant to exactly this kind of step-down control.

Level 4, agent isolation, is reserved for confirmed serious compromise: a real exfiltration attempt, an active adversarial instruction set from a prompt injection, or a tool poisoning chain that's reached the execution phase. The action is to isolate that agent instance specifically, cut off all its outbound tool calls, preserve its state and logs for forensic review, and route its pending work to a clean instance or a human queue. Every other agent running the same workflow keeps going untouched.

Level 5, full termination, is the last resort: active exfiltration nothing lower can stop, or a supply chain compromise that's poisoned the agent's core tool registry itself. Even here, logs get preserved before anything shuts down, so the forensic trail survives the kill.

None of these five levels exist in a vacuum. Recent research found that only 30% of organizations have reached maturity level three or higher in strategy, governance, and agentic AI controls. For the other 70%, operating on a governance foundation not designed for this era, most of these levers simply aren't in place. Most companies today are stuck choosing between Level 1 and Level 5 with nothing in between.

Infrastructure requirements for a containment playbook

Planning a graduated response on top of a broken foundation doesn't work, full stop. If every agent shares one credential, has no identity of its own, and dumps into a log nobody can parse, Levels 1 through 3 aren't things a security team can actually do. They're theory.

Every agent needs its own non-human identity, distinct from whichever user it's acting for, provisioned and deprovisioned through the same SSO and SCIM controls that manage human accounts. This is the biggest structural gap right now: only a small fraction of organizations have a formal identity strategy for AI agents.

Credentials need to be short-lived and scoped per invocation: minted fresh for each task, limited to what that task needs, expiring the moment the task ends. OAuth 2.1 with PKCE, as the MCP spec calls for, with token scoping bound to the specific server and task at hand. This is what kills the shared-key problem that makes targeted revocation impossible.

The tool registry itself has to enforce approved versions. Every MCP server and tool an agent can reach needs a checksum or version hash of its last-approved description, checked in real time at the moment of every call. If the description has drifted since approval, the call gets blocked and someone gets alerted. This closes the exact detection gap that Phase 1 of the tool poisoning chain depends on.

Full tracing of every tool call matters too. Without a complete, tamper-proof record of what instruction an agent received and what action it took in response, none of the signal-reading described earlier is possible. The infrastructure has to capture that pairing every single time, not on a sample basis.

Build those four things first. Only then does a graduated containment playbook have something real to act on, instead of a kill switch dressed up as a strategy.