Where to run an AI agent that executes code

As long as an AI only answers questions, hosting is settled in a contract clause. The day it writes a script, opens a terminal or alters a table, everything shifts: it is no longer a writing tool, it is one more user inside your systems. The question comes up fast in a steering meeting, and it is a good one. Here is how I answer it, from the sandbox to the rights I refuse to grant, well before anyone talks about going to production.

The question that lands in the first five minutes

It is always phrased the same way: 'where does this run?' Behind it sit three stacked worries, all legitimate. What this thing can read. What it can break. And who answers when it breaks something. The reflex is to treat it as application security, to be sorted once the demo has landed. It is the opposite: the answer shapes the architecture, so it is given before the first line of code. An agent with no defined place to run always ends up on somebody's machine.

The developer's laptop, the wrong default answer

It settles in when nobody has decided, and it looks harmless. Yet a developer's machine holds SSH keys, API tokens, repository access, shell history and often an open connection to production. You are not giving the agent an execution environment, you are giving it an administrator's context, with everything lying around it. The vulnerability tracked as CVE-2026-22708 describes that exact scenario: poisoning the execution environment of an AI-assisted editor through commands that were themselves authorised. A workstation is not a sandbox.

Where it runs: microVM or hardened container

The answer fits in one line: somewhere else, and for a bounded time. In practice the agent runs in a microVM or a hardened container, created for the task and destroyed after it. This is no longer a home-made rig: in April 2026 OpenAI's Agents SDK shipped native sandbox support with seven official providers, including Cloudflare, E2B, Modal and Vercel. What remains are the four properties that make a sandbox a sandbox.

• Strong isolation: a microVM draws a boundary at the kernel level, where a standard container shares the host's.
• Bounded lifetime: the environment is born with the task and dies with it. A shell left open accumulates state nobody reads any more.
• Nothing persistent: no volume mounted for convenience, no token cache, no inherited configuration. What must survive leaves by one explicit path.
• Capped resources: CPU, memory, maximum duration. A runaway loop should cost a ceiling you set in advance.

What never enters the sandbox

• Production secrets: database passwords, signing keys, payment credentials. An agent working on code has no reason to see them.
• Long-lived credentials: issue a short token, scoped to the task, expired afterwards. A token that never dies is still valid on the day it leaks.
• Write access by default: read first, write requested case by case. The reverse is usually the convenience of whoever set it up.
• The laptop's configuration: shell history, cloud profiles, SSH keys mounted into the container. Those are what turn an incident into a wide one.

An allowlisted network, the thing that cuts exfiltration

The sandbox protects your systems from the agent. The network protects your data from the outside. By default egress is wide open: the package installed on the way, the request that carries a file out. Flip the rule. Egress closed, then an allowlist of destinations, written down and reviewed like a document. That is what goes after the lethal trifecta described by agent security researchers: private data, untrusted content and an outbound channel inside the same process. The 2026 agentic application top ten from OWASP, the open reference in application security, ties prompt injection to six of its ten categories, and the mechanism is laid out in prompt injection, explained. An allowlist does not remove the outbound channel, it narrows it to destinations you accepted, which is what keeps an injection a local mishap.

One identity per agent, and a revocation that works

An agent acts, so it has to be identifiable. That means an identity of its own, separate from the person who launched it. The field observation is the same everywhere I look: plenty of integrations run on a developer's personal token, because that was the fastest route the day it had to work. It is not a scandal, it is an immediate audit finding. I cannot tell you how often it ends badly: nobody publishes those numbers, myself included. The MCP specification of 28 July 2026 hardens authentication in that direction, going as far as deprecating dynamic client registration (securing MCP servers).

• One identity per agent: not a shared account, not a human's token. A log is useless if it cannot say who acted.
• The rights strictly needed: the repository and the task's environment, not the rest of the information system.
• A usable log: every tool call, its arguments, its result. Without it, post-incident analysis is done from memory.
• A tested revocation: cut the agent off in one action, and check every quarter that the cut works. A revocation never tried is not one.

The same sandbox, on French infrastructure

None of this forces you out of Europe. A microVM, a network allowlist and a log deploy just as well at a French host as at an American provider: they are architectural properties, not a product you buy. Isolation even serves the sovereignty case, because it makes the place of execution explicit. A 2026 study of technical leaders in the United States and the United Kingdom puts security at the top of the declared obstacles to enterprise MCP adoption, at 64%, and finds only 19% at broad production scale. Where execution happens is an architecture decision, on a par with where your models are hosted.

The irreversible: human sign-off and the plain no

An agent must not be able to do what you would not know how to undo. Everything else is negotiable.

What is left is sorting the actions, and three buckets do it: what the agent does alone, what goes through an explicit human sign-off, and what is forbidden with no configurable exception. Dropping a database, migrating a schema, deploying to production: sign-off, or forbidden. In 2025 Replit's coding agent deleted a production database during a code freeze. Unbounded write access is what makes that possible. This sorting takes a day, sometimes two, and it impresses nobody in a demo: I do not sell it as a deliverable, I do it before the rest, with the guardrails of production reliability. If an agent is about to run code inside your systems and the question has no written answer yet, one conversation is usually enough to write it down, with no commitment: let's talk.