Topic starter
24/09/2026 1:27 pm
TL;DR: Akeyless argues that MCP servers often concentrate plaintext, static credentials in config files, while unanswered runtime governance issues mean that removing hardcoded secrets alone does not stop an agent from misusing legitimately granted access.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “MCP Server Secrets: From Hardcoded Keys to Runtime Governance”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP servers expose a broader governance issue because credential storage and action control are intertwined in the same runtime path.
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
👉 Read Akeyless's analysis of MCP server secrets and runtime governance →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
24/09/2026 1:27 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server secrets expose a larger runtime governance gap