Operationalizing GDPR Lawful Basis and Consent Signals Across MCP Tool Invocations
Each tool call needs its own lawful basis check, not one blanket permission for the entire agent.
Every MCP tool invocation is its own act of processing under GDPR, and no single consent screen or system-level policy can cover what happens across thousands of calls. Lawful basis has to be checked, and a consent signal has to be attached, at the moment each tool fires, not once at setup. That requirement changes how an enterprise has to build its MCP layer, and it is the subject of everything that follows.
Every MCP Tool Invocation as a Discrete Act of Processing Under GDPR
An MCP server doesn't just pass requests through. It pulls context from multiple places, it lines up tool calls in sequence, and it often merges data from sources that were never meant to sit next to each other. That's the structural fact that sets this problem apart from ordinary application-level GDPR work: each invocation is its own act of processing, and each one needs its own legal justification under GDPR Articles 5 and 6.
Most teams building on MCP treat authorization and lawful basis as one question, but they are not the same thing. MCP's design conflates the two, and that gap is where compliance risk builds up quietly, call after call.
Spain's data protection authority, the AEPD, published a technical and legal framework addressing exactly where GDPR obligations arise inside AI agent deployments.
The "Grant Once, Run Forever" Credential Model and GDPR's Per-Purpose Requirement
Most MCP deployments today run on a simple consent pattern: a user approves a tool once, or clicks "Always Allow" and never sees the prompt again. That single click sets the user's immediate intent, but the agent goes on holding that authority across every future invocation, and the two stop matching once the context changes.
OAuth scope is built for a single moment: the grant. OAuth scope was never built to answer the second one, and treating it as if it does is the root of the problem.
The tool-level toggle only tracks the category of operation. It ignores the arguments passed into each call, and arguments are what GDPR's purpose limitation principle is built to track.
Write operations make this worse in three separate ways, and each one is a GDPR concern in its own right. Consent fatigue only deepens the problem: faced with repeated prompts, users fall back on durable tool-level permissions that quietly authorize everything the agent does afterward, which is the exact outcome per-invocation consent was supposed to prevent. All three issues trace back to the same record-keeping failure, and that's where the next section picks up, because it's what lets purpose drift happen unnoticed.
Purpose Drift and Sub-Processor Sprawl in a Live MCP Pipeline
Purpose drift is the failure mode you see most often in live MCP pipelines. Because agents can pull and recombine data from multiple contexts on the fly, pinning down one exact purpose for a given task, in advance, becomes close to impossible. That conflicts directly with Article 5's purpose limitation principle, which assumes you know the purpose before processing starts, not that you discover it along the way.
Bird & Bird's example lays this out clearly. None of those three new uses has a fresh lawful basis. None of them was disclosed to the candidate. The original task was narrow. The actual processing that happened was not, and nobody signed off on the difference.
This same dynamic appears at the session level. One agent session might pull CRM contacts, resumes from an applicant tracking system, and invoices from accounting, all inside a single prompt. The compliance surface is the context payload the agent assembles the moment it starts reasoning, not any one of those source databases on its own, and that payload is invisible to anyone looking only at the source systems.
Sub-processor sprawl runs along the same pipeline and multiplies the exposure. Every server that touches personal data between the original SaaS system and the language model becomes a sub-processor in its own right, so Data Processing Agreements and Transfer Impact Assessments pile up each time you add a new tool to the chain. Cross-border transfer risk follows the same logic: data can sit safely in Europe at rest and still get swept into a transfer under Chapter V of the GDPR (Article 44 in particular, with Article 46 governing safeguards where no adequacy decision applies) the moment a tool call routes through a model inference endpoint or external API hosted outside the EU. And the fallback many teams reach for, a blanket "legitimate interests" basis for the whole MCP deployment, doesn't hold up: the European Data Protection Board's 2024 guidance on legitimate interests requires a genuine necessity and balancing test for each use case, not a generic justification stretched across all of them. Once you can see purpose drift and sub-processor sprawl as concrete failure modes, you have to ask who answers for them.
Accountability for Ungoverned MCP Processing Falls on the Deploying Organization
The AEPD's position on this is direct: an AI agent, no matter how autonomous it appears in operation, remains a technical means through which processing is carried out, not an autonomous legal actor. That puts the compliance burden squarely on the deploying controller, regardless of how independently the agent seems to behave while it's running.
Think about what that means in a concrete case. "The agent did it" isn't a defense the AEPD's framing leaves any room for.
The Dutch Data Protection Authority made a similar point in early 2026: it warned that highly autonomous agents with broad system access carry serious security and data protection risks, and that the deploying organization stays fully accountable for those risks no matter how the agent was built or who sold it. Any MCP-connected system classified as high-risk under that regulation now carries both sets of obligations at once.
Multiple supervisory authorities landed on the same accountability framing within months of each other, in early 2026, so enforcement posture on agentic GDPR questions is settling into a consensus now, not still being worked out. For an enterprise, the practical consequence is blunt: if there's no audit trail showing a lawful basis was checked at the moment of processing, that's a compliance gap, full stop, because the organization has no way to demonstrate the check ever happened. That audit gap is exactly where the architecture has to change.
What enforcing lawful basis at invocation time actually requires architecturally
The context layer, the part of the system that decides what an agent actually sees before it starts reasoning, is where GDPR controls have to live.
Five obligations have to hold at once, on every single agent task, for an MCP deployment to be compliant: a documented lawful basis, minimization enforced before data ever reaches the model, a Data Protection Impact Assessment where the risk calls for one, an erasure path that actually reaches memory (not just source tables), and Article 22 safeguards on any decision made without a human in the loop. None of these can be checked off once at the system level and left alone. Each has to hold at the level of the individual task.
Minimization is the clearest case. Lawful basis follows the same logic: it has to be mapped at the level of agent task plus data category, including special category data under Article 9, not applied once to the agent as a whole and assumed to cover everything it ever does.
If an agent makes a decision without human involvement and that decision produces legal or similarly significant effects for someone, Article 22 safeguards apply. Approval gates are the engineering answer to that gap: not a UX nicety, but an authorization primitive in their own right.
Three Invocation-Level Authorization Patterns
Closing that gap means answering two separate questions that OAuth scope alone was never built to answer: can this agent call this tool, and should this specific invocation execute, with these arguments, right now. Three patterns have emerged to answer the second question, and each one covers a different part of the problem.
Pattern A is the pause-resume interrupt. The agent reaches a write operation, so the pending call gets serialized, an approval request goes out, and execution blocks until someone responds. Systems that queue the approval and only pull a credential at the moment of execution, rather than holding one in memory across the wait, avoid this failure. That queue-then-execute split is also what keeps approval latency from slowing down the agent's other work.
Pattern B is the dynamic authorization check. Policy evaluation runs at the moment a tool gets invoked, and if the policy flags the call as risky, it routes to human review. This pattern classifies every write operation as it happens and sends each one to either Pattern A or Pattern C depending on how it's scored.
Pattern C is the scope-escalation request: a mid-workflow prompt for additional scope, used when the agent runs into a boundary the original authorization never covered. None of these three patterns stands alone in a real deployment. They compose, with Pattern B typically acting as the classifier that decides whether a given call needs Pattern A's pause or Pattern C's re-consent.
Two research efforts map onto this framework directly. ConLeash (Li et al., arXiv:2605.11360, May 2026) formalizes Pattern B's classification step with a risk-lattice approach: each tool call gets abstracted into a structured consent boundary, calls that stay inside an already-authorized boundary get auto-permitted, and boundary crossings get escalated. Anumati (Kadaboina, arXiv:2604.16524) tackles the audit side that all three patterns share, drawing a formal line between proof of acceptance, a timestamped acknowledgment, and proof of adherence, a per-action reasoning record that cites the specific clause being evaluated. Neither of these is a deployed enterprise gateway. They're research prototypes that prove the patterns work, which raises the question of what it takes to run them in production.
Operationalizing These Patterns at Enterprise Scale with an MCP Gateway
If you run these patterns at scale, you need a dedicated control layer between AI agents and the MCP servers they call, enforcing policy at the moment of invocation, carrying identity and lawful basis information through each tool call, and generating an audit record in real time as processing happens.
MCP Manager, built by Usercentrics, is designed to serve as that control layer for enterprise MCP deployments. A few pieces of that design map directly onto the gaps covered above. Real-time observability into what an agent actually touched is what separates a safety net from a postmortem: a log written after an incident doesn't satisfy the accountability obligation Article 5(2) places on the controller at the moment processing happens, only a log written as it happens does. Governed adoption cuts down on shadow AI too: teams that have a sanctioned, working path to the MCP tools they need are less likely to route around the controls altogether, and that routing-around is the actual risk a strict blocking-by-default policy tends to create.
Scalekit AgentKit covers a narrower, specific piece of this picture: the credential-vault side of Pattern A. These examples show that the architectural requirements laid out earlier are buildable today, not just on paper in a research prototype.
Where the consent-signal problem remains unsolved even with a gateway in place
A gateway can enforce policy the moment a call fires, but it can't solve a deeper tension baked into agentic AI itself: the whole value of the system is its ability to pull in and combine data nobody anticipated in advance, and Article 5's purpose limitation principle assumes the purpose was known before processing started.
Erasure is broken in most deployed architectures today, and not in a small way. GDPR's right to erasure has to reach agent memory, embeddings, and logs, not just the rows in a source database, and most teams don't have a map of where personal data actually ends up once it passes through an agent's memory layer. Consent fatigue doesn't disappear with boundary-scoped escalation either: ConLeash's user study was run with a small group of participants, and whether progressive permission refinement holds up across a real enterprise population, with its full range of agent tasks, is still an open question nobody has tested at scale.
The underlying protocol doesn't help here. A gateway narrows that gap considerably, but closing it the rest of the way means making deliberate decisions about memory management, context scoping, and how erasure actually propagates through the system, decisions no product makes automatically on an organization's behalf.
Decisions a Complete Invocation-Time Governance Posture Requires
Everything above points to five decisions an organization has to make before an MCP deployment goes live, not after regulators or a breach force the issue.
Lawful basis has to be mapped at the level of agent task plus data category, not stated once as a blanket justification for the agent as a whole. The EDPB's 2024 guidance on legitimate interests calls for a documented, case-by-case three-step assessment, and nothing less satisfies it. Every MCP server in the deployment needs a registry entry tying it to an accountable identity, a stated purpose, and a lawful basis, because a server with no registry entry leaves a gap in the Article 30 records-of-processing obligation. And the path for erasure has to be defined before deployment, not improvised the day a data subject access request lands on someone's desk, because memory stores, vector embeddings, and invocation logs are all in scope under Article 17, and a plan that only covers source rows doesn't meet that bar.
These are decisions made once, deliberately, not recurring chores. Organizations that settle them before deployment move faster afterward, because ungoverned MCP access is what actually slows things down in the long run: the friction from regulators, legal review, and incident response after the fact costs far more time than building the governance layer in up front ever does.
