Notifications
Clear all
Topic starter
10/06/2026 11:30 pm
TL;DR: MCP makes AI assistants operational by connecting them to real systems, but the protocol deliberately leaves identity, authorization, and governance to the surrounding platform, which is why shared credentials, implicit delegation, and overbroad permissions emerge quickly, according to Riptides. The key issue is not the protocol itself, but the identity model built around it: once an MCP server can act for multiple people, the authority boundary becomes harder to explain and harder to audit.
NHIMG editorial — based on content published by Riptides: Our AI Is Helpful. Also Slightly Overprivileged
By the numbers:
- NHIs now outnumber human identities by 144:1 in enterprise environments, a 44% increase year-over-year driven by AI agents, CI/CD automation, and third-party integrations.
Questions worth separating out
Q: How should security teams govern MCP servers that act for multiple users?
A: Security teams should treat MCP servers as privileged NHIs with explicit ownership, scoped permissions, and recorded delegation paths.
Q: Why do MCP deployments so often drift into overprivilege?
A: MCP deployments drift into overprivilege because teams optimise for making the workflow work first and governing it later.
Q: What breaks when MCP servers rely on a single shared credential?
A: A single shared credential breaks attribution, scope control, and revocation precision.
Practitioner guidance
- Inventory every MCP server as a governed NHI Record the owning team, downstream systems, credential type, and business purpose for each server.
- Split machine authority from human authority Bind each MCP action to both the workload identity and the initiating user identity wherever the platform allows it.
- Replace shared long-lived tokens with scoped, expiring access Prefer short-lived credentials, task-scoped permissions, and explicit expiry over reusable API keys in configuration.
What's in the full article
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- How the protocol’s communication model works when AI assistants open pull requests, query logs, and update tickets
- The practical trade-offs between shared service accounts, personal access tokens, and user-token forwarding
- The delegation questions teams need to answer when an MCP server acts on behalf of multiple people
- Where transport security stops and identity governance begins in real MCP deployments
👉 Read Riptides' analysis of MCP server overprivilege and identity governance →
MCP server overprivilege: what IAM teams need to govern now?
Explore further
12/06/2026 5:35 am
Implicit delegation is the real governance fault line in MCP adoption: the protocol makes tool use easy, but it does not define who is authorised to combine human intent with machine execution. That gap matters because audits and incident reviews need an enforced delegation model, not just a trail of logs. The practitioner conclusion is simple: treat delegation as an identity control, not an implementation detail.
A few things that frame the scale:
- NHIs now outnumber human identities by 144:1 in enterprise environments, a 44% increase year-over-year driven by AI agents, CI/CD automation, and third-party integrations, according to The NHI and Secrets Risk Report.
- Nearly half of all exposed secrets reside outside code repositories, in CI/CD logs, collaboration tools, and messaging platforms, which shows how quickly machine credentials escape the systems teams think they control.
A question worth separating out:
Q: How do IAM teams decide whether an MCP integration is safe enough to keep?
A: IAM teams should ask whether the integration has an explicit owner, narrow tool scope, expiring credentials, and a delegation model that survives audit review. If any of those are missing, the system may be functional but it is not yet governable. The right test is whether the server’s authority can be explained as clearly as its output.
👉 Read our full editorial: MCP server overprivilege exposes a new identity governance boundary
