When a prompt becomes a shell

For a while prompt injection mostly produced embarrassing screenshots. Agents changed that. Once a model can call tools, an injected instruction doesn’t make it say something, it makes it do something.

Prompt in, calc.exe out

In May, Microsoft described two vulnerabilities in Semantic Kernel, its own agent framework (Microsoft Security):

• CVE-2026-26030 (Python). A search filter built from model output was run through Python’s eval(). A blocklist was supposed to stop dangerous code. It missed a few names, and a crafted input walked Python’s type system to import os and run a command. Fixed in 1.39.4.
• CVE-2026-25592 (.NET). A file-download helper was accidentally exposed to the model as a tool, with a file path the model controlled. An attacker could get the agent to write a script into the Windows Startup folder, where it ran at next login. Fixed in 1.71.0.

Neither bug is exotic. One is eval() on untrusted input, the other is an unvalidated path. What’s new is who supplies the input: the model, steered by whatever text it read.

Instructions hidden in web pages

The input doesn’t have to come from the user. Unit 42 documented indirect prompt injection in the wild: instructions hidden in ordinary web pages, waiting for an AI agent to read them (Unit 42).

The hiding tricks are classic web tricks: zero-size or off-screen text, CSS display: none, text the same colour as the background, instructions inside HTML attributes, Base64 decoded by JavaScript at runtime. The goals ranged from getting a scam ad past an AI reviewer to deleting a database or forcing a payment. Most attempts relied on plain social engineering aimed at the model, like fake “developer mode” claims. The authors also note they know of no confirmed case where the ad-review attack worked against a real deployment.

Here are six of them on a harmless page. Switch to what an agent reads:

The rule that survives

Microsoft’s own post puts it in one line: “your LLM is not a security boundary.” The practical version:

• Treat every parameter the model can influence as attacker-controlled input. Validate it like you would a form field.
• The tools you expose define how bad a successful injection can be. Don’t expose a file writer when a read-only search will do.
• Keep untrusted content (web pages, emails, documents) clearly separated from instructions, and assume the separation will sometimes fail.

None of this is new. It’s the same input validation the web learned twenty years ago, with a model in the middle that is very good at following instructions, including the wrong ones.