Shadow IT Took a Decade to Contain. Shadow Agents Take Five Minutes to Create.

If you were running IT in 2010, you remember how cloud governance became a problem.

It started quietly. Marketing signed up for a SaaS product without telling anyone. A dev team put AWS instances on a corporate card. A regional office adopted a file-sharing service because the approved one was slow. By the time IT found out, company data was spread across dozens of services nobody had reviewed.

We called it shadow IT and spent most of a decade containing it — access brokers, procurement policy, discovery tooling, governance frameworks. Most organizations eventually got a handle on it.

It is happening again, and the shape is worse in one specific way.

Five Minutes, No Purchase Order

A shadow agent is an AI agent connected to enterprise systems through an integration nobody approved.

The mechanics are unremarkable, which is the problem. A developer installs an AI assistant that supports the Model Context Protocol. They add an MCP server — one that connects to a PostgreSQL database, or exposes an internal API. That is the entire process. In a few minutes there is an AI agent on a laptop that can query production data, read customer records, and run commands against live systems.

Compare that to shadow IT. Adopting a rogue SaaS product required a credit card, an account, a vendor relationship, and usually a bill that eventually surfaced in an expense report. There was a paper trail, however delayed, and there was a company on the other end you could send a DPA to.

A shadow agent requires none of that. No spend, no vendor, no contract, no procurement event. Nothing appears in any system your finance or vendor-management processes watch. The configuration lives in a file on someone's machine.

And the capability is categorically different. Shadow IT put data in a place you did not control. A shadow agent grants an autonomous system the ability to act against infrastructure you do control, with the credentials of whoever configured it.

Why the Person Doing It Isn't Wrong

It is worth being clear that this is not usually a discipline problem, because treating it as one guarantees the wrong response.

The developer connecting an agent to the database is trying to do their job faster, using a capability their tools now offer, in an organization that has no policy covering it and no sanctioned way to get the same result. Shadow IT happened for the same reason: the approved option was slower than the unapproved one.

If your answer is a prohibition with no alternative, you get the 2010 outcome — the behaviour continues, less visibly, and now the people doing it have a reason not to tell you.

What Makes This Genuinely Harder

Three properties make agent governance different from cloud governance, and each undercuts a control you currently rely on.

Credentials are inherited, so identity is wrong. The agent acts as the human who configured it. Your logs record that user querying that table. There is no distinguishable actor, which means access review, anomaly detection, and audit trails are all describing a person when the thing acting was a piece of software with a much broader appetite and no fatigue.

Authorization was designed for humans, and the assumptions don't hold. Access models grant broad permissions on the reasonable assumption that a human uses a small part of them, at human speed, for comprehensible reasons. An agent will exercise the full grant, immediately, in combinations nobody anticipated. "Read access to the customer table" means something different when the reader can process all of it in seconds and act on what it finds.

The audit question changed. Compliance regimes want to know who accessed what and why. With an agent, "who" is ambiguous, and "why" lives in a natural-language instruction that may not have been retained anywhere. If a regulator asks why a particular record was read on a particular date, "an agent decided it was relevant to a task" is not an answer any framework currently accepts.

The Reason This Is Worth Getting Right

None of the above is an argument against MCP. It is an argument for owning the decision rather than inheriting it.

The protocol solves a real problem. Before a standard existed, every AI-to-system connection was bespoke — its own integration, its own auth, its own maintenance burden, and its own lock-in to whichever vendor built it. A common protocol means an integration you build works with whatever model or tool you use next, which is the first genuine answer anyone has offered to AI vendor lock-in.

That is a strategic benefit worth having, and it is precisely why the ungoverned version spreads so fast. The same property that makes MCP valuable — anything can connect to anything, cheaply — is what makes it ungovernable by default.

What Actually Works

The organizations handling this well are doing roughly four things.

Discovery first. You cannot govern what you cannot see, and most organizations genuinely do not know how many agent connections already exist. Find out before designing policy. The number is usually higher than expected.

A sanctioned path that is faster than the unsanctioned one. An internal registry of reviewed MCP servers, with a way to request a new one that resolves in days rather than quarters. This is the single highest-leverage intervention, and it is the lesson from cloud: adoption follows convenience, so make the governed route the convenient one.

Distinct identity for agents. Agents get their own service identities and their own scoped credentials, not a human's. This is unglamorous plumbing and it is what makes everything downstream — logging, revocation, least privilege, audit — actually work. Doing it later is far more expensive than doing it now.

Scoped, purpose-bound access. Grant the narrow capability the task requires rather than the role the human holds. This is least privilege, which everyone already believes in and few implement, made unavoidable by the fact that an agent will use everything you give it.

The Timing

The window here is narrow and it is the same window as 2010.

Governance built while adoption is small is cheap and mostly invisible. Governance retrofitted after agents are embedded in daily workflows across a dozen teams is expensive, disruptive, and arrives as a fight — because by then you are taking away something people rely on.

Shadow IT took a decade to contain because we started after it was everywhere. This one moves faster, costs nothing to create, and leaves no procurement trail. There is no reason to expect a longer runway.

The CIO's Guide to MCP: How Model Context Protocol Connects AI to Your Enterprise covers the architecture decision, the end of AI vendor lock-in, composable AI architecture, shadow agents, securing MCP at scale, compliance in the agent era, and moving from pilot to production.