TL;DR: AI data residency cannot be enforced by infrastructure alone because sensitive data can cross borders through prompts, retrieval, tool calls, and logs, according to Skyflow; the control model has to keep raw values in the home region while models and agents operate on tokens. That makes residency a runtime governance problem, not just a hosting decision.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Skyflow's blog post: AI data residency breaks down when prompts, retrieval, tool calls, and logs move sensitive data across jurisdictions.
Why it matters: IAM, NHI, and AI governance teams need a runtime control model because policy applied only at storage or infrastructure layers does not govern where sensitive data actually travels.
Context
AI residency is not the same as where a model is hosted. In practice, sensitive values can move through prompts, retrieval layers, tool calls, and logging paths even when the underlying deployment stays in one region.
The governance gap is that localisation rules are usually written for storage and infrastructure, while AI systems create a runtime data path that is harder to constrain. Where AI agents, tokens, and downstream tools are involved, that gap becomes an identity and access problem as much as a data problem.
Key questions
Q: How should security teams enforce data residency for AI systems?
A: Teams should enforce residency at runtime, not just at storage or infrastructure layers. That means mapping prompts, retrieval, tool calls, memory, and logs, then applying region-aware policy and tokenisation so raw sensitive data stays in its home jurisdiction while the AI workflow still functions.
Q: Why do AI agents create new data privacy risks?
A: AI agents can move data across tools and systems without a fixed human checkpoint, so they widen the number of places where sensitive information can be copied, transformed, or retained. Once those agents connect through MCP or other integrations, they become part of the identity and access plane, which requires explicit governance.
Q: When is tokenisation better than moving data into regional infrastructure?
A: Tokenisation is better when the business needs cross-border AI processing but must avoid exposing raw values outside a governed region. It lets models and agents operate on substitutes while the original data remains in controlled storage, reducing the number of systems that inherit residency obligations.
Q: What is the difference between data localisation and runtime sovereignty for AI?
A: Data localisation focuses on where data is stored or hosted. Runtime sovereignty focuses on how data behaves during inference, retrieval, logging, and tool use, which is where many AI residency failures actually occur.
Technical breakdown
Why AI prompts and tool calls break traditional residency assumptions
Residency controls often assume data stays where it is stored, but AI workflows fragment that assumption. A prompt may contain regulated content, retrieval can rehydrate sensitive values from another system, and tool calls can forward those values to external services or plugins. Logs then create a secondary copy of the same content, often outside the original policy boundary. The real issue is not whether one component is compliant in isolation, but whether the full request path preserves jurisdictional control from input to output. Runtime policy has to follow the data, not just the host environment.
Practical implication: Map every AI request path end to end and treat prompts, retrieval, tools, and logs as separate residency enforcement points.
Why tokenisation matters for AI governance across jurisdictions
Tokenisation replaces sensitive values with non-sensitive substitutes that can be processed without exposing the original data. In AI systems, that allows models and agents to operate on reference values while raw records remain in a governed home region. This matters because residency failures often happen when a downstream system receives more data than it needs for inference or action. Tokenisation does not solve governance by itself, but it narrows the data boundary and makes policy enforcement simpler across borders, vendors, and workloads. It is strongest when paired with clear detokenisation controls and locality rules. See the Data Retention and Secure Deletion Guide.
Practical implication: Use tokenisation to keep raw sensitive data in-region and restrict detokenisation to tightly governed services.
How AI agents change the residency and access-control problem
AI agents can turn residency from a static hosting issue into a dynamic access problem. An agent may request data, pass it to a tool, and persist intermediate state in a log or memory store without human review. That creates a non-human identity pattern: the agent becomes a runtime actor that can move sensitive data across policy boundaries faster than manual governance can inspect it. In that setting, access scope, data minimisation, and logging controls have to be designed for machine-paced actions, not human workflows. The issue is not only where data sits, but what the agent is permitted to touch and export. See the Generative AI Data Loss Prevention Guide.
Practical implication: Govern agents as non-human identities with scoped data access, not as generic application processes.
NHI Mgmt Group analysis
AI residency is becoming a control-plane problem, not a hosting problem. The article’s core point is that jurisdictional control fails when policy only follows infrastructure. Prompts, retrieval, tool calls, and logs create multiple data movement points that can cross borders even when the model itself does not. Practitioners should treat residency as an end-to-end governance path, not a deployment label.
Tokenisation is the practical bridge between compliance intent and AI scale. Keeping raw values in the home region while models and agents operate on tokens reduces the number of systems that ever see regulated data. That does not remove accountability, but it makes cross-border processing easier to contain and audit. For identity programmes, the same logic applies to secrets and sensitive attributes that should never leave their governed domain.
Runtime data sovereignty: the key concept here is that policy must govern data while it is being used, not just where it is stored. AI systems make this unavoidable because they assemble answers from transient retrieval, tool use, and memory state. The practical conclusion is that sovereignty controls need runtime enforcement, not just regional hosting decisions.
AI agents introduce a non-human identity dimension to sovereignty. Once an agent can independently select tools and move data between systems, the question becomes who or what is authorised to transfer that data and under which policy. That brings AI governance into the same conversation as NHI governance, especially where tokens, logs, and tool permissions can leak beyond the intended jurisdiction. Practitioners should design access and localisation together, not as separate programmes.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: Data Retention and Secure Deletion Guide
What this signals
Runtime sovereignty: AI programmes need controls that follow data through inference, retrieval, tool use, and logging, because static regional hosting does not govern the full lifecycle. That is why residency and identity governance are converging around the same runtime enforcement problem.
The practical next step for most teams is to shrink the number of places that ever see raw data. Tokens, scoped agent permissions, and locality-aware logging reduce the blast radius when AI workflows span multiple jurisdictions and multiple vendors.
For practitioners
- Map the full AI data path Trace where sensitive values enter, transform, and leave the system across prompts, retrieval, tool calls, memory, and logs. Identify every point where data could cross a jurisdictional boundary or be duplicated outside the intended region.
- Tokenise sensitive values before model use Replace raw personal or regulated data with tokens before it reaches models or agents, and keep detokenisation in tightly governed services located in the home region.
- Treat AI agents as non-human identities Assign scoped permissions to agents, limit which data sources they can query, and review whether their tool access allows unsanctioned cross-border movement of sensitive values.
- Separate logging from governed content Reduce or redact prompts, retrieval payloads, and tool outputs in logs so that audit data does not become a second residency problem.
Key takeaways
- AI residency fails when teams rely on infrastructure location alone and ignore how data moves through prompts, tools, retrieval, and logs.
- Tokenisation is the clearest control for keeping raw sensitive values in-region while still allowing AI systems to operate across jurisdictions.
- AI agents turn sovereignty into an access problem, which means identity, scope, and logging controls have to be designed together.
Related NHI Mgmt Group resources: Data Retention and Secure Deletion Guide · Generative AI Data Loss Prevention Guide · Top 10 Shadow AI Risks
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governance for AI data movement across jurisdictions. |
| Recommendation — Establish AI governance rules that define who can move sensitive data across regions and under what controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI agents need scoped permissions to limit data movement and cross-border access. |
| Recommendation — Limit agent and service permissions to the minimum data paths required for each workflow. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central when agents and tools can access sensitive data across systems. |
| Recommendation — Apply least privilege to model-adjacent services, retrieval systems, and tool integrations. | ||
| CSA Cloud Controls Matrix | DSP — Data Security & Privacy | The subject is regional control of sensitive data in cloud AI workflows. |
| Recommendation — Use DSP controls to classify, limit, and monitor sensitive data flows in AI pipelines. | ||
Key terms
- Runtime Data Sovereignty: Runtime data sovereignty is the practice of controlling where sensitive data can travel while it is being processed, not only where it is stored. In AI systems, that means governing prompts, retrieval, tool calls, memory, and logs so jurisdictional rules still hold during inference and action.
- Tokenisation: Tokenisation replaces a sensitive value with a non-sensitive substitute that preserves workflow utility without revealing the original data. It is useful when systems need to process or display records while keeping direct personal identifiers out of normal operating paths.
- AI Data Residency: AI data residency is the requirement that certain data remain within a defined jurisdiction or region. The practical challenge is that AI workflows can duplicate or forward that data through multiple layers, so residency must be enforced across the full runtime path.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps practitioners connect identity controls to the broader security and data governance decisions their programmes already make.
Published by the NHIMG editorial team on October 27, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org