How to govern shadow AI agents you cannot see

A shadow AI agent is an autonomous agent running inside your organisation that no one formally approved, inventoried, or scoped. It is an agent a team set up to get its own work done. The team connected it to real systems and never registered it with anyone responsible for security. It is the agent version of shadow IT. It is spreading faster than shadow SaaS did, because setting up an agent now takes an afternoon and a token instead of a procurement cycle.

How big is the shadow AI problem?

Large enough that the count is the main finding.

IBM estimates that by the end of 2026 the average large enterprise will run more than 1,600 AI agents, and that around 70% of organisations cannot govern the ones they already have. The problem is the gap between what is running and what anyone can see. In one widely cited example, a Fortune 500 company that turned on agent discovery found roughly 18,000 active agents after formally approving about 300. Almost all of those agents had never been formally approved.

Governance has not kept up. Analyses of enterprise agent sprawl put the share of organisations with a current, complete inventory of their agents at well under a fifth, with only a small minority running any centralised platform to manage them. If an agent is not in your inventory, you cannot revoke it or rate-limit it, and you cannot answer a regulator's questions about it.

Why is agent sprawl worse than shadow SaaS?

Because a SaaS tool waits to be used, and an agent acts on its own.

Shadow SaaS was mostly a data-residency and licensing problem. A person put company data somewhere it was not approved to be. A shadow agent has the same data-residency problem, and it also takes actions. It holds credentials, calls tools and writes to live systems, with no person checking each action. An unknown spreadsheet can only expose what is in it. An unknown agent can affect every system it was given a token for.

This is why the issue has moved from IT teams to the board. When agents can move money, change records, or send mail on their own, governing them is now treated as a board-level issue rather than a tooling detail. A board wants to know which agents can do something you cannot undo, and who authorised that. The total number of agents matters less.

How do you govern an agent you cannot see?

Make it impossible to run an ungoverned agent, instead of hunting for them afterwards.

Discovery tools help you count the agents that already exist, and the count can be a useful wake-up call. But a count you run every quarter will always lag behind agents that appear every week. The lasting fix is in the architecture. Agents reach systems through a single chokepoint that issues their credentials and records their calls. An agent that did not come through it has no credentials to act with. Your inventory then comes from how access works, instead of being a report someone has to put together.

Three properties make that chokepoint work in practice:

• Deny by default. An agent reaches only the tools its contract named, and every attempt outside that is blocked and logged. Access from yesterday does not carry over to today.
• No raw credentials in the agent. The agent never holds your long-lived keys. It receives short-lived, scoped tokens issued at the gateway. Revoking an agent is then one action, instead of rotating keys on every system it touched.
• The gateway writes the log. The record of what an agent did is written by the system it calls through, not self-reported by the agent. An agent cannot leave itself out of a log it does not control.

What does governed agent access look like?

It starts with a work order instead of a standing key.

Before an agent does anything, there is a signed statement of what it may touch, at what scope, and with which checkpoints. Reads pass through. Writes land in a staging area and reach the live system only after a check. Every call is attributed to the key that made it, by name, in an append-only trace. An agent set up this way cannot be a shadow agent, because it cannot work without being seen. The same logic explains why most agent failures are context failures. If nobody scoped an agent, nobody told it what done meant.

Cognibl is built around that chokepoint. Agents reach your systems through a gateway. It issues scoped tokens, enforces a per-project policy map, keeps tool access read-only until writes can be staged, and records the run in a hash-chained trace. There is one way in, and you can see everything that uses it. An agent that is not registered has no path to your data. See the gateway that governs agent access.