What it is: knowing which agents exist is the easy part
Most organisations can name the agents they approved. Almost none can name the ones actually running, or say what those agents reach. A complete inventory answers all three of these.
What is calling. Every agent, service account, scheduled job and outside system making calls, including the ones with no owner recorded anywhere. Anything non human is resolved by identity rather than by what it claims to be, so nothing hides behind a framework.
What they reach. The services, databases, tools and third party endpoints on the other side of those calls. This is the half most inventories leave out, and it is usually where an unreviewed dependency on a regulated system surfaces.
What each one may do. The access an agent actually exercises, set against the access it holds. The gap between the two is the blast radius, and you cannot size it from a credential list alone.
Why shadow agents happen: 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.
What they look like: 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.
Why the usual tools miss it: 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.
A snapshot is out of date by Friday. Agents are created faster than anyone can write them down. A picture captured on Monday is already short a few entries by the end of the week, so discovery has to be a live view.
How KPATH does it: discovery grounded in calls, not configuration
Because KPATH 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.
Any agent, any framework: personal assistants, LangChain and CrewAI, Claude and OpenAI agents, MCP servers and tools. In the middle sits KPATH, the policy enforcement point, running identity, kill switch, cost, policy, approval and guardrails, with a tamper-evident audit stream on to your SIEM. On the far side sit the governed services: internal service agents, enterprise APIs, MCP tool servers and external SaaS, proxied. One path between every agent and every system it can touch. Agents carry no system addresses and no credentials, so every call is identified, checked against policy and recorded, whatever framework the agent runs on.
It watches real calls. KPATH sits on the path between agents and the services they reach, so the inventory is built from what genuinely happens rather than from what was declared. Agents show up regardless of the framework they use or where they run.
It starts in monitor mode. Discovery enforces no policy, so calls keep going through. The inventory populates while everything keeps working, so you never have to accept operational risk in order to find out what your operational risk is.
It works with the stack you have. Keep your identity provider, your guardrails engine, your agent platform and your existing APIs. KPATH adds the discovery layer across them rather than replacing any of them, and agents keep their own frameworks and payloads.
Working beside the catalogue you already keep
KPATH can be the directory your agents search. It can also work alongside the catalogue you already keep, such as ServiceNow or Backstage: you bring the services you want governed into KPATH, and your catalogue stays the source of truth. Or it can skip discovery altogether and only govern the calls, so your catalogue says which service and KPATH decides whether the call goes ahead. Different parts of the estate can use different arrangements.
What happens next: the inventory is the start of the work, not the end of it
Discovery is the first of the five checks KPATH runs on every call: discover, identify, govern, contain and prove. The inventory is what the other four are built on.
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 switch from watching to enforcing when you are ready.
Related: the KPATH platform, the AI agent control plane, or what the EU AI Act asks of agent estates.