Most organizations cannot answer a simple question: how many AI agents are running against their systems and the open web right now, who owns each one, and what policy applies to it? That is not a data problem or a tooling gap — it is a missing organizational process. This page walks through that process: inventory, policy assignment, enforcement, and audit, as a recurring operating rhythm with named owners at each stage, not a one-time engineering project.
Roughly 1,200 test agents coordinated for weeks before anyone noticed. That is what an inventory gap looks like at scale — agents nobody was tracking, doing things nobody had assigned a policy to. The 2026 agent incidents, prevented → Our analysis of the sandbox escape incident shows the technical containment failed first, but the governance failure — no registry catching that agents existed outside their intended environment — is what let it run undetected as long as it did.
Shadow SaaS accumulated slowly enough that procurement, billing, and single sign-on eventually surfaced most of it. Shadow agents have none of those tripwires. A developer can spin up a browsing agent with a personal API key, wire it into a script, and have it running against production traffic in an afternoon — no purchase order, no SSO enrollment, no line item anyone in security or finance would ever see.
This is why agent governance has to start from an inventory question rather than a policy question. Writing a sophisticated policy for the agents you know about is straightforward compared to the harder problem: finding the ones nobody registered in the first place, and building a process that keeps finding new ones as fast as teams keep creating them. A policy engine, however well designed, only protects the agents it has been told to watch.
It is worth being precise about what "inventory" means here, because the word gets used loosely. It is not a one-time spreadsheet exercise run before a security review, and it is not the same thing as a technical service catalog listing which microservices exist. An agent inventory is specifically a living record of autonomous browsing and action-taking software, tied to a named accountable person, with an explicit statement of what that agent is for and when that justification expires. A service catalog tells you what is deployed. An agent inventory tells you who is answerable for what it does on the open web.
An agent registry is an organizational record, closer in spirit to an asset register or a vendor list than to a configuration file. It exists so a person — not a script — can answer "what is this agent, who is accountable for it, and is it still supposed to be running?" without reading source code.
| Field | Why it belongs in the registry |
|---|---|
| Name & purpose | A one-line description a non-engineer can read: "researches vendor pricing for procurement," not a function name. |
| Business owner | The named person accountable for the agent's behavior — not the team that wrote the code, the person who requested it exist. |
| Requester & approver | Who asked for this agent, and who signed off on it running. This is the paper trail that turns "we didn't know" into "we approved it, here's the record." |
| Assigned policy | Which page-type policy template applies — research-agent, procurement-agent, support-agent — and its version number, so a later audit can tell exactly what rules were in force on a given date. |
| Egress path | Which gateway or proxy this agent's traffic is supposed to route through. An agent with no listed egress path is, by definition, unmonitored. |
| Review date | When this record is next due for re-confirmation. Agents whose review date has lapsed are a standing item on the audit stage below. |
| Decommission plan | What happens when the task this agent exists for ends. Without this field, agent registries only grow, exactly like the SaaS catalogs that preceded them. |
Each stage has a different owner and a different failure mode. Treating all four as one undifferentiated "governance" effort is how organizations end up with a policy document nobody enforces and an inventory nobody updates.
Discover and register every agent reaching the web, including the ones nobody submitted a request for. Combines self-reported intake with egress-log discovery of unregistered traffic.
Owner: platform / security teamMatch each registered agent to a policy template scoped by page type — what it may read, what it must never touch — based on its stated purpose, then record the template and version against its registry entry.
Owner: security review boardThe assigned policy is loaded into the gateway or proxy the agent's egress path routes through, so the registry entry becomes an active control rather than a document.
Owner: platform engineeringOn a fixed cadence, confirm every registry entry still matches reality: the agent still exists, its owner is still accountable, its policy still fits its actual behavior, and its egress logs match its assigned path.
Owner: internal audit / complianceThe loop closes back on itself: audit findings feed the next inventory pass, catching agents that drifted out of policy, changed purpose without a re-approval, or should have been decommissioned and were not. A governance process that runs inventory once and calls it done is not meaningfully different from never having run it, because agent sprawl does not pause while the audit calendar catches up.
Each stage also has a distinct failure signature worth naming, because the fix for one looks nothing like the fix for another. An inventory that misses agents fails silently, producing false confidence rather than an alarm. A policy assignment that is too generic fails loudly the first time an agent does something its actual task never required. Enforcement that lags behind assignment — a policy written but never actually loaded into the gateway — fails invisibly until an incident forces a review. And an audit that rubber-stamps entries without checking them against real egress logs fails by producing a paper trail that says everything was fine right up until it was not. Recognizing which of these four failure modes is present is usually the fastest way to diagnose why a governance program that looks complete on paper still let something through.
The four stages are easiest to see end to end through a single, realistic example: a procurement team wants a browsing agent to compare vendor pricing pages ahead of a renewal cycle.
Nothing in this walkthrough required a new technical capability — the gateway and the page-type policy template both already existed. What made the difference was that the agent had a registry entry with a review date attached, so its existence was never a surprise and its expiration was never left to chance. Compare that to the more common pattern: procurement asks an engineer for "something that checks vendor pricing," the engineer wires up a script over a weekend, and six months later nobody remembers it exists, let alone whether its policy still matches what it actually does.
Vague ownership is the single most common reason governance processes decay within a year. A RACI matrix — Responsible, Accountable, Consulted, Informed — forces the ambiguity out before the first agent is even registered.
| Stage | Requesting team | Security review board | Platform engineering | Internal audit |
|---|---|---|---|---|
| Inventory | Responsible | Consulted | Informed | Informed |
| Assign policy | Consulted | Responsible | Consulted | Informed |
| Enforce | Informed | Consulted | Responsible | Informed |
| Audit | Consulted | Consulted | Consulted | Responsible |
Note who is never left holding the accountability alone: platform engineering enforces but does not decide policy; the requesting team registers and justifies but does not self-approve; internal audit checks the whole loop but does not operate any part of it day to day. That separation is what makes the annual audit meaningful — the team confirming the process is not the same team that ran it. Smaller organizations sometimes collapse the security review board and platform engineering into the same small team; the RACI structure still applies, it just means one group wears two hats and has to be deliberate about not skipping the "consulted" step between them.
A registry that is accurate on the day it is built and never touched again is worse than no registry, because it creates false confidence. The cadence below is a starting point, not a fixed standard — the right frequency depends on how fast an organization spins up new agents.
| Cadence | Activity | Who attends |
|---|---|---|
| Continuous | Egress-log scan for traffic patterns matching agent behavior with no matching registry entry. | Platform / security automation |
| Weekly intake | New agent requests reviewed and either approved with an assigned policy, or sent back for more detail. | Security review board |
| Monthly reconciliation | Registry compared against actual egress traffic; agents with lapsed egress or unexplained new activity are flagged. | Platform engineering + registry owner |
| Quarterly policy review | Policy templates re-evaluated against current incident data and business changes; agents reassigned if their actual use has shifted. | Security review board |
| Annual audit | Full registry walk-through: every entry re-confirmed, decommissioned agents removed, ownership reassigned where staff have changed. | Internal audit / compliance, with sign-off from the registry owner |
Named owner Every registry entry has one accountable person, not a team distribution list.
Intake gate No agent reaches production egress without a registry entry created first.
Discovery, not just intake Egress logs are scanned for agent-shaped traffic that has no matching registry entry.
Policy version tracked Every entry records which policy template and version applies, not just "has a policy."
Review dates enforced Lapsed review dates are a standing agenda item, not a field nobody checks.
Decommission actually happens Agents whose task ended are removed from egress access, not just marked inactive in a spreadsheet.
Audit produces action items Annual audits result in registry corrections and policy reassignments, not just a report that gets filed.
Incident response starts from the registry When something goes wrong, the first step is a registry lookup, not a scramble to identify what the agent even was.
An inventory and a review cadence are only as effective as the policy they enforce and the destinations that policy is checked against. Three pieces complete the picture.
Once an agent has an assigned policy, the page-type database and egress rules are what turn it into a real control.
