The agents nobody authorised
By Anthony Odole · September 3, 2026 · 9 min read
Around three quarters of companies plan to deploy agentic AI within two years. Around a fifth report mature governance for agents.
That gap is the whole story, and it isn't closing. Active agents inside one major productivity suite grew fifteenfold year over year — far outpacing governance frameworks that were designed for supervised tools and quietly inherited by unsupervised ones.
Meanwhile shadow AI already accounts for about twenty percent of breaches, and incidents involving it cost roughly $670,000 more than the average. Those numbers are usually presented as a security statistic. I want to argue they're an architecture statistic, because the mechanism that produces them is one enterprise architects have dealt with for thirty years — and the reason it's biting harder now is a property of agents specifically.
Shadow IT was a procurement problem. This isn't.
Shadow IT — the department that bought its own SaaS on a corporate card — was annoying but tractable. It had physical tells. There was an invoice. There was a login page. There was a vendor with a contract, a support email, and someone in the business who would admit to owning it if you asked directly.
Shadow AI has none of that. Much of it operates through browser extensions, embedded scripts, and personal cloud accounts. There is often no procurement event, no installation, no asset to discover with the tooling you already own. The absence of a purchase order is not evidence of absence.
But the sharper distinction is between shadow applications and shadow agents, and it's worth being precise, because organisations are applying shadow-IT thinking to a category that behaves differently.
A shadow application is a place where data goes that it shouldn't. Bad, bounded, and fundamentally a data-flow problem.
A shadow agent acts. The characterisation I'd endorse is that shadow agents operate at machine speed, can persist system access indefinitely, and can autonomously initiate sequences of privileged actions without human review. That's not a data-flow problem. That's an unaccountable actor inside your estate with credentials you didn't issue, doing work nobody scoped, on a schedule nobody set.
Between those two, the second is the one that should be keeping you up.
The three ways they arrive
In practice I see ungoverned agents enter an estate through three doors, and only one of them looks like the thing security teams are watching for.
Someone builds one. An engineer wires an assistant to a system to automate something tedious. It's genuinely useful, it takes an afternoon, and it never enters any inventory because it wasn't a purchase and doesn't feel like a deployment. It feels like a script — and scripts have never required governance review.
A vendor ships one into a product you already own. This is the largest source and the least discussed. A tool your organisation approved two years ago as a passive application now includes an agent capable of taking actions across your data. Nobody made a decision. The capability arrived in a release note. Your governance record still describes the product you evaluated, which no longer exists.
One you approved grows. This is the quiet one, and it's the subject of the separation-of-duties problem I've written about separately. The agent was authorised. Then it was granted a capability in March because it needed context, and its trust level was raised in September because it had been reliable, and the combination — which nobody reviewed, because no single change warranted a review — is an agent with authority nobody would have granted in one go.
Note what the second and third doors have in common: no unauthorised person did anything. Every actor behaved correctly. The ungoverned state is emergent. That's why the shadow-IT playbook of "find the rogue purchase" catches almost none of it.
You cannot govern what you cannot enumerate
Here's the part I'd ask you to test in your own organisation this week, because I think the answer will be uncomfortable.
Pick one agent you know about. Produce, from the running system rather than from a design document, the complete list of actions it can currently take.
Not what it's for. What it can reach.
I run a multi-agent platform, and I want to be honest about how hard this is even when you built the thing. In our system an agent's usable capabilities are the output of a chain — the capabilities attached to the agent, the skills those imply, the tools those require, a filter for whether each tool needs a connected integration, a registry on the execution side, and a lookup at call time. Every layer can independently remove a tool. The answer to "what can this agent do" is not stored anywhere. It is computed, at the moment of asking, from several systems that must agree.
We also went through a period where those grants were cached, and several code paths wrote to the database without invalidating the cache. For up to ten minutes the running system and the recorded system disagreed about an agent's authority. Six of the seven historical write paths had that flaw. Not one of them was written carelessly — the invariant simply hadn't been stated, because nobody had held the whole picture at once.
If that's the situation inside a system built deliberately, by a team that thinks about this, consider the estate that accumulated agents through three doors nobody was watching.
The evidence trail that doesn't exist
There's a second-order problem that arrives after the incident, and it's the one I'd expect to generate the largest bills.
Most generative systems do not preserve prompt histories or version records. When a decision made by an AI system needs to be reviewed, there is frequently no evidence trail to reconstruct it. You can see that an action was taken. You often cannot establish why, on what basis, under whose authority, or with which version of which instructions.
For a regulated organisation that's not an inconvenience, it's an inability to answer a question you are obliged to answer. High-risk provisions under the EU AI Act take effect this month, with penalties reaching €35 million or seven percent of global turnover. "We can't reconstruct what happened" is a poor position from which to begin that conversation.
The architectural remedy is unglamorous and has to be decided in advance, because you cannot retrofit a record of something that wasn't recorded. In our own system every gated action and every tool execution stamps the agent's trust level at the moment the row was created — so an audit can ask "which actions did this agent take while it was operating at reduced supervision?" without reconstructing history from timestamps. That's one field. It cost almost nothing to add on the day, and it is unrecoverable if you skip it.
The general principle: an agent's action record must capture the authority under which it acted, not merely the fact that it acted. Logs answer what happened. Governance requires what was permitted, and by whom, at that moment.
Six places to look, this week
I want to give you the actual discovery method, because the honest test of everything above is whether it returns anything in your estate. It will. I have never run this and found nothing.
None of it requires new tooling. All six use systems you already own, and you can get through them in a few days.
1. Non-human identities, sorted by recent activity. Ask your identity provider for every service account, machine identity, and API principal, ordered by last authentication. Then ask, for each one active in the last thirty days, who owns it and what it does. The interesting column is not the list — it's how many rows produce the answer "I'll have to find out." In most organisations that's between a fifth and a half, and each one is an actor in your estate with no accountable human.
2. Your top twenty applications, checked for agent features. Highest yield for least effort, because it's a finite list you already have. For each significant application: does it now include agentic capability, what can that agent reach, and did that capability exist when the product was approved? Expect several. They arrived in release notes. Your governance record still describes the product you evaluated.
3. Egress to model providers. Your network logs know which sources are talking to LLM APIs. Pull that, grouped by originating system. The rows you expect are fine. The rows you don't expect are the whole point, and they are usually the most interesting output of the entire exercise — because a system nobody told you was calling a model is a system doing work nobody scoped.
4. API keys issued to "integrations". Go through the keys your systems have handed out, particularly ones issued more than a year ago to something described as an integration. Some proportion now sit behind an agent rather than a script. The credential didn't change; what's holding it did.
5. Browser extensions on managed devices. Much shadow AI operates through extensions and personal cloud accounts rather than anything installed. Your endpoint tooling can enumerate these. It is not a comfortable list.
6. Ask your engineers the right question. This is the one I'd insist on, and it's free.
Do not ask "are you using unapproved AI tools?" You will get honest denials, because nobody thinks of what they built as an AI tool — they think of it as a script that saves them an hour.
Ask instead: "What have you automated in the last year that you'd hate to lose?"
People answer that one happily and in detail, because they're proud of it. Then follow each answer with two questions: what can it reach, and what happens if it's wrong. In my experience this single question finds more ungoverned automation than any technical scan, and it finds it faster, because the people who built it are describing it to you voluntarily rather than being audited.
What the findings will look like
Three things will come out, and it's worth knowing in advance which is which, because they need different responses and organisations routinely conflate them.
Things that are fine. Most of what you find will be legitimate, useful, and low-risk. Resist the urge to shut them down — you'll spend your credibility on the wrong targets and drive the next one further underground.
Things that are ungoverned but bounded. An agent that can read but not write. An automation touching one system with narrow credentials. These need to be recorded, given an owner, and left running. Recording is the entire remediation. It sounds like doing nothing; it is the difference between an estate you can describe and one you can't.
Things that can act on something consequential. Move money, send external communications, change access, alter production data or configuration. This is the short list, it's usually very short, and it's the only one that warrants stopping something. Everything I've written about separation of duties applies here first.
The triage question that sorts them: if this acted wrongly at three in the morning, at machine speed, for six hours before anyone noticed — what would the damage be? That's not a hypothetical framing. It's the actual operating condition of an unsupervised agent, and most estates have never asked it of anything.
The part that isn't discoverable
I want to be straight about the limit of what I've just given you, because it's where this stops being a checklist.
Those six searches find agents. They don't tell you whether your authorisation model is coherent — and that's the harder problem, because it's a judgment about composition rather than a scan for artefacts.
An agent can pass every item above. Owned, recorded, approved, appropriately scoped, no shadow anything. And still be dangerous, because of what happens when its capabilities are considered together, or when it's promoted, or when a second agent is granted an overlapping tool six months later by someone who didn't know about the first. That accumulation is invisible to discovery, because at no point does anything unauthorised occur. It's the third door from earlier, and it is the one I find most often in organisations that have already done the governance work.
Deciding which combinations of authority are acceptable — and encoding that decision so a future administrator can't undo it with a well-intentioned click — is architecture work. It requires someone to hold the whole picture, which is precisely what nobody in a large organisation does by default, and it does not come out of a scan.
That's the piece I'd expect to be hard to do from inside. Not because the people are lacking, but because the whole failure mode is that no individual has the whole picture, and asking one of them to acquire it is asking them to do a different job than the one they have.
What I'd actually do, in order
Not a framework. Four moves, cheapest first.
Inventory by capability, not by purchase. Ask what non-human identities are authenticating against your systems and what they can do. The question that finds shadow agents is not "what did we buy?" but "what is acting?" Your identity provider knows more than your asset register.
Audit the products you already own for agent features. This is the highest yield for the least work, because it's a finite list you already have. For each significant application: does it now include an agent, what can that agent reach, and was that capability present when it was approved? Expect to find several. They arrived legitimately.
Make the reachable-actions list generable. Whatever it takes, you need to be able to ask the running system what an agent can currently do and get a trustworthy answer. Everything downstream — approval, audit, incident response — is guesswork without it.
Decide the record before you grant the authority. What is captured when an agent acts, including under whose authority. Do this before the deployment, because the version of this you build after an incident will always be missing the field you most needed.
The thing I'd resist
The instinct, when this lands, is to prohibit. Ban unapproved agents, mandate review, publish a policy.
I'd resist it, on the same reasoning as the refusal message we built into our own trust ladder: a control that blocks without offering a route through gets circumvented, and circumvention pushes the activity further out of sight. The engineer who automated something tedious was solving a real problem. Prohibition doesn't remove the problem, it removes your visibility of the solution.
The workable version pairs the inventory with a fast, genuinely usable path to doing it properly. Governance that is slower than the shadow route loses, every time, in every organisation I have ever worked in.
Why this is an architecture problem
Security teams will own the incidents. But the failure is architectural, and it's the failure of a specific discipline: maintaining an accurate model of what exists and what it's permitted to do, while the estate changes underneath you.
That has always been the job. What changed is that the things entering the estate can now act on their own initiative, at machine speed, with credentials that persist — and they arrive through doors that generate no procurement event, no installation, and no decision anyone remembers making.
You cannot govern an estate you cannot enumerate. That was true when the unmapped thing was a server under someone's desk. It's less forgiving now that the unmapped thing has an API key and an agenda.
Architecture first. Technology second.
Run the six searches. If what comes back is larger than you expected — or if it's clean and you're not sure you'd have found the third kind — that's worth half an hour.
Book an Enterprise AI Strategy Briefing →
— Anthony Odole · ex-IBM Senior Managing Consultant · 18 years in enterprise architecture · now building and running a multi-agent platform