TL;DR: A analysis of 5,205 open-source MCP server implementations found that 88% require credentials, 53% rely on static API keys or PATs, and only 8.5% use OAuth, underscoring how quickly AI agent infrastructure is scaling on weak identity foundations, according to Astrix Security. Static secrets are not a deployment detail here; they are the governance flaw that makes MCP adoption harder to secure than it first appears.
Editorial analysis by NHI Mgmt Group, based on content published by Astrix Security: “State of MCP Server Security 2025: 5,200 Servers, Credential Risks, and an Open-Source Fix”.
Key questions
Q: What breaks when MCP servers depend on static API keys or PATs?
A: Static credentials break the assumption that access can be tightly scoped, short-lived, and cleanly revoked.
Q: Why do static MCP secrets create more governance risk than they first appear to?
A: Because the credential is usually embedded in operational tooling, not held in a reviewable access workflow.
Q: How should teams handle MCP authorization when multiple users share the same server?
A: They should avoid shared secrets wherever possible and use delegated authorization that preserves per-user scope and revocation.
Practitioner guidance
- Map every MCP server to a credential owner Inventory which team owns each server credential, how it is issued, where it is stored, and who can revoke it.
- Replace static credentials with runtime vault retrieval Pull secrets from a secure vault at startup or request time so they are not written into repositories, images, or long-lived host files.
- Prefer delegated authorization over shared API keys Use OAuth or an equivalent delegated model where the server acts with scoped, user-linked access rather than a reusable shared secret.
Bottom line: MCP server adoption is being built on long-lived credentials that are easy to distribute but hard to govern.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Static secret dependency is the core MCP governance failure: the article shows that MCP servers are being built on credentials that were designed for convenience, not lifecycle control. When 53% of servers rely on static API keys or PATs, the identity model is already misaligned with secure delegation. The practitioner conclusion is that MCP should be treated as a secrets governance issue before it is treated as an integration pattern.
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.
A question worth separating out:
Q: How do security teams know whether an MCP deployment is using a safe identity model?
A: Look for evidence of runtime secret retrieval, scoped delegation, explicit ownership, and revocation that does not depend on editing a config file. If access only exists because a secret was copied into the runtime, the model is still relying on static trust.
👉 Read our full editorial: MCP server security is still built on static secrets