Data Residency and Code Privacy in Agent Deployments

Most large organizations are deploying agents into real business functions right now. Only a fraction of them can honestly say they know what those agents are doing with sensitive data. The gap spans model interfaces, tool integrations, and third-party supply chains all at once. It's less like a security problem and more like trying to patch a dam after the water has already found three new cracks.

Among organizations with agents running, a majority acknowledge those agents touch sensitive information daily. Most lack mature guidelines for responsible usage. Most offer no meaningful transparency about how customer data moves during inference. "We have a policy" and "we know what our agents are doing" are two very different things. I've watched teams conflate those two statements in security reviews, and it never ends well.

The layer that gets the least attention is the retrieval and context delivery layer. Per Gartner's 2025 research, fewer than half of enterprises have extended their AI governance frameworks to cover it. That is exactly where most residency violations actually happen. Everyone governs the model. Nobody governs the stuff feeding it.

The financial consequences are real. Enterprises have collectively absorbed multi-billion-dollar losses tied to AI compliance failures in recent years. Confirmed or suspected AI agent security incidents are now nearly universal among large organizations.

Shadow AI makes all of this worse. Developers use unapproved AI coding tools, many through personal accounts that entirely bypass enterprise controls. Proprietary code leaves the organization's infrastructure quietly. No log entry. No review. Nobody notices until it's too late, if they notice at all. The policy exists. The data left anyway.

This is increasingly a legal problem, and a risk management one. The regulatory environment has moved.

The regulatory environment agents now operate inside

The rules are already here. Here's what organizations are actually navigating.

EU AI Act. Full high-risk enforcement arrived in August 2026. High-risk systems under Annex III require documented data governance, risk management maintained across the full lifecycle, automatic logging with multi-month retention, and conformity assessments. Penalties for high-risk violations reach a meaningful percentage of global turnover. Prohibited-practice penalties go higher. The Act applies to any organization whose AI systems affect people in the EU, regardless of where that organization is headquartered.

GDPR and the CLOUD Act gap. Cross-border data transfers require Standard Contractual Clauses, Binding Corporate Rules, or adequacy decisions. The EU-US Data Privacy Framework provides a current pathway, but it faces ongoing legal pressure. The CLOUD Act creates a real and uncomfortable split between where data physically sits and whose laws govern it. A server in Frankfurt operated by a US-headquartered company satisfies residency. It does not satisfy sovereignty. American authorities can compel access regardless of which country the hardware is in.

For LLM inference where prompts contain personal data, encryption doesn't solve that problem. The European Data Protection Board's April 2025 guidance identifies on-premise inference as the strongest available mitigation, because it eliminates the cross-border transfer risk at the model layer. The same guidance notes that LLMs rarely meet GDPR's standard for true anonymization. Data transmitted to a third-party model endpoint carries ongoing exposure.

US sector-specific requirements. There's no federal AI law, but the body of state privacy law and sector regulation is growing fast. Financial services requires tamper-evident, auditable records for every regulated workflow, including agent-generated ones, and documented due diligence for every model and tool in an agent's call chain. Healthcare's HIPAA obligations around access controls, audit trails, and breach notification are significantly easier to demonstrate when all data handling stays within US jurisdiction.

Global localization. China, Russia, India, and a growing list of countries impose data localization requirements that restrict or prohibit cross-border transfers, with active enforcement. China's first administrative penalty targeting unlawful cross-border AI data transfers arrived in 2025.

Singapore's agentic-specific framework. Unveiled in January 2026, this is the first governance model designed specifically for agentic AI systems. It is a signal worth paying attention to. Regulators are starting to understand what agents actually do. Agent-specific requirements will spread.

The cumulative effect for an organization deploying agents across multiple jurisdictions is overlapping, sometimes contradictory requirements. None of them can be satisfied with a configuration-based approach that doesn't capture what the agent actually does at runtime.

The specific paths through which agents move data outside intended boundaries

Most residency failures aren't the result of bad intentions. They happen because nobody noticed a component was routing data somewhere unexpected. Here's where it actually goes wrong.

The inference endpoint gap. The model API is served from a different region than account settings imply. Failover routing during capacity events can silently shift traffic across borders, with no human decision and no log entry a compliance team would ever see.

The embedding and vector database gap. When agents call external embedding APIs, documents leave the organization's infrastructure to be vectorized on vendor hardware. Cloud-hosted vector databases store chunked document fragments, including code, PII, and proprietary content, on infrastructure the organization doesn't control. This layer sits between the agent and the model, and it is frequently outside the scope of whatever model-layer governance organizations actually invest in.

The context-layer blind spot. The critical residency decisions happen in the milliseconds between a retrieval request and data entering the context window. Governing the model layer without governing context delivery means the exposure is at exactly the place that matters most.

Multi-turn memory and RAG compounding. Sensitive data accumulates across sessions. A single multi-turn interaction can carry PII, proprietary documents, financial records, and internal communications, all transmitted in plaintext to a third-party endpoint. The agent doesn't know it should be concerned. It's just doing its job.

Sub-agent delegation and identity federation. When an agent delegates to a sub-agent across a cluster boundary, the federated identity carries the authorization but not the region context. The receiving agent can't tell whether data arrived from inside or outside a sovereign perimeter. What a data protection officer actually needs at that boundary, including source jurisdiction, destination jurisdiction, processor identity, and personal data scope, does not exist in a deployment manifest. It can only come from runtime observation.

Residency drift. The most common cause of violations in mature deployments is adding a new tool or service without a residency impact review, so the boundary shifts invisibly over time. The system looked compliant at launch. It drifted while everyone was focused on something else.

Fine-tuned weights as regulated data. A model fine-tuned on regulated data can memorize and reproduce parts of that data. The weights themselves are subject to the same residency requirements as the training data, wherever those weights are moved for inference.

Why source code is a distinct and underappreciated category of at-risk data

Source code doesn't appear in most governance frameworks as a regulated data category. It should. A source code breach can be more damaging than a PII breach, because competitive value is harder to recover than a compromised password. You can reset a password. You can't un-leak your architecture.

The canonical case is Samsung in 2023. Within weeks of Samsung Semiconductor lifting its internal ChatGPT ban, engineers pasted proprietary semiconductor diagnostic code, internal test sequences, and a confidential meeting transcript directly into prompts. The data went into a third-party training pipeline. There was no mechanism to retrieve it. Samsung banned generative AI tools company-wide and began building an internal alternative. The incident prompted restrictions at major financial institutions and technology companies globally.

The element that doesn't get enough attention: that incident involved humans manually pasting code into a chat interface, one deliberate action at a time. Modern agents send code continuously and autonomously, without a human making that decision at each step. The surface area is orders of magnitude larger. The Samsung incident was a slow leak. Agentic tools are a different kind of problem entirely.

Policy compliance is an unreliable control here. A large majority of developers use AI coding tools their organizations haven't approved, many through personal accounts that bypass enterprise controls entirely. When organizations impose AI bans, a substantial majority of affected employees continue using AI tools through personal devices or accounts anyway. That's an honest read of the data. Policies that depend on voluntary compliance are structurally insufficient for this problem.

Prompt injection makes it worse. A critical-severity vulnerability demonstrated in 2025 showed how hidden prompt injection inside a pull request description enables remote code execution through a major AI coding tool. A separate zero-click data exfiltration vulnerability in a major enterprise AI assistant was triggered through a crafted email, bypassing the platform's own injection classifier. These are not theoretical. They are documented, scored, and exploited attack paths specific to agentic tools.

Research from recent years also shows repositories using AI coding tools have meaningfully higher rates of leaked secrets. The tools that accelerate development also accelerate a specific class of exposure. Most teams haven't fully priced in that trade-off.

What infrastructure-level control actually requires in an agentic environment

Here's the core shift. Controls must travel with every execution, not be set at provisioning. Because the agent's data routing decisions happen at runtime, governance has to be captured at runtime. Everything else follows from that.

What that actually requires:

An AI bill of materials extended to the delegation graph. Traditional software bills of materials capture components. For agents, the compliance artifact must also capture every edge in the delegation graph, labeled with source jurisdiction, destination jurisdiction, processor identity, and personal data scope. This cannot be derived from a deployment manifest. It has to be built from runtime observation of actual agent behavior.

On-premise inference as the strongest structural control. When inference runs on the organization's own infrastructure, cross-border transfer risk is eliminated at the model layer. The EDPB's own guidance identifies this as the most effective mitigation for LLM data exposure. The same principle applies to embedding generation and vector storage. Keeping both on-premise or in a controlled environment closes the context-layer gap.

Model agnosticism as a residency enabler. Organizations locked into a single vendor's inference infrastructure cannot route to compliant endpoints when jurisdictional requirements change. The ability to swap models without re-architecting the agent stack is a structural residency advantage, not a feature checkbox.

Continuous visibility at the runtime layer, not just at configuration time. That means:

• Execution traces with every tool call, every retrieval request, every sub-agent delegation, logged with jurisdiction metadata
• Runtime behavioral records that capture what the agent actually did, not what it was configured to do
• Audit trails that satisfy SEC Rule 17a-4, FINRA tamper-evidence requirements, and EU AI Act logging obligations simultaneously

Code-specific enforcement at the tool layer. Preventing source code from leaving infrastructure requires enforcement that doesn't depend on human approval at each step. Agentic tools operate without that approval, and policy compliance rates among developers are low enough that the math doesn't work in your favor.

Treating fine-tuned weights with the same residency discipline as training data. Where possible, prefer RAG over an in-country document store rather than fine-tuning on sensitive data. It avoids the weights-as-regulated-data complexity entirely.

How open, self-hosted agent infrastructure addresses these controls in practice

Closed, API-dependent agent platforms cannot satisfy the requirements described above. The organization doesn't control where execution happens or what the platform logs. That means trusting vendor documentation rather than verifying the behavior yourself. For a compliance use case, that's a structural problem.

Self-hosted, open-source agent infrastructure is the class of solution that actually meets these requirements. The reasons are structural:

• Execution stays inside the organization's own infrastructure. No cross-border transfer at the model, embedding, or context layer.
• The codebase is inspectable. Organizations can verify what data is logged, where it flows, and what sub-processors are involved.
• Deployment can happen anywhere the code lives: on-premise, in a specific sovereign cloud region, or air-gapped, matching the deployment to the jurisdictional requirement rather than to whatever regions the vendor happens to offer.

OpenHands, built by All Hands AI, is a concrete example of this approach. It is an open-source platform for AI coding agents. Organizations can inspect the full codebase, verify data handling behavior, and deploy within their own infrastructure. It is model-agnostic, meaning organizations choose their own inference endpoint — whether that is an on-premise model, a sovereign cloud provider, or a regionally appropriate API — without being locked into the platform's inference infrastructure. That flexibility is what makes compliant routing possible when jurisdictional requirements shift. It also means that when a new regulation lands in a market you care about, you're not waiting on a vendor's roadmap to respond.

The runtime visibility and guardrails that other tools treat as a vendor-controlled black box are, in an open-source deployment, something the organization can instrument, inspect, and own.

The compliance evidence regulators now expect is a runtime trajectory of each agent execution. Producing that artifact requires controlling the infrastructure where the execution happens. Governing what you can see, and owning what you need to see, are the operational requirements that follow.