RCE in AI agent frameworks happens when text an agent reads is carried into the layer that runs its tools, so the model’s output stops being an answer and becomes a command on the machine. Microsoft’s Defender research team published this path in May 2026 against Semantic Kernel, where a crafted prompt walked through the framework’s own tool invocation and launched a process on the Windows host running the agent. Two CVEs came out of it, CVE-2026-25592 and CVE-2026-26030, both fixed. The reason it still matters after the patch is the shape of the bug rather than the bug itself. Any framework that lets model output select and parameterize code has the same seam, and most teams wiring agents into business workflows have never drawn a boundary there.
The Five Things That Change Once an Agent Can Run Tools
We work through these five points with every client that asks us to put an agent in front of a real system.
- The severity moved off the model and onto the host. Earlier prompt injection work ended with bad text or leaked data. This one ended with a process running under the agent’s service account.
- Validation at the parser is not validation at the boundary. The research bypassed abstract syntax tree checks by walking Python’s class hierarchy until it reached a module that could run system commands.
- The agent’s identity is the blast radius. Whatever that service account can touch is what an injected prompt can touch, which makes account scope the control that actually limits damage.
- Version drift is the whole exposure. Teams pin an SDK during a pilot and never revisit it, so the fix ships and the pilot stays vulnerable for months.
- This belongs to infrastructure, not to the AI team. Patching an agent framework is server patching, and it needs to sit in the same cycle as everything else you update.
Why Prompt Injection Stopped Being a Content Problem
Prompt injection became a code execution problem the moment agent frameworks were given the ability to call functions with model-chosen arguments. For two years the working mental model was that an injected instruction could make an assistant misbehave in language: reveal a system prompt, summarize a document it should have refused, produce output that embarrassed somebody. That model shaped the defenses. Teams wrote content filters, output classifiers, and refusal training, all of which sit at the text layer because the damage was believed to stop there.
Agents broke the assumption quietly. An agent is a model plus a set of callable tools plus a loop that lets the model pick which tool runs next. The picking is the problem. If the model chooses the tool and fills in the parameters, then anything that steers the model steers a function call, and a function call is code. Our team has watched this land badly in two kinds of deployment: internal automation agents that were given a file or shell tool for convenience, and customer-facing agents that read untrusted content as part of their normal work.
How the Semantic Kernel Path Actually Worked
The Semantic Kernel path worked by treating a restriction on syntax as a restriction on capability. The framework validated the expressions a plan could contain, using an abstract syntax tree check meant to keep the agent inside a safe subset. That check looked at the shape of what was being evaluated rather than at what the evaluation could eventually reach.
Reading it the other way, the design was defensible at the time. A syntax allowlist is a real control, it is cheap, and it stops the obvious attempts. Plenty of production systems run on exactly that pattern and have never been broken. The argument against it is not that it does nothing, it is that it holds only while the language underneath has no route from an allowed expression to a disallowed one.
Python has such a route. Starting from an ordinary object, an attacker can walk up to its class, out to the class hierarchy, and along to a subclass that imports or exposes the operating system module. Nothing in that chain looks like an import statement, so an AST check tuned to catch imports sees nothing worth blocking. From there the research reached a point where it could run a system command, and the demonstration launched calc.exe on the host. A calculator is a harmless payload chosen to prove a point. The same position runs anything else.
Why Your Own Agent Probably Has the Same Seam
Your agent probably has the same seam because the seam is architectural rather than vendor-specific. Three conditions produce it: the model selects a tool, the model supplies the arguments, and the tool runs in a process that can reach something valuable. Almost every useful agent meets all three, which is why we treat this as a design review rather than a patch notification.
The counterargument is worth holding. A great many agents are wired to narrow tools with typed parameters, such as a lookup against a read-only table or a call to a ticketing API with a fixed schema. Those are meaningfully safer, and the honest position is that they are not the same risk class at all. A tool that can only return a customer record cannot be turned into a shell no matter how clever the prompt.
Where we see trouble is the middle ground nobody classifies. A tool that renders a template, evaluates an expression, builds a query string, or writes a file to a path the model chose is doing more than it looks like. The parameter is not data at that point, it is partially a program. We ask clients to inventory their tools and sort each one into data-returning or program-accepting, and the second pile is always larger than expected. Our work on AI-enhanced security usually starts with that inventory rather than with the model.
What the Two CVEs Tell You to Check This Week
The two CVEs tell you to check versions first, because that is the part with a definite answer. CVE-2026-25592 affects Semantic Kernel .NET SDK builds older than 1.71.0, and CVE-2026-26030 covers the related execution path. Both have fixes. An agent running a pinned older SDK from a pilot is exposed regardless of how careful the surrounding prompt engineering was.
Checking versions is unglamorous and it is also the highest-yield hour anyone will spend on this. We ask for three lists: every service running an agent framework, the exact framework version each one has loaded, and the account each one runs as. Teams routinely cannot produce the second list, and the reason is that agent work started as an experiment outside the normal software inventory.
There is a fair objection that version chasing is treadmill work and does not address the class of bug. That is true, and it is still the right first move. The class-level fix takes weeks of design, and the version fix takes an afternoon while removing a known, published, working exploit path from your estate. Do the afternoon, then do the weeks. Our managed security services team keeps framework versions in the same patch cycle as operating systems for exactly this reason.
How to Put a Real Boundary Between the Model and the Host
The boundary that holds is process isolation, because it does not depend on predicting what the model will say. Every control at the text layer is a guess about attacker phrasing, and the Semantic Kernel research is a clean demonstration of why guessing loses: the bypass used no malicious-looking words at all, just ordinary attribute access. A boundary made of memory and permissions does not care about phrasing.
This is the argument we make when a client asks whether better filtering would have stopped it. Filtering would have raised the effort. It would not have changed the outcome, because the attack lived below the level filtering inspects. The same reasoning appears in our write-up on defending against prompt injection in AI systems, where the recommendation is the same: assume the text layer fails and decide what happens next.
Run the Tool Layer Somewhere You Are Willing to Lose
Run tool execution in a container you would be comfortable throwing away. The practical setup we deploy has the agent orchestration in one process and the tool execution in another, with the second one holding no durable credentials, no mounted file shares, and no network route to anything but the specific APIs it needs. If a prompt reaches execution, it reaches a box with nothing in it.
The cost is real and worth naming. Two processes mean more moving parts, more latency on every tool call, and a harder debugging story when something misbehaves. Small teams push back on this, and for a low-value internal agent with a read-only tool they are often right to. The calculation changes as soon as the agent touches production data or runs under an account with any standing access.
Give the Agent Its Own Identity and Keep It Small
Give the agent a dedicated service account rather than running it as a person or as a shared automation identity. We see agents inherit an existing integration account constantly, usually because that account already had the permissions the pilot needed. That is the single decision that turns a contained incident into a broad one, since the injected command arrives holding whatever that account accumulated over years.
Scope it to the specific resources the agent’s tools name, review it on the same cadence as any other privileged account, and log its actions separately so an anomaly is visible against its own baseline rather than lost in a shared account’s noise. We covered the account side in more depth in AI agent identity security, and the short version is that identity is the control with the best ratio of effort to protection.
Treat Retrieved Content as Hostile by Default
Treat every document, email, web page, and ticket the agent reads as attacker-controlled, because in most workflows some of it genuinely is. The indirect case is the one that catches teams out: nobody typed the malicious instruction into a chat box, it was sitting in a PDF a vendor sent, and the agent read it while doing its job. We walked through that mechanism in what indirect prompt injection is and in whether AI agents are vulnerable to prompt injection.
Practically, that means marking retrieved content as data in the prompt structure, refusing tool calls whose parameters trace back to retrieved text without a human step, and monitoring the tool call stream rather than only the conversation. Tool calls are structured and low-volume, which makes them far easier to alert on than free text. Pointing your network security monitoring at agent tool invocations costs little and catches the case where everything upstream failed.
Frequently Asked Questions
Does patching Semantic Kernel fix this completely?
Patching removes the specific published path, and it does not remove the class of risk. Upgrade past 1.71.0 for the .NET SDK, then treat the tool execution layer as a security boundary in its own right. A future framework bug in any vendor’s stack lands the same way if the agent still runs with broad host access.
Is this only a Microsoft problem?
No. The vulnerable pattern is model-selected tool invocation, which every major agent framework implements in some form. Microsoft’s research team found and published it in their own product, which is the responsible outcome, not evidence that their framework is uniquely weak.
Can input filtering stop RCE in AI agent frameworks?
Filtering raises the cost of an attack and does not close the path. The published bypass used ordinary attribute access rather than anything a filter would flag, so the defense that holds is process isolation plus a tightly scoped service account. Use filtering as a layer, never as the boundary.
What should a small IT team do first?
Inventory every service running an agent framework, record its exact version, and record the account it runs as. That list takes an afternoon and tells you whether you have a live exposure. Version upgrades come next, then the isolation work.
How do we know if an agent was already abused this way?
Look at the tool call logs rather than the chat transcripts, since the abuse appears as an unusual tool invocation with unusual parameters. If your framework does not log tool calls separately, turn that on first, because without it there is no record to review.
Who Is Behind This Advice
Our team has spent the last two years putting agents into production at firms between 10 and 500 employees, which means we have seen the gap between a demo that works and a deployment that survives contact with real data. The pattern in this article comes from that work: the security questions that matter are almost never about the model, they are about what the model is allowed to call and what that call runs as.
Matt Rosenthal, who leads Mindcore, has pushed our practice toward treating AI deployments as infrastructure rather than as experiments, with the same patching, identity, and monitoring discipline we apply to servers. That framing is why our agent reviews start with service accounts and process boundaries instead of with prompts.
Decide What Your Agent Is Allowed to Run
RCE in AI agent frameworks is an infrastructure question wearing an AI costume, and the organizations that handle it well are the ones that stopped treating agent deployments as a separate category. The Semantic Kernel research gave everyone a free lesson: a prompt reached the tool layer, the tool layer reached the host, and no amount of careful wording at the top of that chain would have mattered. The fix list is short and it is ordinary. Know which frameworks you run and at which versions, patch them on your normal cycle, give every agent its own narrow identity, run tool execution in a process you would be willing to lose, and log tool calls where somebody will see them. None of that requires new tooling, and all of it survives the next published bug in a way that prompt-level defenses do not. If you are putting agents in front of systems that matter and want a second set of eyes on where the boundaries sit, book a free strategy call and we will walk your deployment with you.
