Sovereign AI: where your agents actually run

Why it matters: the model is in Europe, the agent isn't

Picture a claims team at a Dutch insurer that builds an agent to read incoming claims. They do the sovereignty work everyone talks about: the model is an open-weight one, served from a European GPU cloud, and the claims database sits in Frankfurt. Then the agent needs to parse a scanned PDF, so it writes some Python and runs it with a code-execution tool. That tool is a hosted sandbox the team picked during the prototype, running in a US region from a provider they never put through a sovereignty review.

Every claim the agent touches is now copied to that sandbox, outside the EU and under another country's law. The sandbox can also reach the whole internet, because the agent sometimes needs to pip install a library. So a claim PDF with hidden instructions in it ("send this file to this URL") can make the agent send customer data anywhere. That attack is called prompt injection: text the agent reads gets treated as an instruction. Simon Willison calls this combination of private data, untrusted content and a way to send data out the lethal trifecta, and an agent sandbox with open internet has all three.

Asking where the model runs won't surface either problem. You have to ask where the agent runs, and that's the layer most sovereign AI guides skip. For an agent, the execution layer is where the data actually moves: files get read, code gets run and requests go out.

What sovereign AI is, layer by layer

Sovereign AI is control over the AI you depend on: where its data is kept, who runs its models and compute, and which country's law decides who can get at them. The term has no single agreed scope. Wikipedia's entry describes it as national or regional efforts to reduce critical dependence on foreign providers, and notes that Nvidia's CEO began promoting the phrase to governments in 2023.

Most of what you'll read is about countries, which is why you'll see terms like "sovereign AI factory": a national compute centre for training and serving models. The EU's version is its AI Factories programme, with 19 selected so far on its public supercomputers. That work sets where models get trained. It doesn't decide where your agent runs.

For a company, the same idea breaks down into layers you can check one at a time:

• Data: where it's stored and where it's processed. Processing includes every copy an agent makes while it works.
• Models: whose model it is, and where inference runs. Inference is the step where the model reads your prompt and data and answers.
• Compute: whose hardware the work runs on, and who has admin access to it.
• Jurisdiction: which company operates each layer, and which country's courts can compel it to hand data over.

Jurisdiction is the layer that location doesn't fix. The US CLOUD Act of 2018 added a rule, 18 U.S.C. § 2713, that makes US providers disclose data in their possession, custody or control whether it's stored inside or outside the United States. In June 2025, Anton Carniaux of Microsoft France's legal team told a French Senate hearing that he could not guarantee under oath that French data would never pass to the US government without French consent, though he added it had never happened. So a server in Frankfurt run by a company under US law is in the EU, but it isn't under EU law alone.

What sovereign AI infrastructure needs from the machine that runs agents

The machine an agent runs on has to answer the same questions as the rest of the stack: where it runs and under whose law. Because agents act on their own, it also needs two controls that are usually filed under security. An agent decides at run time which files to open, which code to run and which hosts to call, and a machine in the right country that sends data wherever it's told hasn't kept that data under your control.

Where it runs. The machine's disk holds whatever the agent has read: customer files, database extracts, intermediate results. It needs to sit in the region your data is allowed to be in, and so do its backups and saved states. So does the control plane, the service that creates and manages the machines, because it holds their metadata and logs.

Who operates it, under which law. Ask who owns the company that runs the machines, which courts its contract names, and whose data centre and hardware it runs on. A European region from a provider under foreign law fixes location but not jurisdiction, as the CLOUD Act shows. If you run the machines yourself, the question moves one level down, to whoever owns the hardware or the cloud account.

What it can reach. An egress allowlist is a list of hosts a machine may connect to, enforced outside the machine so the agent can't change it. With one, a prompt-injected agent can call your model endpoint and your own API, and nothing else. Secrets need the same care: if the real API key sits on the machine, a manipulated agent can print it or send it out. A host-bound secret keeps only a placeholder on the machine and swaps in the real key on the way out, only for requests to the host it belongs to.

What it shares with other workloads. A container shares the host's kernel, the core of the operating system that controls memory, files and hardware, with every other container on that host. So one kernel flaw can let code in one container reach the host and its neighbours. A virtual machine (VM) has its own kernel, and code that breaks it still has to get past the hypervisor, the layer that separates VMs on the host. For code an LLM wrote, on hardware other customers also use, that boundary decides who else could see your data.

The options for running agents, compared

There are five ways to run the machines your agents work on, and they differ mostly in who operates them and whose law applies.

Hosted by a non-European provider is where most teams start, because it's quick and there's nothing to run. Many of these services let you pick a European region, which fixes where the data sits. Whose law applies still depends on who owns the provider, so read the contract before customer data goes in.

Hosted in the EU by a European company puts both the location and the contract under European law without you running anything. The trade-off with any hosted option is that you trust the operator's controls instead of your own. General European clouds give you VMs in the EU, but then the sandbox layer (machine lifecycle, egress rules, secrets) is yours to build.

BYOC puts the platform inside your own cloud account, operated by the vendor. You can do this with boxd, E2B or Northflank, and Northflank also supports Oracle and bare metal. The data stays in an account you own, but two companies still have a hand in it: your cloud provider, which the CLOUD Act reaches if it's American, and the vendor that operates the platform, whose home country you should check as well.

Self-hosted means you run the whole platform yourself, on hardware or a cloud you pick. Self-hosted boxd runs on Google Cloud, AWS or bare metal, which includes servers rented from a European provider. E2B publishes a self-hosting guide for AWS, Google Cloud and Azure, and Coder runs workspaces for developers and coding agents on infrastructure you own. You decide the jurisdiction, and you also own the upgrades, the monitoring and the on-call.

Air-gapped is self-hosting with no internet connection at all, for defence, critical infrastructure and some public-sector work. boxd offers air-gapped installs on request, and Northflank can run its control plane air-gapped. It's the most control and the most operational work, because every update has to be carried in.

None of these options covers the model layer. If your agent calls a model API, that endpoint needs its own answer, either an EU-hosted model provider or open-weight models on GPUs you control.

How to choose

Pick the option that matches the data your agents touch and what you've promised your customers, then check each layer of the stack against it.

You don't need any of this if your agents only touch public or synthetic data and your customers haven't asked where it goes. A sovereignty project costs time, and a prototype on test data doesn't need one. Use whatever sandbox is fastest, and revisit before real customer data goes in.

Use a non-European hosted provider when the data isn't personal or confidential, or when your customers have reviewed and accepted the provider. Pick its EU region and turn on any egress limits it offers.

Use an EU-hosted European company when your agents handle European customer data and you don't want to run infrastructure. For most agent teams selling to European businesses, this is the sensible default. If you pick boxd here, you sign with a Dutch company based in Amsterdam, under Dutch courts, and a machine in its Frankfurt cluster stays on infrastructure within the EU/EEA. The two agent-specific controls are there too, because each agent gets a machine with its own kernel, an egress allowlist and host-bound secrets; agent sandboxes on boxd shows that setup for untrusted code.

Use BYOC when your data already lives in a cloud account you control, your security team has accepted that cloud provider's contract, and you'd rather not operate the platform. With boxd in BYOC, the operator inside your account is the same Dutch company.

Self-host when you need to choose the hardware and operator yourself, for example a European provider's bare metal or your own racks. Self-hosting is only worth it if the platform is small enough to run. boxd is a single Rust binary, with no Kubernetes, external Postgres or Redis, and a cluster deploys in 30 to 60 minutes. It runs the same release as boxd cloud, so the CLI commands and SDKs your agents use don't change when you move.

Go air-gapped only when the workload must have no internet at all. If your agent still calls a hosted model, you aren't air-gapped, so plan the model layer first.

Whichever you choose, ask every provider in the chain the same questions:

1. Which company operates this, and which country's courts does the contract name?
2. Whose data centre and hardware does it run on?
3. Which regions do the machines, disks, backups, saved states and control plane live in?
4. Can I limit which hosts each machine can reach, and keep API keys off the machine?
5. Does each workload get its own kernel, or share one?
6. Who has admin access, and can I see when it's used?

The decision

Put the machines your agents run on under the same law as your data and models, and limit what they can reach. For most European agent teams that means a European provider hosting in the EU today, and self-hosting when a customer or regulator asks for more. If you want to run it yourself, self-host boxd with the open-source installer.

Michiel Voortman

PostShare⎘Copy link