You ask the platform team where the model runs and they answer with a region: “Frankfurt.” You exhale. That same night, to resolve a customer case, the agent queries a CRM in a third party's cloud, calls an external search tool, passes the text through an MCP server someone installed in March and, when the main provider gets overloaded, retries against another model in another region. Frankfurt was one hop out of five.
The thesis in one line: an agent's data sovereignty isn't decided by where the model runs; it's decided by every hop of the chain the agent walks to do its job. A perimeter that only watches the model is a lock on a door with four open windows.
Data sovereignty with AI agents: every call decides it, not the model
A classic chatbot had a border that was easy to draw: the user types, the model answers, and the data goes back and forth through one place. An agent breaks that geometry because it acts: it reads in one system, writes in another, asks a tool for help, stores memory. Each of those actions is a network call, and each network call is a decision about where the data goes, who processes it and how long they keep it. “Where does our agent live?” has no useful answer. The question that does have one is: “where does every byte of this run go?”
If the run contains personal data, each destination is, in data-protection terms, a processing operation with its own vendor, its own processor contract and, if it leaves the European Economic Area, its own transfer basis. An agent doesn't change the rules: it multiplies the places where you have to apply them. We already covered in generative AI and GDPR: what your vendor doesn't tell you why the “enterprise” label isn't a guarantee; with agents, the problem stops being a contract and becomes a route.
The five hops of an agent chain and what leaves at each one
| Hop | What can leave | The question that decides it |
|---|---|---|
| Main model | The full prompt: instructions, retrieved context and case data | Which region does it process and retain in, and under what contract? |
| Tools and APIs | The parameters of each call: names, amounts, identifiers | Which fields does the tool actually receive, and does it need all of them? |
| MCP servers and connectors | Whatever the server asks for and the agent hands over, sometimes to a third party | Who operates it, where does it run and who approved it? |
| Fallback model | The same request re-sent to another provider or region when the main one fails | Does your policy allow that fallback, or does it switch on by itself? |
| Memory, traces and embeddings | Copies of the data in vectors, logs and observability tools | Who sees the traces, how long are they kept and where do they live? |
MCP deserves its own line. It's the standard that connects an agent to tools and data through servers, and those servers can be yours, a vendor's or a third party's that someone installed for convenience (we explain what MCP is and why it changes enterprise agents). A remote server receives whatever the agent sends it. Treating it as “a plugin” is treating a sub-processor like a browser extension.
The two hops that leak most are the fourth and the fifth, for the same reason: they work when you don't see them. The fallback model is a useful safety net: the main one returns an error, the router retries against the next on the list and the user notices nothing. Neither does your data policy, which said “EU region only” and just sent the same prompt to another one. Traces are just as silent: the tool that helps you debug keeps, unless you configured it on purpose, a literal copy of every conversation.
And the legal framework for transfers? It's not a constant either
Part of the answer to “can I send this to a US vendor?” rests on the EU-US Data Privacy Framework. The EU General Court upheld its validity on 3 September 2025, dismissing Philippe Latombe's challenge, and Latombe appealed to the Court of Justice on 31 October 2025 (source: WilmerHale, December 2025). Scope: EU law; it matters for personal data leaving the EEA toward certified US companies, and it doesn't extrapolate to other regimes.
How to audit an agent's sovereignty without a platform team
You don't need a six-month project. You need one real run and one hour:
- Take a real request, one that carries customer data, and run it with the agent's network log or traces switched on.
- Write down every destination that traffic goes to: domain, vendor and region if you know it. Usually there are more than you expected.
- Mark the ones carrying personal or confidential data and, for each, write three things: contract, region and retention period. Wherever you can't fill one in, that's your finding.
- Decide per hop: cut it, minimise it (send only the fields needed), pseudonymise before it leaves, or change vendor.
- Keep the result as a living map: one page of approved destinations. Any new hop — a tool, an MCP server, a fallback — goes on the map before it goes into production.
Two pieces make it easier than it looks. The first is what permissions to give an AI agent: an agent with its own identity and per-task scope already limits which data reaches each tool. The second is picking which model to use in an agent with region and contract on the table, not just accuracy. And if your answer to “do we host it ourselves?” is yes, first read when self-hosting pays off and what it really solves: hosting the engine doesn't close the other four hops.
When the map has more destinations than your team can review, that's data governance work, and the part that proves what happened in each run is traceability of AI decisions.
When you don't need all this
If your agent only touches public or non-personal information — one that summarises open documentation, say — and writes to no system, the five-hop map is overkill: knowing which vendor runs it is enough. And hosting everything in-house isn't an automatic fix: a model on your own infrastructure that hands the full data to an external tool still leaks; it just moved hop. All of this is operational judgement, not legal advice: your DPO or counsel validates the legal basis of each transfer.
The line to take away: don't ask where the model runs, ask where each call goes. The first question has a comfortable answer. The second has a list, and that list is what you need to be able to show.