AI Agents and Memory: Privacy and Power in the Model Context Protocol (MCP) Era

ChatGPT can answer your questions, but imagine if, someday soon, it could renew your driver’s license. That might sound like a minor difference, but moving from a chatbot responding to prompts to an AI agent acting on our behalf would require a major leap in data access and memory standards. In order to process a license renewal, an AI agent might need to fill out an application, schedule a test date, and file for a disability placard or income fee waiver. Doing so requires accessing your personal information, calendar, medical records, and bank statements, and holding that data as it moves between apps.

This could one day save time and stress—if it works as intended. But these potential efficiencies may also introduce new dependencies and risks we don’t fully understand. The AI agent could have easily submitted an outdated medical record, disqualifying you from your benefits and locking you out of public services without explanation.

This shift from chatbot to autonomous agent is underway in business and consumer applications. In the latter category, OpenAI recently released its consumer-facing “Agent” model, while Anthropic unveiled a directory of Claude “connectors.” These systems are built on a new technical standard called the Model Context Protocol (MCP), which allows AI systems to connect to external tools like calendars, email, and file storage. Think of MCP as a universal plug, like USB-C, that makes chatbots interoperable across digital ecosystems. By standardizing these connections, MCP enables memory and context to move seamlessly from one app to another. Most users won’t hear or know about MCP, but it’s the invisible infrastructure that makes agents possible.

Silicon Valley is betting on the future of agents and MCP, but reliability, security, and readiness remain open questions. On one hand, current consumer applications are fragile, with an OpenAI employee noting it took a full hour for an agent to place a cupcake order. Yet, at the same time, CEOs cite agents as justification for major workforce reductions, and security experts worry about the ability of agents to break encrypted privacy guarantees.

That’s why now is the time—before agents become widely adopted—for evidence building and nuanced cost-benefit analysis. To be most effective, this conversation should center around the dual nature of these technologies: An agent can be used to uncover complex cybersecurity vulnerabilities, but that same agent can just as easily be used to automate zero-day attacks.

Because memory is federated and persistent, traditional privacy frameworks built around app-specific data silos no longer apply cleanly. In this early stage, the priority is not racing to deploy but learning enough to govern well—treating these systems as experiences in need of evidence, not inevitabilities.

This brief examines how agents and MCP work, where risks emerge, and why current guardrails fall short. It proposes targeted interventions to ensure that the systems remain understandable, accountable, and aligned with the people they serve. Finally, it examines how existing privacy frameworks map onto this new architecture and identifies where we may need new interpretations or protections.

What Is an AI Agent?

AI agents are built atop traditional large language models (LLMs) like ChatGPT or Claude. Unlike a chatbot that simply responds to a single query, an agent is coordinated by an orchestrator that plans tasks, uses external tools, and then sequences steps to accomplish a goal. These connections are enabled through application programming interfaces (APIs) and increasingly standardized by the model context protocol (MCP), which makes plug-and-play autonomy possible. To work effectively, agents also rely on memory to carry context across sessions, authentication credentials to securely interact with external systems, and a persistent agent profile that allows them to remember users across time. If a chatbot is like a copilot for a single task, then an agent is more like an autopilot managing multi-step workflows with minimal oversight.

The Anatomy of an Agent

This architecture illustrates why governance is more complex for agents than traditional AI systems, making these core components important for policymakers to understand.

• Large Language Model (LLM): acts as the reasoning engine, interpreting language and generating responses.
• Orchestrator: serves as the agent’s “brain.” It interprets instructions, plans tasks, decides which tools to use, and sequences steps to accomplish a goal.
• External Tools: applications and services the agent connects to, such as calendars, email, databases, or financial systems.
• APIs: define which actions are available, like creating a calendar event, uploading a file, or searching a database.
• Model Context Protocol (MCP): provides standardized coordination that allows agents to dynamically discover and connect to external tools through a universal interface. MCP builds on top of APIs and makes plug-and-play autonomy possible.
• Memory: enables agents to retain context across sessions, tools, and platforms. MCP extends this capacity beyond local storage, raising new governance challenges around persistence and distribution.
• Authentication: gives agents temporary credentials or tokens to log into external services. This process determines where encryption ends and trusted access begins.
• Persistent Agent Profile: maintains a user-linked identity across sessions, allowing for personalization and continuity, and shifts how memory, consent, and control are managed.

Terminology: Two Meanings of MCP

There are two distinct uses of the acronym “MCP.” This brief uses the term to refer to model context protocol, the technical standard governing how agents interface with external tools. Some developers, though, also use MCP to refer to a multi-capability platform, which means the full range of tools and knowledge sources available to an agent. For clarity, this brief uses MCP only in the protocol sense.

MCP as Infrastructure

MCP is not a model or an application—it’s a protocol. Analogies can help to clarify this role:

• Like USB-C, it standardizes how a diverse set of systems can plug into one another.
• Like HTTPS, it offers a consistent coordination layer.
• Like TCP/IP, it serves as infrastructure, routing actions, and information among services.

Each analogy highlights MCP’s dual role: It confers convenience and interoperability but also concentrates control over how agents connect and operate. While adjacent standards like agent-to-agent (A2A) and agent capability protocol (ACP) have tried to take shape, MCP remains the most established and impactful today, making it the most urgent focus for governance.

The Shift in Memory: From Local to Persistent and Distributed

Applications have traditionally stored user data locally, meaning it stays within a single app. But AI agents, especially those using MCP, allow data to be stored long-term across multiple tools, devices, and sessions. Imagine an agent booking a doctor’s appointment. It remembers your preference for morning slots (from your calendar), preferred transit (from a navigation app), and insurance information (from a health care app). Through MCP, the agent can accomplish all of this without needing to prompt the user.

MCP-enabled memory raises key user questions: Can users limit or edit what’s remembered? Which services have access to what information? Who is responsible for securing shared memory across tools?

Deployment Types

AI agents appear in three broad contexts:

• Personal Agents: Embedded in consumer apps—like calendars, travel planners, or finance bots—these agents handle lightweight tasks but can still handle sensitive data once linked across services.
• Workplace Agents: Integrated into enterprise workflows—such as IT ticketing, procurement, or contract drafting—these agents raise concerns around employee consent, auditability, and liability in regulated domains.
• Infrastructure Agents: Deployed in system-level contexts like transportation or public benefits, these agents pose cascading risks; failures or biases in one domain—routing data, eligibility determinations—can multiply across interdependent systems.

Whether agents serve individuals, firms, or public systems, their behavior is ultimately constrained by the protocols that govern what they can access and do—and it all begins with MCP.

From chat-based schedulers to procurement assistants and infrastructure monitors, new deployments of AI agents bring risks that are often misunderstood by users and policymakers. Evaluating those risks requires asking who the agent actually serves—the user, the developer, or the platform?

Commercial Use of MCP: From Early Adoption to A-Commerce

While agentic AI remains in early development, companies have begun deploying MCP-enabled systems in the wild. One example is Google’s public MCP server for Maps, which has a range of capabilities: converting addresses to coordinates, retrieving place information, calculating travel time and elevation, and offering directions. This kind of plug-and-play functionality, enabled by MCP’s client/server architecture, offers a glimpse of how agents can perform multi-step real-world tasks without custom integrations.

Retailers and financial platforms are also investing in agent-mediated commerce. Walmart’s CTO has noted plans to develop agents that communicate directly with customer agents—exchanging product preferences, issuing recommendations, and automating transactions. The goal is to move beyond static web interfaces and into dynamic, personalized negotiations among autonomous systems. In this vision of “a-commerce,” organizations may still support basic APIs for simple tasks like subscriptions, but will rely on MCP to handle complex use cases like fraud response, fulfillment optimization, and tailored upselling.

What would make “a-commerce” different is that instead of transactions being initiated through web clicks, a user’s agent might send a bundle of data containing verified credentials, payment methods, loyalty memberships, and budget constraints—allowing retail or travel agents to respond dynamically in return. This would mark a real economic shift where autonomous agents spend on a user’s behalf.

Common Misconceptions and Design Tradeoffs

Even as agents and MCP develop, headlines have fed a hype cycle around the technology, and many stakeholders may misunderstand certain aspects of how agents function.

Misconception 1: AI Memory Is Shallow and Harmless

Most users assume agents remember what’s helpful and forget the rest. In practice, memory is often fragmentary, persistent, and invisible. Agents may carry over personal details like purchase history, tone, or prior instructions without making them visible to the user. This can warp how agents represent identity and context over time, creating tradeoffs between convenience and risks to privacy, consent, and accountability.

Misconception 2: Human-in-the-Loop (HITL) Oversight Is Always a Safety Net

In high-speed or high-complexity environments, human intervention is not always possible. Take autonomous vehicles, where events can unfold faster than humans can react. A blanket HITL requirement risks creating a false sense of safety, legitimizing flawed systems without fixing them. Even when intervention is possible, it often isn’t helpful—if an AI agent’s decision-making process isn’t transparent, humans have no way to understand what went wrong or how to correct it. Without clear insight into how decisions are made, human oversight can’t prevent mistakes; it can only watch them happen.

Misconception 3: The U.S. Will Set Agent Governance Standards in Isolation

While the U.S. debates oversight, the EU and China are already advancing frameworks that will shape global norms. The EU’s AI Act requires risk assessments for AI systems that interact with humans, and China’s algorithmic rules mandate transparency and user consent. U.S. firms face a tradeoff: Absent leadership, American values on privacy and democratic oversight may be sidelined on the world stage while compliance burdens grow abroad. Agent governance is becoming a factor in global competitiveness.

Misconception 4: All Agents Are Equally Autonomous

The term “AI agent” currently covers a wide range of systems, many of which differ dramatically in complexity. At the low end are tool-use models—chatbots connected to a single API, that work as a search-augmented language model or an email filter that routes and drafts simple replies. The next level is orchestration agents, which coordinate across multiple tools and apps, like Siri in Apple Intelligence or agents that manage both calendars and inboxes. And at the far end are agentic systems, with broad permissions to act across a user’s digital environment, negotiate with other agents, and execute open-ended tasks that touch multiple domains.

While the ambition behind AI continues to grow, the delivery remains uneven. Some systems focus on narrow, automatable tasks, while others aim for socially transformational applications. Across this spectrum, it is still unclear which functions will gain meaningful public traction or how users will adapt to agent-led interactions.

Early deployments have shown promise in areas like research synthesis, presentation drafting, and workflow coordination. Yet many remain brittle, slow, or difficult to trust—less like autonomous copilots, and more like high-maintenance interns. This uneven capability landscape is incredibly important: It makes this moment an opportunity to shape how agentic systems evolve before orchestration becomes an overly entrenched layer of digital infrastructure.

AI agents and orchestration protocols like MCP raise new governance challenges. Many current privacy and governance frameworks already apply to today’s lower-risk agent uses, like in customer support or supply chain automation, and should remain the starting point for oversight. But, as agents evolve toward persistent, cross-service memory, they may strain existing laws and create uncertainty. The challenge is less that agents will fall outside the law, and more that existing safeguards will break down when AI systems connect across multiple services and share information automatically, making it unclear who controls the data or how it’s being used.

Privacy

From App-Based Memory to Infrastructure-Level Memory

Modern privacy frameworks were built for an earlier generation of software where data was meant to be stored locally: Information stayed within a single app, memory was temporary, and interactions were discrete. Of course, even in that era, cloud storage, APIs, and third-party vendors complicated the picture—data didn’t always remain truly siloed. The prevailing model assumed services controlled their own memory and that cross-context sharing was the exception.

MCP could upend this structure entirely, as it makes memory distributed, persistent, and interoperable. AI agents can access multiple tools and services in real time, retain memory across sessions, and infer patterns over time without direct user input. Crucially, they can carry user data from one context to another without prompting or transparency. Memory becomes its own infrastructure layer spanning multiple services—increasingly invisible to the user.

Consider a user who asks an AI assistant to find a physical therapist. That preference is remembered. Later, while applying for disability accommodations, the agent automatically references that previous request to recommend insurance coverage. This information lived across scheduling, mapping, and health care tools, but the agent accessed it all simultaneously, without user direction.

New Categories of Privacy Risk

• Opacity: Users can no longer track what their agent “knows” or where that knowledge lives. Even if permissions were originally granted, the lack of interface-level memory visibility makes it impossible to review, edit, or revoke.
• Cross-Service Leakage: Services may gain access to information they were never designed to handle. An agent might infer a user’s health status from a calendar entry and pass that along to a completely unrelated tool, accidentally exposing sensitive information or enabling new uses the user never intended.
• Behavioral and Emotional Influence: Beyond remembering facts, agents may also infer and store patterns about mood, stress, and decision-making. A system might detect that a user spends more impulsively when their calendar is overbooked or that certain email tones correlate with anxiety. These emotional inferences are a form of sensitive personal data. Treating emotional states as personalized data creates strong incentives to monetize or exploit them, extending the kinds of privacy harms seen in social media into the agentic AI context.

Looking ahead, these dynamics could implicate “cognitive autonomy,” as agents expand the implications of influence by using personal data in persistent, relational ways. Some scholars have warned that what begins as an individual privacy concern could metastasize into a challenge for democratic resilience, as manipulation of beliefs and behaviors compounds across societies.

Legal Frameworks Are Strained

• Consent: Traditional consent models were already criticized as little more than click-through exercises. But at least in the app-based era, users interacted directly with the services requesting the data. MCP changes that. A single prompt can now trigger a cascade of actions across dozens of services, none of which the user authorizes or sees. Without mechanisms for disclosure or interface-level accountability, consent becomes diffuse and even more hollow.
• Purpose Limitation: Privacy frameworks such as the GDPR require that data be used only for specific, clearly defined purposes. By contrast, AI agents are designed to recombine data dynamically to meet user intent. This orchestration across contexts makes it nearly impossible to predefine purposes.
• Data Minimization: Legal principles of minimization require that only the data necessary for a given function is collected and retained. Yet AI agents depend on persistent, cross-service context to operate effectively. Because MCP distributes memory across tools, even identifying collected data is a challenge. As a result, auditing or enforcing minimization requirements becomes increasingly difficult.
• Cross-Border Complexity: A single agentic task may draw on services hosted in multiple jurisdictions. An agent may combine a medical scheduler in the U.S., health records stored in the EU, and a messaging app in Asia. Privacy laws emanate from geographies; agents do not. This mismatch exposes regulatory gaps that no single legal framework can adequately address. Recent analysis of the EU AI Act underscores this strain, noting that agents’ autonomy and tool access create system risks that current classifications and safeguards may not capture.

These developments do not merely create new risks. They challenge certain foundational assumptions in privacy law: Users can meaningfully consent, purposes can be specified in advance, data collection can be minimized, and processing can be bounded within a legal jurisdiction.

Security

Lack of Identity and Access Standards

MCP currently lacks a standardized method for authenticating agents or delegating access to external APIs—a critical gap in banking, health care, and enterprise systems. Without reliable identity protocols, agents cannot verify each other’s legitimacy or establish secure trust boundaries. This raises the risk of impersonation, unauthorized use of sensitive data, and circumvention of existing security policies. One emerging proposal to address this is the development of Know-Your-Agent (KYA) requirements, akin to Know-Your-Customer requirements in finance, designed to validate agent credentials without over-centralizing control.

Equally important: MCP lacks a layer of security for intermediate permissions. Today’s systems tend to offer binary access: either full delegation with sweeping authority or none at all. The lack of support for scoped, context-aware permissions leaves users stuck between oversharing and underutilization—forced to grant broad access to untrusted agents or to deny access and lose functionality.

End-To-End Encryption Is Challenged

End-to-end encryption protects data in transit, but once data is handed to an agent, encryption ends. To summarize, infer, or act on the content, the agent must access it in plaintext. This shifts the trust boundary from the user’s device to the orchestration layer, which can lack strong transparency or auditability. Even secure messaging apps can’t shield you here: Once decrypted, your data becomes legible to any agent plugged into the orchestration layer.

Because MCP enables persistent memory across tools and time, even small vulnerabilities can have system-wide consequences. A weak point in one service may expose memory pulled from others. And even where visibility exists today, research suggests that agent reasoning traces, such as chain-of-thought outputs, may become less monitorable over time as models optimize for outcomes rather than transparency, further weakening audit and oversight.

Prompt Injection and Agent Hijacking

New security risks emerge when memory persists across sessions. In one 2024 incident known as Echoleak, a prompt hidden in an email caused an agent to leak private information from prior conversations. This happened because the agent treated the new user prompt and old memories as the same context. Without session isolation, malicious actors can trick agents into exposing sensitive content. As memory becomes more integrated, defending against these attacks becomes significantly harder.

Cascading Failures and Interdependent Tools

When agents coordinate multi-step tasks across services, a small error in one tool, like a misinterpreted time zone, can ripple through the entire chain, wasting time, money, or triggering unintended consequences. And each tool sees only a narrow part of the workflow. What was once a contained problem that could be identified now becomes hidden and exponential.

Orchestration as the Attack Surface

Current security frameworks focus on endpoint protections and model behavior, but in agentic systems, the orchestration layer itself has become a new point of vulnerability. MCP turns memory and coordination into shared infrastructure, yet there are no standards governing how memory is stored, segmented, or reused. Without clear guardrails, providers often optimize for speed over safety. This would be especially concerning if agents were deployed in critical infrastructure such as energy grids, transportation systems, and public services, where a single compromised tool could trigger cascading real-world harms.

Recent incidents have highlighted how this infrastructure layer can be exploited. In tool poisoning attacks (TPA), malicious instructions are embedded in tool metadata, visible to the model but invisible to the user. These can redirect agent behavior, hijack trusted servers, or silently ingest unauthorized actions. In some cases, even invisible Unicode characters have been used to manipulate agent reasoning. These risks make one thing clear: Orchestration protocols are not neutral plumbing. They are a live attack surface and must be governed as such.

Power, Openness, and Competition

As outlined in preceding sections, orchestration protocols like MCP govern access, integration, and control. The design choices baked into these systems determine which services are compatible, who gets priority, and how data flows between tools. Done right, MCP could lower switching costs and further open AI ecosystems. Done wrong, it entrenches incumbents under the guise of interoperability.

The New Moat: Context

As foundational models begin to converge in performance, the competitive edge is shifting to context. Agents rely on memory, preferences, documents, tone, and task history to perform effectively. This creates a “context flywheel”: the more context an agent collects and the more personalized it becomes, the harder it is to leave. This mirrors recent warnings that context, not model performance, is the true source of monopoly power.

MCP can make agents technically portable, but without proper portability of context, interoperability alone doesn’t dismantle this moat. Instead, it could entrench a few powerful incumbents like Microsoft, OpenAI, or Google, giving them leverage as agents orchestrate services while enclosing user data—consolidating power rather than leveling the field.

How MCP Can Help

With the right policies, MCP can be a counterweight. By standardizing how agents interact with tools and data, it can enable portability as well as interoperability. In principle, an MCP-enabled agent should be able to move across apps, retain memory across environments, and even switch model providers securely without losing accumulated context. Much like HTTP and SMTP helped build an open web and interoperable email, MCP could prevent AI ecosystems from devolving into closed silos—but only if context remains portable.

Protocols Alone Aren’t Enough

Interoperability only works if the surrounding platforms remain accessible. Already, companies are restricting API access, limiting behavioral data sharing, and giving their own agents privileged integrations. Weak permissions and unsegmented memory create security risks and tilt the market toward incumbents. Without enforceable portability, MCP could recreate the very chokepoints it was meant to solve.

The Path Forward

To fulfill its promise, MCP must support not just technical interoperability, but economic interoperability—ensuring that context and memory remain portable rather than becoming proprietary moats. Policy interventions around API access, memory portability, and personalization standards will be key.

This is the essence of what some have called “open intersections,” ensuring user data is portable so personalization doesn’t harden into a proprietary moat. Equally important, openness must extend to who the agent serves. Users should be able to choose agents that act on their behalf, not the platform’s. That requires duties of care and loyalty, backed by portable memory, so switching providers doesn’t mean starting over.

Traditional antitrust and competition tools are not well suited to this kind of infrastructural control. Left unchecked, the connective tissue of agents could become the next mechanism of platform dominance.

If agent systems continue evolving toward infrastructure, user protections should develop in parallel—built into experimentation, not added after deployment. There have been important early strides in developer-side governance like frameworks for connector permissions, prompt-injection defenses, and human-in-the-loop safeguards. But users still lack necessary visibility into what agents remember, the ability to port memory across services, and independent governance of protocols like MCP.

This section offers high-level, directional recommendations to address governance gaps in privacy, security, and power. They should be paired with detailed research efforts to understand the scope of governance problems and opportunities that agents pose. These recommendations assume a level of adoption and compliance that is not guaranteed—platforms may resist or co-opt standards, and policymakers may lack the capacity or political will to ensure meaningful compliance. With adoption and enforcement uncertain, governance is not the province of a single actor. At this early stage, we instead outline priority areas that require engagement from regulators (FTC, NTIA, NIST, CISA), companies and app developers, and civil society and academic experts.

The recommendations are presented in a deliberate order, reflecting both feasibility and logical sequencing. Some issues, like portability, are both urgent and achievable today—but portability alone cannot solve the problem if the data being moved is opaque or insecure. That’s why transparency and user control come first. Infrastructure safeguards then provide the structural baseline, followed by portability and inclusive access to sustain long-term fairness, competition, and equity.

1. Foundational User Protections

The first step is to give users meaningful visibility and control over how memory functions inside agent systems. Without transparency, portability becomes symbolic—users can “move” their data but remain blind to what has been collected or how it is used.

AI companies and developers should provide:

• Plain-language authorization disclosures when linking agents to external services, clearly explaining what data will be accessed, where encryption may be broken, and what safeguards apply.
• Interoperable memory dashboards that allow users to view, edit, or delete stored information across services.
• Default retention limits for sensitive memory categories (health, finance), with clear opt-in extension mechanisms.
• “Memory-free” modes in high-stakes settings such as health care, law, and government services.

Both developers and government agencies should develop:

• Updated consent frameworks, requiring multi-service disclosure standards that reflect agent-driven orchestration.

Together, these interventions would anchor a baseline of user visibility and control, ensuring that agents serve the people who rely on them rather than the platforms that build them.

2. Infrastructure Safeguards

Transparency alone is not enough. Because MCP breaks end-to-end encryption and recombines data across services, orchestration itself requires a data protection baseline. Persistent memory and multi-step orchestration create opportunities for exploitation that demand new safeguards. And because MCP increasingly functions as shared infrastructure, it must be governed like one.

Priority actions for AI companies and app developers include:

• Orchestration-layer data protection: Minimize plaintext exposure (secure enclaves, short-lived keys), compartmentalize memory by default (per-user, per-session, per-tool), and link purpose to data through tags verified each time data is accessed.
• System-level security and traceability: Develop cryptographically signed action logs and accessible audit trails; require plain-language rationales for actions in regulated contexts (public benefits decisions, financial recommendations); issue NIST-led guidance for MCP-level security controls, including memory isolation, prompt sanitization, and inter-agent authentication; and encourage embedded policy decision points (PDPs) to enforce permissions without required centralized chokepoints.

Federal agencies (regulatory and non-regulatory) must pursue:

• Governance of MCP as infrastructure: Federal agencies must recognize orchestration as critical coordination infrastructure, employ interagency coordination (OSTP, NIST, OMB, CISA) to develop baseline standards, establish nondiscrimination rules for third-party service integration, and create a registry or standards body—including ecosystem transparency tools such as the MCP Registry—to ensure open participation and forward compatibility.

These measures establish structural accountability, making agents traceable, orchestration transparent, and MCP itself governed as it develops into digital connective tissue.

3. Long-Term Fairness and Inclusion

Once transparency and structural safeguards are in place, the next priority is to prevent memory from concentrating power and ensure systems remain usable and contestable. The good news is that portability may be easier to implement with AI than with previous technologies, but it will only succeed if paired with trust frameworks for secure, responsible data transfers.

In the near term, companies and app developers should pursue the following priorities, which over time should be incentivized and enforced by legislators and regulators:

• Memory portability and anti-lock in: Require MCP-compatible memory systems that let users transfer their agent history across platforms with explicit, revocable consent. Embed strong security protocols (end-to-end encryption, topic-level permissions that are granular and revocable), and establish accreditation for trusted third parties to access shared memory responsibly.
• Inclusive access usability and contestability: mandate accessible design defaults (multilingual interfaces, low-verification flows, and alternative input modes); implement explainability standards with clear, user-facing rationales; and create dispute-resolution and override mechanisms for consequential agent decisions.

These policies ensure that memory does not harden into proprietary moats and that agent systems remain accessible, navigable, and equitable across diverse populations.

The path forward for responsible AI agents isn’t about halting innovation or reinventing governance from scratch. It’s about applying practical safeguards. Regulating infrastructure, from telecommunications and financial services to transportation, is not new. The challenge is strategically adapting long-standing principles of privacy, security, and accountability to systems that increasingly act on our behalf.

That means giving users control over what agents remember, establishing standards for how they connect to tools, requiring human oversight in critical sectors, and ensuring traceability when things go wrong. As AI agents and MCP become more widespread, privacy and usability must be design requirements, not afterthoughts. Agents should serve people, not the other way around. That’s not a technical constraint—it’s a governance choice. And it’s one we can still make.