Topic starter
07/06/2026 9:13 pm
TL;DR: 53% of MCP servers still rely on static API keys or PATs, only 8.5% use OAuth, and 79% pass API keys through environment variables, leaving AI agent integrations built on exposed, long-lived credentials, according to Astrix Security’s State of MCP Server Security 2025. Hardcoded secrets make MCP adoption an identity governance problem, not just an implementation problem.
Editorial analysis by NHI Mgmt Group, based on content published by Astrix Security: “Astrix Researchers Uncover Credential Risk in the Majority of MCP Servers”.
By the numbers:
- Astrix Security analyzed over 5,200 public repositories in the State of MCP Server Security 2025.
- More than half, 53%, of MCP servers still rely on static API keys or Personal Access Tokens.
- Only 8.5% of MCP servers use OAuth, while 79% of API keys were passed via environment variables.
Key questions
Q: What breaks when MCP credentials are hard coded?
A: Hard-coded credentials break lifecycle control.
Q: Why do static API keys create risk for AI agent access?
A: Static API keys create risk because they are long-lived, reusable, and difficult to tie to a specific action.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Replace hardcoded MCP credentials Move API keys and PATs out of repositories, configs, and endpoint files, and require runtime retrieval from a governed vault before any agent call is made.
- Scope every MCP integration as an NHI Classify each agent connection as a non-human identity with explicit ownership, purpose, expiry, and revocation criteria rather than an informal application integration.
- Enforce short-lived delegated access Use OAuth or equivalent delegated authorisation where available so token lifetime and audience are bounded instead of relying on reusable static secrets.
Bottom line: MCP server growth is colliding with credential practices that still rely on static, long-lived secrets.
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
08/06/2026 9:04 am
Hardcoded MCP secrets are not an implementation flaw, they are an identity governance flaw: The article shows that MCP adoption is scaling faster than secret lifecycle discipline. When agents depend on static API keys and PATs, the environment is building privileged access around reusable bearer credentials instead of governed delegation. That means the control question is not simply where the secret lives, but whether the identity model can tolerate secret reuse at all.
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.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should security teams do when AI agents need access to tools and data?
A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.
👉 Read our full editorial: MCP server security exposes hardcoded credential risk in AI agent
This post was modified 4 days ago by NHI Mgmt Group