Your AI agent writes code. Where does it run?

The moment an AI agent runs code it generated from untrusted input, prompt injection stops being a content problem and becomes remote code execution. An agent that reads a web page, a support ticket, or a repo file — and then runs a shell command, a script, or a tool call based on what it read — has handed a stranger a keyboard on your infrastructure. In 2026, agents do exactly this by default. The sandbox is not a nice-to-have. It is the security boundary, and if you don't build it, you don't have one.

Why this matters now

Two things changed in 2026. Agents got hands, and attackers noticed.

"Computer use" and code execution moved from demo to default this year — coding agents now write a script and run it, drive a browser, and chain tool calls without a human between steps. At the same time, the OWASP GenAI Security Project's 2026 report shifted from cataloguing plausible threats to cataloguing real CVEs, vendor advisories, and breach reports. Prompt injection is now ranked the single leading agentic vulnerability, and it maps to six of the ten categories in the agentic Top 10.

This isn't theoretical. In May 2026, Microsoft's security team documented a class of remote-code-execution bugs in popular AI agent frameworks — "when prompts become shells." Disclosed CVEs have shown an agent's own output redefining the boundary of its own sandbox, and allowlisted commands like git branch being poisoned to deliver arbitrary payloads. The pattern is always the same: text the model treated as data turned into a command that ran.

The mechanism: the model can't be the boundary

Here is the uncomfortable root cause, and why you can't prompt your way out of it:

A language model has no built-in way to separate trusted instructions from untrusted data, because both arrive as the same stream of tokens.

Your system prompt, the user's request, and the malicious sentence buried in a scraped page are — to the model — one undifferentiated sequence. That's why prompt injection behaves less like a bug you patch and more like a structural property of how these systems work. You will not eliminate it with a cleverer system prompt or a filter.

So the boundary has to live outside the model, at the runtime. You assume the agent will eventually be tricked into trying something hostile, and you make sure that when it does, the blast radius is a disposable box — not your database, your secrets, or your other customers' data.

The four isolation tiers

By early 2026 the field converged on four ways to isolate untrusted code, and the consensus is blunt: plain Docker/runc containers are not enough for agent-generated code. From weakest to strongest:

• Standard containers — fast to start, but share the host kernel. A kernel escape is a full compromise. Fine for trusted code, wrong for agent code.
• gVisor — intercepts syscalls in a user-space kernel, shrinking the attack surface at a moderate performance cost.
• Firecracker microVMs — true hardware-level isolation with a fresh guest kernel per task, and a ~125ms cold boot fast enough to spin one up per agent run. This is the sweet spot for running untrusted code at scale.
• WebAssembly — near-zero overhead and capability-first: the sandbox can do nothing it wasn't explicitly granted. Great for pure computation, more constrained for full toolchains.

The rule of thumb: one throwaway environment per task, destroyed when the task ends. State should never leak from one agent run to the next.

The checklist that actually contains an agent

Isolation is necessary but not sufficient. A sandbox shrinks the impact of a successful injection; it does not stop the injection. Layer these on every agent task:

1. Non-root, always. The process inside the box owns nothing worth stealing.
2. Egress filtering. Default-deny outbound network. Exfiltration needs somewhere to go — don't give it one.
3. Read-only mounts + no ambient secrets. The agent gets the files it needs and nothing else. Keys live in a broker it must ask, not in an env var it can cat.
4. Strict timeouts and resource caps on every task, so a runaway or a crypto-miner dies quickly.
5. Tool allowlists, not denylists. Enumerate what the agent may call. Everything else is refused by default.
6. Output auditing. Log every command and tool call the agent actually ran — that's your incident trail.

Our opinion

Treat every agent as hostile-by-default, because from a security standpoint it effectively is: it is a program that will follow instructions from whatever text it happens to read. The most common 2026 mistake we see is teams shipping agent code execution on a bare container behind a friendly demo, reasoning that "our prompt tells it not to do that." The prompt is not a control. The runtime is.

If you're building an agent that runs code, the sandbox is the product-defining decision, not an afterthought you bolt on before launch. Design it first. It's cheaper than the breach, and it's the difference between an agent that's contained and one that's merely polite.

How Ashvara helps

We build the backend and infrastructure that AI features actually run on — including the isolation, secret-brokering, and egress controls that make agent code execution safe to ship. We've built and shipped real production systems end to end, from our own apps on the App Store to the cloud behind them, so this is the layer we live in, not a slide.

If you're adding agents that touch code, tools, or customer data, our DevOps & cloud and AI solutions work is where that gets built correctly. Tell us what you're planning and we'll pressure-test the security model with you — get in touch. For the attack it defends against, see our earlier piece on why prompt injection is the new SQL injection.

Source: OWASP GenAI Security Project, "Exploit Round-up Report Q1 2026" (genai.owasp.org); Microsoft Security Blog, "When prompts become shells: RCE vulnerabilities in AI agent frameworks," May 2026.