MCP Server Secrets: From Hardcoded Keys to Runtime Governance

Key Takeaways

• MCP servers are unusually credential-heavy, aggregating secrets for every backend they connect to into one place.
• The dominant failure mode today isn’t a sophisticated attack; it’s hardcoded, static secrets sitting in plaintext config files.
• Standard fixes exist and should be table stakes: dynamic credentials, workload identity, least privilege, rotation, and audit logging.
• Removing hardcoded secrets doesn’t stop an agent from misusing access it was legitimately granted; that takes a further layer of runtime governance.
• Akeyless addresses both layers: SecretlessAI removes standing secrets from the server itself, and Agentic Runtime Authority governs what the agent does with the access it’s granted.

Quick Answer: How Do You Secure Secrets in an MCP Server?

Nearly half of MCP servers store credentials in plaintext (Trend Micro), so replace stored credentials with short-lived ones issued through workload identity, then scope and audit what each server can access.

• Never store API keys or tokens in .env files or JSON configs.
• Authenticate the server itself (cloud IAM, GitHub OIDC, SPIFFE/SPIRE) instead of hardcoding a key.
• Scope, rotate, and log every credential the server touches.

What IQuick Facts

Category	Data Point
Plaintext exposure	48% of reviewed MCP servers recommend storing secrets in plaintext .env or JSON files (Trend Micro)
Unauthenticated servers	492 publicly exposed MCP servers found with no client authentication, exposing 1,402 tools, 90%+ with direct read access (Trend Micro)
Cloud concentration	A majority of those exposed servers are hosted on major cloud providers including AWS, Azure, GCP, and Oracle (Trend Micro)
MCP config exposure	24,008 unique secrets found in MCP configuration files on public GitHub, including 2,117 valid credentials, 8.8% of all MCP-related findings (GitGuardian)
AI-service leak growth	AI-service secret leaks rose 81% year-over-year in 2025, reaching more than 1.27 million exposed secrets (GitGuardian)

MCP servers give AI agents access to outside systems, and that access runs on credentials the server holds. Right now, most of the ecosystem is handling those credentials badly.

Securing MCP server secrets means covering two layers. Most guides already walk through the credential hygiene layer. Almost none of them mention the runtime governance layer that comes next.

s an MCP Server, and Why Is It So Secrets-Heavy?

An MCP server sits between an AI agent and the outside systems it connects to, holding a credential for every one of them. The agent’s client sends a request, the server translates it into an action against a database, an API, or a cloud service, and each of those connections needs its own credential to work.

MCP’s own specification explains why credentials accumulate this way. The protocol defines a host-client-server architecture, where one host application runs multiple clients, and each client connects to exactly one server. Servers are designed to be single-purpose and composable. A typical setup stacks several small servers side by side instead of running one that does everything. Each server in that stack holds its own credential.

The number of public servers has grown by more than an order of magnitude within about a year of the ecosystem taking off. The credential surface keeps expanding as adoption grows.

The protocol’s own guidance adds to the problem, not just the architecture. For local (stdio) servers, MCP’s authorization spec tells implementations to skip OAuth entirely and pull credentials from the environment instead. It’s a spec-level nudge toward exactly the plaintext .env pattern below.

Why MCP Servers Keep Leaking Secrets

Nearly half of reviewed MCP servers recommend storing credentials in a plaintext .env or JSON file instead of pulling them from a secrets manager. Trend Micro found 492 of these servers running with no client authentication at all. Together they exposed 1,402 tools, and more than 90% granted direct read access.

Storage hygiene isn’t the only failure mode. The protocol’s own design adds another one. The NSA’s May 2026 security advisory on MCP states plainly that authorization is optional in the protocol. The spec doesn’t mandate token expiration, rotation, or revocation either, so each implementation decides on its own whether to build those controls in at all.

Some attacks skip credential storage entirely and go after the agent’s behavior instead. The NSA’s advisory documents a technique called tool poisoning, first identified by security researchers. A malicious instruction hidden inside a tool’s description, invisible to the user, gets silently followed by the agent. One proof of concept against a WhatsApp MCP integration used this to expose a user’s full message history to an attacker without triggering any notification.

OWASP’s own MCP security guidance names a related risk it calls contextual secret leakage. A token that persists in the agent’s conversation memory can be recalled later with a crafted prompt or scraped out of an unredacted debug log.

How Do You Secure MCP Server Secrets?

Securing an MCP server means replacing stored credentials with short-lived ones issued only when they’re needed. In practice, that’s workload identity: cloud IAM roles, Kubernetes service accounts, GitHub OIDC, certificates, or SPIFFE/SPIRE. The server authenticates as itself instead of holding a static key. From there, scope each credential to the minimum access it needs, rotate what can’t be made short-lived, and log every use.

MCP’s own authorization spec backs up that scoping requirement directly. It requires clients to bind every token to the specific server it was issued for, using a mechanism called Resource Indicators. Servers must reject any token issued for a different service.

The spec’s security guidance names specific attack patterns worth defending against by name. Token passthrough, where a server forwards a client’s token to a downstream service, is explicitly forbidden. Server-side request forgery through OAuth metadata discovery can redirect a request toward a cloud provider’s internal metadata endpoint. It’s the same class of attack that has caused major cloud credential breaches elsewhere.

The NSA’s May 2026 advisory adds a further layer of defenses beyond credential handling. Run each server inside an OS-level sandbox, such as AppContainers, seccomp, AppArmor, or SELinux. Sign MCP messages with expiration timestamps to block replay attacks. Scan your own network regularly for unauthenticated MCP servers using a purpose-built tool.

A Practical Checklist for MCP Server Secrets

Fixing MCP secrets exposure means changing some things today and rebuilding others into the architecture permanently.

Immediate:

• Remove unnecessary network exposure, use stdio instead of exposing the server publicly where possible.
• Enforce TLS on any traffic that stays on the network.
• Strip hardcoded credentials and move to OAuth token delegation.

Long-term:

• Add zero-trust, request-level authorization checks.
• Vault credentials and rotate them on a defined schedule.
• Monitor and alert on anomalous access patterns.

Comparing Approaches to MCP Secret Security

Every approach to MCP secrets trades convenience for risk, and the safest ones remove standing credentials entirely. Each row below handles MCP server secrets differently, from riskiest to safest.

Approach	How It Works	Risk Level
Plaintext/hardcoded	Credentials sit directly in a .env or JSON config	Highest, one file leak exposes everything
Secrets-manager injection	Pulled from a vault at startup, static once loaded	Lower, but still long-lived in memory
Dynamic/ephemeral secrets	Short-lived, scoped credentials generated per session	Low, minimal exposure window
Workload identity/secretless	Server authenticates via cloud IAM, OIDC, or SPIFFE/SPIRE	Lowest, no standing credential to steal

492 publicly exposed MCP servers had no client authentication at all, exposing 1,402 tools (Trend Micro).

Is Eliminating Hardcoded Secrets Enough?

Removing hardcoded secrets closes off that exposure path, but it doesn’t stop an agent from misusing access it already has. Treating MCP security like traditional secrets management misses that risk. Over-permissioned access and weak attribution matter as much as exposure. An agent correctly scoped to query a database can still attempt a command outside that scope, a DROP TABLE instead of a SELECT, and workload identity alone has no way to catch that.

How Akeyless Secures Secrets and Governs Agent Behavior in MCP Servers

The Challenge

Fixing the credentials side isn’t the whole job: an MCP server also needs a way to govern what an already-authorized agent actually does. Most MCP server secrets advice stops exactly there.

The Approach

Akeyless fixes both problems: SecretlessAI removes standing credentials, and Runtime Authority governs what the agent does next. SecretlessAI issues credentials through workload identity, cloud IAM, GitHub OIDC, or SPIFFE/SPIRE plugins, so nothing sits on the server waiting to be stolen. Runtime Authority classifies what an agent is trying to do and can trigger its Kill Switch to block an action in real time if it falls outside that intent.

The Outcome

The result is a server with no standing secrets and no unchecked agent actions. It becomes a control point instead of a liability.

Akeyless’s own Runtime Authority MCP server proves the pattern works, exposing list-secrets, query-db, and service-execute as governed tools instead of open-ended access.

How Enterprises Already Trust Akeyless With Credential Security

Akeyless’s credential discipline isn’t new either: Cimpress replaced HashiCorp Vault with Akeyless and hasn’t worried about credential rotation since.

Cimpress

In the words of Conor Mancone, Principal Application Security Engineer at Cimpress: “We set Akeyless up 9 months ago, and we haven’t had to worry about credential rotation… it just works.”

Progress

Richard Barretto, CISO and VP at Progress, reports the same discipline at a different scale: “Akeyless is true SaaS that allows you to scale. It’s purpose-built to live in the cloud. We saved 70% of our maintenance and provisioning time with Akeyless.”

How Do You Choose the Right Approach for Your MCP Deployment?

Cimpress’s track record doesn’t make one approach right for every MCP deployment: basic hygiene covers low-risk tools, and full governance covers production access. A script calling one read-only API carries a different risk than a production agent with database write access, and the fix should scale with that difference. Either way, MCP server secrets deserve the same discipline as any other production credential. The goal was never to hide API keys better; it was to make sure neither the agent nor the server ever needs to hold one.

FAQs About Securing Secrets in MCP Servers

Can Multiple MCP Servers Share One Secrets Manager?

Yes, and it’s usually the safer pattern. Centralizing issuance, rotation, and audit logging in one secrets manager beats letting every server manage its own local store. Each server’s access should still be scoped separately, so compromising one server’s session doesn’t expose what every other server can reach.

How Do You Rotate MCP Server Credentials Without Downtime?

Overlap the old and new credential during a short grace period instead of swapping them instantly. Most secrets managers support this natively. The server picks up the new credential on its next request while the old one still works until it expires, so nothing breaks mid-session.

Is a Local (stdio) MCP Server Safer Than a Remote One?

It removes one risk but not the other. Running over stdio keeps the server off the network entirely, closing the exposure path Trend Micro found in 492 unauthenticated servers. It doesn’t fix how the server stores its own credentials. A local server can still hardcode a plaintext secret just as easily as a remote one.

Does MCP Encrypt Traffic Between the Client and Server on Its Own?

No. MCP doesn’t define its own encryption; it runs over whatever transport you choose. For a network-exposed server, that means terminating TLS the same way you would for any HTTP service. MCP itself doesn’t enforce it.

How Do You Audit Which AI Agent Accessed Which Secret?

Tie every credential to the workload identity that requested it, not to a shared static key. When each agent authenticates as itself, its actions map to a specific identity in the audit log. A generic API key could have been used by anyone.

Do Compliance Frameworks Like SOC 2 Address MCP Servers Specifically Yet?

Not by name. MCP is too new for major frameworks to reference it directly, but the controls they already require, access logging, least privilege, credential rotation, apply the same way to an MCP server as to any other credentialed system.