MCP server access without OAuth still needs user governance

At a glance

What this is: This is a governance analysis of MCP server access when the server has no user concept, showing why shared service-account keys break offboarding and auditability.

Why it matters: It matters because identity teams now have to govern agent-mediated access paths that blend human entitlement, NHI credentials, and tool-level authorisation across endpoints and internal bridges.

By the numbers:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.

👉 Read Hush Security's analysis of MCP access when servers have no user concept

Context

MCP server access becomes an identity problem when the resource has no concept of users and the same credential is copied into many developers' environments. In that model, the security team is not just protecting a secret, it is trying to preserve offboarding, audit, and least-privilege boundaries across a shared non-human credential.

The article argues that this gets worse as agents run in individual developer environments, because the credential footprint now follows headcount rather than the number of integrations. That makes the access model look more like distributed NHI sprawl than classic centralised application onboarding, especially when the upstream server cannot issue per-user OAuth tokens.

The practical question for IAM and NHI programmes is whether identity must be asserted before the call reaches the resource. If the answer is yes, the control point has to sit in front of the server, not inside it, which changes how teams think about gateways, consent, audit trails, and entitlement revocation.

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 teams decide between a broad MCP tool and a narrow one?

A: Choose the narrowest tool that still supports the business task. Broad tools collapse many actions into one permission boundary, which makes consent, review, and least privilege far weaker. Narrow tools give the gateway and the policy layer something real to enforce, especially when the upstream server itself has no native user model.

Q: What does identity-aware gating change for offboarding in agent-based access?

A: It changes offboarding from a credential rotation event into a person-level entitlement event. The right design lets teams remove one user without breaking everyone else who relies on the same upstream capability. That is the difference between access that is operationally shared and access that is governed by identity.

Technical breakdown

Why static service-account keys fail for MCP server access

A static service-account key works only when a small number of integrations share it and the operator can rotate it without disrupting a workforce. Once that key is copied into many local environments, the credential becomes both a deployment dependency and an access token, which creates a revocation problem: removing one person means breaking everyone else. MCP intensifies this because the agent lives close to the credential, often in a laptop config file or synced environment, so the secret is exposed to more handling paths than a traditional CI secret.

Practical implication: Treat shared MCP keys as a governance failure mode, not just a secret management issue.

How an identity gateway restores user context before upstream access

A gateway pattern inserts a control point between the agent and the MCP server. The gateway authenticates the person first, evaluates entitlement, and then presents a credential it holds on the user's behalf. That means the upstream resource can remain user-agnostic while the access decision becomes user-specific, which is the difference between shared service-account access and governed delegated access. The important detail is timing: identity is resolved before the resource is touched, so audit and consent can attach to the person rather than the shared secret.

Practical implication: Move access decisions ahead of the resource call so revocation affects one user instead of the entire population.

Why tool surface design limits or expands governance depth

Even with a gateway, the tool interface determines how much authority can be controlled. A broad tool such as run_query(sql) exposes the full upstream capability to any entitled user, while narrower tools like get_invoice(id) or list_open_invoices() create smaller, more governable permission boundaries. This is not per-record security, because that still belongs to the resource, but it does determine whether the gateway can meaningfully separate read, write, and consent-gated actions. In practice, tool design either preserves coarse shared access or creates room for usable policy.

Practical implication: Design internal MCP tools around discrete actions, not all-purpose wrappers.

Threat narrative

Attacker objective: Maintain continued access through a shared credential that outlives the person who originally used it.

1. Entry occurs when a shared service-account key is copied into many developer environments so multiple agents can reach the MCP server.
2. Escalation happens when the same credential is reused across users, making offboarding impossible without breaking everyone else's access.
3. Impact is persistent access for former users, weak auditability, and a credential footprint that cannot be cleanly revoked or attributed.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Shared service-account access is now a governance anti-pattern for agent-mediated work. When one credential must be copied into many developer environments, the organisation has already lost the ability to revoke access cleanly by person. That is not a tooling inconvenience, it is a lifecycle failure that breaks joiner-mover-leaver discipline across the whole access path. The practitioner implication is that entitlement must be separated from the shared secret before the workforce scales further.

Access governance now depends on a control point in front of the resource, not just stronger secrets handling. If the server cannot speak OAuth, then the identity layer has to be restored by the gateway or equivalent enforcement point. This is where NHI governance and human IAM converge, because the user behind the agent still needs attribution, consent, and revocation even when the upstream resource is blind to identities. Practitioners should re-evaluate whether current architecture assumes the resource itself will ever become governable.

Tool design defines the boundary of governability. A broad tool surface turns every entitled call into a full-privilege transaction, while narrower tools create meaningful policy checkpoints. This is the same identity lesson seen in privileged access programmes: if the control boundary is too wide, the governance model becomes mostly symbolic. Teams should treat internal MCP interface design as an authorisation design problem, not only an integration problem.

Identity blast radius is the right concept for MCP server governance. The issue is not just how many people can use a credential, but how far one compromised or stale credential can travel before anyone can stop it. That blast radius expands when the same secret is distributed to every agent runtime and collapses only when access is asserted per person before the upstream call. The practitioner takeaway is to measure access by revocability, not by convenience.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That confidence gap aligns with our analysis of the 52 NHI breaches, where delegated access and weak lifecycle control repeatedly widen blast radius.

What this signals

Identity gateway design is becoming a practical control for agent-era access. When resources cannot natively support user-level OAuth, the programme has to recover identity upstream rather than hoping the downstream system will eventually catch up. That shifts implementation thinking from secret distribution to entitlement brokering, which is a very different IAM and NHI operating model.

Identity blast radius: the useful metric is no longer how many developers can reach a tool, but how many of them can be removed without forcing a shared credential reset. This is where shared secret management, offboarding, and audit evidence meet, and it is also where the access model either stays governable or becomes irreversible.

For teams already running agents in developer laptops and local environments, the next question is whether the gateway pattern is enforced everywhere the credential can travel. If it is not, the organisation may have built a policy layer that protects only the easiest path, while the unmanaged path remains the one users actually take.

For practitioners

• Separate user entitlement from shared credentials Place a gateway or equivalent enforcement layer in front of MCP servers so the person is authenticated before any upstream request uses a shared service-account key.
• Narrow the tool surface before scaling access Prefer discrete tools such as get_invoice(id) over broad wrappers such as run_query(sql), because the narrower surface creates smaller policy boundaries and less standing privilege.
• Make offboarding revoke one person only Test whether removing a single user stops their access without forcing credential updates across every developer environment or breaking other agents.
• Record calls against named users, not shared keys Ensure audit logs bind each MCP action to the person behind the agent so investigations and approvals do not terminate at a generic service account.

Key takeaways

• Shared MCP keys do not scale safely once access is copied into many developer environments.
• User-aware gateways restore revocation, audit, and consent without requiring every resource to understand OAuth.
• Narrow tool design and per-person attribution are the controls that keep agent-mediated access governable.

Key terms

• AI Identity Gateway: An AI identity gateway is a policy enforcement layer placed between agents and resources. It downscopes credentials, centralises access decisions, and prevents the agent from holding broad reusable privileges that would otherwise accumulate across tools and workflows.
• Service-account key: A service-account key is a non-human credential used by a workload, integration, or automation process to authenticate without a person present. When keys are stale, duplicated, or stored outside a managed vault, they become difficult to govern and easy to overlook during lifecycle reviews.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• 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.

What's in the full article

Hush Security's full research covers the operational detail this post intentionally leaves for the source:

• Exact gateway flow for authenticating the person before any upstream call is made
• How the managed secret is decrypted only inside the gateway and never exposed to the agent
• The distinction between OAuth-speaking servers and internal API bridges that do not support OAuth
• How consent, guardrails, and audit are applied consistently across users, agents, and databases

👉 The full Hush Security post explains the gateway model, offboarding behaviour, and tool-level governance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or NHI programme, it is worth exploring.