MCP server secrets expose a larger runtime governance gap

At a glance

What this is: This is an analysis of why MCP server secret hygiene is only half the problem, because runtime authority and access governance become part of the control surface once agents can act through the server.

Why it matters: IAM, PAM, and NHI teams need to treat MCP servers as credentialed runtime intermediaries, not just secret containers, because standing access and misuse risk move together.

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

Context

MCP servers create a governance gap because they sit between an agent and downstream systems while holding the credentials needed to make those systems work. If those credentials are static, plaintext, or broadly scoped, the server becomes a concentrated access bridge rather than a controlled identity boundary.

For non-human identity programmes, the issue is not only where secrets are stored but also how the server authenticates itself, what it is allowed to reach, and whether its actions are still acceptable after access has been issued. In other words, the control problem spans both secret handling and runtime authority.

The source article frames this as a two-layer problem: remove standing secrets from the server, then govern what the agent does with the access it receives. That distinction matters because one control set reduces exposure while the other addresses misuse after legitimate issuance.

Key questions

Q: What breaks when MCP sessions rely on persistent client secrets?

A: Persistent client secrets create a standing-access model that is hard to reconcile with MCP’s stateful sessions and multi-step workflows. The result is broader authority than the user may realise at approval time, especially when one client can reach several servers. Teams should prefer session-scoped authorization and explicit revocation paths instead of assuming long-lived tokens are harmless.

Q: Why do MCP servers need runtime governance as well as secret hygiene?

A: Because removing a standing secret does not stop a legitimately authenticated agent from making unsafe requests. Secret hygiene reduces exposure, but runtime governance decides whether an allowed action still fits intent, scope, and policy. In practice, this means MCP security must cover both issuance of access and the use of access after issuance.

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: When do MCP secret controls need to be paired with access policy controls?

A: They need to be paired whenever the server can reach production systems, write back to data stores, or trigger actions that matter operationally. At that point, secret handling alone is incomplete because the real risk includes what the authenticated server is allowed to do. Access policy must travel with the credential lifecycle.

Technical breakdown

Why MCP server secrets accumulate so quickly

An MCP server is a credential hub by design. It sits between the agent and multiple back-end services, and each connection can require its own token, key, certificate, or workload identity. That architecture creates a dense secret surface because the server becomes the place where access is assembled for databases, APIs, cloud services, and tools. If implementers follow plaintext config patterns or skip authentication, the server is no longer a thin mediation layer. It becomes a durable repository of standing access. The key technical issue is not just storage location, but the way protocol design and implementation choices turn the server into a concentration point for reusable credentials.

Practical implication: Map every MCP server to the credentials it aggregates and remove any design that leaves reusable secrets sitting in config or memory longer than necessary.

Why workload identity is stronger than stored credentials

Workload identity changes the trust model from secret possession to authenticated execution. Instead of embedding an API key in a file, the server proves its identity through cloud IAM, OIDC, SPIFFE, or another federated mechanism and receives short-lived access tied to that runtime context. That reduces the blast radius of leakage because the identity is issued on demand, scoped more tightly, and easier to revoke than a long-lived token. It also improves attribution, because the server can be audited as its own identity rather than hiding behind a shared credential. The architecture is not secret-free by magic; it is secretless by shifting trust to runtime issuance.

Practical implication: Prefer workload identity for MCP servers that reach production systems, and reserve stored secrets only for exceptions that cannot yet be federated.

Why runtime governance still matters after secrets are removed

Even if every standing secret disappears, an MCP server can still be dangerous when the agent uses legitimate access in an unsafe way. The residual problem is not credential theft but authority misuse: a server granted read-only access can still be steered toward actions that exceed intent, context, or policy. That is why runtime controls belong alongside identity controls. Secret removal solves exposure, but it does not answer whether a given tool call, database query, or downstream action should be allowed once access already exists. For MCP, governance must evaluate the action, not just the credential.

Practical implication: Add request-level authorisation and action inspection so the server can block unsafe tool use even when the underlying credential is valid.

Threat narrative

Attacker objective: The objective is to turn one exposed MCP credential into broad, reusable access across the systems the server can reach.

1. Entry occurs when attackers or careless implementers place plaintext or long-lived credentials directly in MCP configuration files, environment files, or similar storage.
2. Credential abuse follows when the server authenticates with a standing secret that can be reused outside its intended runtime context.
3. Escalation happens when that credential grants access to multiple back-end systems or tools, expanding the impact of a single exposed secret.
4. Impact is the unauthorised use of downstream databases, APIs, or cloud services through the compromised MCP server identity.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing secrets are the wrong trust primitive for MCP servers. The article shows that the core weakness is not just poor storage hygiene but the fact that MCP servers are being built around reusable credentials in the first place. That design makes every file, config path, and deployment artifact part of the access boundary. For NHI governance, this is a classic secret concentration problem: the more the server aggregates, the more valuable and fragile the identity becomes. Practitioners should treat MCP servers as privileged credential brokers, not ordinary application components.

Runtime governance is now part of identity governance. The article is right to separate secret removal from action control, because an agent with legitimate access can still do the wrong thing within policy boundaries. That is the governance gap exposed by MCP: authentication alone does not tell you whether a given action matches intent. For identity teams, this pushes MCP deployments into the same conversation as PAM, request-level authorisation, and runtime authorization policy. The practitioner conclusion is simple: issuance and use must both be governed.

Ephemeral credential trust debt: short-lived credentials reduce exposure but do not remove the operational debt created when a server can still act outside intent, context, or scope. This article makes that debt visible by showing how static secret removal and runtime authority are separate layers. The first reduces leakage, the second constrains use. When teams treat them as one problem, they under-govern the server. The implication is that MCP identity architecture must be evaluated on both credential lifecycle and action governance.

MCP adoption is turning workload identity into a baseline expectation. A server that still depends on plaintext .env files or JSON configs is already below the governance floor for production use. That is not because secrets managers are obsolete, but because federated runtime identity is now the cleaner control boundary. The broader field implication is that NHI programmes will need explicit policy for agent-facing servers, not just for service accounts and APIs. Practitioners should normalize workload identity before they normalize agentic scale.

Access review alone is not enough for agent-mediated systems. Access reviews assume privileges persist long enough to be observed and recertified. MCP servers can authenticate, act, and complete work faster than those review cycles can meaningfully intervene, especially when credentials are short-lived and actions are delegated. That means governance has to move closer to issuance and action time. The practical conclusion is that teams need runtime decision points, not only periodic attestations, when agent-facing servers mediate production access.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
• Read next: Guide to NHI Rotation Challenges

What this signals

Ephemeral credential trust debt: MCP deployments can remove standing secrets and still leave a control gap if the server can use valid access outside intent, scope, or context. The programme question shifts from whether a secret is present to whether the server’s runtime authority is governed well enough to matter.

Workload identity becomes the practical baseline for agent-facing servers. If an MCP server is still depending on plaintext config files or static keys, the deployment is already behind the governance floor for production use. That is where identity teams should anchor their next control review.

The scale of the exposure problem is not hypothetical: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, a reminder that secret handling and runtime authorization have to be designed together, not treated as separate clean-up tasks.

For practitioners

• Remove standing credentials from MCP servers Replace .env, JSON, and similar config-stored secrets with short-lived credentials issued at runtime through federated identity.
• Authenticate servers as workloads Use cloud IAM, OIDC, or SPIFFE-based workload identity so the server proves who it is before it reaches downstream systems.
• Scope each server to one purpose Limit each MCP server to the minimum tools and back-end systems it actually needs, then log every credential use for review.
• Add runtime authorisation checks Evaluate tool calls at execution time so a valid credential does not automatically permit every downstream action the agent can request.
• Prefer local exposure only where feasible Keep servers off the network when the use case allows it, because reducing reachability narrows the surface for credential theft and unauthorised access.

Key takeaways

• MCP servers expose a broader governance issue because credential storage and action control are intertwined in the same runtime path.
• The article’s central warning is that removing hardcoded secrets reduces exposure, but it does not prevent misuse of access that was legitimately granted.
• The control answer is to combine workload identity, least privilege, rotation, logging, and runtime authorisation so the server is governed at issuance and at use.

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 Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• 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 article covers the operational detail this post intentionally leaves for the source:

• Trend Micro findings on plaintext secret storage and unauthenticated MCP servers
• Step-by-step guidance for replacing hardcoded credentials with workload identity
• Protocol details on token binding, rotation, and server-side request forgery risks
• The runtime governance layer that governs what an authorised agent can do next

👉 Akeyless's full post covers the secretless architecture details and agent runtime controls in more depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.