Topic starter
24/09/2026 1:27 pm
TL;DR: MCP servers are frequently built around plaintext or long-lived credentials, with Trend Micro cited by Akeyless showing 48% recommend storing secrets in .env or JSON files and 492 exposed servers lacking client authentication. The deeper issue is that even secretless authentication does not stop misuse of legitimately granted access, so runtime governance becomes part of the identity problem.
NHIMG editorial — based on content published by Akeyless: securing secrets in MCP servers and governing agent behaviour
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Akeyless's analysis of MCP server secret exposure and runtime governance →
MCP server secrets: what this means for IAM and runtime control?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
24/09/2026 1:27 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server secrets expose a larger runtime governance gap
