Est.
FeaturesLong read

Containing a Compromised AI Agent Without Killing the Workflow

AI agents need runtime containment strategies that traditional security tools cannot provide.

· 9 min read · Updated
Cover illustration for “Containing a Compromised AI Agent Without Killing the Workflow”
Features · September 16, 2026 · 9 min read · 2,066 words

A compromised AI agent cannot be handled the way a security team handles a compromised application, because the agent's attack surface is recursive and action-oriented rather than bounded by one input and one output. Shutting it down stops the bleeding, but it also stops the business. Containment has to isolate the threat at the exact point it occurs, while everything else keeps running. That's the problem this piece works through: what makes agents different, how they got this exposed, and what a layered response actually looks like once an incident is live.

Containing AI Agents vs. Conventional Software

A compromised web application typically gives an attacker control over what gets shown on a screen. A compromised agent gives an attacker control over what gets done: a database write, an email sent, an API call made with real credentials, another agent invoked to carry the action one step further. That's a different category of failure, because it moves money, data, and permissions instead of just displaying something wrong.

Every action an agent takes produces new context, and that new context feeds the next reasoning step, which picks the next tool to call. A single poisoned instruction, planted early, can ride that loop through an entire workflow before anyone notices the output looks off. OWASP's Top 10 for Agentic Applications 2026, alongside the Agent Control Standard unveiled September 1, 2026, names this recursion directly: production agents need to be inspectable, traceable, and governed by runtime policy enforcement, not treated as black boxes that occasionally misbehave.

Speed makes this worse. Researchers looked at exposed AWS credentials found on AI infrastructure in May 2026, and found those credentials in active use against live APIs in under 90 seconds, faster than the audit logs even surfaced the first event to a defender. Separate research on agent activity found data movement running roughly 16 times higher than typical human levels. Every minute an agent runs uncontained, it's moving data at roughly 16 times human volume, a pace that makes manual intervention nearly meaningless after the fact. Manual response, built around a human noticing something and then acting, cannot keep pace with that. Containment has to be built into the system beforehand, because there's no reacting fast enough once the loop is running.

How MCP's design created today's containment gap

The Model Context Protocol gave agents a standard way to call tools, read files, and talk to other agents. That standardization is why MCP spread so fast across enterprise deployments. It also means the protocol was built for capability, not for stopping an agent that's gone wrong mid-task.

MCP runs on a client-server pattern: a client requests data or asks for a tool to run, and the MCP server executes the action and sends back a result. That pattern creates attack paths that most traditional security tooling simply can't see, a gap the NSA documented in a Cybersecurity Information Sheet in May 2026. The Cloud Security Alliance confirmed, also as of May 2026, at least seven high- or critical-severity CVEs spread across major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf.

Authorization on MCP servers has largely been an afterthought. Among the servers that bother to enforce authentication at all, most rely on static API keys: single credentials that never expire and carry no limit on what operation they can authorize. Only a small share use OAuth with short-lived tokens. That's the baseline most enterprises are running today.

The July 28, 2026 spec revision made real progress on this front. It brought in OAuth 2.1, Resource Indicators under RFC 8707, mandatory issuer verification, and a rule requiring servers to reject tokens that weren't issued for them specifically. Those are meaningful fixes. But the same revision removed protocol sessions and dropped the initialization handshake, which exposed hidden session dependencies and confused-deputy risks that a lot of existing deployments were never built to absorb.

The confused-deputy problem sits underneath all of this and the July 28 revision leaves it standing. MCP servers act using their own elevated privileges, not the privileges of the person who made the request. A user without database admin rights asks an agent to run a query. The server has admin rights. It runs the query anyway. Nothing in the spec stops that today.

The three identity anti-patterns that make a bad situation uncontainable

The protocol gaps matter, but most enterprises have made the problem worse on top of them, through how they've provisioned agent identity in the first place. Three patterns show up constantly in incident reports, and each one removes a tool a security team will need during an actual incident.

The first is the shared service account: one credential covering every agent in the environment. When every agent authenticates the same way, no single action can be traced back to the agent that took it. Revoking that credential during an incident doesn't isolate the threat, it kills every agent at once, which is the opposite of surgical containment.

The second is inherited operator entitlements. An agent's permission set grows every time someone with broader access runs it, and that permission set only ever expands, never shrinks. The agent ends up holding the union of every user who ever touched it. If that agent is compromised, the blast radius equals the largest entitlement any single operator ever held, whether or not that operator still works there.

The third is secrets pasted directly into the system prompt. Those credentials leak through traces, through evaluation sets, through error messages, through prompt-echo behavior that repeats text back to a user who shouldn't see it. An API key can be rotated the moment it's exposed. A system prompt that's already leaked can't be patched silently mid-session, since the damage is in what the prompt revealed, not just in the credential itself.

These aren't rare mistakes. Roughly a third of non-human identity security incidents trace back to over-privileged identities, and roughly half of enterprise non-human identity credentials are long-lived API keys instead of short-lived, scoped tokens. That's the baseline across the industry, not an edge case.

Multi-agent systems compound this risk further. When Agent A invokes Agent B, most architectures in production today let permissions expand across that handoff instead of narrowing them. Trust escalates transitively unless someone has explicitly built a constraint to stop it, and Agent B can end up running with capabilities its own provisioning never granted it. Each of these three anti-patterns, on its own, removes an option a response team needs mid-incident: attribution, scoped revocation, or a clean boundary between what one agent can do and what another can.

What a real compromise looks like at tool-call depth

Documented incidents follow a pattern, and that pattern is what any containment architecture has to be built to interrupt.

Cisco's own environment produced a clear example of lateral movement across agents rather than within a single process. An attacker compromised a low-privilege data query agent first, by poisoning the external data source it pulled from. From there, the attacker used that agent's cross-agent communication interface to send disguised requests to a much higher-privilege financial approval agent. A shared service account or inherited entitlement structure makes exactly that kind of jump far easier.

A different pattern appeared in what researchers at Tenet Security called "agentjacking," disclosed in June 2026. A crash report gets filed with a plausible-looking Resolution field, but that field contains a shell command instead of a description. The agent reads the crash report alongside legitimate reports and runs the command, no human review involved. Tenet Security tested this across more than 2,000 organizations with injectable DSNs and found an 85% agent execution rate. Sentry declined to fix the underlying class of vulnerability, and the July 28 spec revision doesn't close it either. That's a scale problem: a vulnerability class with an 85% agent execution rate across more than 2,000 organizations, left open on both the vendor side and the protocol side.

A third pattern is slower and arguably more corrosive: the rug pull. The postmark-mcp package on npm quietly BCC'd a copy of every email sent through it, from any agent using it, to an attacker-controlled address. It built trust over 15 published versions before that behavior ever activated, in September 2025. No amount of per-session credential review would have caught it, because the server was legitimately authorized the entire time. The compromise wasn't in the credentials. It was in the server's own code, delivered as a routine update.

Even Anthropic's own official Git MCP Server wasn't immune. In January 2026, a chain of three vulnerabilities, path traversal, argument injection, and repository scoping bypass, combined with prompt injection and the Filesystem MCP server to produce remote code execution. CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145 were all patched.

Telling an agent "do not exfiltrate data" or "do not approve more than $1,000" fails under prompt injection, because the constraint and the override travel through the same channel. Runtime enforcement at tool-call depth, not a sentence in the system prompt, is the only thing standing between a crafted input and the action it tries to trigger.

Diagram: How a Low-Privilege Agent Reaches a High-Privilege Target. Visualizes: Illustrate the lateral movement chain documented in Cisco's environment: an attacker poisons an external data source feeding a low-privilege data query agent, that…

The containment architecture: isolating the threat without stopping the workflow

Containing a compromised agent without shutting down the surrounding workflow calls for several distinct responses working together, each at its own depth, so that a failure in one place doesn't cascade into the next.

The foundation is credential architecture. Each agent needs its own scoped, short-lived credential, never a shared service account. When a credential belongs to exactly one agent, revoking it is surgical: that agent stops, nothing else does. Issuing credentials just-in-time, rather than provisioning them in advance and letting them sit, means a credential never exists long enough to be stolen and reused later, and revocation has an immediate, bounded effect rather than a delayed one.

None of that works without the protocol enforcing it on the other end. The rule that servers reject tokens not issued specifically for them has been normative since the June 18, 2025 spec revision and was carried forward in the July 28, 2026 update. A token issued for Server A simply cannot be replayed against Server B. That single rule is what makes scoped, per-agent credentials meaningful instead of theoretical.

The second concerns delegation between agents. When Agent A invokes Agent B, Agent B's permissions need to be equal to or narrower than Agent A's, never wider. Enforce that single constraint at every handoff, and it closes the escalation path that let Cisco's financial approval agent get reached through a far less privileged data query agent in the first place. The AIUC-1 framework's refresh, effective April 15, 2026, backs this with dedicated, mandatory controls for MCP and A2A protocol authentication, transport security, message integrity, and runtime containment, elevating requirements that used to apply only to APIs to cover the full surface of modern agentic interfaces, including inter-agent communication.

The third requires approval queues for any mutating call. Reads keep flowing during an investigation. Writes, sends, and executions get held for a human to review before they run. That split matters because it lets the agent keep delivering value, answering questions, pulling data, while the one category of action that can actually cause damage waits for a person to sign off.

None of this works without visibility into the chain of actions as it happens. Full OpenTelemetry tracing across every tool call, including calls between agents, makes the recursive action chain visible instead of inferred after the fact. In the Cisco case specifically, that kind of tracing would have surfaced the compromise at the exact moment the low-privilege agent reached across the communication interface to the financial approval agent, before the disguised request went through.

The final piece addresses the supply chain itself: the postmark-mcp rug-pull vulnerability. The AIUC-1 Q2 2026 update made third-party access monitoring a mandatory control, and it extended tool call validation to cover MCP servers the same way it already covered approved internal functions. A server that behaved correctly for 15 versions and then didn't needs ongoing validation beyond a one-time credential check at setup, which is a direct response to the rug pull pattern.

Taken together, these layers don't promise an agent will never be compromised. They promise that when one is, the response can isolate that single agent, that single credential, that single delegation chain, while every other agent in the environment keeps running the job it was built to do.

Sources

  1. MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure
  2. Model Context Protocol (MCP): Security Design ...
  3. AI Agent Security: Threats, Attack Paths, and Defense in 2026
  4. AIUC-1 Q2 Refresh: MCP Security and Agent Identity Controls
  5. labs.cloudsecurityalliance.org
  6. genai.owasp.org
  7. AI Agents at Work 2026: Securing the agentic enterprise

More in Features