Topic starter
16/09/2026 9:21 am
TL;DR: Static service-account keys for MCP servers force teams into unsafe credential sharing, because a credential copied to every developer’s environment cannot be cleanly rotated or revoked. Hush Security argues that governance converges on a gateway pattern where user identity is asserted before upstream access, which restores per-person control without pretending the resource understands users.
Editorial analysis by NHI Mgmt Group, based on content published by Hush Security: “When Your MCP Server Has No Concept of Users”.
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.
Key questions
Q: What breaks when one MCP service-account key is shared across many users?
A: Offboarding and revocation break first.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: A single MCP service-account key shared across many users turns access into a credential distribution problem instead of a per-person governance problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 21 hours ago by NHI Mgmt Group
16/09/2026 9:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server access without OAuth still needs user governance
This post was modified 21 hours ago by NHI Mgmt Group