You cannot secure agents you do not know about. An inventory is the list of every agent actually running, found from evidence rather than surveys.
This page covers where agents hide, the signals that give them away, and how the list becomes control through a registry and an AI agent allow list.
Inventory and registry are often used as synonyms. It helps to keep them apart.
What is actually running, found from evidence.
Owned by security. Updated by discovery.
What is allowed to run, with owners and rules.
Owned by governance. Updated by approvals.
Agents in the inventory but not the registry are your shadow agents.
Closing that gap is the whole job.
Each place catches a different kind of agent. Network logs find scripts and servers, SaaS settings find vendor agents, browsers find extensions.
Agents rarely announce themselves. They appear as traffic, grants, keys and settings spread across many systems.
No single source finds everything. Most teams need at least four of the seven to get close to the real number.
Start with the sources your team can query today. Add the rest over the following weeks as access is arranged.
Each signal on its own is weak. Two or three pointing at the same source are usually enough to call it an agent.
| Signal | Where you see it | What it suggests |
|---|---|---|
| Regular calls to model provider APIs | Egress proxy or firewall logs | Something is using a model, often on a schedule |
| Model API keys in code or secrets stores | Secrets scanning, vault audit | An agent or app built in-house |
| Agent framework packages in repositories | Dependency manifests | An agent under development or running |
| OAuth grants to AI apps | Identity provider, SaaS admin consoles | A third-party agent acting for a user |
| AI features switched on in SaaS tools | SaaS admin settings | Vendor agents inside products you already use |
| AI services enabled in cloud accounts | Cloud billing and configuration | Agents built on cloud platforms |
| Headless browser traffic from servers | Proxy logs, user-agent strings | Browser automation, often an agent |
| AI browser extensions | Endpoint management | Agents acting inside staff browsers |
| Service accounts with unusual request patterns | Directory and access logs | A script that decides its own steps |
| Traffic to AI tool domains | DNS and proxy logs | Staff or agents using AI services |
| New signups from company addresses | Mail logs, finance invoices | An agent creating accounts elsewhere |
| MCP server processes or configs | Endpoint and container inventories | Agents connected to tool servers |
Score each source by how many signals point at it, then investigate the highest scores first. For recognising AI tool domains in logs, our sibling AI Tools Blocklist classifies tens of thousands of AI services.
Ten fields are enough to triage. Everything else can wait until the agent is registered.
Keep the inventory lighter than the registry. Its job is to be complete, not detailed.
A stable ID, matched to a registry ID once registered.
Which source and signal revealed it.
Shows whether it is still active.
A best guess, to be confirmed.
Server, cloud account, SaaS tenant or browser.
Keys, tokens or grants it uses.
Whether it reaches the public web, and which page types.
What it calls to think.
Yes, no, or pending.
Registered, paused or retired.
Work from the widest net to the narrowest. Network logs catch the most agents for the least effort, so they come first.
Pull a month of egress logs. List every source that called a model API or used a headless browser.
Scan repositories and secrets stores for model keys and agent frameworks.
Export OAuth grants to AI apps and list AI features switched on in SaaS tools.
Review AI services in cloud accounts, AI browser extensions and MCP configs.
Merge duplicates, find owners, and compare against the registry.
Knowing an agent exists is step one. Knowing what it does on the web decides how urgent it is.
Only pricing, documentation and similar pages. Register and review.
Seen near signup, checkout or upload pages. Prioritise.
Traffic to sites nobody classified. Investigate first.
The third source has no known owner and already tried to upload and post. That is the agent to find today.
This view needs nothing new on the agent side. Your existing proxy logs plus page-type data are enough to produce it.
Speed depends on two things: whether anyone owns the agent, and whether it touches pages where it can act.
| Finding | Action | Within |
|---|---|---|
| No owner, touching action pages | Pause its egress, then find the owner | Same day |
| No owner, read-only | Find the owner, register or retire | One week |
| Known owner, not registered | Register with a web policy | Two weeks |
| Registered, activity outside its purpose | Reassess risk, tighten policy | Two weeks |
| Registered and behaving | Keep, review on schedule | Next review |
| Vendor agent switched on by one person | Decide at tenant level, record it | One month |
First inventories follow a familiar pattern. Knowing it in advance helps you plan the triage work.
A composite of common findings, not any specific company.
Team leads remember the agents they built on purpose.
Scheduled scripts, forgotten pilots and personal experiments on servers.
Vendor agents switched on per user or per team.
Nobody would claim them. They were paused, and nobody complained.
Each with an owner and a web policy.
A one-off inventory is out of date within weeks. Four routines keep it current with little effort.
New model API callers and headless browser sources go straight to triage.
New OAuth grants to AI apps are reviewed.
New agent frameworks in code trigger a registry reminder.
Unregistered agent identities cannot reach the web, so they surface themselves.
The last point changes the game. When unregistered agents are denied web access, owners come to you.
It also means the inventory stops depending on detective work. The proxy log of denied, unregistered agents becomes the list of agents still to register.
Each of these mistakes leaves agents out of the list, usually the riskiest ones.
Surveys find what people remember, not what runs.
One app can host several agents with different access.
They act for staff inside tools already approved.
The most urgent agents look the same as harmless ones.
The list is stale within weeks.
A list nobody triages changes nothing.
Security operations leads, but three other teams hold sources it needs.
| Task | Security operations | Identity team | AI platform team | Agent owners |
|---|---|---|---|---|
| Log sweeps | Does it | Informed | Informed | Informed |
| Grant exports | Reviews | Does it | Informed | Informed |
| Code and key scans | Reviews | Consulted | Does it | Informed |
| Owner confirmation | Asks | Consulted | Consulted | Confirms |
| Triage decisions | Decides | Consulted | Consulted | Consulted |
Five numbers, reported monthly, show whether the inventory is shrinking the shadow.
Total, and new this month.
Found but not registered.
The target is zero.
Found agents that touched signup, checkout or upload pages.
Days from discovery to decision.
An agent running without a registry entry or owner.
Records of traffic leaving your network.
Permission a user gives an app to act on their behalf.
A browser run by code with no visible window.
What a URL is on its site, such as pricing or signup.
Deciding quickly what to do with each finding.
Four objections come up in almost every first inventory. Each has a short, honest answer that keeps teams cooperating.
An inventory can feel like surveillance to the teams building agents. Clear answers keep them on side.
Thank you, and please do. Discovery exists for the ones nobody remembers, including old pilots.
Finding an agent does not stop it. Only agents with no owner that touch action pages get paused.
If it calls a model to decide what to do next, it acts like an agent and needs an owner.
Then it still belongs in the inventory, with the person who manages that vendor as owner.
Six sources, most of them already paid for and already running.
Most of the seven sources already exist in a typical security stack. The work is joining them, not buying new tools.
Show model API calls, headless browsers and page-level web activity.
Lists OAuth grants and service accounts.
Finds model keys and agent frameworks in repositories.
Lists browser extensions and local tool servers.
Shows which AI services are enabled in each account.
Turns raw URLs in logs into page types, so risky activity stands out.
A composite example of how triage works in practice, week by week.
A server nobody claims called a model API and tried to upload files to a paste site.
Action: egress paused the same day, owner found in a week, agent retired.
The analytics team runs a report agent that reads documentation and status pages only.
Action: registered with a read-only web policy within two weeks.
Switched on by one sales manager, it drafts emails and can browse.
Action: browsing disabled at tenant level, email drafting kept, entry recorded.
Three findings, three different answers. The deciding factors were ownership and web activity, not how clever the agent was.
Auditors care less about the number of agents than about whether the method would catch a new one.
Which sources were searched, and how often.
Evidence that inventory and registry were reconciled.
What happened to each unregistered agent, with dates.
Proof that unregistered agents cannot reach the web.
The honest fine print — the same two assumptions we publish, plus two operational ones
Tag every URL in your logs with its page type, on 40M+ domains.
