Privacy and data residency for AI agents requires runtime evidence

At a glance

What this is: ARMO argues that AI agent residency compliance cannot be established from deployment configuration alone because inference-time tool calls, retrievals, and delegations reshape where personal data actually goes.

Why it matters: IAM, privacy, and security teams need runtime evidence because AI agents can move data across processors and jurisdictions in ways static controls and inventories will miss.

Context

Data residency for AI agents is a runtime governance problem, not just a deployment-location problem. Static region selection assumes deterministic transfer paths, but agents can call tools, retrieve from external corpora, and delegate work to sub-agents after deployment, which changes the actual flow of personal data.

That makes GDPR evidence hinge on the observed data trajectory: every personal-data field, every processor, every cross-border hop, and the legal basis attached to each step. The identity angle is real here because federated identities and delegated access can hide where data moves, even when the infrastructure appears region-bound.

Key questions

Q: What fails when AI agent residency is judged only by deployment region?

A: Deployment region fails because it describes where infrastructure sits, not where an agent actually sends or retrieves personal data during execution. Tool calls, retrievals, and delegations can create new transfers after deployment, so the real control gap is the missing runtime trail. Without that trail, teams cannot prove what data moved, who received it, or which legal basis applied.

Q: Why do AI agents create GDPR risk even in sovereign cloud environments?

A: Sovereign cloud reduces location risk, but it does not by itself prove what the agent did at inference time. If tool calls, retrievals, or delegation paths leave the protected boundary, the organisation still needs evidence of each hop, processor, and transfer mechanism. The risk comes from runtime behaviour, not just from where the storage account lives.

Q: How can security teams prove which personal data an AI agent processed?

A: They need a runtime-derived trajectory that records every external call, retrieval, and delegation, then ties each event to a processor, jurisdiction, and legal basis. A deployment manifest is not enough because it only shows intended design. The answer has to come from observed execution if the organisation wants defensible GDPR evidence.

Q: Should organisations treat AI agent data flows like traditional SaaS processing records?

A: No. Traditional SaaS records assume stable processing paths, while AI agents can change destinations and processors during inference. Organisations should treat each execution as an event that produces evidence, then roll those events up into records of processing and transfer documentation. That approach matches how agents actually behave and how regulators will assess accountability.

Technical breakdown

Why static region controls miss AI agent data flows

Static residency controls describe where infrastructure is placed, not how an AI agent behaves while processing a request. At inference time, the agent can choose a tool endpoint, retrieve from a remote store, or hand work to another agent, and each decision can create a new transfer event. That is why deployment manifests, DPA checklists, and region labels do not prove compliance on their own. The control boundary must move from location to observed execution, with the runtime path treated as the evidence object.

Practical implication: Treat region selection as an input to compliance, not the proof of compliance.

How tool calls, retrievals, and delegation create the residency gap

The article identifies three runtime boundaries: external tool calls, retrievals from replicated data sources, and sub-agent delegation across clusters. Tool calls can invoke processors not named in the original inventory. Retrievals can surface data from replicas in other jurisdictions. Delegation can move payloads through federated identities that preserve authorization but not region context. Together, these boundaries turn a single agent execution into a chain of transfers that static privacy tools cannot reconstruct after the fact.

Practical implication: Instrument each boundary so the organisation can trace where personal data actually moved.

Why runtime evidence is the only defensible GDPR record

Under GDPR, the relevant questions are no longer only what the system was configured to do, but what it actually did with personal data. Article 30 records of processing, Article 32 effectiveness checks, and Chapter V transfer controls all depend on observable processing, not just declared architecture. For AI agents, the runtime trajectory becomes the operative record because it ties each access to a processor, jurisdiction, and legal basis. Without that chain, the organisation has configuration evidence but not compliance evidence.

Practical implication: Build records of processing from observed agent executions, then reconcile them against the active processor registry.

Threat narrative

Attacker objective: The underlying objective is not theft in the classic sense but untraceable personal-data movement that weakens GDPR evidence, transfer accountability, and incident reconstruction.

1. Entry occurs when an AI agent invokes a tool, retrieves data, or delegates work at inference time across a boundary the deployment inventory did not declare.
2. Credentialed access then follows the federated or delegated identity path, which authorises the action but often carries no usable region signal.
3. Impact is a residency and accountability gap, because the organisation cannot reliably prove which personal-data hops, processors, and jurisdictions were involved in the execution.

Breaches seen in the wild

• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime evidence is becoming the real residency control for AI agents. Deployment location still matters, but it no longer answers the compliance question on its own. AI agents choose tools, retrieval sources, and delegate paths after deployment, which means the evidentiary unit is the execution trajectory, not the cluster. Practitioners should treat runtime traceability as the control that makes residency claims defensible.

The data trajectory is the right named concept for AI agent compliance. It captures every personal-data hop, every processor, every jurisdiction, and the legal basis at each step. That concept is more useful than generic "data flow" language because it ties privacy governance directly to observed agent behaviour and creates a clear audit object for DPO and security teams. Practitioners should model trajectories as first-class compliance artefacts.

Federated identity can hide residency risk when region context does not travel with the session. The article is right to separate authorization from geography, because an agent can be properly authenticated and still move data across boundaries the privacy team never approved. This is where identity governance intersects privacy governance: delegated access without jurisdictional telemetry is an evidence failure, not just an architecture quirk. Practitioners should bind identity, processor, and location metadata together at runtime.

Static privacy dashboards create a false sense of control in agentic environments. A sovereign cloud perimeter, a signed SCC, and a region-bound deployment can all be true while the agent still routes data elsewhere during execution. That is the governance gap this article exposes. Practitioners should shift assurance from configuration attestation to continuous runtime verification, because that is what regulators will ask to see.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Data trajectory management is emerging as the practical control plane for agentic privacy governance. Teams that only certify regions, clusters, or storage locations will keep missing the runtime decisions that actually move personal data across processors and jurisdictions.

AI agent programmes should expect privacy evidence to shift from point-in-time configuration reviews to continuous traceability. That means linking identity, processor registry, and execution telemetry before the first audit request arrives.

For practitioners

• Instrument the three runtime boundaries Capture tool calls, retrievals, and sub-agent delegations as discrete events so each personal-data hop can be reconstructed later.
• Build a runtime-derived records of processing view Continuously refresh the records of processing from observed executions and reconcile each processor and destination against the approved registry.
• Tag every hop with processor and jurisdiction metadata Attach processor identity, destination jurisdiction, and data scope to each agent execution so legal basis and transfer mechanism can be traced per step.
• Test whether breaches can be explained from runtime evidence Run one production agent through a traceability drill and confirm the team can answer who processed the data, where it went, and under which legal basis.

Key takeaways

• AI agents change residency from a deployment question into a runtime evidence problem because they can route personal data through tools, retrievers, and delegated agents after deployment.
• Static region selection, sovereign cloud branding, and signed transfer clauses do not by themselves prove what happened to personal data during inference.
• Security, privacy, and IAM teams need shared runtime telemetry so processor identity, jurisdiction, and legal basis can be reconstructed per agent execution.

Key terms

• Data Trajectory: The complete runtime path of a data item through an AI system, including tool calls, retrievals, delegations, processors, and cross-border hops. It is the most useful evidence unit when static deployment records no longer match how an agent actually behaves.
• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
• Records Of Processing Activities: A RoPA is the living inventory that records how personal data is processed, why it is processed, and which systems are involved. In mature programmes, it is evidence backed and continuously updated, not a spreadsheet assembled after the fact.
• Cross-Border Transfer: The movement of personal data from one jurisdiction to another, especially outside the EU or EEA. GDPR requires a valid transfer mechanism and supporting safeguards. In identity programmes, that means access, logging, encryption, and retention controls must all support the legal arrangement.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and agentic AI identity. It helps security and identity practitioners align runtime access decisions with governance that stands up to audit and incident response.