MCP server security is still built on static secrets

At a glance

What this is: Astrix Security’s MCP research shows that most server implementations still depend on credentials, with static secrets far outpacing modern delegation patterns.

Why it matters: IAM, NHI, and agent governance teams need to treat MCP server identity as production access, not implementation plumbing, because these servers sit inside the control path of AI agents.

By the numbers:

• Only 8.5% use OAuth, the modern, preferred method for secure delegation.
• 53% rely on static API keys or Personal Access Tokens (PATs), which are long-lived and rarely rotated.
• 79% of MCP Servers Store API Keys in Environment Variables

👉 Read Astrix Security's analysis of State of MCP Server Security 2025

Context

Model Context Protocol, or MCP, is the access layer that lets AI assistants connect to tools and data sources. The problem is not the protocol itself but the identity model many servers inherit from it: long-lived secrets, broad permissions, and weak separation between the server and the resources it can reach.

That creates an NHI governance problem as much as an AI problem. If the server is the identity executor, then API keys, PATs, and environment-variable secrets become the control plane for agent action, and that control plane is often far less mature than enterprise teams assume.

Key questions

Q: How should security teams handle credential storage for MCP servers?

A: Security teams should treat MCP server credentials as production NHIs and remove them from static configuration wherever possible. Use vault-backed runtime injection, scope access tightly, and make revocation possible without changing the server code. If a credential can be copied from a file or environment variable, it is already too easy to reuse outside the intended session.

Q: Why do MCP servers create more NHI risk than ordinary API integrations?

A: MCP servers sit in the execution path of AI tools, so a compromised credential can become a control point for multiple downstream actions, not just one API call. The risk is amplified when the server uses long-lived secrets, because the same identity can persist across sessions, users, and tool invocations.

Q: What do teams get wrong about environment variables for secrets?

A: Teams often treat environment variables as a safe middle layer, but they are only a delivery mechanism. Secrets in process state can be exposed through logs, debugging, host inspection, or orchestration metadata, so environment variables reduce friction without reducing the underlying exposure problem.

Q: What should IAM and security teams do before scaling MCP adoption?

A: They should define a governance model for MCP identities before broad rollout, including secret lifecycle, access scope, audit logging, and revocation. If the server will be used by multiple users or tools, the identity design has to support delegated access, not a single shared static credential.

Technical breakdown

Static secrets in MCP server identities

MCP servers commonly authenticate with API keys, access tokens, or PATs because those credentials are easy to inject into runtime environments. The security trade-off is structural: long-lived secrets survive across deployments, are often copied into config files or environment variables, and are rarely scoped tightly enough to match actual tool usage. That makes each server a durable identity bearer rather than a short-lived delegated actor. In identity terms, the server is functioning like an NHI with persistence, not a transient request broker. Practical implication: treat every MCP credential as a production secret with lifecycle, scoping, and rotation requirements.

Practical implication: inventory MCP credentials as production secrets and remove them from static configuration wherever possible.

Why OAuth changes the MCP trust model

OAuth changes the trust model because it shifts from direct secret possession to delegated authorization. Instead of embedding a reusable credential inside the server, the server can operate with scoped tokens tied to user or app consent, which is closer to least privilege and easier to govern. That does not eliminate risk, but it reduces the blast radius of compromise and makes revocation and audit more tractable. In MCP environments, this matters because servers may serve multiple users and multiple tools. Practical implication: prefer delegated authentication patterns that let you revoke access without redeploying the server.

Practical implication: use delegated authentication patterns that support revocation and scoped access without changing the server binary.

Environment variables are not a control boundary

Passing secrets through environment variables is operationally convenient, but it is not a security boundary. Once a secret reaches the host environment, it can leak through logs, process inspection, debug tooling, crash dumps, or misconfigured orchestration layers. MCP makes this more visible because the server often acts as a runtime bridge between the user session and enterprise systems. The server is still an NHI, but the handling pattern is closer to hidden credential distribution than governed identity. Practical implication: move secret delivery to vault-backed runtime injection and audit where the secret exists after launch.

Practical implication: assume environment variables are exposure points and audit the runtime path, not just the repository.

Threat narrative

Attacker objective: The attacker wants durable tool access and downstream data reach through the MCP server’s privileged identity.

1. Entry occurs when an MCP server is deployed with hard-coded API keys, PATs, or other long-lived secrets embedded in configuration files or environment variables.
2. Credential access follows because those secrets can be copied from repositories, hosts, logs, or orchestration metadata and reused outside the intended server context.
3. Impact comes when the compromised credential lets an attacker operate tools, reach protected data, or abuse downstream systems through the MCP server’s delegated access.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static credential persistence is the core MCP governance failure. The research shows that MCP server deployments are still being built around long-lived secrets instead of delegated identity patterns. That is not just a deployment preference, it is a governance mismatch between AI runtime access and legacy secret handling. The practical conclusion is that MCP servers should be governed as production NHIs with lifecycle, not as convenience wrappers around copied credentials.

Ephemeral runtime identity is the only model that fits MCP at scale. When a server can be instantiated, used, and torn down repeatedly across users and tools, persistent secrets become a liability because they outlive the session that needed them. OAuth and vault-backed injection move the conversation from secret possession to controlled delegation, which is the right identity posture for tool-mediated AI systems. Practitioners should read this as a signal to re-evaluate where standing credentials still underpin agent workflows.

Environment-variable secret delivery creates hidden identity debt. This research makes clear that the exposure point is not only the repository, but the host runtime itself. Once secrets are loaded into process state, they become discoverable by more paths than most teams account for, and the identity boundary is no longer where policy expects it to be. That means the control gap is not just rotation, but the assumption that runtime placement equals secure governance.

Agent ecosystems are forcing NHI governance to move closer to application runtime. MCP is turning AI integrations into identity-bearing service paths, and that pulls NHI governance into places IAM teams have historically treated as engineering detail. The category is converging on a simple reality: if an AI system can act through a server, the server’s identity must be scoped, audited, and revocable like any other privileged non-human actor. Practitioners should align app security, IAM, and secrets governance around that shared control surface.

Secret sprawl is becoming a named operational concept for MCP. The combination of hard-coded values, environment variables, and non-expiring tokens creates a distinct form of identity debt that is broader than one server or one tool. This is not just insecure storage, it is distributed credential persistence across an emerging protocol ecosystem. The practical conclusion is that MCP security starts with eliminating secret sprawl before teams attempt broader agent governance.

From our research:

• 53% rely on static API keys or Personal Access Tokens (PATs), which are long-lived and rarely rotated, according to State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how far MCP governance still lags behind the identity model it depends on.
• If you are comparing this pattern with broader agent governance, OWASP Agentic Applications Top 10 helps frame the adjacent tool-misuse risk surface.

What this signals

Secret sprawl will become the default failure mode for early MCP programmes. The research makes clear that many teams are deploying protocol capability faster than they are modernising identity handling. When 53% of deployments still depend on static API keys or PATs, the next scaling problem is not adoption, it is control-plane debt. That is why teams should align MCP rollout with the Guide to the Secret Sprawl Challenge and treat runtime secret placement as a governance decision.

Credential scope and tool scope need to be designed together. If the server identity can reach tools that are broader than the business task, the protocol becomes a privilege amplifier instead of a delegation layer. That is where the governance line intersects with OWASP Top 10 for Agentic Applications 2026: tool access, identity scope, and runtime authorisation cannot be separated in AI-enabled environments.

MCP adoption changes the shape of NHI lifecycle work. Provisioning, revocation, and rotation now need to follow server instances and not just human ownership of a repository or app. In practice, that means teams should map MCP credentials into the same lifecycle control discipline they already apply to service accounts, certificates, and other high-value NHIs.

For practitioners

• Inventory every MCP server credential path Map where each server receives secrets, including repositories, .env files, CI variables, orchestration settings, and host-level injection points. Classify each as persistent, delegated, or ephemeral so you can see where static identity is still controlling runtime access.
• Replace hard-coded MCP secrets with vault-backed runtime injection Move credential retrieval out of code and configuration into a vault-driven launch path so the server never stores reusable secrets on disk or in source control. Validate the runtime path to ensure the secret exists only for the duration of the process that needs it.
• Prioritise OAuth or equivalent delegated access for MCP servers Use delegated authentication when downstream platforms support it so access can be scoped, revoked, and audited without redistributing secrets. This is especially important for multi-user AI workflows where a single credential should not represent open-ended server authority.
• Treat environment variables as exposure surfaces, not controls Review container, shell, and orchestration settings to determine where environment variables can be read, logged, or inherited. If a secret is present only because it was easier to pass at launch, assume it needs a stronger delivery and rotation model.

Key takeaways

• MCP server security is being built on long-lived secrets that outlive the sessions and workflows they were meant to support.
• The scale of the issue is already visible in the data, with static credentials dominating while OAuth adoption remains limited.
• Teams that scale MCP without delegated identity, vault-backed runtime injection, and scoped tool permissions will expand risk faster than control.

Key terms

• Model Context Protocol Server: An MCP server is a service that exposes tools and data sources to an AI assistant at runtime. In practice, it becomes an identity-bearing control point because it authorises the actions the assistant can take through the server, often on behalf of multiple users or workflows.
• Static Secret: A static secret is a long-lived credential such as an API key, PAT, or token that is reused across sessions. In MCP environments, static secrets are dangerous because they are easy to copy, hard to scope precisely, and remain valid long after the original deployment context has changed.
• Delegated Authentication: Delegated authentication lets a service act with scoped permission rather than with a reusable shared credential. For MCP, this matters because the server can reach enterprise systems without storing a permanent secret, improving revocation, auditability, and separation between the user session and the server identity.
• Secret Sprawl: Secret sprawl is the distributed accumulation of credentials across code, configuration, hosts, and pipelines. It becomes an identity governance problem when teams lose track of where secrets live, who can read them, and whether they can be revoked without disrupting production access.

What's in the full report

Astrix Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The full methodology behind how 5,205 open-source MCP server implementations were identified and filtered.
• The credential classification approach used to separate API keys, PATs, OAuth, and unknown patterns across the dataset.
• The MCP Secret Wrapper design and how vault-backed runtime injection changes the deployment path.
• The research appendix on GitHub search limitations and how that shaped the estimate of total MCP server implementations.

👉 Astrix Security's full post covers the methodology, credential breakdowns, and the MCP Secret Wrapper approach.

Deepen your knowledge

MCP server credential governance is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting from static secrets and environment-variable injection, that course gives you the governance baseline to move forward.