MCP Servers and the Return of the Service Account Problem

Across large enterprises, MCP servers are quietly assuming a role security teams know all too well from previous eras of IT infrastructure development. Like the service account before them, they typically operate as persistent access brokers with broad privileges, shared across workflows, and gradually treated as background plumbing rather than as identities that require ongoing scrutiny.

In practice, MCP servers are beginning to inherit the same risks that made service accounts difficult to secure at scale. More concerning, MCP servers are not replacing service accounts. They are being layered on top of an already sprawling service account footprint, often with even less oversight. The result is a multiplicative access problem, where MCP servers compound existing service account risk rather than eliminating it.

This resemblance follows a familiar logic: MCP servers exist to simplify access between agents and the systems they act upon. That same reasoning once justified the creation of service accounts. But over time, operational convenience displaced security discipline. Permissions accumulated as new use cases were layered on. Credentials routinely outlived their original purpose, lingering in place and reused as default long after the work they enabled had changed or disappeared.

This perilous pattern unfolded long before agentic AI arrived. Service accounts expanded across enterprise environments as non-human identities proliferated far beyond human users amid the explosion of automation and cloud-native development. Credentials tied to these identities have repeatedly surfaced in security incidents.

Recent MCP-specific research suggests history is about to repeat itself. Independent analyses examining thousands of MCP server implementations have found that the vast majority rely on preconfigured credentials to operate, and that insecure authentication practices remain common, including reliance on long-lived static API keys or personal access tokens rather than delegated authorization mechanisms. Separate investigations have also identified large numbers of publicly reachable MCP servers exposed without authentication, many of which allow unauthenticated enumeration of internal tools.

The Comparable Risk of MCP Servers

MCP servers operate under continuous demand from agents that typically act without pause or situational judgment. When those servers run with pre-granted access, each request inherits the same level of trust regardless of the agent involved, the prompt that triggered it, or the surrounding context. As reliance grows, the access surface expands incrementally, often without a corresponding review of scope.

MCP servers also share another trait long associated with service accounts. Once they work, they fade from attention. Teams focus on agents, tools, and outputs, while the access layer that enables all three remains largely untouched.

This concern is increasingly reflected in the MCP security specification. The protocol’s security guidance treats MCP servers as privileged control surfaces rather than neutral infrastructure, with explicit attention to risks such as confused deputy attacks, token passthrough, session hijacking, and overbroad scopes. It emphasizes least privilege, per-client consent, strict token audience validation, and disciplined credential handling as baseline requirements for MCP implementations.

Much of responding to this guidance requires tightening how access is issued, used, and revoked at the MCP boundary, where agent activity meets sensitive systems.

What to protect at the MCP layer:

• Prove identity and issue access per request

  MCP servers should not rely on long-lived, pre-established secrets to establish trust. Identity should be proven through cryptographic attestation tied to the runtime environment, such as cloud instance identity or Kubernetes workload identity. Access should be issued just in time, scoped to the specific task, and expire when the interaction ends. This prevents MCP servers from accumulating persistent privilege as usage scales.

• Preserve context across agent and user actions

  Agents operate in different modes, including autonomous execution and user-initiated requests. Access decisions at the MCP boundary should account for both the agent’s identity and the user context that triggered the action. Treating all MCP traffic as a single service identity strips away intent and makes audit trails difficult to interpret.

• Enforce policy at the boundary, not inside agents

  MCP servers are the natural control point for agent access. Policy should live at this boundary rather than being hardcoded into agent logic or scattered across integrations. Centralized enforcement allows access to be tightened or revoked without redeploying agents or manually rewriting code.

Avoiding the Same Mistakes of Service Accounts

Unchecked, MCP servers tend to accumulate authority quietly. Permissions expand as new agents and tools are added. Credentials linger because removing them risks breaking production workflows. Over time, access becomes something the system assumes rather than something it proves. This is the same failure pattern that followed service accounts into every large environment – and is now unfolding at a higher operational tempo.

But by applying the above guidance, MCP servers remain active control points rather than passive infrastructure. Access becomes something that is granted deliberately and temporarily, instead of something that accumulates by default as systems scale.