MCP server security is still built on static secrets

At a glance

What this is: Astrix Security’s research shows that MCP server adoption is scaling on long-lived credentials, with static secrets still dominating and OAuth remaining rare.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as an identity governance problem because delegation, credential storage, and runtime access patterns are being established before secure controls become default.

Context

MCP server security is a credential governance problem, not just a protocol adoption story. When servers depend on API keys, PATs, and other long-lived secrets, the security model inherits the weaknesses of static non-human identity handling from the start.

Astrix Security’s research looks at more than 5,200 open-source MCP server implementations and shows that credential dependency is the norm, while secure delegation methods remain limited. The gap matters because MCP is increasingly used to connect AI agents to tools and data sources, which makes the identity layer part of the operational control plane.

For IAM and NHI programmes, the central issue is where secrets live, how they are injected, and whether the runtime model assumes a credential can be safely reused. That assumption becomes fragile as MCP spreads across repositories, environments, and agent workflows.

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. In MCP environments, that means the server can keep working long after the original trust decision should have expired, which widens the blast radius of a leaked or reused secret.

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. Once it lives in a file or environment variable, it can be copied, inherited, and reused outside the original approval context, which turns one integration choice into persistent access risk.

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. If a server cannot explain which user or workload owns which access path, the authorization model is too coarse for enterprise use.

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.

Technical breakdown

Why static secrets dominate MCP server deployments

MCP servers are designed to call tools and data sources on behalf of a client, which means they need credentials somewhere in the chain. In practice, many implementations use API keys or PATs because they are simple to wire into configuration files and environment variables. That convenience creates a weak identity posture: the secret is reusable, often long-lived, and detached from a strong issuance and revocation lifecycle. OAuth changes the model by introducing delegated access with a more explicit identity relationship, but adoption is still low because it adds integration and token-management complexity.

Practical implication: Treat every MCP server that consumes a static secret as a governed NHI and track it like any other long-lived machine credential.

Why environment variables are not a security boundary

Passing secrets through environment variables is operationally common, but it does not make the credential ephemeral or well governed. The secret still exists on the host, can be inherited by child processes, and can leak through logs, debugging output, crash dumps, or misconfigured orchestration. In MCP environments, that matters because the server often runs close to the workload that needs access, which expands the exposure surface. Environment variables are a delivery mechanism, not a control. If the secret itself is static, the storage pattern changes the location of risk, not the risk class.

Practical implication: Assume any MCP credential injected through environment variables is exposed unless the host, runtime, and retrieval path are explicitly controlled.

What OAuth changes for MCP authorization

OAuth introduces delegated authorization instead of handing a server a reusable secret with broad implied trust. For MCP, that matters because the server may need to act for multiple users or sessions, and the identity relationship has to survive that delegation without collapsing into a shared token pattern. OAuth also makes token scope, expiry, and revocation observable in ways static keys do not. But OAuth only helps if the implementation actually manages client registration, token lifecycle, and per-user delegation correctly. Without that, the system still behaves like static secret infrastructure with a different label.

Practical implication: Use OAuth where possible, but verify token scope, rotation, and per-user delegation instead of assuming the protocol itself enforces them.

Threat narrative

Attacker objective: The attacker’s objective is to reuse a leaked or overexposed MCP credential to access downstream services and perform actions through the server’s trusted identity.

1. Entry begins when an MCP server is configured with a static API key, PAT, or other long-lived secret that grants access to downstream services.
2. Credential exposure follows when those secrets are stored in configuration files or environment variables on hosts that are easier to inspect, copy, or reuse.
3. Escalation occurs because the same credential can often be replayed across multiple requests or systems without a fresh approval step or expiry boundary.
4. Impact is the ability to invoke tools, access protected data, or abuse delegated actions through the MCP server’s identity path.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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 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.

Ephemeral runtime injection is a better trust pattern than persisted secret storage: pulling credentials from a vault at runtime reduces how long a secret sits exposed on a host, but it does not solve authorization design by itself. It shifts the control point from file or environment storage to issuance-time handling, which is where the real policy boundary belongs. The practitioner conclusion is that runtime retrieval must be paired with scoped access and clear ownership.

OAuth adoption is a signal that MCP is moving toward managed delegation, not a finished control state: 8.5% adoption is still too low to assume the ecosystem has normalised secure authorization. That gap shows how much of the market is still relying on coarse credentials instead of per-user or per-session delegation. The practitioner conclusion is to challenge any MCP rollout that cannot explain its delegation model end to end.

Identity blast radius is now a protocol-level concern: the article’s findings show that one weak MCP server can become a shared access path into many tools, accounts, and data sources. Because MCP is central to AI agent connectivity, credential misuse no longer stays local to a single integration. The practitioner conclusion is to assess MCP through blast-radius and privilege scope, not just through individual server hardening.

MCP adoption is ahead of NHI governance maturity: the research makes clear that the ecosystem is scaling faster than its identity discipline. That means teams cannot wait for the protocol community to standardise secure patterns before they set their own controls. The practitioner conclusion is to impose enterprise governance on MCP secrets, delegation, and revocation now.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Runtime secret injection is the practical floor for MCP governance: when a server can fetch credentials from a vault at execution time, the team at least removes one durable exposure point from host storage. That does not make the server safe on its own, but it changes the control problem from secret sprawl to managed issuance, which is where IAM and NHI programmes can actually enforce policy.

Static credential inheritance is the wrong default for agent-connected services: MCP servers sit close to the execution boundary of AI agents, so a single shared secret can extend trust across many actions and contexts. Security teams should treat that as a privilege design problem, not just a configuration problem, because the blast radius follows the credential path.

Model Context Protocol authorization should be judged by delegated trust quality, not protocol adoption alone: the difference between a shared PAT and a scoped delegated token is the difference between unmanaged reuse and reviewable access. For practitioners, the signal to watch is whether every MCP integration can prove per-server ownership, expiry, and revocation.

For practitioners

• 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. If ownership is unclear, the server is already outside governance.
• 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. Pair that with short expiry and revocation controls.
• 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.
• Constrain host-level secret exposure Harden the runtime so environment variables, debug logs, crash dumps, and process inspection do not turn an MCP secret into an easy extraction path.
• Classify MCP servers by privilege scope Separate read-only servers from write-capable or sensitive-data servers and apply stricter review to any integration that can change records or trigger actions.

Key takeaways

• MCP server adoption is being built on long-lived credentials that are easy to distribute but hard to govern.
• The research shows that static secrets and environment-variable delivery are still the dominant pattern, which increases the exposure surface for agent-connected services.
• Teams should move MCP integrations toward runtime secret retrieval, delegated authorization, and explicit ownership before the ecosystem’s default trust model hardens further.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
• Secret Injection At Runtime: A method of supplying credentials only when a job or workload starts, rather than storing them in code or static configuration. This reduces the persistence of secrets in repositories and build artifacts, but it only works when lifecycle controls and rotation are enforced.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.