Learn why AI agent inventory is the foundation of enterprise AI governance in 2026. Discover shadow agents, orphaned agents, and effective authority across every platform.
Security teams ask the right follow-up questions about AI agents: Which ones are over-permissioned? Which ones accessed sensitive data last week? Which ones are running with a disabled creator account? Every one of those questions assumes a prior answer: which agents exist at all.
AI agents are non-human identities (NHIs). They hold OAuth tokens, embedded credentials, and service account access. In modern enterprises, NHIs already outnumber human identities by 25 to 50 times, and every new agent deployment widens that gap. Agents also move data at roughly 16 times the rate of human users. The blast radius of a single misconfigured or untracked agent is not a theoretical concern. It is a measurable quantity tied directly to what that agent can actually access.
Emerging governance and compliance expectations increasingly treat agent inventory as a foundational requirement. You cannot classify risk, document controls, or demonstrate accountability for agents you have not cataloged. AI governance has become a board-level concern precisely because regulators are starting to ask the same question security teams cannot yet answer: what AI systems are you running, and what can they do?
Inventory is not a nice-to-have feature. It is the control plane prerequisite. Without it, every downstream security action is built on assumption.
Most teams start with a spreadsheet. One person owns it, it covers the agents they know about, and it goes stale within weeks. That is not an inventory. That is a list.
A complete AI agent inventory captures six dimensions for every agent in the environment:
DimensionWhat It AnswersIdentityWho created this agent? Who owns it? Is that account still active?PurposeWhat business function does this agent serve?ConnectionsWhich SaaS applications, data sources, and tools does it connect to?PermissionsWhat OAuth scopes and credentials does it hold? What is its effective authority?AccessibilityIs it org-wide? Publicly accessible? Restricted to specific users?StatusIs it active? Orphaned? Unsanctioned? When did it last execute?
Note that this article focuses on cataloging the agents themselves. The MCP servers those agents connect to represent a companion inventory challenge: which MCP servers are sanctioned, which are shadow infrastructure, and what tools do they expose at runtime. That is a distinct governance problem addressed in MCP server inventory.
The distinction matters because an agent can look clean in isolation while connecting to a shadow MCP server that exposes tools far beyond its intended scope. Effective AI agent security requires both inventories to be maintained in parallel.
Two agent categories create the most acute visibility gap, and both are invisible to native platform tools.
Shadow agents are agents deployed without IT or security oversight. Business users build them in Copilot Studio, n8n, or Salesforce Agentforce using low-code interfaces that require no central approval. The agent is live, connected to production data, and executing workflows before security knows it exists. Across enterprise customers, patterns consistently show agents numbered in the hundreds to thousands before any inventory process was in place.
Orphaned agents are agents whose creator account has been disabled. The human left the organization, the account was deprovisioned, but the agent continues running. It still holds the credentials it inherited from its creator. It still executes on schedule or on demand. And because the creator's account is gone, no one has a clear ownership path for reviewing or retiring it.
Both categories represent machine insider risk: agents that hold credentials and access data like insiders, but sit entirely outside any insider risk program. Native platform logs do not surface these agents in a unified view. They require correlation across identity provider data, platform configurations, and runtime activity to identify reliably.
The AI agent security risks associated with orphaned and shadow agents compound quickly. An orphaned agent with org-wide accessibility and maker mode credentials is not a medium-severity finding. It is a toxic combination: multiple risk factors stacking on a single agent to produce a critical-priority exposure.
The core problem with every native platform inventory tool: they show theoretical configuration. They show what an agent is set up to do on paper. They do not show what it can actually execute inside each SaaS application it connects to.
The gap between those two things is where real risk lives.
Consider maker mode. In many agentic platforms, an agent is built using the creator's credentials. Any user who invokes that agent, regardless of their own permission level, accesses data at the creator's privilege level. A user without Salesforce access can invoke a Copilot Studio agent built by a Salesforce administrator. That user now has effective authority over CRM data they were never provisioned to see. The agent did exactly what it was configured to do. Your IAM controls were bypassed without a single policy violation being logged.
Theoretical configuration shows: "this agent connects to Salesforce." Effective authority shows: "this agent connects to Salesforce using admin credentials, and any user in the organization can invoke it." Those are not the same statement. Only the second one tells you the actual blast radius.
This is why monitoring approaches that rely solely on configuration data leave security teams ghost chasing. They can tell you what could be exploited. They cannot tell you what was accessed, by whom, and whether the invoker had any right to that data. Runtime truth requires correlating agent configuration with actual SaaS entitlements, identity context, and live activity into a single authority map.
The inventory problem is not just about depth. It is about breadth. Agents do not stay on one platform.
A workflow might originate in n8n, trigger an action in Salesforce Agentforce, pull context from Amazon Bedrock, and write output to a Google Vertex AI-connected data store. Each platform has its own native logging. None of them shows the cross-platform chain. Security teams managing each platform separately see fragments. They do not see the full action chain, and they cannot assess the cumulative blast radius of a multi-platform agent sequence.
A single pane of glass across all platforms is not a convenience feature. It is the architectural requirement for governing agents that cross platform boundaries. That view needs to cover, at minimum:
The inventory layer feeds every downstream security action. Risk scoring, access reviews, toxic combination detection, and audit reporting all require this foundation. Major agent platforms are beginning to introduce agent inventory as a first-class governance object, with explicit fields for purpose, capabilities, scopes, and guardrails. The industry is converging on the same conclusion: agents need a system of record, not just a log.
Inventory answers the question: what exists? Governance answers the question: what should be allowed to exist, and under what conditions?
The path from inventory to governance runs through AI agent risk management. Once every agent is cataloged with its effective authority, the next step is identifying which agents carry risk factors that require immediate remediation and which combinations of factors create critical-priority exposures.
A single risk factor (org-wide accessible agent, maker mode connector, disabled creator account) may be a medium-severity finding on its own. Two or three of those factors on the same agent create a toxic combination: a shadow agent with org-wide access and maker mode admin credentials is not a medium finding. It is the highest-priority item in the queue.
Deterministic guardrails for probabilistic agents are the enforcement layer that follows inventory. Probabilistic agents deviate from intended behavior by design. They do not check the invoker's permissions against the platform. They execute what they are asked to execute, within the scope of their effective authority. Deterministic guardrails cut off action options before damage occurs. But guardrails require knowing which agents exist, what they can do, and what rules should apply to them. That is exactly what the inventory provides.
It is worth noting that enforcement guardrails are on the near-term roadmap: Copilot is targeted for Q1 2026, with other supported platforms targeting Q2 2026. Inventory and effective-authority mapping are the present foundation; enforcement is the next layer built on top. The AI agent risk assessment process starts with inventory. It cannot start anywhere else.
An AI agent inventory is a centralized catalog of every AI agent operating in an enterprise environment. It captures each agent's identity, purpose, connections, permissions, accessibility, and operational status. It matters for security because agents hold credentials, access sensitive data, and take autonomous actions. Without knowing what agents exist, no access review, risk scoring, or compliance audit is possible.
An AI agent inventory catalogs the agents themselves: who built them, what they connect to, what permissions they hold, and whether they are active or orphaned. An MCP server inventory catalogs the MCP servers those agents connect to: which servers are sanctioned, which are shadow infrastructure, and what tools they expose. Both inventories are necessary. This article addresses the agent layer. MCP server inventory is a companion governance challenge addressed in detail at [MCP Server Inventory](/blog/mcp-server-inventory).
Shadow agents are AI agents deployed without IT or security oversight. Business users build them using low-code platforms like Copilot Studio, Salesforce Agentforce, or n8n. Because these platforms require no central approval to create and publish an agent, shadow agents accumulate quickly. One enterprise discovered hundreds of Copilot agents it had no record of, identified only through a dedicated assessment.
An orphaned agent is an agent whose creator account has been disabled, typically because the employee left the organization. The agent continues running with the credentials it inherited from its creator. Because the creator's account is gone, ownership is unclear and the agent sits outside any active review or remediation process.
Native platform tools show configuration data for agents within their own platform. They do not correlate across platforms, they do not surface the gap between theoretical configuration and effective authority inside connected SaaS applications, and they do not flag orphaned agents or shadow agents that were never registered in a central system. Cross-platform agent chains are entirely invisible to single-platform native tools.
Theoretical configuration is what an agent is set up to do on paper: which connectors it has, which permissions are listed in its configuration. Effective authority is what the agent can actually execute inside each SaaS application after all entitlements resolve. Maker mode is the clearest example: an agent configured with admin credentials gives any invoker admin-level access, regardless of the invoker's own permission level. Theoretical configuration does not show that. Effective authority does.