Data sovereignty is a property of the tool layer, not the cloud region

The gap agentic AI opened

Wiring an MCP client, Claude Desktop, Cursor, whatever a developer has open, to an internal tool means exposing that tool somewhere it can be reached. In practice that means one of two things: punching a hole through the corporate network so a client running on somebody's laptop can reach an internal service directly, or handing the request to a multi-tenant proxy that terminates it before it reaches your systems at all. Either way, the actual data flow just moved to a piece of infrastructure that is neither the model nor your own network.

Call that piece of infrastructure the tool layer. It is where a single agent session pulls a customer record from the CRM, cross-references an open invoice in the ERP, and reads a page from the internal wiki, all in the same round trip, in plaintext, before any model ever sees it. A chatbot saw your prompts. An agent sees your business, and the tool layer is what it sees it through.

The instinct is to answer this with a residency claim: our data stays in the EU. That answers where the disks are. It does not answer who can be compelled to open them, which is the question that actually decides whether "in the EU" means anything.

Residency and sovereignty are not the same claim

Residency is a geography question: which country is the physical disk in. It is answerable by picking a region from a dropdown, and most cloud providers now let you do exactly that. Sovereignty is a jurisdiction question: which legal system can compel the company that operates the disk to hand over what is on it, regardless of which country the disk happens to sit in.

AWS makes the distinction concretely. In January 2026 it launched the AWS European Sovereign Cloud, a genuinely serious commitment: 7.8 billion euros, EU-located infrastructure, operational independence, an EU-staffed subsidiary. It is still owned by a US corporation. Under the US CLOUD Act, that ownership is what matters, not the region: the Act reaches an American provider wherever its servers physically stand, because it compels the company, not the country the disks happen to be in. Billions of euros buy operational sovereignty. They do not buy an exit from a jurisdiction.

This is also the backdrop the 2020 Schrems II ruling (CJEU, Case C-311/18) left European data protection law with: contractual safeguards on top of a still-US-reachable provider are not a substitute for there being no US entity in the chain to reach in the first place. Separating the infrastructure from a parent company is not the same as separating the law that parent answers to.

A three-part test

"Sovereign" gets marketed into mush fast enough that it is worth pinning down to three concrete questions, none of which a region selector answers on its own.

Who can legally compel access to the data is the first one, and whether that reach travels with the operator regardless of where the servers physically sit. The second is who actually holds operational control: who holds the encryption keys, who runs the identity provider a platform's users authenticate against. Every externalised piece of that is a piece of control the operator no longer holds outright.

The third is exit. If a customer needed to leave, provider, country, or contract, could they. Sovereignty that cannot be exercised is a claim, not a property, and most of what gets sold as sovereign cloud passes the geography test and stops there.

Where foro.sh actually sits

Run against that test, the honest answer for foro.sh is short. Compute and object storage run on OVH Groupe SAS, a company incorporated and headquartered in France. foro.sh itself is established and built in Amsterdam, so the whole chain is European end to end, with no US parent anywhere above it. There is no US company anywhere in that chain for a CLOUD Act warrant to be served on, and no non-EU region to opt into by accident, since EU hosting is the only mode there is, on every plan including Free.

That is a jurisdiction claim, not a compliance certification, and it is narrower than "fully sovereign" on purpose: it says which law reaches the request path, not that nothing about the business ever touches a non-EU company. The EU data residency page is the full version of this, with the controller and processor split under GDPR and the complete subprocessor list. This post exists to explain why that page is the answer to a different, and more specific, question than a region picker.

What the tool layer has to do

Jurisdiction over the operator is necessary and not sufficient. An MCP server is connective tissue by design, the place several systems' data converges so a model can reason across it, which makes the tool layer the highest-leverage point in the whole stack for a sovereignty argument. Getting the operator's jurisdiction right and then running a leaky tool layer on top of it defeats the point. A few architectural decisions are what actually close that gap.

One container and one private network per project, never shared with another project and never reused across a redeploy, so one tenant's tool layer has no route to another's, and neither has a route to the platform's own database, queue, or internal API.

Authentication enforced inside the deployed workload, not by a control plane sitting in front of it. A gate injected at build time checks the bearer token from inside the container itself, which means the platform's own API is never in the request path and never becomes the single thing an attacker, or a subpoena, would need to reach to see every tenant's traffic at once. Call that auth in the workload, not auth at the edge, since edge implies a control-plane chokepoint that this design deliberately does not have.

Secrets encrypted with libsodium under a master key that lives only as a Docker secret, decrypted once at the moment a container is created, and never fetched back over a network afterward. There is nothing for a compromised container to call to get a credential; it already has the only copy it will ever get.

And where the platform needs a number about a payload, a token count for billing, it counts inside the container the payload already lives in rather than shipping the payload out to get measured. The arguments and results a tool call carries are serialised only to be counted, and only the count crosses back out.

The honest boundaries

A sovereignty page with no caveats is not describing a cleaner architecture. It is describing one where somebody stopped writing when it got inconvenient. A few things are worth naming plainly rather than leaving a reader to find them later.

Source code lives on GitHub if a project connects a GitHub repository, a US company, because that is where developers already are; Codeberg, hosted in Germany, and a direct archive upload are the EU-local alternatives for the same step, and neither is required. Certificate issuance and DNS resolution touch Cloudflare for the domain name involved, never project content. Build-time package downloads, base images, dependencies, are ordinary public HTTPS requests to registries like Docker Hub or PyPI, the same request anyone else makes for the same package.

The metering path is not payload-free either, and it should not be described as if it were. A tool call's error, if it has one, is captured as a string truncated to 500 characters in the per-call metric record, which can carry a fragment of whatever the error contained. And whatever a deployed server itself chooses to print to its own runtime logs is redacted for stored secrets, and scrubbed for structured PII on paid plans, before it is persisted, which is a real protection but a different one than "never leaves the container" would imply.

The precise version is: arguments and results are measured in place, and only counts and a bounded error string leave. That is a narrower claim than "no payload data ever leaves," and it is the one that is actually true.

None of these boundaries are disqualifying on their own. What would be disqualifying is a vendor who will not name theirs.

A checklist for evaluating any tool layer

Whatever platform is running the MCP servers a team depends on, the tool-layer questions are the ones worth asking before the region-picker question, not after it.

Under whose jurisdiction does the operator of the tool layer fall, not just where its disks are. Who holds the encryption keys, and who runs the identity provider. Is the check that gates a call enforced inside the workload, or by a control plane a caller has to trust is never compromised. And, the question that tells you the most: what does the vendor admit it does not control.

For a server already running on foro.sh, none of this is a configuration a project opts into; it is what a deploy already is. For everyone else, the fastest way to see the shape of it is to run uvx foro init against a repo and watch what a minute of deploying actually touches.