MCP shared service keys need central control, not bespoke auth

At a glance

What this is: This analysis argues that MCP servers using shared service keys should be governed through a central control plane rather than custom authentication built for each server.

Why it matters: IAM and NHI teams need a model that preserves access control, auditability and rotation without multiplying bespoke identity logic around every MCP integration.

Context

MCP servers often rely on a single shared service key, which makes the identity problem less about the server itself and more about how access to that credential is governed. The practical failure mode is familiar to IAM teams: once the key is embedded in multiple places, access scope, logging and rotation all drift out of control.

In this model, the MCP layer is not a special case that demands a new auth stack. It is a service integration that should sit inside existing identity governance, with access decisions taken from current user groups and policies, and with the credential stored and rotated centrally.

Key questions

Q: How should teams govern access to MCP servers that use shared service keys?

A: Treat the shared key as a centrally managed NHI credential and put authorisation in front of the server. Users should authenticate with the corporate IdP, and the control plane should check group and policy eligibility before forwarding the request with the stored key. That keeps access decisions aligned to existing IAM governance rather than creating a separate auth layer for every server.

Q: Why do shared service keys create risk in MCP environments?

A: They collapse many users into one downstream identity, which removes attribution and slows revocation. If the credential is copied into configs or developer machines, rotation becomes difficult and the organisation loses control over who can exercise the key.

Q: What breaks when an MCP service key is copied into multiple configs and developer machines?

A: Rotation turns into a manual recovery exercise instead of a controlled change. Every extra copy expands the exposure window, increases the chance of missed revocation and makes it harder to prove that the old credential is gone everywhere. The result is credential drift, not controlled lifecycle management.

Q: What is the difference between bespoke MCP authentication and centralised credential control?

A: Bespoke authentication pushes identity logic into each MCP server, while centralised credential control keeps the service key in one place and lets the enterprise identity stack make the access decision. The second model reduces duplication, preserves existing policy structures and gives the organisation one audit boundary instead of many.

Technical breakdown

Centralised secret storage for MCP service keys

A shared service key is a non-human credential, so the core control question is where that credential lives and who can retrieve it. If it is copied into configuration files, local machines or tool-specific wrappers, the organisation loses a single source of truth and makes rotation error-prone. A control plane changes the architecture by holding the service key in one secret store and brokering requests on behalf of authenticated users. That preserves a single credential boundary while letting the downstream MCP server remain unchanged. The control objective is not to redesign the integration, but to prevent credential sprawl from becoming operational policy.

Practical implication: Keep the MCP service key in one managed secret store and remove every duplicated copy from server configs and developer endpoints.

Identity-aware access control at the MCP layer

The downstream service only sees one key, so it cannot tell which person initiated a tool call. That means access control has to happen before the request reaches the service, using corporate identity, group membership and policy evaluation. In practice, the control plane maps user identity to entitlement and decides whether that user can reach a given MCP server or tool. This is a classic separation of authentication and authorisation: the user authenticates with the organisation's identity system, and the control plane authorises the action against local policy. Without that layer, the shared credential becomes effectively universal access.

Practical implication: Enforce server-level access through IdP groups and policy checks, not through the shared service key itself.

Auditability and rotation for shared NHI credentials

Shared service keys collapse individual accountability unless the platform logs the user identity alongside each tool invocation. The article's model solves this by stamping tool calls at the control plane, then using the secret store as the single place for rotation. That matters because rotation is only simple when one credential is managed once, not copied across teams and endpoints. The technical pattern here is straightforward: one key, one broker, one audit trail. The governance benefit is that identity and secret lifecycle controls can be applied without asking every downstream SaaS vendor to expose per-user semantics they may not support.

Practical implication: Log every MCP tool call with user identity and rotate the shared key only through the central secret store.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

MCP shared service keys are a governance problem before they are a protocol problem. The article shows that the real issue is not whether each MCP server can build its own auth flow, but whether a shared non-human credential can be governed without multiplying exceptions. That makes this an NHI management question about control planes, entitlement boundaries and secret lifecycle ownership. Practitioners should treat the MCP server as a managed integration, not a new identity island.

Central control works because it preserves existing identity authority. Access decisions remain with the IdP, while the MCP control plane only brokers the request using the stored service credential. That is a cleaner model than teaching every third-party server to understand local enterprise policy, and it avoids fragmenting logging across downstream services that only see one key. The practitioner takeaway is to extend current IAM policy into the MCP layer, not duplicate it.

Shared service keys create an identity blast-radius problem. Once one credential is reused across tools, one compromise or one mis-scoped grant can affect every integration that depends on it. The important concept here is not bespoke authentication, but centralised credential custody with per-server policy enforcement and auditable tool invocation. Teams should regard the blast radius of the credential, not the novelty of the protocol, as the design constraint.

Delegating MCP access through existing groups is more defensible than creating a parallel authorisation model. The article's model keeps access decisions aligned to the structures IAM teams already operate, which reduces drift between enterprise policy and tool usage. That alignment matters most when multiple departments want different access to the same shared server. The right control is policy reuse, not policy invention.

The control plane becomes the accountability boundary for MCP usage. When every tool call is stamped with the user's identity, the organisation can answer who used what and when even though the downstream service only sees one credential. That is the minimum viable governance pattern for NHI-backed integrations at scale. Practitioners should make the control plane, not the target service, the source of audit truth.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Shared service keys turn MCP into an identity-governance problem, not just a tooling problem. The control point has to move to the place where access is decided and logged, because downstream services cannot provide per-user accountability when they only ever see one credential. For IAM teams, that means the control plane becomes the governance layer for both authorisation and audit.

Centralised custody changes the lifecycle of the credential itself. Rotation, revocation and usage review become tractable only when the key is not scattered across machines and configuration files. That is the difference between a manageable NHI and a shared secret that behaves like an uncontrolled dependency.

92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs, and MCP integrations fit that exposure pattern closely. The practical response is to treat every external server that consumes a shared credential as part of the trust boundary, not as an isolated integration.

For practitioners

• Centralise shared service keys Store the MCP credential in a single secret store and remove copies from config files, laptops and local wrappers so rotation remains one action instead of many.
• Enforce IdP-based access decisions Use existing corporate groups and policies to decide who can reach each MCP server, rather than embedding custom authorisation logic into the server itself.
• Stamp tool calls with user identity Record which user invoked each MCP tool call at the control plane so the downstream service no longer has to provide per-user visibility.
• Treat rotation as a managed control Define one operational rotation path for the shared key and test that it can be completed without searching for hidden copies across teams.

Key takeaways

• Shared MCP service keys concentrate access, visibility and rotation risk into one credential that must be governed centrally.
• If the organisation cannot stamp user identity onto each tool call, it cannot prove who used the MCP integration or whether that use was authorised.
• The control-plane model is the practical answer because it keeps identity decisions in the IdP, audit in one place and rotation to one managed secret.

Key terms

• Shared Service Key: A single API credential used by multiple users or systems to access one downstream service. In MCP environments, the key is a non-human identity asset that must be centrally held, attributed, and rotated, because the service itself cannot distinguish which internal actor initiated a request.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• 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.
• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.

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.