PrivacyPoint
In our last installment, we argued that the rush to deploy AI agents across the enterprise has outpaced the rush to govern them, and that privacy-by-design is the only viable path forward. This piece goes a layer deeper. Here, we examine the specific technical standard that is rapidly becoming the connective tissue between agents and the applications they act upon: the Model Context Protocol, or MCP. Understanding MCP is no longer optional for privacy professionals. It is about to become as fundamental to a modern privacy assessment as understanding a data processing agreement or a sub-processor list.
What MCP Actually Is
MCP is an open standard that defines how AI models and autonomous agents communicate with the external tools, applications, and data sources they need to do useful work. It offers a structured way for AI agents to access data, perform functions, and maintain context across applications.
In plainer terms, MCP solves a combinatorial problem that has been quietly throttling the agentic AI movement. Before the protocol existed, whenever a developer wanted to connect an agent to a new application, such as Salesforce, Gmail, a ticketing system, or an internal database, they had to write custom integration code. Each application had its own API, its own authentication scheme, its own vocabulary for describing what it could do. The result was bespoke plumbing at every junction: a hundred agents times a hundred tools equal ten thousand fragile and inconsistent integrations. MCP solves that problem by standardizing the "handshake." More specifically, the agent learns one common language, MCP. Any application that wants AI agents to use it sets up a small translation service called an MCP server that speaks the same language. Once both sides speak MCP, they can connect without either having been built specifically for the other. Before this kind of common standard existed, every connection had to be custom-built, one application at a time.
From Clicks to Intent
The deeper significance of MCP lies in the shift from users needing to learn the software's language to new intent-based interactions. For nearly four decades, software has required humans to translate their goals into sequences of clicks, menu selections, and keyboard shortcuts. MCP begins to remove that layer. Instead of navigating screens, the user states a goal in natural language, and the agent, via MCP, accesses the underlying applications and fulfills the intent directly. This is what privacy and technology vocabularies have come to call intent-based design: systems built to understand the user's true goal rather than merely react to literal commands. MCP is the plumbing that makes intent-based interaction possible at scale.
The Spotify Example
The most frequently cited consumer illustration of MCP in action is Spotify. The company has implemented an MCP server that provides core capabilities, such as music playback control, playlist creation, and song metadata retrieval, via a standardized protocol. When a user asks an AI assistant to "generate a playlist of upbeat jazz for a dinner party," the assistant does not need to be trained on Spotify's specific API. Instead, the assistant recognizes the user intent, identifies Spotify as the relevant capability, and issues a structured request through MCP. No clicks. No navigation. No knowledge of Spotify's interface required.
It is tempting to dismiss the Spotify case as a consumer novelty, but the underlying pattern is about to reshape the enterprise. Multiply the pattern across Salesforce, Workday, Jira, SharePoint, Outlook, a company's internal data lake, its expense system, its HR platform, and its customer support tooling, and the contours of the agentic future come into focus. For the privacy function, this transition is not a distant possibility. It is already beginning, and the governance questions it raises are arriving faster than most organizations are prepared to answer them.
The Double-Edged Sword
MCP is simultaneously the solution to one governance problem and the source of another. On the upside, MCP standardizes and therefore centralizes the points at which agents interact with enterprise data. An organization that routes all agent-to-application traffic through a well-governed set of MCP servers has, for the first time, a genuine chokepoint where authentication, authorization, logging, data minimization, and audit trails can be consistently enforced. Done well, MCP is the technical substrate on which privacy-by-design for agentic systems can finally be built.
The downside is a mirror image of the upside. Because MCP dramatically lowers the friction of connecting agents to data sources, agents will reach into more systems, more often, with less deliberation than before. What was previously a month-long integration project now takes an afternoon. And because the protocol enables context-aware orchestration, agents will increasingly make decisions by combining data streams that no individual privacy notice or impact assessment ever anticipated.
This aggregation effect is the risk that deserves the most attention. A customer's location data, considered alone, is one category of personal information subject to one set of rules. Their calendar, considered alone, is another. Their purchase history, their support ticket record, and their communication preferences are also governed, mapped, and retained under their own regime. But an agent that fluidly combines all of these through MCP, in real time, has created a new composite profile that is more sensitive than any of its components. The legal basis for processing the component parts does not automatically extend to the combination. The data subject's expectations almost certainly do not.
The Governance Response
The answer to this challenge is not to slow MCP adoption. That would be both futile and counterproductive. The answer is to treat every MCP server an organization deploys, and every MCP connection an agent establishes, as a discrete data processing activity that deserves the same rigor as any other integration. The questions are old ones applied to a new substrate:
- Who is the controller of the data flowing through the connection?
- What is the legal basis for each category of processing the agent will perform?
- What personal data categories actually traverse the link, and has that inventory been mapped and recorded?
- What retention and deletion rules apply — not just to the source systems, but to the agent's memory, the orchestration layer's logs, and any cached outputs?
- Is the connection read-only, or does it permit the agent to write back? If it writes, what guardrails prevent unauthorized actions, and how are those guardrails tested?
These questions map directly to the existing documentation obligations. A record of processing activities should reflect MCP-mediated flows with the same specificity as any other integration. A privacy impact assessment should be triggered whenever a new MCP connection introduces a novel processing activity, particularly one involving sensitive categories or automated decision-making. Transfer impact assessments apply whenever the agent or the MCP server transmits personal data across jurisdictional boundaries, which, given that most foundation model providers operate internationally, is nearly always.
What the Privacy Function Must Do Now
The practical implication is that privacy teams need to insert themselves into MCP governance before the connections proliferate. The window for doing this in an orderly way is open now, but it will not stay open long. Within the next twelve to eighteen months, MCP or a close successor will be as routine as OAuth tokens or REST calls. If privacy review is not built into the process at the point of first adoption, it will have to be retrofitted across a landscape of existing connections that already process personal data.
There are three concrete steps that privacy functions can take immediately. First, require that any new MCP server deployment be treated as a new integration and assessed accordingly. Second, extend the organization's ROPA template to explicitly capture MCP-mediated flows, including the agent identity, the MCP server endpoint, the data categories accessed, and the retention behavior of any logs or outputs the agent produces. Third, engage the AI and platform engineering teams now. A privacy team that shows up as a collaborator rather than a checkpoint will be far more effective than one that arrives after the fact with a list of concerns.
The Opportunity Inside the Risk
There is a version of this story that ends well. MCP, when properly governed, is not just a risk to manage but a genuine opportunity for the privacy function to expand its influence and demonstrate its value in the agentic era. An organization that builds its MCP infrastructure with privacy controls baked in, including granular authorization, server-level data minimization, immutable audit logs, and automated PIA triggers for new connections, will have a compliance posture that scales with its AI ambitions rather than lags behind them.
MCP is not the last protocol that will matter for privacy governance. But it is the one that matters most right now. The organizations that treat it as a governance moment rather than a technical footnote will be better positioned for whatever comes next.
PrivacyPoint helps organizations build the governance infrastructure to keep pace with emerging technology. If your organization is beginning to evaluate MCP adoption or AI agent deployment, our team can help you develop the assessment frameworks and ROPA templates you need. Contact us at privacypoint.ai/Contact.