Join our Newsletter — 33% off our NHI Course

MCP server security and the governance gap teams are missing

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 20739
Topic starter  

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 →


This topic was modified 4 days ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21367
 

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


This post was modified 4 days ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.