Code execution through Semantic Kernel tool parameters

Signal

In May 2026, Microsoft disclosed two critical issues in Semantic Kernel (including CVE-2026-26030) where a single prompt injection could cross the line from "unsafe text" to host-level code execution. The vulnerable path passes model-generated parameters to code that can execute on the host. Validate those parameters at the tool boundary.

How tool parameters reach execution

A prompt injection can affect more than the assistant's answer when the application lets it call privileged tools. In agentic systems, prompt injection is increasingly an execution primitive.

The difference is simple:

A chatbot produces text.
An agent produces actions by selecting tools and filling parameters.

Once you connect an LLM to tools, every place untrusted text can enter becomes an attempt to control the next tool call.

How prompt injection becomes host execution

[IN]

Untrusted text
web, email, docs

[LLM]

Tool selection
plus arguments

[TOOL]

Framework maps
args to code

[HOST]

Command, file, network
executes

This is why agent frameworks are a systemic risk layer. They sit between natural language and privileged execution.

What happened in Semantic Kernel (representative, not unique)

Microsoft's write-up describes a path where the Search Plugin backed by an in-memory vector store used a dynamically generated Python lambda, executed via eval().

That matters because it is a classic security boundary violation hiding in a modern wrapper:

The agent is asked to search
The LLM produces a string parameter
The framework interpolates that string into executable code

If an attacker can influence the input string, they can shape the code.

failure treating tool parameters as safe data

In the vulnerable configuration, an LLM-controlled value flows into a string interpolation sink. At that moment it stops being "data" and becomes "code".

The prompt is not "tricking the model". The model is doing its job. The failure is the trust model in the framework.

lesson your weakest boundary is the first tool hop

Teams keep investing in output filters, refusal policies, and system prompts. None of those are security controls if the first tool call can carry attacker-controlled parameters into an interpreter.

In agentic systems, the "shell" is not /bin/sh. It is whatever code path turns LLM output into execution.

CISO translation

If an AI agent can call tools, then the security question is no longer "can it be jailbroken". The question is: what execution paths exist downstream of untrusted text, and what stops them when intent and input are compromised.

The bigger takeaway: the framework layer is now your universal vulnerability multiplier

Agent frameworks are becoming infrastructure. When an issue appears in that layer, it scales across:

internal copilots
workflow agents
coding assistants
customer-facing autonomous features

That is why this class of issue will keep repeating. It is not because developers are careless. It is because we are rebuilding the same control plane mistake:

We are letting a generative system write the parameters to privileged code.

What controls actually hold

Below is a control model that assumes prompt injection is normal, not exceptional.

Control	What it blocks	Implementation note
Schema-hardening at the tool boundary	Argument smuggling, type confusion, interpolation into interpreters	Prefer allowlists and typed validation. Treat every tool arg as hostile input, even if it came from your model.
No "eval paths" in toolchains	Prompt to interpreter execution	Eliminate dynamic evaluation, templates that become code, and "smart" expression languages in agent plugins.
Capability scoping per tool	Privilege escalation through generic tools	Split tools by privilege tiers: read-only, write, network, exec. Most agents should never have exec.
Egress governance	Data exfiltration after partial compromise	Even if a prompt injection succeeds, outbound destinations and payload classes can still be constrained.
Audit-ready action traces	Undetected low-noise compromise	Log tool calls with input provenance: which sources influenced context, which messages were used, and the final args.

Mapping to OWASP agentic top 10 (2026)

This incident class is not one OWASP item. It is a cascade across multiple categories:

ASI02, tool misuse and exploitation (the model controls a tool interface)
ASI05, unexpected code execution (tool argument becomes code)
ASI03, identity and privilege abuse (agents often run with standing permissions)
ASI06, memory and context poisoning (the injection vector is frequently an external data source)

If your program treats these as separate problems, you will keep missing the combined chain.

A practical checklist for this week

01, Inventory agent toolchains

List every agent and the tools it can call. Highlight anything that can execute code, run shell commands, evaluate expressions, write files, or reach internal networks.

02, Find interpolation sinks

Search for eval, templating, expression engines, and string formatting in plugins and tool handlers. Assume any LLM-controlled value can reach those sinks.

03, Enforce argument allowlists

For each tool, define allowed values and shapes. Reject anything outside policy. If you cannot describe an allowlist, the tool is too generic for agent autonomy.

04, Remove default exec capability

Agents should not have a general shell by default. Split privileged operations into explicit, narrow tools with extra approval and strict validation.

05, Add provenance to logs

When an agent calls a tool, log which external sources were present in context. Without provenance, you cannot tell "user asked" from "injection asked".

06, Patch and set a policy gate

Update agent framework dependencies quickly, then put a gate in CI to prevent vulnerable versions from re-entering production through transitive deps.

The Semantic Kernel CVEs are a useful forcing function. They make a hidden truth visible:

In agentic systems, the prompt is increasingly the first stage of a kill chain.

If your framework turns model output into privileged execution, you must treat that translation layer as security-critical code.

References

Microsoft Security Blog (May 2026): When prompts become shells: RCE vulnerabilities in AI agent frameworks
OWASP Top 10 for Agentic Applications (2026): Overview and Complete guide

Rogue Security helps security teams enforce tool-level policies and contain agent blast radius at runtime. If you are deploying autonomous agents in production, you can reach us at rogue.security.