Agent Governance & Inventory

Most organizations cannot produce a list of the AI agents running inside them. Industry research puts the share that maintain a current and complete AI inventory at 18% (IBM Institute for Business Value, reported at Think 2026, May 2026), while 94% report concern that AI sprawl is increasing complexity, technical debt and security risk and only 12% have implemented a centralized platform to manage it — both figures from the same survey of approximately 1,900 global IT leaders (OutSystems, 2026 State of AI Development, April 2026).

That distance is the problem this page describes. It is an organizational gap rather than a technical one: registers, ownership records and audit logs are long-established technology. What is usually missing is the decision that agents belong to the organization rather than to whoever created them.

What agent sprawl is

Agent sprawl is the accumulation of agents with no central record of what exists, who owns each one, what it may do, and what it has done. Agents get created by individuals — in personal accounts, with personal keys, on personal machines — and each works in isolation. The failure is collective: nobody can produce the list, and you cannot govern, secure, audit or shut down what you cannot enumerate.

The three properties that close it

1. One inventory for the organization

In agent.ceo, an agent is not a script on someone's laptop. It is created inside an organization, which is the unit of ownership and the isolation boundary. Every agent in that organization appears in one place, with its role, its state and its history.

Because the register is the runtime — agents run as organizational objects rather than being catalogued after the fact — it cannot silently drift out of date the way a manually maintained inventory does. That is the mechanism behind the 18% figure above: hand-kept inventories do not survive growth.

2. Declared ownership and authority per agent

Every agent operates within a role that defines its responsibilities, its available tools, its operational boundaries and its position in the reporting hierarchy. Roles are declarative: an agent's authority is a stated property, not an emergent consequence of which credentials it happened to be given.

Access is enforced through role-based access control, and credentials are held in per-organization encrypted vaults rather than in an individual's environment. The practical consequence is continuity: when a person leaves, the agents they created remain organizational assets with an owner who can be reassigned. A departing agent-owner otherwise takes the capability with them — a sharper loss than a departing employee, whose work at least stayed behind and could be read.

3. Every action attributable to an owner

Audit logging records security-relevant operations to an append-only, tamper-resistant trail. Actions are attributable to a role acting under declared authority, which is the form an auditor's question actually takes: not what happened, but who authorized this.

This has to be in place beforehand. Without agent identity and boundaries at the time of the action, events were never recorded as actions with an actor — there is no partial trail to enrich later, because the attribution was never captured. Evidence is either produced at the time or it does not exist.

How the pieces fit

graph TD
    ORG[Organization<br/>ownership + isolation boundary]
    ORG --> INV[Agent inventory<br/>every agent, one place]
    INV --> ROLE[Role<br/>responsibilities · tools · boundaries · hierarchy]
    ROLE --> RBAC[RBAC + per-org credential vault<br/>what this agent may touch]
    RBAC --> ACT[Agent action]
    ACT --> AUDIT[Append-only audit trail<br/>attributed to role + owner]
    AUDIT --> Q[Answers: who authorized this?]

    style Q fill:#e8f5e9

Isolation between domains

An organization is rarely one undifferentiated unit. Engineering, security, marketing and data are separate concerns with different authority, and they generally need to stay separate.

agent.ceo treats each domain as its own organization, so cross-domain interaction is explicit and audited rather than ambient. A system that lets any agent read anything has not removed overhead — it has concentrated risk.

Isolation is logical, implemented through namespaces and role-based access control, not physical separation of hardware. The distinction matters to an auditor and is stated plainly here for that reason. Our full published security posture, including the certifications we do not hold, is at agent.ceo/security.

Verifying the role structure without an account

The deployed roles are published over an open protocol and can be inspected directly:

https://api.agent.ceo/.well-known/agent.json

This returns the deployed agent roles with their declared skills. Requesting a role that does not exist returns a 404 — the endpoint reports what exists and nothing more.

What this does not do

Worth stating so the boundary is clear:

• It does not reduce the number of agents you run. It is what makes adding more of them safe. If you have two people and three agents, a human organization genuinely wins and this structure would be overhead.
• It does not govern agents that run entirely outside it. An agent on someone's laptop, on their personal key, is outside any register — including this one. Governance follows adoption; it cannot be applied retroactively to what was never enrolled.
• It is not a compliance certification. It produces the evidence an assessment asks for. It does not substitute for one, and we do not hold ISO 27001 or SOC 2.

Related

• Organizations — the ownership and isolation boundary
• Agents — agent architecture, roles, lifecycle and communication
• Organizational Intelligence
• RBAC — how access is enforced
• agent.ceo/security — full published security posture

Further reading

• Agent Sprawl: The Gap Between 94% Concerned and 12% Prepared — the four market figures with primary sources
• Agentic AI Governance: Why Your AI Agents Need a Control Plane, Not Just Guardrails
• Zero Trust for AI Agents

Market figures on this page are quoted from their primary publishers (OutSystems, IBM Institute for Business Value) and were verified against those sources on 30 July 2026.