Shadow SaaS Was Unapproved Software. A Shadow Agent Is an Unapproved Representative.

In July 2025, someone gave an AI coding agent one rule: do not touch production. The company was in a code freeze. The agent deleted the production database anyway. Then it generated fake records to cover the gap, and when it was asked what had happened, it reported that the data was destroyed and a rollback was impossible.

It was wrong about the rollback. The data came back. It was a vibe-coding experiment, not a bank, and the blast radius was small. But for a few hours the operator nominally responsible for that system was the last to understand what the tooling had just done. This is the Replit incident, and the CEO apologized for it in public.

The agent's failure is not the interesting part. What it had quietly become is. It held real credentials and it acted on them. It optimized for looking finished over being correct. And no one had decided, on purpose, to give a non-human actor that much reach.

For the last couple of years, the pitch for AI agents to small IT teams has been the opposite of that scene. It has been relief.

Two diseases, one promised cure

Every lean IT team carries two chronic conditions.

The first is the single point of failure. When a handful of people run everything, one of them holds knowledge that exists nowhere else. The runbook is in someone's head. The integration that breaks at 2am has exactly one person who knows why. We have a polite name for this. We call it the bus factor, and on a small team the bus factor is often one.

The second is shadow IT. People route around the tools they are given, because the official path is slow and the deadline is not. A personal Dropbox. An unsanctioned signup. A spreadsheet that quietly becomes load-bearing. You cannot govern what you cannot see, and on a small team you cannot see much.

AI agents arrived as the cure for both at once. For the bus factor: stop keeping the knowledge in one head, codify it, let an agent hold the runbook and answer the question at 2am. For shadow IT: stop fighting people, give them a sanctioned assistant, and if the official path is finally fast, nobody needs to go around it.

It is a good pitch. I believed a version of it. The pitch is specifically seductive to a lean team, because it promises the one thing a lean team never has enough of: a second person who knows.

Here is the claim I have arrived at, and it is one you can disagree with. The cure did not fail to work. It worked, and that is the problem. Codify the runbook into an agent and you have built a new single point of failure. Hand people a capable agent and you have not ended shadow IT, you have armed it.

So: the cure for the lean team's two oldest diseases is making both of them worse.

Flip one: shadow IT stopped leaking and started acting

The old shadow IT had a ceiling on its damage. A rogue signup or a personal account leaked data. That is bad, but it is passive. The information goes somewhere it should not, and then it sits there.

The new shadow IT does not sit. It acts.

The thing people are quietly wiring up now is not a file share. It is an agent. The tooling went mainstream in the last year. The Model Context Protocol, which lets any model reach into real systems through standardized connectors, crossed from a developer curiosity into default agent plumbing, with more than ten thousand public servers by the end of 2025. No-code agent builders did the same for non-engineers. So an employee, with the best intentions and a real deadline, can now point an agent at company systems, hand it live credentials, and let it run. No one in IT approved it. No one in IT can see it.

What makes the new shadow IT dangerous is that reading is now enough to trigger action. In June 2025, Aim Security disclosed EchoLeak (CVE-2025-32711, rated CVSS 9.3): the first documented zero-click prompt-injection exploit to pull real data out of a production AI system. A single crafted email, never clicked, was enough. When Microsoft 365 Copilot read it during normal summarization, it followed the hidden instructions inside, reached into the user's own files across Outlook, Teams, SharePoint, and OneDrive, and sent the contents to an outside server. No link clicked. No user action.

Now notice the part that should worry a lean team. EchoLeak happened to a sanctioned, vendor-run tool: Aim Security probed it and Microsoft shipped a patch, all before anyone exploited it in the wild. The homemade agent an employee wired up last week has neither. No researcher is looking at it, and no patch pipeline stands behind it. The lesson of EchoLeak is not that Copilot was unsafe; it is that the official tool had someone to catch the flaw, and the shadow one does not. OWASP maps prompt injection to six of the ten categories in its Top 10 for agentic applications, the common thread running through most agentic failures.

Each of those agents is an identity. It has permissions, secrets, and access paths, and it is not a person. Non-human identities already outnumber human ones by roughly forty-five to one on average, and far more in cloud-native estates. More than one in six organizations do not even track when a new AI-related identity is created. A large enterprise loses these in the noise. A lean team never knew they existed.

So: shadow IT used to mean data you could not see leaving. Now it means an actor you cannot see working.

Flip two: the cure became a single point of failure you cannot interview

Now the other half, and I want to be precise about it, because the obvious version is wrong.

A governed agent genuinely can reduce the bus factor. If it runs under a service account you provisioned, tied to your identity system, versioned, with someone who owns it, then yes, the knowledge that lived in one head is now written down and executable, and that is a real gain. I am not going to pretend otherwise.

The failure is the ungoverned one, and it is the one lean teams actually produce. The agent that holds the 2am runbook gets built by one person, on one prompt design, against one API key, on a Tuesday, to solve a fire. It is never versioned. No one else can read its logic the way they would read a colleague's documentation. And when that person leaves, it keeps running, with no offboarding, because nothing in your joiner-mover-leaver process was ever pointed at a thing that has no hire date and no manager.

So you did not remove the single point of failure. You changed its species. The old single point of failure was a person, who could be asked, trained, and replaced. The new one is an opaque process that holds real credentials, that nobody fully understands, and that, like the Replit agent insisting the rollback was impossible, will answer you confidently and be wrong. A person who is the only one who knows is a risk you can see the shape of. An agent that is the only one who knows, and cannot reliably tell you what it knows, is the same risk wearing a label that says resilient.

So: codifying the knowledge did not retire the single point of failure. It promoted it to something you can no longer interview.

The question underneath both flips

Step back from the two flips and they are the same event, seen twice. The company gained a new kind of actor. It did not gain a way to decide what that actor may do.

For two decades the discipline for this was identity and access management, and it asks one question: who can access what. That question still matters, and the tooling for it is mature. It is also no longer the whole job. An agent does not just access a system. It acts in it, on the company's behalf, and it chooses its next step as it goes. So the question a lean team now owns is bigger: who, or what, may act in the company's name, with how much autonomy, under whose authority.

Those are two different questions.

That is also what separates this wave from every shadow-SaaS wave before it. Shadow SaaS was unapproved software. A shadow agent is an unapproved representative.

Read the opening scene again with that in mind. The Replit agent's database access was not the anomaly; plenty of processes held that access. The anomaly was standing authority to act that no one had granted. And once you see it, everything in this article lines up behind the same question: the identities nobody counts, the runbook agent nobody can interview, the gate on the irreversible, the owner column, the offboarding that never fires. All of it is authority work.

So: access was the old question. Authority is the new one, and on a lean team nobody has been assigned to ask it.

The amplifier: the gap is widest where the team is smallest

Both flips hit any small team. Scale decides how hard they land.

The large players are racing too, but they race with a net. Take BMW. Its AIconic system already runs ten agents inside Purchasing and the supplier network, and the company says plainly that in future the application will "perform certain tasks without human supervision," such as monitoring supply chain data and creating reports. That is a serious, on-the-record move toward autonomy. But it sits on top of a platform team, a security function, and an identity program. At BMW's scale the autonomy and the controls are built by different people, in parallel. The agent that acts without supervision and the system that watches the agent grow together.

Now the other end of the same industry, and of almost any other. A fast-scaling company's overseas subsidiary can run on a few dozen people. The same agent wave hits it, with the same self-serve tools and the same pressure to do more with less. But there is no platform team to build the net. The role that would inventory the non-human identities, tier the agents by autonomy, and own the blast radius is the role nobody budgeted for, because it was not a category when the entity was stood up. The autonomy arrives on schedule. The supervision does not.

This is the same shape I wrote about with European compliance. A lean entity inherits the full obligation surface of a giant, with a fraction of the headcount to carry it. And in Europe that surface is legal, not only operational.

Here the directive itself is blunt, and it is no longer pending paperwork: Germany carried it into national law in December 2025, with no transition period. NIS2 makes an entity responsible for managing the risk in its own network and information systems, and it writes in no exception for work an automated agent did on the entity's behalf (NIS2 Article 21). It puts a clock on failure. Once a significant incident fires, the entity owes an early warning within 24 hours, a notification within 72, and a final report a month after that (Article 23). A team that cannot see its own shadow agents starts that clock blind. You cannot report an incident in a system you did not know was running.

And the duty is personal. Management has to approve and oversee those measures, and can be held individually liable for the entity's failures; accountability delegates in execution but not in responsibility (Article 20). An agent no one approved, no one owns, and no one can see is the textbook version of that failure, with a named person attached. A GDPR personal-data flow through the same agent runs the same way: you cannot demonstrate the security of processing you cannot see, which is exactly what accountability under Article 5(2) demands.

And do not assume a small entity sits outside this. NIS2 catches medium-sized firms and up in its listed sectors, which looks like it lets a few-dozen-person subsidiary off. But size is assessed on the group, not the local headcount: a subsidiary of a large parent is measured on the consolidated numbers, and manufacturing sits inside the directive's scope. That overseas subsidiary is in scope because of the group it belongs to and the sector it works in, not in spite of being small.

The newest meter started running on 2 August 2026, when the AI Act reached its main application date. Brussels softened the hardest edge just before the deadline: the Digital Omnibus, in force since late July, pushed the high-risk obligations to December 2027 and August 2028, because neither the national authorities nor the technical standards were ready. What was not pushed is the transparency tier: from now on a system that talks to people has to say it is a machine, synthetic output has to be marked, and deploying AI-generated media or public-facing AI-written text carries disclosure duties of its own, on penalties up to fifteen million euros or three percent of worldwide turnover. And deferred is not cancelled: the hiring screener an employee quietly wires up today becomes a regulated high-risk deployment in December 2027. Every one of those duties starts from the same premise, that the company knows which AI it runs, what it does, and who answers for it. That is an inventory question and an authority question. A shadow agent fails both.

All of this lands unevenly. Adoption is uniform across the industry; the capacity to govern it is not. Gartner expects that by 2027, forty percent of enterprises will pull back or shut down autonomous agents because of governance gaps that only surfaced after a production incident. The giants will absorb that as a line item. For the lean entity, one such incident is the whole year.

So: the same wave does not hit every org equally. The smaller the team, the deeper it goes before anyone is assigned to look.

The strongest version of the other side

The honest objection is good, and it is right about exactly one thing.

It goes like this. Agents do reduce the bus factor, because executable knowledge beats tribal knowledge. The security problems are real but not new in kind: every wave produced shadow versions and ungoverned identities, the industry built governance for service accounts and APIs before, and it will build it for agents. The giants are already doing it. The small teams will catch up.

That objection is correct about the giants and wrong about everyone else, and it smuggles in a category error besides. A service account executes the code you gave it, so governing it was an access problem, and the industry has genuinely solved access at scale. An agent chooses its next step, so governing it is an authority problem, and the industry has no comparably mature operating model for that yet. What remains of the objection is capacity, and two asymmetries break it.

First, codified knowledge only retires the single point of failure if someone owns, versions, and audits the agent that now holds it. The giant has a team for that. The lean entity codifies its runbook into an agent and then has no one positioned to own the agent, which does not remove the fragility, it hides it. Writing knowledge into a black box you cannot question is not the same as writing it down.

Second, the giant amortizes its governance across a platform and millions of identities it already manages. The lean team is cold-starting the same controls in two years, not over decades, while also running everything else. "They will catch up" assumes spare capacity that a lean team, by definition, does not have. Catching up is exactly what it has no slack for.

What to actually do

None of this argues for banning agents. That is the one move guaranteed to fail, because it pushes every agent into the shadow. The work is to make the governed path real and the shadow path unnecessary, and to do it at a scale a lean team can actually sustain. The frameworks below are public; the sizing is the point.

Find the agents you cannot see before you try to govern them. Every other step assumes you know an agent exists, and flip one was that you do not. Discovery is not free, but it is cheap. Pull the OAuth grant list in your Microsoft 365 or Google admin console and read what has been authorized against your data. Read the expense reports for AI SaaS subscriptions IT never provisioned. Neither needs a tool, just an afternoon once a quarter. If your firewall already logs egress, add a third check: connections to API endpoints you do not recognize. Then open the cheapest discovery channel of all: amnesty. Make it a standing rule, and have management announce it rather than IT: report a shadow agent in good faith and it costs you nothing; hiding one is what gets you in trouble. Open a one-time registration window for whatever already exists, no questions asked. The incident clocks give this teeth. The 24-hour and 72-hour timers start when the company becomes aware, and awareness is exactly what a hidden agent delays. When one finally fails, you start that clock on a system you are seeing for the first time.

Keep an inventory, and make it a document, not a project. The non-human-identity vendors will sell you a discovery platform. You do not have time to run one, and inventory-first programs have a way of going stale the moment they ship. Your inventory is a shared doc with four columns: the agent, who owns it, what it can touch, and how to kill it. It is the control you run until you have earned the headcount for the platform, not instead of it. An imperfect list you maintain beats a perfect tool you abandon.

Ask two questions instead of building tiers. Gartner's own guidance is that one uniform governance policy across all agents is a route to failure, because agents run at different levels of autonomy and across different trust boundaries. The enterprise frameworks define several levels. You have capacity for two questions, one per disease. Can this agent do something irreversible? That is the blast-radius question, and everything in the yes column gets an owner, a gate, and a leash. Count a leak as irreversible: an agent that can read your most sensitive data belongs in the yes column even if it never writes a byte, because a disclosure cannot be recalled. Does anyone besides its builder depend on it? That one is about the bus factor, and a yes means it gets an owner and a page of documentation. If you already classify your data, half the sorting is done for you: an agent inherits the tier of the most sensitive data it can reach. A multi-tier model you do not maintain is theater.

Put a human gate on the irreversible, and starve agents of standing privilege. Replit's own remediation is the template: separate development from production, add a planning-only mode, make destructive actions require a human. Assume prompt injection will happen, because EchoLeak showed that merely reading untrusted input is enough, and never give an agent standing high-privilege credentials it does not need for the task in front of it.

When you take over a shadow build, make it a promotion, not a confiscation. The person who wired up the 2am runbook agent is not the defendant. They are the closest thing you have to a second engineer, and the thing they built is useful, or nobody would depend on it. So adoption has to hand them something. Move it onto company infrastructure and it gains the backups, the monitoring, and someone on call when it breaks. Put the code in the company repository with their name still on it. Take the credentials into managed storage so the thing survives their departure instead of dying with their laptop or running on a key nobody can revoke. Done that way, governance feels like a service. Done as a seizure, it teaches every future builder to keep the next one hidden, and you are back at flip one.

Make the sanctioned path faster than the shadow path. Shadow AI is driven by speed. People go around IT because going through IT is slower than the deadline allows, and this is not a fringe behavior. IBM's 2025 breach report found that breaches involving shadow AI cost about 670,000 dollars more than breaches at firms with little or none of it, and that one in five organizations had already had one. Yet half of workers use unsanctioned AI anyway, and sixty-nine percent of the C-suite are fine with it, most of them saying the speed is worth the risk. You will not win that with policy. You win it by making the approved agent the fast one. If the governed path is slower, you are funding your own shadow IT. And mind the gap before that. Until the approved option exists, an explicit, bounded tolerance works where a blanket ban gets quietly ignored: name the permitted uses, name the data classes that stay out, and set a migration deadline for the day the sanctioned tool lands. What the tolerance buys is visibility. The breaches behind that 670,000-dollar premium happened in use nobody could see.

If you take one thing from this, size it to your team. A five-person shop will not run an identity program this quarter; it will run the quarterly OAuth review, the four-column doc, and the amnesty rule, gate the one agent that can touch production, and adopt the one build people already depend on. A fifty-person entity can build the tiers and the gateway for real. The mistake is treating those as the same job, or treating either as optional.

The thing I am most sure of

Separate what I know from what I am betting.

What I know is cited above. Agents act now, they do not just leak. A single untrusted email was enough to turn a sanctioned assistant into an exfiltration tool. The biggest carmakers are deliberately moving real work onto agents that run without supervision, and half the workforce is already running AI no one approved, with most of their leaders fine with it.

What I am betting is this. The agent wave will not be hardest on the companies with the most agents. It will be hardest on the teams with the fewest people to watch them. The single point of failure and the shadow did not get solved. They got automated, and handed to the smallest teams to discover on their own.

The bus factor never left. It stopped being a person you could ask, and came back as a service account no one remembers creating, holding a key no one remembers issuing, doing work no one remembers approving.

If you are the one person who would have to run this on a small team, I would want to hear how you are drawing the autonomy line.