How do you find the AI agents already running in your organisation?
The same way you find shadow IT, but with lenses built for agents, and a register that keeps them found.
You find them the same way you find shadow IT, but with agent-specific lenses. The discovery sources are egress and DNS logs filtered for AI endpoints, SaaS admin consoles and OAuth grant reviews, expense and procurement records, browser extension audits, and structured staff attestation. What keeps them found is an agent register built on five questions per agent: what it is, what it may decide without a human, whose identity it acts under, what data it can reach, and where the record of its actions lives.
The question matters in 2026 because agents arrived faster than inventories. A copilot that drafts is one risk class; an agent that acts, sends, books, approves or commits is another, and most organisations acquired both through individual initiative rather than procurement. An inventory is the precondition for every other control: no one can set a mandate, revoke an identity or audit a record for an agent that has not been found.
Why do organisations have agents they do not know about?
Because agents rarely arrive as projects. They arrive as features switched on inside software already licensed, as browser extensions installed in minutes, as scripts a developer wired to a model endpoint to automate a chore, and as trials paid for on a corporate card below the procurement threshold. None of these passes through an architecture review, so none lands in an asset register. The result is an estate where the official AI programme is a minority of the AI actually running.
What counts as an agent for inventory purposes?
Anything that takes actions with software autonomy, not only things that answer questions. Four forms cover most estates: a purchased agent product, an in-house script or workflow calling model endpoints, a browser extension acting inside web sessions, and an embedded copilot inside a SaaS suite. The boundary case is a chatbot used purely for drafting; it belongs on the register too, at a lower risk tier, because one vendor update can change the tier.
What is the agent inventory test?
Five questions, asked of every agent found, with the answers recorded in a register.
- What is it: a product, a script, a browser extension or an embedded copilot, and which vendor or team maintains it.
- What mandate does it have: what it can do without a human approving, stated as a list of actions, not a job description.
- Whose identity does it act under: its own service identity, or a person's borrowed credentials.
- What data can it reach: the stores, mailboxes and systems its permissions actually open, not the ones the description mentions.
- Where is the record of what it did: a log the organisation controls, a vendor log it can query, or nothing.
An agent that fails question five is the priority, because whatever it has already done is unrecoverable.
Where do you actually look?
Six sources find most of the estate.
- Egress and DNS logs: resolve which internal systems are talking to known AI endpoints, and how often.
- SaaS admin consoles: review enabled AI features and third-party integrations tenant by tenant.
- OAuth grant reviews: list which applications hold delegated access to mail, files and calendars; agent products concentrate here.
- Expense and procurement data: search card statements for AI vendors, because trials hide below the procurement threshold.
- Browser extension audits: managed browsers can enumerate installed extensions; unmanaged ones cannot.
- Staff attestation: ask, in a structured amnesty rather than a hunt, because people disclose tools they are not punished for using.
Personal devices escape all of these, and honesty about that limit is worth more than pretending a control exists; enforcement on personal hardware is its own subject.
How do you keep agents found?
Treat the register as a living control, not a report. Give every agent a named owner, a mandate statement and a review date. Route new agents through a lightweight intake: registration in exchange for permission, measured in days not months, because a slow gate recreates the shadow estate it was built to remove. Re-run discovery on a cadence and reconcile it against the register; the difference between the two lists is the shadow agent population, and its trend is the metric that shows whether the control works.
What does architecture change about the inventory problem?
Discovery is only ever a snapshot; the estate changes the day after the sweep. On operator-owned infrastructure the inventory can instead be true by construction. On Mickai, a Sovereign Intelligence Operating System, agents run inside a zero-egress perimeter, act under hardware-attested identities bound to the audit chain, and have every action sealed to a post-quantum signed ledger. An agent cannot exist inside the boundary unregistered, because identity is issued rather than assumed, and its actions cannot go unrecorded, because sealing is not optional. The register stops describing what the organisation hopes is running and starts describing what the substrate proves is running.
“Discovery tells you what was running on the day you looked; architecture is what keeps the inventory true.”
The architecture that makes an agent estate enumerable by construction is set out at /sovereign-ai, and the film at /film shows the interface those agents run behind.
Frequently asked questions
How do I find out if my staff are using AI agents without approval?
Combine technical discovery with amnesty. Egress and DNS logs, OAuth grant reviews and browser extension audits reveal most corporate-network use, and a structured attestation exercise without punishment surfaces much of the rest. Organisations that lead with discipline get silence: the estate stays hidden and the risk stays unmanaged.
Should we block AI agents until we have an inventory?
Blanket blocking tends to push use onto personal devices, which no corporate control reaches. A better sequence is to discover first, register what is found, remove the few agents whose data access is indefensible, and provide a sanctioned route quickly, so the incentive to hide shrinks while the inventory is built.
What should an agent register actually record?
The five inventory answers per agent: form and owner, mandate, identity, data reach and record location, plus a risk tier and a review date. Kept that narrow it stays maintainable, and it directly supports the later controls: mandate enforcement, credential rotation and audit.
Do embedded copilots in software we already license count as agents?
Yes, and they are the most commonly missed class, because they arrive through a vendor update rather than a decision. A copilot embedded in an office or CRM suite can read broadly across tenant data and increasingly can act. Tenant admin consoles list these features, and the register should carry them like any other agent.
How often should agent discovery be repeated?
On a fixed cadence, quarterly for most organisations, and after any event that changes the estate: a major SaaS update, a merger, a new integration. The reconciliation between each sweep and the register is the point of the exercise; a widening gap means the intake route is too slow or too feared.