Data residency when the model lives somewhere else

There is a meeting that happens in every regulated organisation considering agentic coding. Engineering has run a pilot, the results are good, and someone from security or legal asks a question that stops the room: where does the code go?

The question is usually answered badly. Not dishonestly, exactly, but with a confidence nobody in the room is entitled to. “It stays in our environment.” “The vendor does not train on it.” “We are on the enterprise tier.”

Those statements are about three different things and none of them is an answer.

Separating four questions that get merged

The reason this conversation goes badly is that “where does the code go” is four questions wearing one coat, and the answers are different, provided by different parties, and enforced by different mechanisms.

Once separated, the uncomfortable structural fact becomes visible: for three of the four, the party that controls the answer is the model provider, not whoever built your development pipeline. If inference happens on a provider’s infrastructure, then processing location, retention and training use are terms of your agreement with that provider. Your tooling does not determine them and cannot.

This is why I distrust any tool that claims your code never leaves your network while also calling a hosted model. Those two things cannot both be true. Something left. What you want to know is what, where to, under what terms, and whether you can prove it afterwards.

Enforce and prove, rather than provide

The honest framing for anything sitting between your developers and a model is that it does not provide residency. It enforces a residency policy you have chosen, and it proves the policy held.

That is a smaller claim than the marketing usually makes and a considerably more useful one, because it is the part that is actually missing.

Consider what a regulated organisation typically already has. It has an agreement with a model provider, quite possibly through a cloud platform, specifying a region and terms about retention and training. That agreement is real, negotiated, and often good. What it does not have is any mechanism ensuring the agreement is what developers actually use.

An engineer with a personal API key can bypass a carefully negotiated regional endpoint in about ten seconds, not maliciously but because their editor was already configured that way. A tool that pulls a default endpoint from an environment variable will use whatever is set. A new agent adopted by one team last month is calling something nobody has reviewed. The negotiated contract governs a path that is one of several available, and nothing checks which one was taken.

What provable actually requires

“Provable” is a word that gets used loosely, so it is worth saying what it takes.

For each model interaction, the record needs the endpoint or runtime identifier, the time, the identity that initiated it, the work it was attached to, and something that ties the record to the actual event rather than to an intention. A log line written by the same process that made the call is weak evidence, because a process that can be misconfigured about where it called can be misconfigured about what it logged. A signed manifest produced at the boundary, covering the whole chain, is stronger.

The distinction matters most in the case you are trying to defend against, which is not a hostile developer. It is a misconfiguration nobody noticed for four months. Self-reported logs are exactly as wrong as the configuration that produced them. Boundary-level records are not.

runtime:     bedrock://eu-central-1/anthropic.claude
policy:      eu-only-approved-runtimes
decision:    allowed
initiated:   agent://refactor-worker on_behalf_of user://dpatel
work:        PLAT-4471
signed_at:   2026-03-11T09:22:41Z  (boundary, not caller)
runtime:     api.example-vendor.com/v1/chat
policy:      eu-only-approved-runtimes
decision:    refused  (runtime not registered)
initiated:   ide-plugin on_behalf_of user://mokoye

That second record is the point people miss. A residency control that produces no refusals is either perfectly configured or not working, and from the evidence alone you cannot tell which. Refusal records are how a control demonstrates it exists.

The cross-vendor problem

There is a structural reason this cannot be solved by the model providers themselves, and it is worth being direct about it.

Each provider offers governance for its own service, and some of it is very good: regional endpoints, zero-retention options, enterprise agreements with real teeth. But a development organisation in 2026 is not using one provider. It is using a coding agent from one vendor, a different assistant in the IDE, something else for code review suggestions, and whatever a team adopted last month because it was better at their language.

Every one of those has its own governance surface, its own configuration, its own logs in its own format. The provider’s controls are genuinely good and they cover exactly one path each. The organisation’s policy needs to cover all of them, uniformly, with evidence in one place.

That gap is not a deficiency in any provider’s product. It is a consequence of each vendor covering itself, and it does not close as the providers improve, because there is no provider whose job it is to govern a competitor’s endpoint.

The air-gapped end of the spectrum

At the far end, some environments do not permit any egress. Defence, certain national infrastructure, classified work, and a handful of financial contexts where the constraint is absolute rather than a matter of terms.

Here the answer is different in kind: the model runs inside the boundary, on hardware the organisation controls, with no outbound path at all. The capability ceiling is lower, because the models that can be self-hosted lag the frontier, and the operational burden is real. In exchange, the residency question stops being a matter of evidence and becomes a matter of physics.

What is worth noting is that the governance layer is more necessary here rather than less. An air-gapped environment still has multiple internal runtimes, still needs to prove which one processed what, still needs the criteria and the proof chain for the auditor. Removing the internet removes one class of risk and none of the accountability requirements.

Where this breaks down

Enforcement at the tool boundary is not network egress control. A runtime registry governs the path that goes through it. It does not stop a determined engineer from curling an endpoint from a laptop, and describing it as though it does is the exact overclaim this piece is arguing against. It is a governance control, not a data loss prevention product, and it should be deployed alongside network controls rather than instead of them.

You are still trusting the provider’s word on retention and training. No mechanism available to a customer can verify that a provider deleted an input. You verify the endpoint, the region and the terms; the rest is contract, audit report and reputation. Anyone claiming to prove non-retention is describing something they cannot observe.

Regional endpoints are not always what they appear. Some services route to a region for inference and process metadata, safety classification or abuse monitoring elsewhere. This is usually disclosed and rarely read. If the jurisdictional constraint is strict, the diligence has to go deeper than the endpoint hostname.

Registries decay in the direction of permissiveness. A team blocked by an unregistered runtime at four o’clock on a Friday gets it registered, and the review is lighter than it should be. Over a year the approved list becomes the list of everything anyone asked for. Periodic re-justification is the only counter I know of and it is widely skipped.

Self-hosting trades one risk for several. The air-gapped option removes egress risk and introduces model quality limits, patching burden, capacity management and a much smaller pool of people who can operate it. It is the right answer where the constraint is absolute and an expensive answer where it is merely preferred.

The takeaway

Nobody who calls a hosted model can honestly tell you your code never leaves your network. What they can tell you, if they have built it, is which runtimes are permitted, that calls to anything else are refused, and that every interaction carries a record of where it went that was produced at the boundary rather than self-reported.

Enforce the policy, prove it held, and be precise about which of the four questions you have actually answered. Contracts with providers cover processing location, retention and training use. What contracts do not cover, and what nothing in the stack covers by default, is whether the path your developers took is the path you negotiated.

If you take one thing into next week: try to produce evidence of which model endpoints your organisation called last month. Not a list of approved ones. Evidence of the calls. The difficulty of that exercise is the size of the gap.

The next piece goes to the extreme end of this spectrum and looks at what an air-gapped agentic life cycle actually involves once the internet is genuinely not available.