Building an Enterprise Agent Inventory

Overview

An inventory only earns its keep once it's built, and building one is less about tooling than about discipline: pulling signal from places that were never designed to report to a central system, in a way that survives contact with a live enterprise.

Agents don't live in one tidy directory. A data-analytics team stands one up inside a notebook platform. A marketing team authorizes a third-party agent through an OAuth grant nobody else sees. A platform team deploys one into a Kubernetes cluster as a service account. They span AI platforms, SaaS tools, automation systems, cloud environments, code repositories, and developer workstations, and most of them were never announced to anyone responsible for tracking such things.

Five steps turn that sprawl into something you can query, and then there's the harder problem: keeping all of it current once the first pass is done.

Step 1: Discovery

You cannot inventory what you cannot see, and no single signal is complete. The practical approach is to pull from several sources at once and treat each as a partial view rather than the final word.

• OAuth grants: authorizations issued to third-party agents through your identity provider, usually the fastest way to surface SaaS-embedded and external agents.
• API usage: traffic and key-usage patterns that indicate an automated, non-human caller hitting internal or partner endpoints.
• Service accounts: non-human identities in cloud and directory systems that an agent uses to act.
• SaaS integrations: connected apps inside platforms like your CRM, HRIS, or ticketing system.
• Network activity: egress to model providers or tool endpoints that hints at an agent running somewhere unexpected.
• Code repositories: agent frameworks, prompts, and tool definitions checked into source control.
• Cloud deployments: functions, containers, and jobs running agent workloads.
• Self-registration: a submission workflow where teams declare agents they're building or adopting.

Take a procurement team that authorizes a vendor-supplied agent to read purchase orders and draft supplier emails. To finance it looks like a helpful add-on. From a discovery standpoint it shows up as an OAuth grant against the procurement SaaS, an outbound integration to a mail API, and, if nobody asked, nothing in any official record. Three signals, one agent nobody logged. Discovery is connecting those dots before an incident does it for you.

Step 2: Normalization

Discovery produces a messy pile of signals from systems that all describe agents differently. Normalization collapses that into one consistent schema, so an agent found in a code repo and one found through an OAuth grant end up described the same way. Skip this and the inventory is just a list of links you can't query.

At minimum, every record should carry the same core fields:

{
  "name": "supplier-comms-assistant",
  "owner": "procurement-ops",
  "technical_owner": "platform-team",
  "purpose": "Draft supplier emails from open purchase orders",
  "connected_systems": ["coupa", "outlook-graph"],
  "permissions": ["po:read", "mail:send"],
  "credentials": ["svc-procure-agent"],
  "users": ["procurement-ops"],
  "lifecycle_state": "production",
  "risk_classification": "medium"
}

The exact shape matters less than the consistency. Once a recruiting-screener in the HRIS and a revenue-forecast job in the data warehouse map to the same fields, you can finally ask portfolio-level questions: which agents can send external email, which touch regulated data, which have no owner.

Step 3: Ownership

Ownership is the field people skip and regret skipping. Every agent needs a business owner, the person accountable for why it exists and whether it should keep existing. Many also need a technical owner who understands how it runs and can change or stop it.

Without ownership, basic questions have no answer. When a legal-intake agent starts mis-routing privileged documents, who reviews its access? When a marketing agent keeps emailing a suppressed segment, who pauses it? When the engineer who built a data-pipeline agent leaves, who inherits it? An ownerless agent doesn't get safer with time. It turns into an orphaned access path nobody is watching.

Step 4: Permissions at a Useful Level of Detail

The inventory should record permissions at a resolution that's actually useful for risk decisions. Noting that an agent is connected to the CRM or connected to the data lake isn't enough. Connection is binary. Risk lives in the verbs.

• read and export: can it pull data out of the system, or remove it entirely?
• create, update, and delete: can it change records?
• send and share: can it reach the outside world or other people?
• approve: can it complete an action that normally requires a human's sign-off?

A sales-ops agent with read on the CRM is a reporting convenience. The same agent with export and send can quietly walk a customer list out the door. An IT-operations agent with read on cloud config is harmless; the same agent with delete can take down production. Capturing the verbs is what lets you tell the two apart without inspecting every agent by hand.

Step 5: Lifecycle State

Lifecycle state is the field that stops a prototype from silently becoming a production system. Tag every agent with where it sits:

• experimental: early exploration, not connected to anything sensitive.
• pilot: running with a limited scope and audience.
• approved: reviewed and cleared, but not yet broadly live.
• production: operating with real access and real consequences.
• deprecated: on its way out, scheduled for removal.
• decommissioned: retired, credentials revoked, access removed.

The common failure is a quiet promotion that never happened on paper. A finance team builds an experimental agent to reconcile a handful of invoices. It works. Six months later it's reconciling thousands a day with write access to the ledger, still tagged experimental, never reviewed. Lifecycle state, kept honest, forces that promotion to be a decision instead of an accident.

Figure 1 — The five build steps, feeding back into discovery as agents drift, change owners, and gain access.

Keeping It Live at Scale

A handful of agents, one person can hold in their head. That stops being true somewhere past a few dozen, and the failure mode changes with it. Below that line, an inventory that's a little stale is an inconvenience. Above it, a stale inventory is actively dangerous, because people start trusting it, and it's wrong.

Volume also breaks the naive version of every step above. Discovery signals start colliding: the same agent shows up under three names because three teams registered it separately, and somebody has to reconcile them. Normalization schemas that were fine for fifty agents get inconsistent at five hundred, once enough people are filling them in by hand. Review cadences that worked for a curated pilot group turn into a backlog nobody clears.

The fix is the same two forces, applied continuously instead of once:

• Automated signals continuously rediscover agents and flag drift: a new OAuth scope, a service account that gained a permission, an agent that stopped reporting. Automation is what finds things at a volume no human review process can keep up with.
• Human review supplies the context automation can't infer: why an agent exists, whether a new permission was intended, and whether it should still be allowed to operate.

Automation without review produces a haystack of unexplained findings nobody triages. Review without automation produces a confident-looking document that quietly rots. We think the combination is the only version that survives past a hundred agents.

In Practice

Most teams don't need to perfect all five steps before getting value. A pragmatic sequence works better than a big-bang rollout.

Start with the highest-signal source. For many enterprises that's OAuth grants in the identity provider: it surfaces third-party and SaaS-embedded agents fast, with little instrumentation. Normalize early, even if the schema is thin, because a small consistent record beats a rich inconsistent one. You can add fields later. You cannot retrofit consistency cheaply once five teams have filled in a form five different ways.

Backfill ownership before permissions. An owner can describe an agent's permissions later; a permission map on its own can't tell you who to call. And set lifecycle state at discovery time, tagging every newly found agent immediately, even if the tag is just "unreviewed." Untagged agents are the ones that drift.

The first pass will be uncomfortable. Expect agents nobody remembers authorizing, agents with permissions far broader than their stated purpose, and agents whose owner left two reorgs ago. We'd treat that discomfort as the inventory doing its job. It's the difference between assuming you're governed and being able to show it.

Conclusion

None of the five steps above is hard on its own: discovery is plumbing, normalization is a schema, ownership is a name in a field. What's hard is doing all five at once, and keeping the record honest after nobody's looking at it anymore.

Everything downstream depends on getting this right. Authorization needs to know what an agent should be allowed to do, monitoring needs to know what normal looks like, and audit trails need to know which agent acted and on whose behalf — none of it is possible without a current record underneath.