Microsoft built an AI agent that searched for hotels by city. In the vulnerable configuration it tested, a model-controlled city value could become executable Python on the host.

The research published on 7 May described two flaws in Microsoft's Semantic Kernel. Both had been fixed before the report appeared. They were configuration-dependent demonstrations, not evidence that every Semantic Kernel application, or every agent framework, had been compromised.

That boundary sharpens the finding. Prompt injection influenced a value. The surrounding framework and tool decided what that value could do.

The Filter Assembled Code from the City

Microsoft's hotel finder exposed a search_hotels function to the agent. A normal request for hotels in Paris led the model to call the tool with city="Paris".

The affected in-memory vector-store filter inserted that model-controlled value into a Python lambda expression and evaluated it. Microsoft demonstrated an input that closed the expected string, traversed Python's class hierarchy and reached a shell command while still passing the filter's structural checks.

Exploitation required two conditions: an attacker needed a prompt-injection route into the agent's input, and the application needed the affected Semantic Kernel Python package with the in-memory vector store's filter functionality enabled by default.

The project advisory identifies versions of the semantic-kernel Python package before 1.39.4 as affected. The fix replaced the loose checks with restrictions on permitted syntax, function calls, names and attributes. Users were directed to upgrade to 1.39.4 or later.

The engineering lesson is familiar because it predates AI: keep values as data. A string should select among supported operations or enter a parameterised query; it should not become part of code evaluated later. Checking that the model returned a string says nothing about whether the receiving function will treat its contents safely.

The agent layer adds a complication. The untrusted value may arrive through natural language, be converted into a well-formed tool argument and pass schema validation. Every step can appear to work. The unsafe decision remains if the implementation constructs executable code from that argument.

A Transfer Helper Crossed the Sandbox Boundary

Microsoft's second demonstration involved SessionsPythonPlugin, which ran agent-generated Python in an isolated Azure Container Apps session. A helper function moved files from that sandbox to the host.

In the affected .NET package, DownloadFileAsync was accidentally advertised to the model as a callable tool. The model controlled its localFilePath parameter, and it lacked the path checks needed to restrict where the host wrote the file.

Microsoft demonstrated a chain in which the agent created a script inside the sandbox and then used the helper to write it into the Windows Startup folder. The script ran the next time the user signed in. The container had not been broken. A trusted bridge carried the file across its boundary.

The .NET advisory identifies versions of the Microsoft.SemanticKernel.Plugins.Core package before 1.71.0 as affected and points users to that version or later. Microsoft removed model access to the function and added resolved-path validation and directory allow-listing for intentional developer calls.

“Runs in a sandbox” is therefore an incomplete security description. The review also needs every import, export, credential and host-side helper that crosses the isolation boundary. A model-selected filename is not a safe destination simply because the file began inside a container.

For either flaw, installing the fixed version closes the demonstrated route. It does not establish whether an earlier execution occurred; that evidence would have to come from host telemetry rather than patch status.

Finding the Vulnerability is the First Handover

The UK's National Cyber Security Centre published ten questions for organisations using AI to find vulnerabilities.

The guidance asked teams to define what they were trying to achieve, decide whether AI was the best use of effort, establish how findings would be received and prioritised, restrict production access and verify results with both people and AI.

One question that comes to mind is: what happens if an organisation spends all its time and resources finding vulnerabilities and leaves nothing to actually fix them? I see this logjam of waiting for updates as a looming issue.

Final Perspective

With the ever-increasing number of vulnerabilities being discovered, I think there's a growing need to focus on remediation capacity, which isn't necessarily the most glamorous issue, but it is the basis for a strong, resilient foundation.