MCP server access without OAuth still needs user governance

At a glance

What this is: This is a governance analysis of MCP access when the server has no OAuth support, showing that static service-account keys create user-level control gaps and push teams toward a gateway pattern.

Why it matters: It matters because IAM teams cannot treat MCP access like a normal shared integration when every developer, agent, and offboarding event is tied to the same credential.

By the numbers:

• 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.

Context

MCP access without OAuth creates a basic identity governance problem: the resource can be technically reachable, but the organisation still needs to know which person is using it, when access should stop, and how entitlement changes do not break everyone else. In practice, a single shared credential cannot answer those questions cleanly.

The pressure increases when developers run agents in their own environments. The credential moves out of a controlled integration layer and into laptops, config files, and other user-managed contexts, which makes offboarding, consent, and audit materially harder. That is why the issue is not just protocol support, but user governance around a non-user-aware resource.

The article’s starting position is typical of how MCP access problems surface in real teams: one key, many people, and no clean way to revoke access for one person without creating disruption for everyone else.

Key questions

Q: What breaks when one MCP service-account key is shared across many users?

A: Offboarding and revocation break first. If the same key is copied into many developer environments, removing one person means rotating a shared credential that affects everyone else, so teams keep the key alive and former users retain access. That creates a standing access problem, weak attribution, and a revocation process that no longer maps to the person who should lose access.

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 should security teams govern MCP OAuth flows in enterprise environments?

A: Treat MCP OAuth as an identity control plane, not a convenience layer. Bind authorization state to the initiating session, display clear consent context, restrict redirect URIs, and review every proxy-style client registration. If the server cannot prove who initiated the request and where the callback should go, it should not issue a usable authorization code.

Q: When does a gateway solve MCP governance, and when does it not?

A: A gateway solves the user-governance problem at the entry point, but it does not create per-record authority inside the upstream resource. If the exposed tool is a broad query surface, every entitled user still inherits the same backend permissions. That means the tool design and the upstream credential scope remain important limits.

Technical breakdown

Why a single MCP service-account key breaks user governance

When an MCP server authenticates with one shared key, the identity of the human using it disappears from the access model. The server sees one credential, not one person, so entitlement, offboarding, and audit all become indirect problems. That also makes lifecycle controls brittle: rotate the key and every dependent user is disrupted; leave it in place and former users can keep working. In identity terms, the resource is governable only at the credential layer, not at the user layer.

Practical implication: treat a shared MCP key as a governance failure mode, not just a convenience choice.

Why agent runtime makes secret exposure worse than old integration patterns

A traditional integration secret sat in a small number of controlled systems. An agent credential now follows the developer, often into local config files, synced environments, screen sharing, and other places where it can be copied or reused. The article also highlights prompt injection as a new read path, because text arriving in a tool result can be interpreted by the process that holds the credential. That changes the trust boundary around secrets: the agent becomes part of the exposure surface.

Practical implication: assume the credential is exposed to more endpoints than the MCP server itself.

How a gateway restores identity before upstream access

The gateway pattern interposes a control point between the user and the resource. The agent authenticates to the gateway, the gateway ties the session to a person, and only then does it present a credential upstream. Where the server supports OAuth, the user token can travel through the model cleanly. Where it does not, the gateway holds and decrypts a managed secret on behalf of the user, then records the action under that person’s identity. That does not give the resource per-record identity, but it restores per-person governance at the entry point.

Practical implication: move the decision about who may call the resource ahead of the server, not inside it.

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.
• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.

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

NHI Mgmt Group analysis

Static MCP credentials collapse user accountability at the point where governance is supposed to begin. A single service-account key shared across many developers turns one identity into many copies, which means offboarding becomes a blast-radius problem rather than a clean revocation event. The core governance assumption that access can be withdrawn per person fails once the resource only recognises one shared credential. Practitioners should treat that as a structural governance break, not a minor implementation weakness.

Agentic access makes secret handling materially different from older integration patterns. The article’s point is not that secrets are new, but that their distribution model has changed. When an agent runs in each developer environment, the secret follows the user and inherits the weakest storage and sharing habits of that environment. That is why the named concept here is credential copy proliferation: the more places a shared MCP secret must exist, the less meaningful central rotation becomes. Teams need to recognise that the secret’s lifecycle is now coupled to people, not just workloads.

The gateway model is a governance compensator, not a substitute for native resource identity. It restores user attribution, consent, and offboarding at the first control point, which is enough to make access administrable even when the upstream server has no concept of users. But the resource still receives a shared credential, so the residual risk moves inward to the tool surface and the permissions that credential already has. The practitioner conclusion is clear: govern the gateway tightly, but keep pushing for finer-grained authority at the resource itself.

This is the point where OAuth becomes a governance enabler rather than a protocol preference. The article shows that OAuth matters because it gives teams a way to bind actions to people and revoke one person without collapsing the entire workflow. Where the server cannot speak OAuth, the organisation has to recreate that property above the server. That shifts the design question from 'does the resource support OAuth' to 'where does identity get asserted in the chain?'

Internal bridges deserve the same scrutiny as external SaaS endpoints. The article correctly notes that bridges written for a single trusted caller often inherit broad credentials and minimal identity controls. That means the governance problem is not limited to vendor software; it appears anywhere teams wrap an API with an MCP layer and keep the original trust model. Practitioners should evaluate bridge design as an identity boundary, not just an integration pattern.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: MCP Security Guide

What this signals

Credential copy proliferation: When an MCP credential must live in every developer environment, the access model stops being a shared integration and becomes a user-distributed secret problem. That changes the control plane from server configuration to identity governance, because offboarding and rotation now depend on what people have already copied locally.

A gateway can restore user attribution before upstream access, which is the right compensating control when the resource cannot speak OAuth. The remaining question for practitioners is how much authority the shared backend credential already carries, because gateway governance cannot fix an overbroad upstream permission set.

Teams should expect MCP access governance to converge on patterns borrowed from IAM and PAM rather than from classical application integration. The practical signal is simple: if you cannot revoke one person without affecting ninety-nine others, the credential model is still doing the governance work that the identity layer should own.

For practitioners

• Define per-person entitlement at the gateway Make the gateway the place where a user is allowed or denied before any upstream MCP request is sent. Tie each request to a named person so offboarding removes only that person’s access.
• Inventory where MCP credentials live Map every location where the shared MCP credential exists, including config files, synced developer environments, and any bridge that reuses the same secret.
• Reduce the authority of shared upstream credentials Scope the credential held by the gateway or bridge to the smallest upstream permissions that still support the tool surface being exposed.
• Separate governable tools from broad query surfaces Prefer MCP tool surfaces that expose distinct actions, because a broad run_query style interface limits how much the gateway can govern once access is granted.
• Treat prompt injection as a secret exposure path Review whether agent-readable tool output can reveal or influence the process that holds the credential, then isolate that path from direct secret exposure.

Key takeaways

• A single MCP service-account key shared across many users turns access into a credential distribution problem instead of a per-person governance problem.
• The risk intensifies in agent-driven workflows because the secret now lives in user environments and can be exposed through more copy paths than a traditional integration.
• A gateway can restore user identity at the point of access, but teams still need to minimise upstream credential scope and narrow the exposed tool surface.

Key terms

• Gateway-mediated access: A privileged access model where a relay or gateway brokers the connection between a user and an internal resource. It reduces broad network exposure by constraining access to specific systems, while shifting governance onto session controls, resource inventory, and authorization policy.
• Credential copy proliferation: The spread of one secret across many user environments, devices, or processes until revocation and audit become difficult to manage. In MCP use cases, this creates a governance problem because access is distributed through people rather than contained in one controlled integration.
• Tool Surface: The tool surface is the set of commands, APIs and connected services an AI agent can invoke at runtime. It is a governance boundary because each tool expands what the agent can do, and therefore expands what an attacker can abuse if they gain control of the runtime.
• Upstream credential: A token, certificate or secret used by one service or workload to authenticate to another service. In AI toolchains, upstream credentials often sit behind the scenes, but they still require ownership, rotation and revocation because they can expose internal systems if reused or leaked.

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.