Notifications
Clear all
Topic starter
19/08/2026 4:04 pm
TL;DR: MCP servers backed by shared service keys create three governance problems at once: access scoping, usage visibility, and rotation, according to Obot. The right problem is not building custom auth for every server, but centralising the credential and enforcing access, audit, and rotation through existing identity controls.
NHIMG editorial — based on content published by Obot: MCP and Shared Service Keys, the right problem to solve
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
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.
Q: What breaks when MCP access is not centrally enforced?
A: When MCP access is not centrally enforced, agents can bypass the sanctioned protocol and reach the same data through alternative connectors or direct application paths.
Practitioner guidance
- Centralise shared service keys Store each MCP server credential in one managed secret store and prohibit direct distribution to developers, laptops, or local config files.
- Enforce identity-based access at the gateway Use existing IdP groups and policy checks at the MCP control plane so only approved users can reach a given server before the shared key is presented.
- Stamp every tool call with the caller identity Record the authenticated user, server, and tool invocation at the control plane so downstream logs no longer have to serve as the source of truth.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- How the control plane pattern works for shared service keys in a real MCP deployment.
- How existing IdP groups and policies can be reused to decide who may reach a given MCP server.
- How audit logging can stamp each tool call with the authenticated user identity.
- How secret rotation behaves when the credential is held in one managed store instead of scattered across endpoints.
👉 Read Obot's analysis of MCP shared service keys and enterprise control planes →
MCP shared service keys: what IAM teams need to govern?
Explore further
19/08/2026 4:38 pm
MCP shared keys are an NHI governance problem, not an auth invention problem. The article is right to reject the instinct to build a new authentication stack for every server. The real issue is how to govern a non-human identity that already exists in the enterprise pattern: a shared credential with delegated authority, unclear ownership, and lifecycle risk. The better question is which existing IAM and secret controls can be extended to cover MCP without fragmenting accountability.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.
A question worth separating out:
Q: How do organisations reduce rotation risk for MCP service keys?
A: Make the control plane the only authoritative holder of the secret, then test rotation end to end. If the key exists in multiple places, the rotation workflow is not complete and emergency revocation will remain too slow.
👉 Read our full editorial: MCP shared service keys need central control, not bespoke auth
