OAuth 2.1 is becoming the minimum for remote MCP security

At a glance

What this is: This analysis argues that remote MCP servers need OAuth 2.1, DCR, PKCE, and scoped tokens because unauthenticated or static-key deployments collapse identity boundaries for AI agent workflows.

Why it matters: IAM and NHI teams need to treat remote MCP as a governed access layer, because the protocol now sits between agents and the systems they can read, change, or exfiltrate.

Context

Remote MCP has become the access layer for AI agent workflows, which makes it part of identity governance rather than just a developer integration pattern. When MCP servers broker access to internal tools, databases, cloud infrastructure, and CI/CD systems, the security question is no longer whether the model can call a tool, but whether the calling identity is known, scoped, and revocable.

The governance gap is straightforward: many deployments still rely on static keys, environment files, or unauthenticated local transports. That leaves no consent boundary, no meaningful audit trail, and no practical way to separate legitimate agent activity from compromised or overreaching tool use.

For NHI and IAM programmes, this is the point where protocol design and access policy converge. Remote MCP changes the control surface from isolated secrets handling to lifecycle-managed identity, token scope, and delegated authorisation.

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 static secrets create problems for MCP deployments?

A: Static secrets break lifecycle governance because they are hard to review, rotate, and revoke at the same cadence as enterprise access. They also make it difficult to prove who authorised a tool call after the fact. For MCP, that means security teams lose both control and evidence.

Q: How should teams decide between long-lived API keys and OAuth 2.1 for remote MCP?

A: They should treat OAuth 2.1 as the default when MCP is exposed beyond a single local process. Long-lived keys can be acceptable only for tightly bounded prototypes, because they cannot express consent, scoped delegation, or time-limited trust in a way that scales to enterprise workflows. Once remote access is involved, OAuth 2.1 is the governance baseline.

Q: What signs show that MCP access is still being managed like a prototype?

A: Look for .env files, command-line secrets, wildcard scopes, and logs that show one credential calling every tool. Those patterns indicate that the platform is relying on possession of a static secret rather than a controllable identity lifecycle. In practice, that means the deployment has no meaningful separation between access grant and access use.

Technical breakdown

Why unauthenticated MCP deployments fail identity governance

A remote MCP server without an authorization layer behaves like a shared control plane with no subject attribution. Every request can look identical because the server sees the same static credential, or no credential at all, regardless of which agent, workflow, or operator initiated it. That destroys auditability and makes least privilege impossible to enforce at the protocol layer. In practice, the security model shifts from identity-based access to secret possession, which is a weaker and less governable boundary for enterprise workflows.

Practical implication: treat any remote MCP endpoint without token validation as a governance defect, not a configuration detail.

How DCR and PKCE change remote MCP trust

Dynamic Client Registration lets MCP clients register at runtime instead of preloading hardcoded client IDs and shared secrets. PKCE then protects the authorization code flow from interception, which matters because MCP clients may run in mixed, distributed, and partially controlled environments. Together, these mechanisms move the trust anchor away from embedded credentials and toward protocol-mediated registration plus proof-of-possession during the auth exchange. That is the architectural shift that allows remote MCP to work without baking long-lived secrets into every client.

Practical implication: require DCR and PKCE wherever clients are not centrally provisioned and controlled.

Why short-lived scoped tokens are the real control boundary

Short-lived tokens replace all-or-nothing access with a time-bounded, scope-bounded grant that can be reviewed and revoked. In MCP, that matters because a tool request may be harmless in read mode but dangerous in write or deploy mode, and the protocol should express that difference explicitly. Scoped tokens also reduce blast radius when a credential is exposed, because the access window is narrow and the privileges are constrained. Without that, one leaked key can impersonate an entire agent workflow indefinitely.

Practical implication: design MCP authorisation around minimal scopes and short expiry, not reusable platform-wide keys.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Remote MCP is now an identity boundary, not just an integration layer. Once an MCP server brokers access to CRMs, databases, cloud infrastructure, and CI/CD pipelines, the governance question becomes who or what is authorised to invoke those actions. Static credentials and unauthenticated transports collapse that boundary into secret possession, which is insufficient for enterprise control. Practitioners should treat remote MCP as part of the identity plane, not as a sidecar to application logic.

Static credentials create an identity blast radius that is larger than the tool itself. When the same credential is reused across workflows, the server cannot distinguish legitimate agent activity from compromise, and every call inherits the same trust level. That means revocation, attribution, and scope isolation all fail together. The practical conclusion is that MCP security is no longer about hiding keys, but about eliminating reusable trust at the protocol layer.

OAuth 2.1 makes remote MCP governable because it turns access into a lifecycle event. DCR, PKCE, and short-lived scoped tokens introduce registration, proof, and revocation points that align with IAM and NHI operations. This does not make MCP secure by default, but it does make control measurable and enforceable. Teams that keep treating tokens as implementation detail will miss the governance model the protocol now expects.

Ephemeral token scope is the named concept that matters most here. Remote MCP security hinges on whether access can be expressed as a short-lived, narrowly bounded grant rather than a standing credential. That concept is what separates prototype convenience from production governance, and it is the control premise that most deployments still violate. Practitioners should organise policy, review, and logging around issuance time, not around post-hoc secret discovery.

Agent workflows expose the weakness of assuming access can be reviewed after it is granted. MCP clients may obtain and use privilege in the same execution path, leaving little value in controls that depend on long-lived standing access. That shifts the discipline toward token issuance, consent, and correlation across systems. Identity teams should re-evaluate review cycles that assume access persists long enough to be certified.

From our research library:

• 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Static secrets are the wrong trust model for remote MCP. Remote tool access needs a subject, a scope, and an expiry, because the whole point of the control is to make every call attributable and revocable. When teams keep embedding credentials in configuration, they are preserving a prototype habit inside a production access path.

Ephemeral credential trust debt: The longer a credential can be reused, the more governance debt accumulates around attribution, offboarding, and blast-radius containment. That debt is now visible in MCP deployments because the protocol can move from shared keys to tokenised delegation, but only if teams actually adopt the model.

MCP security should now be reviewed as part of NHI lifecycle governance, because the question is no longer whether a tool can be reached, but whether the reaching identity can be constrained over time.

For practitioners

• Enforce OAuth 2.1 on every remote MCP server Require token validation at the resource server boundary and reject deployments that still depend on unauthenticated STDIO access or embedded static keys.
• Use Dynamic Client Registration for MCP clients Register clients at runtime instead of shipping hardcoded client IDs and shared secrets in env files, scripts, or onboarding docs.
• Make PKCE mandatory for every client flow Block authorization code flows that do not prove possession, especially where clients run on developer machines, desktops, or mixed-trust agent runtimes.
• Issue short-lived scoped tokens by default Replace wildcard or all-access grants with task-specific scopes and expiry measured in minutes, then log every elevation with correlation IDs.
• Audit remote MCP for secret-bearing configuration Search .env files, command-line arguments, and JSON configs for reusable credentials and treat any exposed secret as a standing access path until revoked.

Key takeaways

• Remote MCP security fails first as a governance problem when servers lack authentication, authorization, and auditability.
• Static credentials and long-lived keys create durable access paths that are hard to attribute, scope, or revoke once exposed.
• OAuth 2.1 with DCR, PKCE, and short-lived scoped tokens turns MCP access into a controlled lifecycle event instead of a standing trust relationship.

Key terms

• Remote MCP Server: A Remote MCP server exposes tools over a network so an AI client can discover and invoke them through a standard protocol. In security terms, it becomes part of the identity chain, because it brokers requests, handles authorization, and can expand the blast radius when its OAuth implementation is weak.
• 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.
• Session Token Exposure: Session token exposure occurs when authentication tokens or session artifacts are stored, transmitted, or logged in places they should not be. Once exposed, they can function like reusable credentials. This makes them part of identity and access risk, not only application behaviour.
• Identity Boundary: The point in an application where authentication and authorisation decisions are enforced. In Node.js systems, this often sits in APIs, middleware, and session handling code, making it the place where governance, runtime behaviour, and security evidence intersect.

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.