Notifications
Clear all
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.
NHIMG editorial — based on content published by Astrix Security: State of MCP Server Security 2025
By the numbers:
- The research analyzed over 5,200 public repositories.
- Only 8.5% use OAuth, the preferred delegation framework.
Questions worth separating out
Q: How should security teams handle hardcoded credentials in MCP server deployments?
A: They should remove static secrets from configuration files, environment variables, and code repositories, then replace them with runtime retrieval from a controlled vault.
Q: Why do MCP servers create more NHI risk than ordinary service integrations?
A: MCP servers often sit in front of multiple tools and data sources, so a single exposed secret can grant broad downstream access.
Q: What do security teams get wrong about secret rotation in AI agent environments?
A: They often focus on rotation cadence without first fixing where secrets live and how widely they are reused.
Practitioner guidance
- Eliminate hardcoded MCP secrets from repositories and configs Move credentials out of configuration files, environment variables, and checked-in manifests.
- Scope each MCP credential to a single agent and tool boundary Avoid reusable credentials that can call multiple systems.
- Audit MCP deployments for OAuth coverage and fallback paths Identify where static API keys or PATs are still being used because OAuth is unavailable or unimplemented.
What's in the full report
Astrix Security's full research covers the operational detail this post intentionally leaves for the source:
- Repository-level breakdown of where hardcoded MCP secrets were found and how they were stored
- Credential pattern analysis showing which deployment styles relied on API keys, PATs, or OAuth
- The MCP Secret Wrapper implementation details for fetching secrets at runtime
- The full recommendation set for developers and enterprise teams securing MCP integrations
👉 Read Astrix Security's State of MCP Server Security 2025 research →
MCP server security and hardcoded credentials: what teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
08/06/2026 9:04 am
Hardcoded MCP credentials are not a hygiene issue alone, they are an identity design failure. MCP servers are becoming the access layer for AI agents, yet the research shows that most still depend on static secrets, environment variables, and coarse-grained access. That means the identity boundary is being implemented as a reusable credential rather than a governed delegation model. Practitioners should treat this as a structural NHI control gap, not a packaging problem.
A few things that frame the scale:
- Only 8.5% use OAuth, the preferred delegation framework, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
A question worth separating out:
Q: How can organisations tell whether MCP access is actually governed?
A: Look for three signals: whether credentials are fetched at runtime, whether each credential maps to one agent or tool, and whether access can be revoked without breaking unrelated workflows. If the answer is no, the environment is still relying on standing access. Governance is real only when ownership, scope, and revocation are all visible.
👉 Read our full editorial: MCP server security exposes hardcoded credential risk in AI agent
