GDPR and AI Agents: Data Ownership Doesn't Survive an A2A Handoff by Default

GDPR’s whole enforcement model rests on being able to name two roles for any personal data in play: who is the controller deciding why it’s processed, and who is the processor handling it on the controller’s instructions. Every downstream obligation — a data processing agreement, a lawful basis for an international transfer, a clean answer to a subject access request — depends on that pair of names staying attached to the data as it moves. An AI agent that delegates a subtask to a second agent over A2A can detach them in the space of one JSON-RPC call, because nothing in the protocol asks whether the receiving agent is even allowed to see what’s in the task payload.

The question a single agent already struggles with

Data ownership in agentic AI is hard enough with one agent and one credential: a support agent authenticated as a service account can technically reach every customer’s record, and nothing about a valid API key tells the receiving service whose data this particular call is supposed to touch. GDPR sharpens that same gap into a legal one. “Did this call belong to this data subject’s controller-authorized purpose” isn’t just a good architectural question under GDPR — it’s the question Article 5’s purpose-limitation principle and Article 6’s lawful-basis requirement are actually asking, on every single processing operation, not once at onboarding.

Most teams answer it for the first hop: the agent they built, running under a contract and a data processing agreement they signed. What they don’t have an answer for is the hop nobody put in the contract.

What changes the moment a second agent is in the loop

An A2A delegation is, from a GDPR standpoint, a decision to hand personal data to a new party — and the protocol makes that decision at runtime, based on which Agent Card looked like the right match for the task, not at design time, when a lawyer could have reviewed it.

• The receiving agent may be a different legal entity entirely. A scheduling agent delegating “find this customer a slot” to a third-party calendar agent has just handed that vendor personal data. If nobody signed a data processing agreement with that vendor, the controller has no lawful basis for the transfer the moment it happens — and the agent that triggered it has no way to know that’s what it just did.
• A cross-border hop can happen without anyone deciding it should. Agent Card discovery doesn’t check jurisdiction. An agent picking the best-fit tool for a task can route personal data to an agent hosted outside the EU as easily as one hosted next door, turning an ordinary delegation into an international transfer that needed its own safeguard — a standard contractual clause, an adequacy decision — that was never put in place.
• Sub-processing chains grow one hop at a time, past what anyone reviewed. GDPR’s chain of accountability assumes a controller knows its processors and each processor’s sub-processors. A multi-hop A2A chain can add a new sub-processor every time an agent decides to delegate further, with no step in that chain resembling the sub-processor approval GDPR Article 28 contemplates.

None of this requires anything going wrong in the security sense. Every hop can be authenticated, every credential correctly scoped, every call logged — and the data can still have moved somewhere the controller had no lawful basis to send it, because authentication answers who called, not whose data this was and who was allowed to receive it next.

Why the audit log has to answer a specific question

A subject access request or an erasure request under GDPR isn’t satisfied by “we have logs somewhere.” It has to be answerable as: which systems and parties received this person’s data, and can we now reach all of them to correct or delete it. An audit trail built for incident forensics that records “agent X called endpoint Y” is necessary but not sufficient — it has to resolve, for a specific data subject, into a list of every downstream agent that task payload actually reached, including hops the original developer never wrote code for and wouldn’t have thought to ask about.

That’s a different bar than most agent observability was built to clear. Tracing a request across A2A and MCP hops for debugging purposes only needs to reconstruct what happened for engineers. A GDPR-adequate trail needs to reconstruct it for a data subject’s rights, on demand, potentially years later, in a form that holds up as evidence rather than a best guess from scattered service logs.

What actually has to be true

• Personal data fields need to be a scoping dimension, not just an endpoint. Scoped credentials that limit an agent to specific endpoints don’t yet answer whether a specific field in the response is personal data that shouldn’t leave the controller’s processors. That’s a policy decision that has to be evaluated before a payload is handed to the next hop, not assumed away because the call itself was authorized.
• A delegation to a new party needs a lawful-basis check, not just an authentication check. An agent shouldn’t be free to route personal data to any agent that answers a capability query correctly. Whether the receiving party is a known, contracted processor has to be a gate the delegation can fail, the same way a missing scope fails a credential request.
• Cross-border hops need to be visible before they happen, not discoverable afterward in a log review. Jurisdiction is exactly the kind of fact that’s cheap to check at the broker and expensive to reconstruct after the fact from a chain of independently-hosted agents.
• The chain of custody needs to be reconstructable per data subject, not just per agent. An incident review asks “what did this agent do.” A subject access request asks “what happened to this person’s data” — a query the log has to support even though the person was never a field the system was tracking on purpose.

The business case: the broker is the one place that sees every hop

Fullmakt sits as the credential broker between every agent and every call it makes — which puts it in the one position that can actually see a delegation before the data leaves, rather than only after:

• Every A2A delegation flows through the same policy gate as every other brokered call. A hop to an unrecognized or uncontracted agent is something policy can block before the payload is sent, not something a compliance review discovers three months later in an access log.
• Scope can be defined in terms of what a call is allowed to carry, not just which endpoint it’s allowed to hit. That’s the difference between “this agent may call the scheduling API” and “this agent may hand this specific customer’s name and time zone to a scheduling agent, and nothing else in the record.”
• The tamper-evident audit trail already ties every call to an identity, a task, and a policy decision — extending that record to note which fields moved to which downstream party turns “can you show us where this person’s data went” from a forensic reconstruction into an export.
• Revoking a sub-processor’s access takes effect at the next call, not at the next contract renewal. When a vendor relationship ends, the broker is the single place that has to change for every agent that used to delegate to it to stop being able to.

This is the same shape of argument as the EU AI Act and ISO 42001 mapping: a broker doesn’t make an organization GDPR compliant on its own, but the specific slice of the problem — control what a call can carry, attribute it to an identity and a purpose, and keep a record that survives a real request — is exactly the slice that sits at the choke point every brokered call already passes through.

FAQ

Does GDPR apply to data inside an AI agent’s context window, or only to data in a database? GDPR’s definition of processing covers any operation performed on personal data, including data held or transmitted in an agent’s working context — where the data is stored technically doesn’t change whether it was processed.

Is delegating a task to another company’s AI agent over A2A the same as appointing a sub-processor? It can be, in substance, if personal data is part of what’s handed over — which is exactly why it needs the same review a sub-processor appointment gets, rather than happening automatically because an Agent Card matched the task.

Can a credential broker make our AI agents GDPR compliant by itself? No. It enforces and evidences one important slice — controlling and logging what data a call carries and who it goes to — but lawful basis, data processing agreements, and data subject rights processes are organizational and legal work a broker can’t do for you.

Does this only matter for agents operating in the EU? No — GDPR applies based on whose personal data is processed and where the controller or data subjects are, not where the agent infrastructure happens to run, so a delegation chain that never touches EU servers can still be in scope if it touches an EU data subject’s data.

How is this different from the data ownership problem in a single agent? The underlying question is the same — whose data is this, and does the current task justify touching it — but A2A adds a new party into the answer on every hop, at runtime, which a single-agent credential-scoping model was never built to evaluate.

The controller/processor line GDPR draws was built for a world where handing data to a new party was a decision someone made and documented. Agentic AI turns that decision into something an agent can make on its own, mid-task, by picking the best-matching tool for the next step. Keeping data ownership attached to the data as it crosses that hop takes a broker sitting at the point where the hop happens — not a policy document describing how hops are supposed to work.

Fullmakt is a credential broker, not a law firm or a data protection officer. This post is general information, not legal advice — validate any GDPR obligation, lawful basis, or transfer mechanism against the regulation and your own counsel.