Notifications
Clear all
Topic starter
07/06/2026 7:57 pm
TL;DR: MCP servers are beginning to inherit the same persistent access, broad privilege, and credential-linger risks that made service accounts difficult to secure at scale, according to Aembit. The governance problem is not the protocol itself but the assumption that access can be treated as background plumbing instead of an identity boundary that needs continuous scrutiny.
NHIMG editorial — based on content published by Aembit: MCP servers are becoming the new service account problem
Questions worth separating out
Q: How should security teams govern MCP servers that act like service accounts?
A: Treat MCP servers as first-class non-human identities with explicit ownership, scope, and expiration rules.
Q: Why do MCP servers increase non-human identity risk in cloud environments?
A: Because they add another persistent access layer on top of an already crowded service account footprint.
Q: What breaks when MCP access is controlled inside agents instead of at the boundary?
A: You lose consistent enforcement, revocation becomes harder, and auditability degrades across integrations.
Practitioner guidance
- Inventory every MCP server as a governed identity Map each server to an owner, business purpose, data scope, and expiry condition.
- Replace static secrets with runtime-bound credentials Move away from long-lived API keys and personal access tokens at the MCP layer.
- Enforce authorisation at the MCP boundary Make the boundary the sole place where tool access is approved, limited, and revoked.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Guidance on proving identity with cryptographic attestation tied to cloud or Kubernetes runtime identity.
- Specific discussion of least privilege at the MCP boundary, including per-client consent and token audience validation.
- How to preserve user context across autonomous and user-initiated agent actions without losing audit clarity.
- Why policy should live at the boundary rather than inside agent logic or scattered integrations.
👉 Read Aembit’s analysis of MCP server security and access governance →
MCP servers and service account sprawl: what IAM teams need to know?
Explore further
07/06/2026 9:43 pm
MCP servers are becoming service accounts with a new interface, not a new security model. The article shows that enterprises are layering MCP on top of existing non-human identity sprawl instead of replacing it. That makes access multiplicative, because the new control surface inherits the old problems of broad entitlement, weak ownership, and long-lived credentials. Practitioners should read MCP adoption as an identity governance problem first and a protocol problem second.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the same survey.
A question worth separating out:
Q: Who is accountable when an MCP server is over-privileged?
A: The accountable party should be the system owner who approved the server's access scope, not the agent that consumed it. Over-privilege is a governance failure when ownership, purpose, and revocation are not clearly assigned. Frameworks such as the NIST Cybersecurity Framework 2.0 help anchor that accountability.
👉 Read our full editorial: MCP servers are becoming the new service account problem
