Static MCP tokens leave server access exposed for months

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Doppler's blog post: MCP server authentication depends on backend credentials, and static tokens create long-lived exposure that transport-level auth does not solve.

Why it matters: IAM and platform teams need to treat MCP server credentials as governed non-human identities, because backend access controls, revocation and auditability determine whether agent workflows are safe to operate.

By the numbers:

• Only 8.5% implement proper mechanisms for securing those credentials.
• Nearly 88% of model context protocol servers require authentication to external services.
• The access token is scoped to the permissions the user requests and usually expires within a limited timeframe, typically between 1 and 24 hours.

Context

MCP server authentication splits into two different problems: how the client reaches the server, and how the server reaches backend systems. Confusing those layers leaves organisations with a transport control that looks complete while the real credential risk remains untouched.

The governance gap is simple. A server can be properly reachable and still rely on static secrets, API keys, or passwords that behave like any other long-lived non-human identity credential. That is where revocation, auditability and blast-radius control either exist or fail.

MCP security only becomes meaningful when backend identity is treated separately from client transport and given its own lifecycle rules.

Key questions

Q: How do MCP servers authenticate to backend services?

A: MCP servers usually authenticate to backend services with OAuth access tokens, mutual TLS client certificates, or signed service account tokens presented at request time. The safest pattern is short-lived, scoped credentials bound to the server process, with audience checks, certificate validation, and revocation or rotation when the backend trust relationship changes.

Q: Why do static API keys and app-level permissions create risk in MCP deployments?

A: They grant access at the wrong level of abstraction. MCP workloads change tools, prompts, and data needs at runtime, so static credentials tend to authorize far more than the live task requires. The result is broad access to systems and records that should have been constrained to a narrower, context-aware request.

Q: How does workload identity reduce secret storage for machine access?

A: Workload identity reduces secret storage by replacing shared passwords and API keys with signed tokens issued to the workload at runtime. The workload proves its identity through a certificate, token exchange, or platform-attested identity, so applications can call other systems without keeping static secrets on disk or in configuration files.

Q: What is the safest way to rotate long-lived credentials used by servers?

A: The safest way is to rotate credentials through a managed secrets system that issues a new secret, updates the dependent service, verifies the new credential works, and then revokes the old one. For servers, this should use short overlap windows, automated deployment, and per-service credentials rather than one shared long-lived password.

Technical breakdown

MCP authentication has two different trust boundaries

The MCP specification separates client-to-server communication from server-to-backend access. The first boundary governs how a user, host or local process reaches the MCP server. The second governs how that server authenticates to GitHub, databases, cloud APIs or other backend services. Security breaks when teams stop at the first boundary and assume OAuth or local process trust solves the full problem. It does not. The server still needs durable or temporary credentials for backend calls, and that credential model determines exposure, revocation and audit behavior. See the NHI Authentication Guide.

Practical implication: Map client transport controls and backend credential controls separately, then verify that each boundary has its own authentication and revocation model.

Why static secrets fail inside MCP workflows

Static secrets fail because they couple access, storage and longevity. A GitHub PAT, database password or API key placed in a config file or environment variable remains usable until someone rotates it, and the same credential often spreads across local machines, CI systems and logs. That creates credential sprawl, poor traceability and a long exposure window after compromise. If the secret is also overprivileged, the blast radius grows beyond the original workload and into adjacent systems the MCP server can reach. See the Secrets Management Buyer's Guide.

Practical implication: Treat every long-lived backend credential in an MCP workflow as a revocable liability and scope it to the smallest feasible access pattern.

Short-lived credentials change the failure mode

OAuth, workload identity and runtime-fetched service tokens reduce the persistence of backend credentials. OAuth delegates access through scoped grants and produces time-bounded tokens. Workload identity removes stored secrets by letting the platform attest to the server’s identity with signed tokens. Runtime fetching from a secrets manager keeps the secret out of static files and reduces how long it lives in memory. These patterns do not eliminate credential risk, but they shift it from permanent storage to controlled issuance and expiry, which is much easier to govern. See the Secrets Management Guide.

Practical implication: Prefer issuance patterns that expire or federate credentials at runtime, and reserve static secrets only for systems that genuinely cannot support alternatives.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed backend credential into durable, reusable access through the MCP server’s trusted integrations.

1. Entry occurs when an attacker gains access to a leaked or overprivileged backend credential embedded in an MCP server workflow.
2. Escalation follows when that credential is reused beyond its intended scope, allowing the attacker to act through the server against external systems.
3. Impact arrives as branch manipulation, data access or token reuse across repositories, databases or cloud services that trust the same credential.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static backend credentials turn MCP servers into privilege amplifiers: Once the server can reach multiple backends, one leaked token becomes a reusable control plane for data access. That is not a transport problem, it is an identity lifecycle problem, because issuance, scope and revocation all determine the real blast radius. Practitioners should govern MCP server credentials as first-class NHI assets, not as configuration convenience.

Backend authentication is the real security boundary for MCP: Client-to-server trust can be correct while server-to-backend identity remains unsafe. The result is a false sense of completion, where OAuth on the transport path masks static secrets deeper in the workflow. Teams should evaluate MCP server risk by the credentials it presents to external systems, not by the protocol layer they can see first.

Ephemeral credential governance replaces secret persistence as the design goal: Static token handling was designed for a world where access could be reviewed after the fact. That assumption fails when a server needs to authenticate repeatedly across tools, hosts and sessions without a stable human operator. The implication is that governance must move to issuance time, with short-lived credentials, scoped grants and clear offboarding for machine access.

Blast radius, not authentication style, is the decisive variable: OAuth, workload identity and secret managers are different mechanisms, but they all matter because they constrain how far a stolen credential can travel. The useful question is not whether a token exists, but whether its misuse can be contained to one workflow or one session. Practitioners should align MCP authentication patterns to the narrowest reachable blast radius.

MCP secret sprawl is a governance debt, not just an implementation bug: Exporting secrets into .env files, CI systems and chat channels creates distributed custody with no reliable owner. That pattern outlives the team that created it and makes audit trails fragmentary. The operational conclusion is that every MCP deployment needs explicit ownership of backend credentials across creation, use, rotation and retirement.

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.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Guide

What this signals

Credential persistence is the real MCP exposure pattern: When a server keeps backend secrets in files, environment variables or memory for long periods, the issue is not just leakage but the inability to constrain how long a compromised credential remains useful. The governing model has to move from stored secrets to time-bounded issuance.

MCP programmes that treat transport authentication as the finish line will miss the deeper risk. The practical shift is toward backend identity lifecycle controls, especially scoped grants, revocation hooks and offboarding for service credentials.

Secret sprawl becomes operational debt quickly: Once tokens move through CI, logs and developer machines, the organisation loses a clear answer to where the secret exists and who can still use it. That is why runtime credential delivery matters more than static placement.

For practitioners

• Audit backend credentials separately from transport auth Inventory every secret, token and password an MCP server uses to reach external systems, then classify each one by owner, scope, rotation cadence and revocation path.
• Replace long-lived secrets with scoped issuance patterns Use OAuth, workload identity or runtime-fetched credentials wherever the backend supports them, and keep static credentials only where no safer alternative exists.
• Remove shared credentials from multi-user MCP setups Stop using one account token across multiple engineers or agents, and tie each session to a distinct identity so misuse is traceable and revocable.
• Redesign logging to exclude bearer material Sanitize request logs, debug traces and memory dumps so headers, secrets and tokens cannot be reused by anyone with log access.
• Define offboarding for machine access Revoke backend credentials when a human owner departs or a workflow is retired, and verify that no MCP server still depends on the stale access path.

Key takeaways

• MCP server risk is concentrated in backend authentication, where long-lived credentials can outlast the workflow they were meant to protect.
• The strongest evidence in the source is the gap between broad external-service authentication and proper credential protection, which leaves static secrets exposed.
• Practitioners should govern MCP credentials as non-human identities, with scoped issuance, revocation paths and offboarding that do not depend on manual cleanup.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Static vs Dynamic Secrets · API Key Management Guide · MCP Security Guide · Secrets Management Guide

Key terms

• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

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.