An AI agent inventory is a live list of every agent running in your organisation, each with a named human owner, where it runs, the model it calls, the tools, MCP servers and credentials it can reach, and when it last acted.
Key facts
Definition
An AI agent inventory is the live join of enrolled agents and what discovery finds, each record naming an owner, runtime, model, tools, credentials, data reach, environment, last activity and status.
How Bigcircle does it
- On Solarpunk, Bigcircle injects credentials from an encrypted vault at the call, lets the agent act only through registered tools, and queries the registry each step rather than giving the model the list.
- On Skionis, Bigcircle tags created resources with creator, owner, environment, tool and request, and measured template errors before deploy falling from around 10% to 4%.
- On the insurance voice agent, Bigcircle puts the permission check in the tool contract, so the model's output is a request to call a tool and never an action by itself.
Comparison
A registry is the list agents enrol in on purpose, while an AI agent inventory is that list reconciled against gateway traffic, identity grants, endpoint telemetry and SaaS builder APIs.
Key number
On Solarpunk, plans completed with no person rose from about 55% to 80% once local retrieval and planner memory grounded the agent, in our own measurement during the build.
You build it from several signals because no single one sees everything: a registry agents enrol in, gateway traffic, identity and OAuth grants, endpoint and runtime telemetry, and SaaS platform APIs. Shadow AI agents are the ones that only show up in the second set of signals.
The agents we build keep scoped credentials in a vault, act only through registered tools, put a check in the tool contract before a call, and leave a per-run trace. On Skionis, created AWS resources are tagged at creation with creator, owner, environment, tool and request, so those fields live in the systems rather than in a spreadsheet someone updates later.
The hard part is not naming the agents you already like. It is the coding agent on a laptop, the Copilot Studio or Agentforce bot a team published last Tuesday, the always-on background worker that inherited someone's access, and the child an agent spawned during a run. Until those have owners, you cannot set permissions, flip a kill switch, attribute cost or keep an audit trail. The inventory is the precondition for those pages, not a replacement for them.
This guide starts with what an AI agent inventory is and the fields of one record. It then covers why sprawl happens, how you find shadow AI agents, and what belongs in a registry. It ends with a 30 day rollout, what to do with the list, and how the agents we ship already keep a vault, a reach limit, a last-acted trace and, on Skionis, tags at creation.
What is an AI agent inventory?
Treat an AI agent inventory as a living record of every agent that can act, not as a catalogue of models or a list of chatbots. One record is one agent. A named person owns it. The fields say where it runs, which model it calls, which tools and MCP servers it can reach, which credentials and scopes it holds, which data it can see, which environment it is in, when it last acted, and whether it is live, idle or retired.
A model catalogue answers a different question, and so does a SaaS licence report. Those lists miss the coding agent that talks straight to a provider, the local MCP server on a laptop, and the background bot that never sent a chat. The inventory is the list you would hand a security lead who asked "what can act, as whom, on what".
We already keep a slice of that record on the agents we build. On Solarpunk, a desktop agent that reaches more than a hundred tools, the agent can act only through systems someone registered, and it cannot invent access it was not given.
On Skionis, the DevOps agent we shipped on a live AWS account, created resources are tagged with creator, owner, environment, tool and request, because attribution written at creation will never be reconstructed afterwards. Full coverage is our internal record and is worth confirming before it is quoted as 100%. Those habits are how an inventory stays true, and they are not a product we sell under that name.
| Field | What it records | Why it has to be there |
|---|---|---|
| Agent | A stable name and id | Two Copilot bots with the same display name are not one agent |
| Owner | A named person, not a team inbox | A stop with nobody assigned is only a log line |
| Runtime | Desktop, SaaS builder, in-house service, background worker | Each runtime needs a different discovery signal |
| Model | The model id the agent calls | Spend and routing attach to this, not to a vendor invoice |
| Tools and MCP servers | The actions it can take | Reach the agent was given, not reach it might talk its way into |
| Credentials and scopes | Vault, OAuth grant, service account | A grant nobody listed is a shadow agent |
| Data reach | Systems and stores it can read or write | Permissions later bind this; the inventory only names it |
| Environment | Dev, staging, production, a tenant | A halt scoped to one tenant needs this field |
| Last activity | Last model call, tool call or session | Idle agents still hold credentials |
| Status | Live, idle, retired | Retirement has to drop the credential, not only the chat |
Skip a field and the next control fails, because without an owner governance has nobody who can change an autonomy level. Without tools and credentials, permissions has nothing to bind, and without last activity monitoring cannot tell a quiet agent from a missing one.
Why does AI agent sprawl happen?
AI agent sprawl starts when agents can be created in more than one place, and none of those places writes to the same list. A platform team ships an in-house agent and a developer installs a coding agent on a laptop. A business team publishes a bot in a SaaS builder, and the agent itself starts a child in the middle of a run. Each of those is a new actor with some person's access, and the invoice still arrives as one line.
We watched the in-house half of this on Solarpunk, where direct wiring of every tool into the prompt held until roughly 30 tools. Past that, the model picked plausible tools from the wrong system with no sign in its output. Point-to-point wiring had a second cost, because a vendor changes a response and the break shows up somewhere unrelated, days later. Across a company the same failure is quieter: nobody can say how many agents exist, because each team counted only its own.
The last two weeks of product news make the other places harder to ignore. Sysdig's 4 November 2026 press release lists a live inventory of agents, harnesses, models, MCP servers, skills and plugins, each traced to a person, across Claude Code, Codex, GitHub Copilot and Cursor. Policies on that product start in alert mode before enforcement, and spend is attributed per agent, including calls that never pass through an AI gateway. That is Sysdig's own account of what it ships, and it is useful for the coding-agent traffic a gateway never sees.
Okta's 5 November 2026 write-up of Okta for AI Agents puts an AI agent registry in Universal Directory as first-class identities, and watches new OAuth consent grants in managed browsers to catch unmanaged agents. Microsoft's Copilot Agents usage numbers in the Microsoft 365 admin center, as of November 2026, cover active agents, licensed and unlicensed users, and usage per agent. None of those is a complete estate, and each one is a signal the inventory has to read.
Snowflake's 3 November 2026 CoCo and CoWork press release covers always-on bots that inherit the caller's access rights and run background tasks until they need a decision. Those bots are in private preview soon, so they are not a live source the inventory can already read.
IBM's 2026 Tech Leader Study surveyed 2,000 technology executives. 77 percent of organisations surveyed say AI adoption already outpaces governance. Use that as a reason to look, not as a count of your own agents, and count yours from the signals below.
How do you find shadow AI agents?
Shadow AI agents are agents that can act and that nobody enrolled, and AI agent discovery is the work of finding them. Start from the registry you already have, then read every other signal, and treat a match as owned and a miss as shadow. Do not wait for a single product to see the whole estate, because it will not.
The figure is the join: blue is the reconciled list, green has an owner, and orange is unmatched, so it is shadow.
A gateway is a discovery point for traffic that passes through it, and a blind spot for traffic that does not. An MCP gateway sees tool calls to registered servers, and an AI gateway sees model calls from callers pointed at it. A laptop coding agent that holds its own key, a local MCP server over stdio, and a model pulled onto a machine never cross either hop. Put both gateways on the inventory as sources, and never treat them as the inventory.
| Signal | What it sees | What it misses |
|---|---|---|
| Registry enrolment | Agents someone put on the list on purpose | Everything a team stood up without asking |
| AI or MCP gateway traffic | Model and tool calls that pass the hop | Direct provider keys, local MCP, on-device models |
| Identity and OAuth grants | New consents, service accounts, tokens | Agents that reuse a person's session with no new grant |
| Endpoint and runtime telemetry | Installed tools, config files, processes, MCP servers on the machine | SaaS-only bots that never touch the laptop |
| SaaS platform APIs | Copilot Studio, Agentforce, n8n and similar builders | Coding agents and in-house runtimes |
| Cloud accounts and code repos | Service principals, deploy pipelines, agent definitions in git | Personal emails, unmanaged browsers, desktop installs |
Endpoint scans of AI tool and MCP config files catch the laptop slice, SaaS-platform connectors catch the builder slice, and identity monitoring catches the grant slice. Runtime telemetry catches processes that the agent's own log never wrote, so use all of them and rank none of them.
On Solarpunk we stopped giving the model the registry, and each step queries it, so the working context stays small and the action list stays enumerable. That query log is a discovery signal for tools the agent actually used, and it still misses an agent that never called us. Reconcile the query log against enrolment the same way you reconcile gateway traffic: a call with no record is a shadow agent, and a record with no call is idle.
Assign an owner the day you flag a miss, because an unmatched grant that sits in a queue for a month is still a live credential. The owner is a person who can retire it, not a shared inbox that forwards it.
What goes in an AI agent registry?
An AI agent registry is the list agents enrol in on purpose, and the inventory is that list plus everything discovery found that is not on it. Keep the two words apart, because a registry that nobody reconciles against traffic is a hopeful spreadsheet, and an inventory with no enrolment path has no way to stay current.
Enrolment is a deploy gate. A new in-house agent, a new SaaS bot, a new coding-agent workspace and a new MCP server do not take production traffic until a record exists with an owner, a runtime, a reach list and a status. We already do the in-house half of that. Solarpunk cannot invent access it was not given. Skionis has no general shell and no path from a plan step to an arbitrary API call. The insurance voice agent we built treats the model's output as a request to call a tool, never as an action, and the tool contract carries the permission check.
A registry field that is only a display name will collide. Give each agent a stable id, the owner, the runtime, the model, the tools and MCP servers, the credential pointers, the environment and the status. Keep secrets out of the registry. Store a pointer to the vault or the grant, the same way we inject credentials at the adapter on Solarpunk rather than putting them in the prompt.
Children share the parent's record until they need their own. A run that fans out to workers is still one agent if the children die with the run and inherit the parent's remaining allowance, which is the rule on AI agent cost. A child that outlives the run, holds its own grant or can be invoked later is a new agent. Enrol it before the next call, or it is shadow.
Retire in the registry, then kill the credential, because a status flip with the token still live is how orphaned agents survive a cleanup. MCP authorization is where the token, the check before the call and the record of each refusal live, and this page only demands that the registry point at them.
How do you build an AI agent inventory in 30 days?
Do not start by blocking. Start by seeing. A gate on day one will hide the agents you most need to find, because people will route around it. Take 30 days, in observe mode first, then owners, then a gate.
In week 1, point every signal you already have at a single store: registry rows, gateway traces, OAuth grants, endpoint findings, SaaS builder APIs, cloud identities and agent definitions in git. Log the agent, the caller, the model, the tool, the credential and the time, and do not refuse anything yet. You need a week of your own mix before a missing owner is a fact rather than a guess.
In week 2, assign owners. For each record that already has a person, confirm they still want it. For each unmatched record, name a person or retire the credential. A team name is not an owner. We already say this for the spend stop: a stop with nobody assigned is only a log line. The inventory owner is the person who can flip that stop.
In week 3, match registry ids to gateway keys, grants to agents and config files to runtimes. Treat every miss as either shadow or a stale row. Write the join down, because a one-off spreadsheet will drift the week a builder adds a bot.
On Skionis we measured template errors before deploy falling from around 10% to 4% across the validation loop's introduction. The method here is the same: compare the claimed list with the live one, and keep the failures.
In week 4, gate: new agents enrol before they take production traffic, and idle agents with no owner and no activity lose their credentials. The gate is a deploy check and a builder policy, not a prompt instruction. Put guardrails on the tool path so an unenrolled agent cannot call a write, and put the last-acted field on the same trace the observability work already writes.
After day 30, reconcile on a schedule. Daily is the default once you have gateway and identity feeds, and weekly is the floor if you only have SaaS APIs and git. An inventory that updates when someone remembers to open the sheet is not an inventory.
The 30 days are a recommendation from how we already put reach limits, traces and, on Skionis, tags at creation on agents we ship. They are not a client programme we have sold under this name, and they are not a count of anyone's estate.
What do you do with an AI agent inventory?
Use the list, because a list nobody reads is a slower version of not knowing.
Permissions bind each action to a person, a target and a check in code. The inventory tells you which agents exist so you can write those bindings, and it does not decide what they may do: that work is on AI agent permissions.
A kill switch needs a name and a scope. You cannot stop what you cannot find, and you cannot pick writes-disabled on one tenant if the record has no environment. What is an AI agent kill switch is the runtime flag, and the inventory is the directory that flag indexes.
Cost attribution needs the same id on the model call, the tool call and the invoice line. Sysdig's 4 November 2026 account of spend per agent, including calls that never pass an AI gateway, is the shape of the gap. Our own cost page already asks for a cap on the request path, and the inventory is how you know which agent hit it. Read AI agent cost for the cap, not for the list.
Monitoring watches what the agent did, and last activity on the inventory is a heartbeat, not a quality score. AI agent monitoring splits quality from infrastructure, and the inventory only says which agent to open.
Governance sets autonomy per action, on evidence, with a person who can move it down, and across an organisation it needs the list this page builds. Do not copy the autonomy table here: read AI agent governance.
The audit trail still needs the evidence version, the rule, the review and a separate read of the target. The inventory adds who owned the agent when the decision ran. AI audit trail is the record, and this page is the directory that record points at.
How Bigcircle already records reach, traces and tags
We do not ship a product named AI agent inventory. The agents we build already keep a vault, registered tools, a check in the tool contract, a per-run trace, and on Skionis tags at creation. The design below is how those fields stay true when a second team or a second builder arrives.
On Solarpunk we keep credentials in an encrypted vault on the user's machine and inject them at the call, so the model is a reasoning service and never holds the keys. The agent acts only through registered, typed tools: we stopped giving the model the registry, and each step queries it. A trace per run goes from the goal through each call to the final application state, so we can compare claimed completion with what actually landed.
Plans completed with no person rose from about 55% to 80% once local retrieval and planner memory grounded the agent. That is our own measurement during the build.
On Skionis we treat the agent as untrusted, and it acts only through purpose-built tools that wrap the provider's APIs. An engineer approves an architecture diagram before a change applies. One record links the request to every resulting resource, and tags at creation carry owner, environment, tool and originating request. Delivery took roughly four months to a working product, and the numbers are our internal records.
On the insurance voice agent, permission checks and required disclosures sit in the tool contract, so an operation cannot run without them. A failing request escalates and does not degrade into something close. On a current engagement for a telecom marketing platform, we scope each agent to the entitlements of the person it acts for. Prompts stay a user-experience layer that no policy check depends on.
Across more than one team or builder, collect those fields from the signals in the table, reconcile them daily, and refuse production traffic to an agent with no owner. The vault, the check and the trace stay where they are, and the inventory is the join.
Common questions
What is an AI agent inventory?#
A live list of every agent running in your organisation, each with a named human owner, where it runs, the model it calls, the tools, MCP servers and credentials it can reach, and when it last acted. You build it from several signals because no single one sees everything, and it is the precondition for permissions, kill switches, cost attribution and audit, not a replacement for them.
What is the difference between an AI agent inventory and a registry?#
The registry is where agents are enrolled on purpose, as a deploy gate. The inventory is that list reconciled against what discovery finds in gateway traffic, identity grants, endpoint and runtime telemetry, SaaS platform APIs, cloud accounts and code repos. A row in the registry with no matching signal is idle or stale, and a signal with no registry row is a shadow AI agent.
What is AI agent sprawl?#
Agents created in more than one place with no shared list: in-house services, coding agents on laptops, SaaS builders, and children that outlive a run. Each one holds some person's access, and the bill still arrives as one line. Sprawl is a counting failure first, and permissions and monitoring cannot start until the count is real.
How do you find shadow AI agents?#
Read the signals the registry does not own. Gateway traffic, OAuth grants, endpoint config files, runtime telemetry and SaaS builder APIs each see a slice, so match them to enrolled records. Anything a signal saw that is missing from the registry is shadow, and you assign an owner or retire the credential the day you flag it.
What is AI agent discovery?#
Finding every agent that can act, including the ones nobody enrolled. Read gateway traffic, OAuth grants, endpoint config, runtime telemetry and SaaS builder APIs, then match them to the registry, because a signal with no registry row is a shadow AI agent.
Can an AI gateway find all my agents?#
No. An AI gateway sees model calls from callers pointed at it, and an MCP gateway sees tool calls to registered servers. Direct provider keys, local MCP over stdio, on-device models and SaaS bots that never cross your hop do not appear. Use the gateway as one discovery signal, and reconcile it against the others.
How often should an agent inventory update?#
Daily once gateway or identity feeds exist, because a grant issued this morning is already a live agent. Weekly is the floor if you only have SaaS APIs and git. Update on enrol, on a matching signal, and on retirement, because a sheet refreshed when someone remembers is not an inventory.
Who should own an AI agent?#
A named person who can retire it and who would be paged if it had to stop, not a team inbox. On an in-house agent that is often the person who owns the operation it changes. On a coding agent it is the person whose laptop or workspace it runs in. Write the name on the record before the agent takes production traffic.
Further reading
- Sysdig, Sysdig Launches Sysdig AI Defense and Introducing Sysdig AI Defense, 4 November 2026. Live inventory from runtime telemetry, alert mode before enforcement, spend per agent including calls that never pass an AI gateway. Sysdig's own account. The blog cites IBM's 2026 Tech Leader Study for the 77 percent governance gap.
- IBM Institute for Business Value, 2026 Tech Leader Study, 8 June 2026. A study of 2,000 technology executives; 77 percent of organisations surveyed say AI adoption outpaces governance. Primary for that figure.
- Okta, Okta for AI Agents is now Generally Available, 5 November 2026. AI agent registry as first-class identities, shadow AI agent discovery via OAuth consent grants in managed browsers, scoped short-lived tokens, access certification.
- Snowflake, CoCo and CoWork Power the Agentic Enterprise, 3 November 2026. Always-on CoCo and CoWork bots that inherit the caller's access rights and run background tasks. Private preview soon.
- Microsoft, Microsoft Copilot Agents Usage Report, checked 10 November 2026. Agents usage report in the Microsoft 365 admin center, licensed and unlicensed users, usage per agent.
- Nudge Security, Discover and govern shadow AI agents, 24 March 2026. Research preview of SaaS-platform connectors for Copilot Studio, Agentforce, n8n and similar builders.
- C1.ai, Introducing shadow AI discovery, 27 July 2026. Endpoint scans of AI tool and MCP config files, plus cloud and identity connectors.
- AI agent governance, AI agent permissions, AI agent monitoring, AI agent kill switch, AI audit trail, MCP gateway, AI gateway, MCP authorization and AI agent cost.
- AI guardrails and AI observability.
- The Solarpunk build, the Skionis build and the insurance voice agent build.