MCP server secrets expose a larger runtime governance gap

At a glance

What this is: This analysis argues that MCP servers concentrate credential risk and that removing hardcoded secrets is only the first layer of control.

Why it matters: IAM teams need to treat MCP as both a secrets-management problem and an authorization problem because workload identity alone does not govern what an agent does once access is granted.

By the numbers:

• 48% of reviewed MCP servers recommend storing secrets in plaintext .env or JSON files.
• 492 publicly exposed MCP servers found with no client authentication, exposing 1,402 tools.
• 81% year-over-year growth in AI-service secret leaks reached more than 1.27 million exposed secrets in 2025.

👉 Read Akeyless's analysis of MCP server secret exposure and runtime governance

Context

MCP servers are credential-bearing intermediaries, which means they do not just expose an API surface, they concentrate access to multiple downstream systems in one identity boundary. In practice, that makes the server itself a governance object, not just a transport layer, and it brings Non-Human Identity controls into the centre of agent-to-tool integration.

The article’s core claim is that the industry is still solving only the storage problem. Secretless design reduces standing exposure, but the author argues that runtime authority is also needed because an agent can still misuse access it legitimately received. That is the point where identity governance, privilege scoping, and auditability converge. For a wider NHI control baseline, the Ultimate Guide to NHIs remains the most relevant reference point.

MCP’s growth changes the shape of the identity estate because each composable server introduces another credential and another policy boundary. The result is not just more secrets, but more places where static auth assumptions, weak offboarding, and inconsistent logging can fail.

Key questions

Q: What breaks when an MCP server is given direct backend secrets instead of exchanged tokens?

A: You lose privilege separation, audit clarity, and revocation precision. The backend secret can be copied, reused, or buried in configuration, and offboarding becomes secret hunting instead of policy revocation. That is exactly the kind of lifecycle weakness NHI governance is meant to avoid.

Q: Why do MCP servers need more than workload identity?

A: Workload identity proves the server is legitimate, but it does not determine whether a specific action is appropriate once access is granted. An authenticated MCP server can still issue an unsafe read, write, or tool invocation if runtime authorisation is absent. The governance problem therefore shifts from secret possession to action control.

Q: What are the signs that an MCP deployment has weak identity governance?

A: Common signs include plaintext .env files, JSON configs with embedded keys, broad backend scopes, missing client authentication, and unclear logs that cannot attribute a tool call to a specific workload identity. If the team cannot answer which server used which secret and why, the governance model is too loose.

Q: How should teams balance secrets rotation with runtime access control for MCP?

A: Rotation matters, but it is not sufficient on its own. Teams should first remove standing secrets where possible, then enforce per-server scoping, logging, and request-level decisions for higher-risk actions. The right order is exposure reduction first, then runtime governance for the access that remains.

Technical breakdown

Why MCP servers accumulate secrets

An MCP server sits between an AI agent and external systems such as databases, APIs, and cloud services, so each upstream connection often brings its own credential. That architecture creates a dense credential bundle in a single service boundary. If teams use plaintext config, environment variables, or startup-injected static secrets, the server becomes a high-value concentration point rather than a thin orchestration layer. This is an NHI design issue because the server is not a human session, it is a workload identity that inherits access across multiple backends.

Practical implication: Treat every MCP server as a credential-bearing NHI and inventory each downstream secret separately.

Why workload identity is safer than stored secrets

Workload identity replaces a static secret with authentication based on the server’s runtime identity, such as cloud IAM, OIDC, certificates, or SPIFFE. The important shift is that the server proves who it is instead of presenting a reusable credential that can be copied, replayed, or left behind in a file. This does not eliminate authorisation, but it removes the most common theft path: extracting a secret from code, config, or memory. For MCP, that sharply reduces the exposure window for server-side compromise.

Practical implication: Use workload identity to eliminate standing credentials before you tune rotation or logging.

Why runtime authority matters after secrets are removed

Secretless authentication solves only the first layer. Once an agent has legitimate access, the real question is whether the server can constrain what the agent attempts to do at runtime. That is an authorisation and intent problem, not a secrets problem. If the server can query a database, the remaining risk is scope drift: a request that stays inside authentication boundaries but exceeds operational intent. In NHI terms, this is where least privilege must be enforced dynamically, not just at provisioning time.

Practical implication: Add request-level authorisation and audit decisions for every action the MCP server brokers.

Threat narrative

Attacker objective: The objective is to use one exposed MCP server credential boundary to reach multiple backend systems and perform tool actions or data access at scale.

1. Entry occurs when credentials are stored in plaintext config files, .env files, or startup-injected static secrets that can be copied or exposed during deployment, review, or hosting.
2. Escalation occurs when a compromised server session or exposed token grants access to multiple backend systems, letting the actor pivot across the server’s aggregated credentials.
3. Impact occurs when the attacker or rogue agent uses that standing access to read data, invoke tools, or execute actions outside intended scope, extending the blast radius beyond the original server.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing credentials are the wrong primitive for MCP governance: MCP servers aggregate access for multiple downstream systems, so a reusable secret turns one server into a multiplier of compromise. That is why the issue is not just secret hygiene but identity containment. The practitioner conclusion is simple: if the server can hold a long-lived credential, it can also concentrate unacceptable blast radius.

Secretless access reduces theft risk, but it does not solve authorisation risk: removing a hardcoded key eliminates one exposure path, yet it does nothing to stop a legitimately authenticated server from invoking the wrong action. This is where NHI governance must shift from credential ownership to action governance. The implication is that access controls for MCP should be evaluated on runtime scope, not only on where the secret lives.

Runtime governance is now part of NHI governance: once an agent or server can call tools on demand, least privilege has to be enforced at the point of use, not only at provisioning. That changes the control model from static entitlement review to request-level decisioning, logging, and revocation. Practitioners should treat this as an identity design requirement, not an application add-on.

Static secret management is becoming an anti-pattern for composable agent systems: the more MCP servers are stacked together, the less defensible it becomes to manage each one as an isolated secret store. NHI programmes need a model that ties workload identity, per-server scope, and audit attribution together. The practitioner conclusion is that MCP expands the governance surface even when it removes visible secrets.

The named concept here is secretless runtime governance: this is the combined control problem of removing standing credentials and governing what a server or agent does with the access it receives. It matters because one layer without the other leaves either theft exposure or misuse exposure intact. Practitioners should expect MCP controls to evolve toward this two-layer model.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• The same research shows that 97% of NHIs carry excessive privileges, which is why authentication alone is never a complete control model.
• For a deeper control baseline, the NHI Lifecycle Management Guide is the next step for provisioning, rotation, and offboarding discipline.

What this signals

Secretless access is becoming the baseline, but it will not be enough by itself: MCP deployments are moving from exposed keys toward runtime-issued credentials, yet the governance burden is shifting to authorisation and audit. Teams should expect identity architecture reviews to include both secret exposure and tool-use control, especially where MCP servers mediate access to multiple backends.

Identity programmes need a new control pattern for agent-facing services: when a workload can both authenticate and initiate actions, entitlement review alone is too slow to be the only safeguard. Align MCP controls with NIST SP 800-207 Zero Trust Architecture and with the SPIFFE workload identity specification where workload attestation is required. The practical signal is that request-level policy will become a normal part of NHI governance.

Secretless runtime governance: this is the operating model where standing credentials are removed and every privileged tool action is decided in context. With the Ultimate Guide to NHIs showing that 97% of NHIs carry excessive privileges, the issue is not only leakage but overreach. The next programme milestone is to separate authenticated access from authorised action in every MCP deployment.

For practitioners

• Replace standing secrets with workload identity Issue MCP server credentials through cloud IAM, OIDC, certificates, or SPIFFE so the server authenticates as itself rather than storing reusable keys in config files or environment variables.
• Scope each server to a single access purpose Bind every MCP server credential to the minimum backend access it needs, and separate read, write, and administrative paths so compromise of one server does not expose unrelated systems.
• Log and review every brokered action Record which workload identity requested which tool, what backend it touched, and whether the action stayed within intended scope, then alert on unusual combinations of tool use and data access.
• Treat runtime authority as part of the control plane Add request-level approval or denial logic for higher-risk MCP actions so the server cannot rely on authentication alone to decide what an agent is allowed to do.

Key takeaways

• MCP servers are identity concentrators, so stored credentials create outsized blast radius even before an attacker reaches the underlying systems.
• Removing plaintext secrets helps, but the real governance gap is runtime misuse of legitimate access, which requires per-action control and audit.
• Practitioners should treat MCP as a two-layer identity problem: eliminate standing secrets first, then govern the agent or server actions that remain possible.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
• Standing Secret: A standing secret is a long-lived credential that remains valid until it is manually replaced or revoked. In practice, it expands attack exposure because the secret can outlive the service change process, especially when ownership and usage tracking are incomplete.

What's in the full article

Akeyless's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact implementation patterns for replacing stored MCP credentials with cloud IAM, OIDC, certificates, or SPIFFE-based workload identity
• The vendor's breakdown of how runtime authority blocks unsafe agent actions after authentication has already succeeded
• Practical examples of MCP server scoping, audit logging, and kill-switch style controls for higher-risk tool use
• The comparison table that distinguishes plaintext secrets, vault injection, dynamic credentials, and secretless identity models

👉 Akeyless's full post covers the credential model, runtime authority layer, and implementation checklist for MCP servers.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or NHI governance programme, it is worth exploring.