MCP authentication gaps expose secrets and service accounts

At a glance

What this is: This digest shows that MCP deployments are failing at authentication, secret handling and detection, with multiple examples of bypassable identity checks and hidden credential exposure.

Why it matters: IAM and NHI teams need to treat MCP endpoints, gateways and configuration files as governed identity surfaces because weak validation can turn a tool call into service account abuse or secret theft.

Context

MCP security is no longer just a protocol discussion. The control failures described here are identity failures: bearer tokens accepted when they should be rejected, session identifiers accepted on format alone, and configuration files used as secret stores instead of governed credential inventory.

The governance gap is that MCP deployments often assume the gateway or scanner is the boundary of trust. In practice, the real boundary is the credential, the session, and the tool invocation path, which means authentication must hold up across every hop, not only at the edge. See MCP security guide for the protocol mechanics behind that boundary.

Key questions

Q: What breaks when MCP servers do not require authentication?

A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.

Q: Why do skipped issuer checks and fallback logic increase MCP risk?

A: They let the system trust a request before it has established where that request came from. In MCP, that matters because a malicious server can steer a client into sending secrets or authorization material to the wrong endpoint. Once issuer validation is bypassed, the attacker is no longer guessing credentials, they are collecting them.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should teams govern intermediary gateways in MCP deployments?

A: Treat the gateway as a separate trusted actor with its own permissions and accountability. Do not assume that direct server ACLs cover delegated access, because the gateway may need to represent users or agents through token exchange and therefore deserves its own policy boundary.

Technical breakdown

Why bearer-token validation fails in MCP gateways

MCP gateways can fail when they treat any syntactically valid token as sufficient proof of identity. If issuer validation, audience checks, or per-hop reauthorization are skipped, a hostile server or malformed client can still obtain access to tools and backend resources. In the article's examples, that turns a gateway into a trust amplifier rather than a control point. The real problem is not the token format itself, but the decision to equate presence of a token with legitimacy. Practical implication: validate token provenance and reauthorize inside the tool path, not only at the gateway. See the NHI Authentication Guide. See the NHI Authentication Guide.

Practical implication: validate token provenance and reauthorize inside the tool path, not only at the gateway.

How forged session IDs and service accounts become a proxy path

A session identifier is not an identity unless the server binds it to a trusted authentication context. If validation checks only format, an attacker can manufacture a session token that the server accepts and then inherit whatever service account privileges the server attaches to that session. In MCP, this creates a privileged proxy pattern: the caller is not directly holding the service account, but can still act through it. That is why service-account exposure in an MCP server is materially different from a normal application bug. Practical implication: bind sessions to issuer-verified identity and treat service-account-backed servers as privileged access paths. Read the Ultimate Guide to NHIs.

Practical implication: bind sessions to issuer-verified identity and treat service-account-backed servers as privileged access paths.

Why secret scanners miss MCP configuration leakage

MCP configuration files often contain credentials in forms that are hard for generic secret scanners to recognise. If the token shape is non-standard, embedded in nested config, or reused across multiple slots, scanners can report a clean result while the actual credential remains live and usable. That is an inventory failure as much as a detection failure: if you do not classify MCP configs as credential stores, you will not govern them like credential stores. Practical implication: discover MCP configs, classify their secret fields, and scan for secrets that do not match common token patterns. See the Service Account Security Guide. See the Service Account Security Guide.

Practical implication: discover MCP configs, classify their secret fields, and scan for secrets that do not match common token patterns.

Threat narrative

Attacker objective: The attacker wants to turn weak MCP authentication into reliable access to tools, secrets, and backend systems without using a legitimate user credential.

1. Entry begins when a malicious MCP server or exposed endpoint exploits weak authentication handling, such as invalid bearer tokens being accepted or an OAuth fallback skipping issuer validation.
2. Credential access follows when the attacker captures client secrets, authorization codes, PKCE verifiers, or invokes tools through a forged session tied to a service account.
3. Escalation occurs when gateway routes, pass-through endpoints, or backend tool permissions let the attacker move from authentication bypass into broader cloud or system access.
4. Impact is achieved when the attacker reaches cloud compromise, data exposure, or arbitrary code execution through the trusted MCP path.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.

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

Identity validation, not tool execution, is the control plane for MCP security: The article's examples all fail before the tool is even used, which means the real control gap sits in authentication and trust binding rather than in downstream logic. A gateway that accepts invalid tokens or session formats has already conceded the identity decision. Practitioners should treat MCP authentication as a first-class governance boundary, not a helper function.

Secret sprawl is the hidden NHI problem inside MCP adoption: Configuration files with embedded credentials are not just an operational smell, they are an unmanaged NHI estate in miniature. When 55% of secrets do not match recognizable token shapes, conventional secret detection loses visibility exactly where governance is needed most. That is a credential inventory problem, not merely a scanner problem.

Clean scanner results do not establish trust in MCP servers: The article shows hostile servers passing multiple scanners while still carrying payloads in handler code or metadata. That means assurance based on single-point inspection is structurally weak for tool ecosystems, especially when malicious behavior can be fragmented across descriptions, results and runtime messages. Practitioners should stop treating a clean scan as a deployment decision.

MCP exposes a governance assumption that was built for stable, reviewable identities, not opportunistic runtime trust: Least privilege was designed for known identities and bounded access paths. That assumption fails when a malicious server can induce fallback logic, forge sessions, or hide secrets in configuration because the access decision is being made after the trust boundary has already been crossed. The implication is that identity governance for MCP must be anchored in issuance and provenance, not just review cycles.

CoSAI's MCP security model signals category maturation, not closure: Formal assurance levels help separate toy deployments from regulated multi-tenant environments, but they do not erase the operational reality that protocol, gateway and secret-management failures can still chain together. The market is moving toward auditable MCP governance, yet the burden remains on practitioners to decide which deployment tier they actually operate in and what controls that tier demands.

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 trust is now the core MCP governance issue: MCP deployments increasingly fail when trust is inferred from transport, route shape or scan output instead of from identity-bound verification. The control model has to move toward per-hop authentication, explicit reauthorization and secret inventory because the protocol itself makes tool access highly dynamic.

Ephemeral tool trust debt: When MCP configs, gateways and scanners all assume the next layer will catch a mistake, the organisation accumulates hidden trust debt that only surfaces after a malicious tool call. That debt grows fastest where teams are scaling remote MCP servers faster than they can classify their identities, secrets and routes.

Organizations that adopt MCP should expect the assurance burden to rise with scale, not fall. The more remote servers, delegated tools and fallback paths you add, the more you need governance that separates syntactic validity from real provenance.

For practitioners

• Audit MCP authentication paths end to end Trace every hop where bearer tokens, session identifiers, OAuth codes or PKCE values are accepted, transformed or forwarded, and remove any path that does not perform issuer-aware validation.
• Replace prefix-based gateway checks with allowlists Review route matching, composite endpoints and fallback logic so that a single missed path cannot reopen access to restricted MCP servers or tool calls.
• Classify MCP configuration files as credential stores Inventory public and internal MCP configs, identify every credential field, and treat secrets embedded in those files as governed assets rather than developer preferences.
• Require reauthorization inside each tool Do not rely on gateway approval alone. Recheck authorization at the tool boundary so a bypass in one control layer does not become data access or cloud compromise.
• Rotate and remove default keys immediately Eliminate default master keys and stale service credentials from exposed proxies and gateway deployments, then verify that no fallback path still accepts them.

Key takeaways

• MCP security failures in this digest are identity failures first, because weak token handling and forged sessions let attackers cross the trust boundary before tool logic ever runs.
• The exposed secret problem is material, with 24,008 unique secrets found in MCP configuration files in 2025 alone.
• Practitioners should govern MCP like a credentialed access surface, with per-hop validation, inside-the-tool reauthorization and configuration inventory that treats secrets as managed assets.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Service Account Security Guide · Dropbox Sign breach 2024

Key terms

• MCP Authentication Boundary: The point at which an MCP system decides whether a caller is allowed to discover tools, invoke actions, or forward credentials. In practice, this boundary must be identity-bound, issuer-aware, and checked at more than one layer because gateway trust alone is easy to bypass.
• Output Spoofing: Output spoofing is the act of feeding a system false command results so it behaves as if a trusted process produced them. In AI workflows, the model may accept spoofed output as ground truth and take the wrong next step. This becomes dangerous when the output channel is predictable, unverified, or shared.
• Secrets Inventory: A secrets inventory is the structured record of where credentials exist, who owns them, and whether they are still valid. It is foundational to remediation because detection alone does not reduce risk unless teams can trace exposure, assign ownership, and revoke access quickly.
• Gateway Reauthorization: A second authorization decision taken closer to the tool or resource itself rather than only at the entry gateway. For MCP, this reduces reliance on one perimeter check and helps prevent a bypass from turning into unauthorized backend access.

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 building or maturing an IAM programme, it is worth exploring.