How MCP servers handle data privacy and security

When a developer rotates a GitHub token, they know who issued it, what it can access, and why it exists. When an AI agent uses that same access token through an MCP server, triggered by a natural language prompt on behalf of a user, none of those answers are as clear.

Now multiply that by every agent your team deploys. One MCP server can touch five to ten external data sources or cloud services, and most enterprise security teams run dozens of MCP deployments. Each one adds non-human identities acting on real infrastructure outside existing IAM frameworks, with no policy governing their access. At that scale, the provisioning decisions your team made in an afternoon are shaping an attack surface nobody is auditing.

This article explains why MCP creates a governance problem distinct from a storage problem, where the authorization chain breaks down when an agent is involved, and what a governance-first approach to MCP secrets looks like in practice.

Why MCP isn't just a secrets storage problem

You've probably seen the standard MCP security checklist before: Use a secrets manager, rotate credentials, don't hardcode tokens. While all of that is necessary, it only solves half the problem. That checklist answers where secrets live but says nothing about how access is governed, who authorized it, under what conditions, for how long, or with what accountability trail.

To see why that matters, consider how authorization works in a traditional human-to-system flow, where the chain is explicit and traceable end-to-end.

Now consider what happens when an AI agent enters that chain. Instead of a human operating traditional systems through fixed code, a structured request to an AI assistant triggers an agent that autonomously handles tool discovery and decides which external functions to call.

At no point in this client-server communication is there a policy stating that the AI system has explicit user approval to use this credential for this type of action during this session on behalf of this user. That missing layer is the governance gap, and closing it requires answering three questions that most MCP deployments never ask.

Three questions the MCP architecture forces you to answer

Before you can govern credential access in an MCP deployment, you need to answer three questions that the specification leaves entirely to your team.

• Identity: Which entity is actually using the credential? Is it the user, the agent process, or the MCP server itself? These are different principles with different trust levels, and most deployments treat them as interchangeable.
• Scope: What is the credential authorized to do in this context, and is that scope bounded per-session, per-user, or per-tool-call? A GitHub PAT used by an agent in a dev environment carries a very different risk than one running in production, even if the token itself looks the same.
• Accountability: If the agent takes an action using a credential, is there an audit trail that maps it back to the original authorization decision, not just to the API call that executed it?

Answering these three questions is what separates a storage model from a governance model, and the data suggests most deployments haven't made that distinction yet.

Astrix analyzed more than 5,200 public MCP server implementations and found that 88% require credentials for external services. Most of those deployments, however, lack a framework for managing sensitive data or protecting data integrity once the MCP server receives the credentials. Which agent gets access, to what scope, and for how long are questions the MCP specification doesn't answer, which means your team has to.

The instinct to manage MCP credentials the way you manage service accounts is understandable, but it fails across every dimension that matters for governance.

Why AI agent NHIs are different from service account NHIs

With a traditional service account, there was always a paper trail somewhere. Someone filed a ticket, requested access, got it approved, and a Terraform resource or an IAM entry recorded that the identity existed. The credential was visible from the moment it was created.

MCP removes that step entirely; a developer can spin up third-party servers with direct access to critical systems in an afternoon, introducing hidden supply chain risks. The non-human identity appears already credentialed, already acting on real infrastructure, and completely invisible to existing IAM tooling.

If you've been managing them the same way, the table below shows you exactly where that mental model breaks down.

When a service account gets retired, its IAM entries and Terraform resources usually go with it. MCP credentials have no equivalent lifecycle anchor, no deprovisioning trigger, and no natural moment to ask whether a credential should still exist. New ones are created with each deployment, scoped for developer convenience rather than least privilege, and the ones that should have been rotated or revoked simply aren't, because nothing in the system knows they should be.

To fix these problems, you need a governance model that defines how credentials are managed across every agent deployment your team runs. Let's see what that looks like next.

What governance-first secrets management looks like for MCP

A governance-first model for secrets management goes beyond storage; it should define policies for how credentials are issued, scoped, used, rotated, and revoked, and also establish accountability for every action taken with them. Here is what that looks like across four pillars.

1. Policy-bound issuance: Instead of issuing credentials on request, issue them according to a defined policy. That policy should specify the agent identity, the environment, the scope of access, and the TTL. The policy should be the authorization decision, and the credential is simply its execution.
2. Session-scoped access: Bind the blast radius of a compromised credential to a single session. Use short-lived tokens where the protocol supports them, and session-context tracking where it doesn't. When an agent session ends, no valid credentials should survive it.
3. Multi-hop audit trails: Your audit log needs to capture the full chain of MCP interactions, from the user prompt to the agent decision, tool calls, credential use, and external API actions. That way, you can prevent malicious intent or malicious instructions.
4. Automated rotation with propagation: If rotation requires manual steps, it won't happen on schedule. Automate it, and make sure it propagates to all running MCP instances without restarts or redeployments. Rotate in one place, and every consumer gets the updated value automatically.

When these four pillars work together, the result is a closed, accountable loop where every credential access is policy-driven, session-bounded, and fully traceable. The diagram below shows what that looks like end-to-end.

As shown above, the policy engine issues a scoped credential, which is injected into the MCP Server at runtime. The server makes a tool call to the external API, which logs the full chain to the audit log. When a credential is rotated, that change automatically propagates back to the MCP Server, keeping the entire lifecycle governed without any manual intervention.

Governance doesn't live only in policy documents and architecture diagrams. It has to show up in your development practices too, starting with how your team handles credentials at the code level.

Runtime injection for secure client-server communication

Here is what most MCP deployments are doing today:

Full repo scope, shared across every user of the server, living in shell history and .env files that nobody audits. If that config leaks, everything connected to it is compromised.

The governed pattern replaces static exports with runtime injection scoped to the environment, using tools like Doppler CLI:

Swapping --config production for --config development gives you a different credential scope with the same server code. Rotation propagates automatically to every running instance. Nothing exists on disk or in shell history. The governance policy lives in the Doppler configuration, not scattered across .env files that no one owns.

Governance patterns across MCP implementations

Runtime injection handles where credentials come from. What happens inside your server once they arrive is a separate concern, and it is where most implementations leave governance behind entirely. Two patterns matter most here.

The first is fail-closed secret loading. When your MCP server starts, it should immediately verify that every required credential is present and fail loudly if any are missing, rather than starting successfully and breaking silently on the first tool call that needs a credential. Here is what that looks like in practice:

The second is session-correlated logging. Every tool call your MCP server makes should emit a structured log entry that includes a session ID, tying that action back to the specific user request that triggered it. Without this, you end up with API logs that tell you what happened, but not who authorized it or why.

Together, these two patterns give you the accountability chain that maps every API action back to an authorization decision, and incidents become easier to trace.

Wrapping up

The question of how MCP handles data privacy and security has two answers, and as AI adoption accelerates, most teams focus on only one. The technical answer is tractable, meaning that the baseline security of individual MCP components is a known, solvable engineering problem. It is relatively straightforward to encrypt traffic, use a secrets vault, and enforce standard data access policies to limit the blast radius of a compromised MCP server.

The strategic answer, however, is much harder. It requires governing the unpredictable, autonomous workflows where AI agents use those credentials to interact with external systems and external tools. Because MCP forces your organization to build a dynamic governance model for machine identity that doesn't exist by default, most teams skip that crucial decision entirely.

The teams that figure this out early will be able to scale agent deployments with confidence. The ones that don't will eventually hit an incident where an agent took an action nobody can explain, using a credential nobody remembers issuing, in a session nobody can trace. At that point, the governance conversation becomes unavoidable. The only question is whether you're having it now, by design, or later, under pressure.

If you want to see how a secrets governance model works for MCP deployments in practice, book a Doppler demo and see how teams are solving this today.