TL;DR: MCP servers still often rely on API keys, while OAuth support remains uneven and implementation-heavy, with about 60% requiring a key passed on every request, according to WorkOS. That means the security problem is not just authentication choice, but how identity, consent, and token handling are governed across tool-connected AI workflows.
At a glance
What this is: This is an analysis of why MCP server authentication still defaults to API keys or complex OAuth flows, and why that creates secret exposure and governance friction in tool-connected AI workflows.
Why it matters: It matters because IAM teams now have to govern how non-human identities obtain, store, and use tokens inside MCP-connected automation, not just whether an app can authenticate users.
By the numbers:
- Most MCP servers, around 60%, require an API key that gets passed through on every request.
Context
MCP server authentication is the control layer that decides how an AI-connected tool server proves identity and receives permission to act on a user's behalf. In this article, the problem is not whether MCP can connect agents to tools, but whether the authentication pattern introduces secret exposure, brittle token handling, and consent complexity that security teams can actually govern.
WorkOS frames OAuth as the preferred path for MCP, but the operational burden remains uneven because many implementations still default to API keys or require custom OAuth work. That leaves teams with a familiar identity problem in a new place: access tokens, consent flows, and permission scope now have to be managed across AI tool calls, not just traditional web sessions.
Key questions
Q: What breaks when API keys are used as the main MCP credential?
A: Persistent API keys create a standing secret that can outlive the task, the session, and sometimes the user who triggered it. If that key is copied, logged, or reused, the server has no built-in way to distinguish legitimate use from abuse. Short-lived credentials reduce that exposure window.
Q: When do MCP authentication flows create more risk than they reduce?
A: They create more risk when they rely on broad tokens, duplicated policy logic, or unclear delegation chains. If an agent can reuse access across tools or tenants without tight scoping and logging, the authentication layer becomes a distribution mechanism for over-permissioned access instead of a control.
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.
Q: Should teams build their own MCP auth layer or use an OAuth bridge?
A: Teams should only build custom MCP auth when they can support the full OAuth lifecycle, including registration, consent, token issuance, and verification, with the same discipline as any other production identity boundary. If not, an OAuth bridge is the safer pattern because it reduces protocol handling mistakes without removing governance requirements.
Technical breakdown
Why API keys remain the default in many MCP deployments
An API key is a static secret presented with each request, which makes it easy to implement but hard to govern once the client is an AI workflow. In MCP, that means the secret may be exposed to the client layer and any underlying model or orchestration path, while the server has little context about user intent, consent, or scope at request time. The article notes that many servers still use this model because it is faster than building OAuth correctly, but that speed comes with a governance trade-off: the credential itself becomes the control plane. Practical implication: treat every API-key-based MCP integration as a secrets-management problem, not just an authentication shortcut.
Practical implication: treat every API-key-based MCP integration as a secrets-management problem, not just an authentication shortcut.
How OAuth bridging changes the authentication boundary
OAuth shifts MCP from static secret reuse to delegated access, where the server can request tokens tied to user consent and defined scopes. The article describes WorkOS Connect as an OAuth bridge that lets an MCP server rely on an existing authentication system while the bridge handles consent, token issuance, and token verification. That architecture matters because it separates identity proofing, delegation, and token management, instead of forcing the MCP server to implement each part itself. For IAM teams, the key design question is whether the MCP server is acting as an authorization endpoint, a delegated client, or an over-privileged proxy. Practical implication: map the token issuance and verification path before enabling MCP access to production data.
Practical implication: map the token issuance and verification path before enabling MCP access to production data.
Why dynamic client registration and consent flows are the hard part
The article highlights dynamic client registration, grant types, and consent flows as the parts of OAuth that are easy to underestimate and difficult to implement safely. In MCP, those pieces are not cosmetic. They determine which client is allowed to register, what the user is approving, and how the resulting access token is bound to the right application and scope. When those steps are improvised, the result is not just friction but a broader authorization boundary with weak traceability. Practical implication: review whether your MCP implementation can register clients, collect consent, and validate grants without relying on custom one-off logic.
Practical implication: review whether your MCP implementation can register clients, collect consent, and validate grants without relying on custom one-off logic.
Threat narrative
Attacker objective: The objective is to obtain a reusable credential that can be used to invoke MCP-backed APIs and services on behalf of the victim user or application.
- Entry occurs when an MCP server relies on an API key that is passed through on every request, exposing a static secret to the client path.
- Credential access follows because the key or token must be stored, reused, and managed outside the server's own trust boundary.
- Impact occurs when that reusable credential gives the connected client or workflow broader access to APIs and user data than intended.
Breaches seen in the wild
- 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 and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP authentication is really a non-human identity governance problem. Once an MCP server can act on behalf of a user inside an AI workflow, the issue is no longer just whether the login works. The issue becomes how consent, token scope, and secret handling are controlled across machine-mediated actions. That places MCP squarely in the NHI governance domain, where the lifecycle of access matters as much as the initial authentication method. Practitioners should stop treating MCP auth as a developer convenience layer and start treating it as a governed access boundary.
Static API keys are a form of identity debt in tool-connected AI systems. The article's 60% figure is not just a deployment statistic, it is evidence that many MCP integrations still depend on reusable secrets that were never designed for distributed AI access. Those secrets increase exposure when they are passed through clients, stored for convenience, or shared across workflows. The practical lesson is that secret sprawl and MCP adoption now reinforce each other unless access is re-anchored in delegated, reviewable authorization.
OAuth complexity is not incidental, it is where the control lives. The hard parts named in the article, such as dynamic client registration, grant types, and consent flows, are exactly the points that determine whether delegated access is bounded or brittle. In identity terms, these mechanisms define who the client is, what it can request, and how long that permission remains valid. Practitioners should treat implementation shortcuts here as governance shortcuts, because the security boundary is being encoded in protocol handling rather than policy.
MCP creates a new bridge between human consent and machine execution. Users approve access, but the actual calls are executed by tooling and models that can fan out across APIs, data sources, and product surfaces. That makes the quality of the delegation chain more important than the login event itself. Identity leaders should evaluate MCP as part of their broader human-to-machine access model, because the same consent can now drive actions that look machine-native but carry human authorization.
Named concept: delegated tool-access boundary. MCP deployments need a clear boundary between user consent and downstream tool execution, because otherwise the AI client becomes a proxy with ambiguous authority. That boundary is what keeps token issuance, scope, and revocation understandable when the server is operating through multiple layers of software. Practitioners should define that boundary explicitly before MCP reaches sensitive production systems.
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.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Delegated tool-access boundary: MCP forces identity teams to define where human consent ends and machine execution begins. Without that boundary, access tokens become proxy credentials that can move further through the tool chain than the original user ever intended. That is the governance gap most teams will miss if they treat MCP auth as a developer-only decision.
The practical test is whether an MCP integration can express least privilege at issuance time instead of hoping to recover it later through review. When access is mediated by AI tooling, review cycles are weaker than issuance controls because the risky act is often the token grant, not the later use of the token.
For practitioners
- Define the MCP delegated access boundary Document which identity is issuing consent, which component receives the token, and which downstream APIs the MCP server may invoke on behalf of the user.
- Replace static API keys in MCP flows Remove request-by-request API keys where possible and move MCP access to scoped, revocable OAuth tokens tied to user consent.
- Review dynamic client registration handling Check whether your MCP implementation can safely register clients, handle grant types, and validate consent without custom one-off logic.
- Map token lifecycle ownership Assign clear ownership for issuance, refresh, revocation, and rotation so MCP access does not outlive the user or application context.
- Test the server-side trust boundary Verify that the MCP server only accepts tokens it should trust and does not rely on secrets embedded in the client path or model workflow.
Key takeaways
- MCP server authentication is now a governance problem because consent, token scope, and secret handling are part of the AI tool path, not separate from it.
- Static API keys remain common enough to create avoidable exposure, especially when credentials are passed through clients and reused across requests.
- OAuth bridges reduce implementation burden, but the real control question is whether token issuance, registration, and revocation are tightly owned and auditable.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | MCP API keys and tokens are exposed to clients and tool chains, making leaked secrets central to the risk. |
| NHI-04 — Insecure Authentication | The article focuses on whether MCP servers authenticate and authorize access safely. | |
| NHI-07 — Long-Lived Secrets | Request-passed API keys are long-lived credentials that persist beyond any single MCP action. | |
| Recommendation — Eliminate static MCP secrets and move access to scoped, revocable delegated credentials. Enforce end-to-end authentication for MCP clients, consent, and token verification. Shorten credential lifetime for MCP access and remove static keys where OAuth is possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP access scope is an authorization problem that determines what connected tools can do. |
| PR.DS-01 — Data-at-Rest Integrity and Confidentiality | Tokens and secrets must be protected because they govern access to sensitive user data. | |
| Recommendation — Scope MCP entitlements to the minimum access required for each delegated action. Protect MCP credentials with controls that limit disclosure and misuse. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed credentials in MCP flows can enable access to multiple connected systems. |
| Recommendation — Treat exposed MCP credentials as credential-access risk and restrict their use to prevent lateral movement. | ||
Key terms
- MCP Server Authentication: MCP Server Authentication is the process of proving that a client, agent, or tool is allowed to connect to an MCP server. In practice, it uses credentials, tokens, or other trust signals to verify identity and authorize access to exposed tools, resources, and context, reducing unauthorized agent-to-system interaction.
- OAuth bridge: An OAuth bridge is an intermediary layer that connects an application or server to an existing identity system without rebuilding the full authorization flow. In MCP environments, it translates login, consent, and token issuance into a controlled path that the server can validate for scope and audience.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
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 June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org