Find the agents nobody registered.
Almost every organisation running AI agents at any scale has more of them than anyone has written down. Shadow agent discovery inventories what is making calls, and what those calls reach, without blocking a single one.
Nobody set out to run ungoverned agents. It is a byproduct.
Shadow AI is usually described as a discipline problem. It is closer to an arithmetic problem: the number of people who can create an agent grew much faster than the process for recording one.
Building an agent stopped being a project
Low code builders and assistant studios put agent creation in reach of people who do not file architecture tickets. A business analyst can stand something up in an afternoon, and nothing about that afternoon reaches a register.
Every team solved it separately
Different departments picked different frameworks and wired their own credentials, logging and limits. There was never a shared inventory to add to, so nobody added to one.
Pilots outlive their paperwork
Proofs of concept get built to answer a question, then quietly keep running because something started depending on them. The approval was for an experiment, and the thing in production is no longer that.
Agents create other agents
Once an assistant can delegate to a specialist, the population grows without a human deciding to grow it. The agent nobody registered may have been invoked by an agent that was.
Four shapes that turn up in almost every estate.
Shadow agents are rarely exotic. When organisations run discovery for the first time, the same handful of patterns account for most of what surfaces.
The pilot that never ended
Built to test whether an agent could triage support tickets. It could, so it kept going. Eighteen months later it holds a service account with write access, the person who built it has changed teams, and it appears in no register because it was never meant to be permanent.
The console agent
Configured entirely through a vendor's assistant studio, so there is no repository, no pull request and no deployment pipeline. A code scan will never find it. It is reaching your CRM on a schedule nobody set a policy for.
The over-credentialled helper
Needs to read one table and was given a credential that reaches the whole database, because that was the credential to hand. Nothing has gone wrong yet. The blast radius is simply much larger than the job.
The partner's agent
Arrives from outside the organisation on an integration signed off two years ago, when the thing on the other end was a nightly file transfer rather than something that makes decisions. Nobody re-reviewed it when that changed.
You cannot inventory behaviour by reading configuration.
Scanning code finds intentions, not behaviour
A repository scan tells you what someone wrote down. It misses the agent configured through a vendor console, the one running on a laptop, and the partner system calling in from outside.
Identity tells you who exists, not who acted
An identity provider can list the credentials it issued. It cannot tell you which of them actually made a call last Tuesday, or what that call reached.
Most tooling only looks at one side
Knowing which agents exist is half a picture. The other half is the services, databases and third party APIs those agents are touching, which is usually the part that worries an auditor.
Discovery covers what is calling and what is being called.
Because KPATH AMP sits on the path between agents and services, it sees both ends of every call. That produces an inventory of callers and of the things they touch, rather than a list of one and guesswork about the other.
The callers
Every agent, application, scheduled job and outside system making calls, including the ones with no owner recorded anywhere. Anything non human that makes a call shows up the same way, because it is resolved by identity rather than by what kind of thing it claims to be.
The things they reach
The services, tools and third party endpoints on the other side of those calls. This is the half most inventories miss, and it is where an unreviewed dependency on a regulated system tends to surface.
The inventory is the start of the work, not the end of it.
Adopt what should exist
Give the agents you are keeping a name, an owner and a risk tier, so they become things the business manages rather than things it discovers.
Retire what should not
Most estates contain agents whose original purpose is finished. Turning them off is the cheapest risk reduction available, and you cannot do it until you know they are there.
Then decide about enforcing
With a real inventory you can set policy against actual behaviour rather than assumptions, and flip from watching to enforcing when you are ready.
Questions about shadow agent discovery.
What counts as a shadow AI agent?
Any agent making calls into your systems that is not in an inventory somebody maintains. It is rarely malicious. The usual story is a team that built something useful, kept it running, and had nowhere to register it. The risk is not the intent, it is that nobody can say what the agent may do or stop it quickly.
How is this different from a code scan or an asset inventory?
Those describe what was written and what was provisioned. Discovery here watches actual calls, so it surfaces behaviour instead of intentions. It also covers agents nobody committed to a repository, including ones configured in a vendor console and systems calling in from outside your organisation.
Does turning this on block anything?
No. Monitor mode permits every call and changes no behaviour. It builds the inventory while everything keeps working, which is the point: you should not have to accept operational risk in order to find out what your operational risk is.
Do our teams have to rewrite their agents?
No rewriting. Agents keep their own frameworks and their own payloads. Teams point their outbound calls at one governed path instead of reaching services directly, and nothing about how an agent is built has to change.
What do organisations usually find?
More agents than expected, and more surprising is usually the second half: services being reached that nobody reviewed, including systems holding regulated data. Retired pilots still running are common. So are agents holding credentials far broader than their job needs.
How long before the inventory is useful?
It starts populating as soon as calls begin flowing through, and becomes representative once a normal business cycle has passed, since some agents only run weekly or monthly. A month of observation covers most patterns.
Related: what the EU AI Act asks of agent estates, or the KPATH AMP platform.
You cannot govern an agent you have not found.
Start in monitor mode. Nothing gets blocked, and you see the estate you actually have.