How Many AI Agents Do You Have?

Every conversation about AI agent governance begins with the exact same request: show me all our agents. Two questions immediately follow: what can they access, and what have they been doing?

At Oleria, we see executives struggle with the first question constantly. It sounds simple, but traditional identity tools consistently fail here. Ask three different security tools how many agents you run and you will get three conflicting numbers. Legacy systems over-count by treating every service account or version as a separate agent, and they under-count because many agents operate entirely without an identity of their own.

This isn't a UI bug; it's a fundamental data-model flaw. Solving it requires resolving every agent into a single unified subject, detecting invisible agents that lack traditional credentials, and correctly positioning each agent within the access graph. Get the underlying data model right, and every downstream capability, from automated access reviews to blast-radius analysis, delivers accurate results.

The mistake: equating an agent with its identity

The natural move is to treat an AI agent as one more identity type. Add "AI agent" next to service account, API key and user, and the inventory, the access graph and the reviews all work unchanged.

It looks elegant, and it breaks on contact with real platforms. A service account and a user are principals: they hold permissions and show up in audit logs. An API key is a secret. An agent is a third kind of thing. It acts, but it acts through identities it holds: sometimes one, sometimes two, sometimes none, sometimes one it shares with thirty other agents.

The moment the model says "agent equals identity," it has assumed a one-to-one ratio that almost no platform actually has.

Every platform has three layers

Read the platforms closely and the design question stops being a matter of taste. Each one separates, or deliberately fuses, the same three things: a catalog layer where agents are inventoried, a principal layer that holds permissions and shows up in audit logs, and a runtime layer where the agent actually executes.

Google Cloud is the one platform that writes this down. Its Agent Registry documentation names all three: a registry identifier that stays stable for discovery, an agent principal that holds permissions and appears in audit logs, and a runtime reference for where the agent runs. Microsoft Entra makes the agent identity itself a service principal, so catalog and principal are one object. AWS AgentCore creates a workload identity automatically beside the IAM execution role, so one agent gets two. Everyone fuses a different pair, hides a layer, or splits one in two.

One object per layer is the only shape that fits every row in the figure: the catalog layer is the agent, the principal layer is the account it holds, and the runtime layer is the resource it runs on.

Four shapes, each normal somewhere

The ratio between an agent and the identity it authenticates as is not constant. Across today's major platforms, this relationship takes different forms, from a straightforward 1:1 mapping to complex configurations where multiple agents share a single identity or operate without a dedicated identity at all.

‍

While traditional identity models only account for the standard one-to-one mapping, real-world deployments frequently use multi-identity, shared, or uncredentialed configurations. Failing to model these varied relationships leads to inaccurate agent counts and governance blind spots.

Resolution: one agent, one row

Resolution means collapsing everything a platform emits about an agent into a single subject. Count that subject, and you get the number a customer is actually asking for.

In practice that means three things:

• Collapse the platform's internal records. On AWS, one agent can appear as a harness, a runtime, several endpoints and several versions. That's one agent, not a dozen.
• Don't count the identities as agents. Microsoft Entra, for example, can give an agent identity its own agent user account, for agents that need to work where a user is required, such as a mailbox. That account is something the agent holds. It is not a second agent.
• Keep versions as snapshots of the agent, not new agents. Certification decisions point at a version, and drift is measured between the certified version and the one production is actually using.

No filters and no guesswork: if the model is right, the number of agents is simply the number of agent records.

Detection: the agents an identity query can't see

The most dangerous agents are the invisible ones: those operating without a dedicated identity. Because legacy queries inspect principal directories, these agents return zero results, completely evading governance radar.

They are not edge cases. They include:

• Agents that run on whatever API key or app account starts them 
• Registry entries for agents hosted on another platform
• Coding assistants running on developer laptops as the developer's own account

Detecting them means the model must allow an agent row to exist without a principal. Missing facts are normal here, not a data-quality problem. A good model records which facts a source could supply, so a reviewer knows the difference between "this agent has no access" and "this platform doesn't tell us."

Placement: where the agent sits in the graph

An agent is not an account. It holds accounts, the same way an employee holds several accounts across systems. That one decision is the unlock. It keeps the rest of the model small: an agent's effective access is computed exactly the way a person's already is, by walking to the accounts it holds and then to what those accounts can reach.

Around each agent sit four questions: which accounts it runs as, which credentials prove it, whose access it can borrow, and what its configuration says it needs. No agent platform answers all four. The agent is listed anyway, and its record shows which answers its platform could give.

‍

‍

Two rules keep the graph honest. First, grants never attach to the agent itself. They land on the accounts it holds and on the endpoint people and other agents call it through, which is where every platform actually checks who may use it. Second, a requirement is not a grant. Keeping what an agent is configured to need on its own edge makes two findings computable at a glance: required but not granted, and the riskier one, granted but not required.

Take a ticket-triage agent that a support team deploys on AWS. People and applications call it through its AgentCore endpoint, and AgentCore checks each caller there. Once a request is allowed, the agent works as its IAM execution role, so it can reach whatever that role can reach: the ticketing system, a bucket of customer data, and possibly more than anyone intended. The endpoint isn’t the only way to that access. If five other agents run as the same role, each of them can reach everything the triage agent can, and an action taken through the role can’t be pinned on any one of them. Anyone the role’s trust policy allows to assume it can use the same access directly, without going near the agent.

The industry is converging on this shape

Three signals, from three directions, point the same way.

• Directories model agents as a kind of identity, because a directory's job is to authenticate them. Entra's agent identity is a service principal subtype, created from a blueprint that can stamp out many of them.
• Governance products now keep an agent inventory of their own, with its own lifecycle, and point at an agent's identities rather than treating the agent as one of them. Not all do: some still classify each agent as one more non-human identity.
• Standards work is heading the same way. Several Internet-Drafts propose Agent as a SCIM resource type of its own, with its own owners, rather than a kind of User, and the SCIM working group's IETF 125 discussion raised the open question of whether one public agent identity should map to many short-lived private workload identities.

That question is the core challenge: one agent, many identities. A viable governance model must start from the agent itself.

Questions to ask any agent governance tool

The data model decides the answers long before the dashboard does. Five questions show quickly whether a tool got it right:

1. When one agent has two identities, does it count as one agent or two?
2. When thirty agents share one service account, can you tell them apart, and see that they share it?
3. Does an agent with no identity of its own appear in the inventory at all?
4. Can you see what an agent is configured to need next to what it is actually granted, and the gap between them?
5. Can you certify a specific version of an agent, and see when production drifts from it?

AI agents are deploying rapidly across every enterprise platform. Retrofitting them into yesterday's identity models creates severe blind spots. Security leaders need a purpose-built approach: resolve every agent to a single subject, discover invisible agents, and evaluate access with precision. That is the core architecture behind Oleria's agent governance, and we look forward to unveiling it at our Governance launch in December 2026.

Sources

Google Cloud Agent Registry: key concepts, Microsoft Graph: agentIdentity resource, Microsoft Entra Agent ID: agent identities, Amazon Bedrock AgentCore: understanding workload identities, Anthropic Claude Managed Agents overview, IETF draft-wzdk-scim-agent-resource, IETF 125 SCIM agentic schema progress