Notifications
Clear all
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.
NHIMG editorial — based on content published by Hush Security: What to do when the MCP server your workforce depends on has no concept of users
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%.
Questions worth separating out
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 teams decide between a broad MCP tool and a narrow one?
A: Choose the narrowest tool that still supports the business task.
Practitioner guidance
- 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.
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
👉 Read Hush Security's analysis of MCP access when servers have no user concept →
MCP servers without OAuth: how do teams govern user access?
Explore further
16/09/2026 9:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server access without OAuth still needs user governance
