Every MCP connection is a service account no one provisioned.

Every IAM team learned the same lesson around 2015: the dangerous accounts in your environment aren't the ones you provisioned. They're the ones you didn't. The service principal a long-departed contractor created for a one-off integration. The shared key pasted into a wiki page. The "temporary" API token that's been in production for three years.

The whole discipline of modern identity governance — joiner/mover/leaver, periodic access reviews, key rotation, scoped least-privilege — is the answer to that lesson. It assumed identity was something you grant to a human or to a clearly-named service.

That assumption is breaking again, in exactly the way it broke a decade ago, except faster.

Every MCP server your AI agents connect to is, in identity terms, an unmanaged service account. It was created by a developer, often without a ticket. It holds credentials with broad scope to whatever system it fronts. It can read data, take actions, and pipe content directly into the model's working context. And almost no organization is treating these connections the way it treats any other service account in production.

What an MCP connection actually is

When an agent connects to an MCP server — a vendor's hosted server, a self-hosted internal one, a localhost binary on a developer's laptop — it negotiates a privileged channel. From the moment that connection is live:

• The MCP server holds credentials to its underlying system: a database, a SaaS API, a file store, a code host.
• The agent inherits that surface. Whatever the server can do, the agent can do, modulated only by which tools and resources the server chose to expose.
• The connection persists, usually with no expiry, until something explicitly tears it down.

Structurally, that is the same thing as a service principal with a long-lived token. The difference is that MCP connections are created at the agent-config or developer-machine layer rather than through the IAM platform. Most never appear in the directory at all.

The five questions IAM has answered for service accounts

For two decades, mature IAM programs have answered the same five questions for every service account in production. Walk through the list with MCP connections in mind.

Who owns this? A service account has a named owner — a team, a runbook, a Slack channel. When it misbehaves, someone is paged. Most MCP connections have no recorded owner. The developer who set the connection up may have moved teams or left. The agent that uses it may serve dozens of internal users.

What is its scope? A service account is provisioned with explicit permissions, ideally least-privilege. An MCP connection inherits whatever the server's underlying credential allows. A vendor MCP server pointed at your CRM has, in practice, the scope of whatever API key was pasted into its config. That key is rarely scoped to "read the records this agent is meant to summarize."

When does it expire? Service-account keys rotate on a schedule. MCP connections, once configured, sit indefinitely. The credentials behind them rotate sometimes; the connection record on the agent side does not.

Who reviews it? Periodic access reviews are a regulated baseline. Every quarter, an owner attests that this account still needs the access it has. No equivalent process exists for MCP connections in any organization we've seen.

How is it deprovisioned? When a project ends, when an employee leaves, when a vendor is replaced — the IAM platform fires a deprovisioning event. MCP connections are torn down ad hoc, which is to say most of them are not torn down at all.

A useful exercise for any AppSec lead this quarter: ask your team to produce, by name, the owner of every MCP connection in your AI agent fleet. Then ask when each one's credentials were last rotated. The number of "I don't know" answers is the size of the problem.

Why this is harder than classical service-account hygiene

Two reasons MCP connections will not be solved by retrofitting existing IAM.

First, the agent is the actor. Classical service accounts are used by named systems with known call patterns. An agent's call patterns are a function of the conversations it is having today. The same connection might pull customer records on Tuesday and not touch them again for a month. Anomaly detection on usage volume — the standard signal — is much weaker when usage is conversation-driven.

Second, MCP connections compose. An agent connected to ten MCP servers is, effectively, a single principal with the union of their scopes. The blast radius of a compromise — or of a prompt injection routed through one server's resources — is the cross product of every connected server. No individual MCP server's security posture captures that.

These are not reasons to wait. They are reasons the tooling will be different from CloudTrail.

What identity for MCP looks like

The shape of the answer mirrors what worked for service accounts in the first place, with adjustments for the agent-as-actor model.

A registry. Every MCP connection in production gets a record. Server URL, transport, credential reference, scope summary, owner, created-at, last-used-at. This is the inventory step. It is also the artifact every other control hangs off.

Scoped credentials. The credential the MCP server holds is scoped to what the agent actually needs, not to what the underlying API allows. This is often a vendor-side change — most MCP servers ship with broader scopes than they need — but it is the move that turns a sprawling principal into a least-privilege one.

Expiry by default. Connections carry an expiry. An unused connection deprovisions itself. The default state of an MCP connection should be "gone after 90 days unless renewed," not "live until someone notices."

A review loop. Quarterly, the owner re-attests. The set of tools the connection currently exposes is shown alongside the set that was approved at registration. Drift is the audit event.

A breakglass path. When an MCP server is suspected of being compromised — or of having been updated in a way that materially changes its behavior — a single switch revokes every agent's connection to it.

None of this is novel infrastructure. It is the IAM playbook applied to a surface that was not in IAM's mental model when the playbook was written.

Why this is urgent now

Two trends compound. The number of MCP servers per organization is growing past the point where ad-hoc tracking works — five MCP servers is a wiki page; fifty is a directory. And the regulatory perimeter around AI is starting to ask the same questions about agent identity that it asks about human and service identity. The first AI-specific access review request from a regulator is going to look identical to a SOX or SOC 2 access review request, and organizations that cannot produce the list of every MCP connection their agents have will be answering it under deadline.

The teams that get ahead of this will not have a fancier IAM platform. They will have a registry, an owner, and an expiry.

Service-account hygiene took a decade to become baseline. The window to do MCP-connection hygiene before it becomes an audit finding is much shorter than that.