TL;DR: MCP servers break down when shell-exported secrets, shared tokens and ad hoc runtime access are carried into production, where rotation, auditability and multi-user control become mandatory, according to Doppler's guide. Secrets governance, not server convenience, becomes the deciding factor in whether MCP can scale safely.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Doppler's blog post: Secure MCP servers need centralized secrets, per-user access and rotation-ready operations to work in production.
Why it matters: IAM, PAM and platform teams need to govern MCP servers as production identity infrastructure because shared credentials and unmanaged runtime access create audit and blast-radius problems.
Context
Model Context Protocol becomes a governance issue as soon as the server stops being a local developer convenience and starts brokering access for multiple people, services and tools. Once that happens, secrets, tool exposure and request identity all need explicit control boundaries, not shell environment shortcuts.
The core failure mode is simple: secrets that are injected manually at startup are easy to use once and hard to govern repeatedly. Production MCP deployments need credential lifecycle discipline, runtime isolation and traceable access paths so the environment can survive review and incident response. secrets management belongs in the design from the start.
Key questions
Q: How should teams scope MCP server access for different users?
A: Scope MCP server access per user or workload by binding each session to a distinct identity, then issuing only the tool calls and resources that identity is allowed to use. Enforce OIDC validation for the caller, map claims to least-privilege entitlements, separate read and write tools, and log each request for revocation and audit.
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.
Q: How does zero-downtime secret rotation work for service credentials?
A: Zero-downtime secret rotation replaces a service credential before expiry without stopping the workload, by overlapping old and new secrets during a short grace period. The application must fetch secrets at runtime, reload them safely, and support dual validation where the server accepts both credentials until all clients have switched.
Q: What is the difference between dynamic secrets and static secrets in operational access control?
A: Dynamic secrets are issued for a limited time and are meant to expire after a task or session ends, which reduces the window of misuse. Static secrets persist until someone rotates them, so they require stricter manual oversight. For most modern environments, dynamic secrets better support ephemeral access, lower standing exposure, and tighter operational control.
Technical breakdown
Why shell-exported secrets do not scale in MCP runtimes
When an MCP server reads credentials from shell variables or baked-in environment files, the secret lifecycle becomes tied to deployment timing rather than security policy. That creates a static trust model: the token is assumed valid because the process started successfully, not because access is still appropriate. In production, that breaks rotation, revocation and audit requirements because the server cannot distinguish between the original credential state and the current one. The result is a runtime that cannot prove which secret was used, when it changed or whether old values are still active. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.
Practical implication: Move credential handling to a runtime-managed secret source so rotation and revocation are decoupled from redeployments.
How multi-user MCP access changes the identity model
A single-user local MCP process and a shared production deployment are different identity problems. In the local case, one person and one credential are often enough; in the shared case, the server must determine whose permissions the model is using for each request. That requires per-user or role-scoped credentials, plus OIDC-based validation so the server does not trust a client-supplied token blindly. Without that boundary, the server collapses multiple users into one access plane and cannot enforce least privilege or accountability per request. See the NHI Authentication Guide.
Practical implication: Bind every MCP request to a validated user or role context before the backend call is made.
What zero-downtime secret rotation requires in MCP production
Rotation-ready MCP design assumes credentials will change while the service stays up. That means the server must fetch secrets at runtime, refresh them without restart and invalidate old values without breaking live sessions. Hardcoded tokens, static .env files and image-baked secrets all defeat that model because they force access changes through code changes and redeployments. A production deployment needs a documented refresh interval, a revocation path for old material and a way to confirm the new secret has taken effect before the old one is retired. Read Guide to NHI Rotation Challenges.
Practical implication: Design the server so secret updates propagate live and old credentials can be revoked without service interruption.
Threat narrative
Attacker objective: The attacker wants to turn one exposed credential into broader tool access, backend reach and reliable execution inside the MCP deployment.
- Entry occurs when a leaked or shared MCP credential gives an attacker a valid path into the server or its backend integrations.
- Escalation follows when the compromised runtime exposes additional secrets, tools or downstream API permissions beyond the original request scope.
- Impact lands when the attacker can issue privileged actions, reach internal systems or exfiltrate sensitive data through trusted MCP flows.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Rabbit R1 hard-coded API keys 2024: Rabbit R1 source code leaked by an employee held working ElevenLabs, Azure, Yelp and Google Maps API keys; an email key was misused, Rabbit says.
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
Secrets governance, not server convenience, is the real production problem: MCP deployments fail when credential handling is treated as a startup detail instead of a lifecycle control. Shell-exported secrets, baked images and shared tokens all assume access is static enough to ignore after launch. In production, that assumption breaks under rotation, revocation and audit demands, so the control model has to move into runtime governance.
Per-user identity is the missing boundary in shared MCP deployments: A centralized server that cannot distinguish one engineer’s access from another’s turns every request into a pooled privilege event. OIDC validation and role-scoped credentials matter because they preserve accountability at the moment the model acts, not after the fact. This is the difference between delegated access and indistinct shared authority.
Rotation readiness is a blast-radius control, not just an operations task: The ability to replace a secret without stopping the service determines how quickly exposure can be contained. If a token cannot be revoked in place, the environment inherits the lifetime of the compromised credential. Practitioners should treat rotation latency as a design property, not a maintenance preference.
Runtime isolation gives MCP its security shape: Container boundaries, restricted egress and layered logging keep a compromised server from turning into a flat trust zone. The point is not only containment after compromise; it is to make every request path legible enough for audit and incident response. That is what separates production MCP from a developer experiment.
From our research library:
- Enterprises manage far more machine secrets than human ones: 20 times as many according to Enterprise Strategy Group, and 45 times according to GitGuardian.
- Read next: MCP Security Guide
What this signals
Secret governance will move closer to request time: Production MCP deployments cannot rely on startup-only credential injection once they serve multiple users, multiple backends and frequent rotation. The control point shifts from deployment configuration to the request path, which means credential validation, refresh and revocation need to be observable as part of normal operations.
MCP becomes an identity boundary as soon as it brokers tools for more than one user: The platform has to decide whether the request belongs to an individual, a role or a shared service account. When that decision is implicit, blast radius expands silently; when it is explicit, access reviews, logs and policy enforcement finally have something concrete to govern.
Runtime isolation is now a prerequisite for safe tool exposure: Container hardening, network egress limits and structured telemetry are the controls that keep one compromised server from becoming a broader trust failure. Practitioners should expect MCP governance to look more like production workload identity management than like local developer tooling.
For practitioners
- Replace startup-injected secrets with runtime-managed credentials Fetch secrets from a centralized system at request time or through a controlled refresh path, and remove .env files and image-baked values from production builds.
- Bind each MCP request to a validated user or role Use OIDC-backed identity validation and per-user or role-scoped credentials so the server can enforce least privilege per request instead of relying on one shared token.
- Test zero-downtime rotation before go-live Document a refresh interval, revoke old credentials without restarting instances, and prove that rotated values take effect while the service keeps running.
- Constrain tool exposure to the caller's permissions Dynamically return only the tools that match the authenticated user's role so destructive actions never appear to unauthorized callers.
- Instrument audit logs for credential use and tool activity Record who accessed the server, what was accessed and when, then centralize the logs so incident response can reconstruct the request path quickly.
Key takeaways
- MCP servers become a governance problem when local convenience patterns such as shell-exported secrets and shared tokens are carried into production.
- The production risk is not only compromise but also the inability to rotate, attribute and revoke access cleanly when a server serves multiple users.
- Safe deployment depends on runtime-managed secrets, validated user context, layered isolation and logging that supports incident response.
Related NHI Mgmt Group resources: Secrets Management Guide · Guide to NHI Rotation Challenges · MCP Security Guide · NHI Authentication Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | MCP deployments in this post depend on preventing leaked runtime secrets and baked-in credentials. |
| NHI-04 — Insecure Authentication | The article's per-user validation pattern depends on strong authentication for non-human access to MCP services. | |
| NHI-05 — Overprivileged NHI | Least privilege for MCP service accounts and tools is a central control theme in the source article. | |
| Recommendation — Scan MCP environments for exposed secrets and remove any credential source that can leak into logs, images or startup scripts. Require validated authentication for every MCP request and reject shared tokens that cannot be tied to a specific identity. Reduce MCP service permissions to the minimum backend scope and remove tools that exceed the caller's role. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing who can access which MCP tools and backends. |
| Recommendation — Enforce role-based entitlements for MCP access and review exposed tools against current authorization scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation and revocation are core to the article's MCP production guidance. |
| Recommendation — Manage MCP authenticators so they can be rotated, revoked and replaced without service interruption. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article's breach scenarios center on exposed tokens leading to broader access and internal reach. |
| Recommendation — Map leaked MCP credentials to credential access and lateral movement, then monitor for backend access expansion. | ||
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.
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- OIDC: OpenID Connect is a standard that lets applications verify a user’s identity through a trusted identity provider. It extends OAuth 2.0 with an identity layer, using ID tokens and claims so systems can authenticate users, share profile information, and support single sign-on across web, mobile, and API-driven environments.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
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.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org