In McKinsey’s 2026 global AI survey, 40% of respondents from organizations with more than $1 billion in annual revenue reported scaling AI agents, up from 27% in the previous survey. As deployments expand, security teams need to know which agents can act, which identities they use, and who is accountable for their access. McKinsey’s State of AI research makes that operational question increasingly relevant.
An AI agent inventory is a maintained record of AI agents and their deployments, including their purpose, owners, identities, tools, data access, approval status, and lifecycle. A useful inventory connects what an organization has approved with what its systems are configured to permit and what agents are observed doing.
That connection helps teams find unowned deployments, review excessive access, investigate unexpected actions, and retire agents without leaving credentials or scheduled tasks behind. These are practical starting points for securing the AI frontier, where oversight depends on identifying agents, their owners, and the identities through which they act.
Sources checked on 28 October 2026. This guide draws on public research and security guidance. The inventory design, example, and implementation checklist are proposed guidance, not results from a tested customer deployment.
An AI agent inventory answers a practical set of questions: What agents exist within the defined environment, where do they run, what can they access, and who can change or stop them? Its scope should include approved agents and unresolved discoveries, with a clear distinction between those states.
NIST’s AI Risk Management Framework Playbook, GOVERN 1.6, recommends mechanisms for inventorying AI systems and assigning responsibility for maintaining those records. An agent inventory applies that governance foundation to systems that can use tools and perform actions.
For this inventory, treat an AI agent as software that uses an AI model to select or carry out steps toward a goal, potentially invoking tools, accessing data, or delegating work. Record the degree of autonomy because a system that drafts a response and a system that sends it have different operational consequences.
Include custom applications, agents embedded in software as a service (SaaS), local coding assistants with tool access, and externally operated agents authorized to interact with enterprise resources. Distinguish these from endpoint monitoring agents and conventional automation that does not use AI to determine actions.
A model endpoint, tool, or connector is a related asset. It does not automatically become a separate AI agent. If an agent uses a frontier AI model, record that model dependency separately from the deployment’s tools, credentials, and data access. Model capability alone does not describe what the deployed agent can do. For the broader protection requirements, see AI agent security.
Several existing systems can contribute to an inventory. Their labels vary by product, so define the functions your organization needs:
These functions can share one platform or remain connected through identifiers. The requirement is a reliable relationship between records, with an accountable source for each field.
One agent design can run in several environments with different permissions. Counting only its name conceals those differences, while counting every execution as a new agent exaggerates the estate.
McKinsey’s reported increase concerns scaling agents in one or more business functions among respondents from large, revenue-defined organizations. The survey collected 1,719 responses across 97 nations between May and June 2026. It measures reported adoption, not agent counts or inventory completeness. The practical implication is to prepare for agents being deployed across functions with different access requirements.
Use three connected levels in the inventory:
For example, a support agent in a test environment might read synthetic tickets. Its production deployment might read customer records and update cases. The shared agent name does not make their permissions equivalent. Deployment records also need a connection to observed activity.
Record short-lived workers and subagents through their parent deployment and execution identifiers. Create separate deployment records when they acquire distinct credentials, ownership, or persistent access boundaries. This is a proposed counting convention; document it so different teams report comparable numbers.
Frontier AI: Built Without Brakes
Discover how autonomous agents can cross intended boundaries—and the practical steps security teams can take to identify agents, monitor their activity, and contain unexpected behavior.
Each deployment record should contain enough information to identify the agent, assess its authority, find supporting evidence, and reach an accountable person. The following template is a practical starting point; adapt it to your environment and risk decisions.
Keep credential references, issuers, scopes, and expiry details in the inventory. Store secret values in an appropriate secrets-management system. Copying tokens into an inventory creates another place from which they can be exposed.
Separate data the owner declares from data a collector observes. A business purpose is usually an owner assertion; a cloud role assignment is configuration evidence; a successful API event is activity evidence. Each answers a different question.
Also distinguish last activity, last successful collection, and last review. An agent can be dormant while its inventory record is current, or active while the collector feeding its record has failed.
Discovery requires several sources because agents can be embedded in hosted applications, custom services, and local development tools. Begin with a declared coverage boundary, then record which environments and deployment types each source can actually observe.
Collect available agent definitions from approved AI platforms, cloud accounts, SaaS administration interfaces, application catalogs, and deployment pipelines. Examine repositories and deployment manifests for registered agent services and their dependencies.
For local agents, use authorized endpoint software and configuration inventories. An installed package indicates potential capability; it does not prove that a configured agent is running or has enterprise access.
Capture tenant and environment identifiers alongside platform IDs. The same display name can appear in multiple places. Review collector permissions, supported object types, pagination, and refresh intervals before treating an export as complete.
Inspect unfamiliar tools and configurations through approved read-only methods. Discovery should not execute an unknown agent or invoke a tool with side effects merely to identify it.
Map agents to service accounts, application identities, workload identities, and delegated user access. Check who granted access, the resources involved, and whether multiple agents share a principal.
Preserve the chain from initiating user or service to agent deployment, connector, and downstream system. An agent may act through several identities during one task. Shared credentials can make attribution ambiguous, which should remain visible in the record.
Model Context Protocol, or MCP, connects applications to tools and resources. Its security guidance explains how token passthrough and missing audience validation can undermine trust boundaries and accountability. Inventorying a connector therefore requires more than its address: record its authentication relationship and downstream authority.
Non-human identity security provides useful context for managing the service and workload identities involved.
Compare registered deployments with available application logs, tool-call records, identity events, cloud audit logs, endpoint activity, and network metadata. Investigate activity that cannot be mapped to an accountable deployment.
Treat traffic to an AI service as a discovery lead. It could come from a person, a conventional application, or an agent. Likewise, a generic service-account API call does not prove that an AI system initiated it.
Mark unresolved findings as candidates until corroborating evidence establishes what they are. Confirmed agents outside the required approval process may be part of shadow AI. A missing inventory match alone could also reflect collection lag, a renamed deployment, or incomplete attribution.
Network observations can help identify destinations and communication patterns, but encrypted traffic and shared infrastructure limit what they reveal about individual agent actions.
Ask procurement and application owners about agent capabilities enabled inside existing subscriptions, managed services, and externally hosted workflows. Such capabilities may not appear as new software purchases.
For third-party agents, request the operational facts needed for your use case: accountable contacts, connected enterprise resources, permission boundaries, available logs, change notifications, and suspension procedures. Record information that the provider cannot supply as a gap.
Owner attestations help explain purpose and approval. Corroborate technical claims where possible, especially when they determine whether an agent may perform a high-impact action.
Reconciliation turns a collection of records into a usable inventory. Compare what was approved, what access was granted, and what activity was observed, while preserving the evidence and uncertainty behind each finding.
These three views must remain separate. A role assignment may be broader than the approved purpose. An unused permission is still granted authority. An attempted API call may have failed and should not be recorded as a completed action.
A practical reconciliation process is to normalize identifiers, associate evidence with deployments, compare the three views, and route discrepancies to the responsible owner. Use platform IDs and verified identity mappings where available. Display names alone are weak matching keys.
Do not silently overwrite conflicting evidence with whichever source arrived last. Define field-level authority, retain relevant history, and make unresolved conflicts searchable.
Evidence quality also matters. OWASP’s guidance on third-party execution evidence distinguishes supplier assertions from independently checkable observations. A signed record can identify who supplied a claim without proving that all reported actions occurred or that no events were omitted.
For inventory purposes, record what each observation establishes and what it cannot establish. A missing event from an unavailable collector is missing evidence, not evidence of safe behavior.
Review priority should reflect the consequences of an agent’s reachable actions and the quality of its controls. A familiar model or approved platform does not determine the risk of every deployment built on it.
Use the following questions to establish a reasoned priority:
OWASP’s AI Agent Security Cheat Sheet recommends least privilege, oversight for high-impact actions, and security monitoring. Translate those principles into inventory fields that can be reviewed and tested.
An unowned agent with production write access warrants urgent review. A documented read-only agent using public information may warrant a lighter review. These are suggested prioritization examples, not universal risk classifications.
Assess effective permissions where the platform supports it. Assigned roles, resource policies, conditional restrictions, and downstream connector permissions can interact. When that interaction is unresolved, label effective access as unverified rather than equating a role name with a proven capability.
An inventory remains useful when updates are part of deployment and access-management workflows. Combine event-driven updates with scheduled reconciliation and owner review, using a frequency appropriate to the environment’s change rate and risk.
Give each deployment a named business sponsor and technical owner. The sponsor confirms purpose and acceptable use; the technical owner maintains deployment facts and integrations. Identity and access management (IAM) teams validate access, security operations investigates concerning activity, and governance teams coordinate approvals and exceptions.
Assign a separate owner for the inventory service itself. That person or team maintains the record schema, collector health, reconciliation rules, access controls, and escalation process.
Trigger review when an agent receives a new tool, identity, permission, data source, external destination, autonomy setting, or significant configuration change. Ownership transfers and expired exceptions also require action.
Track the changed configuration and its effective time. Otherwise, an investigator may compare yesterday’s actions with today’s permissions and reach the wrong conclusion.
Retirement should remove the ability to act while preserving necessary evidence. Disable relevant triggers and schedules, revoke agent-specific access, remove obsolete integrations, and verify the outcome. Check shared dependencies before changing credentials used by other workloads.
Retain a retired record with the decision, time, responsible owner, and verification evidence. Apply the organization’s retention requirements to logs, memory stores, configuration, and relevant business records. NIST’s GOVERN 1.7 guidance treats decommissioning as a managed process because indiscriminate removal can introduce risk.
The inventory itself can expose sensitive information about privileged identities and accessible systems. Restrict access by role, log material changes, and protect exports. Keep detailed sensitive evidence in controlled systems and reference it from the inventory when practical.
Consider a hypothetical customer-support agent approved to summarize tickets and draft replies. Its purpose is narrow, but the actual access depends on the deployment and connectors attached to it.
The initial inventory record identifies the support application owner, production tenant, agent version, and a connector identity. The approved action set includes reading assigned tickets and saving draft replies. Sending messages requires a human decision.
Reconciliation finds that the connector also has permission to send messages and read tickets outside the intended queue. No unauthorized send has been observed. That finding still matters: the granted scope exceeds the approved scope, even though the available activity records do not show misuse.
The technical owner checks whether other workloads share the connector, separates the agent’s access where feasible, and removes unnecessary permissions. The reviewer records the change and verifies the expected behavior using an approved test case.
Later, an activity record shows the same identity writing to a new external destination. Because the connector previously served multiple workloads, the investigator checks deployment and execution identifiers before attributing the action to the support agent.
This example illustrates two separate benefits: the inventory supports a permission correction before observed misuse, and it preserves the context needed to avoid incorrect incident attribution. It is not a claim about a real customer or product test.
Use this checklist to establish a usable inventory within a defined environment. Mark an item complete when the responsible owner can point to a record, review decision, or test result that verifies it. Track unresolved items with an owner and a review date.
☐ Document the platforms, accounts, tenants, devices, and external services in scope, including known exclusions.
☐ Agree on what counts as an agent definition, deployment, and run, and assign stable identifiers.
☐ Assign an inventory process owner and a business sponsor and technical owner for each known deployment; route unowned records for resolution.
☐ Establish required fields, approval states, evidence sources, and review deadlines.
☐ Restrict inventory access and exports, and store credential references without copying secret values.
☐ Collect available deployment records and document unsupported environments, failed collections, and each source’s last successful refresh.
☐ Map deployments to identities, delegated access, tools, and downstream resources; flag shared credentials and uncertain attribution.
☐ Record approved actions, granted permissions, and observed activity separately, with supporting evidence and timestamps.
☐ Review discrepancies involving sensitive data or consequential write access, and assign each finding an owner and a resolution or exception decision.
☐ Test renamed agents, duplicate records, permission changes, and collection failures using approved test resources; verify that gaps remain visible.
☐ Configure change-triggered updates and periodic reviews, and confirm how overdue reviews or missing owners are escalated.
☐ Verify that an analyst can locate a deployment, explain its access, find its owner, and retrieve relevant activity evidence.
☐ Exercise suspension and retirement with approved test resources, checking scheduled tasks, downstream access, and shared dependencies.
☐ Retain the decision, responsible owner, timestamp, and verification evidence for access changes and retirement.
☐ Report ownership coverage, collection freshness, unresolved discrepancies, and response-test results with explicit denominators and coverage gaps.
Evaluate tools against the deployment types and evidence sources you actually need. A large number of records is not enough to demonstrate that the inventory is accurate, current, or useful during an investigation.
Ask providers to demonstrate discovery across your relevant hosted, local, custom, and third-party agents. Verify prerequisites, collection permissions, latency, unsupported environments, and behavior when a connector fails.
Then test whether the tool preserves stable identifiers, supports shared and delegated identities, records configuration history, exposes evidence provenance, and exports usable records through documented interfaces. Confirm which workflow actions require integrations and separate permissions.
Use a small set of measures with explicit denominators:
Avoid claiming a percentage of “all enterprise agents” unless the denominator can be established. Usually, the defensible statement is coverage of declared accounts, platforms, devices, or known deployments, accompanied by explicit gaps.
Inventory records provide context for security decisions: whose agent is involved, which identity it uses, what actions are expected, and how access can be changed. Detection and response workflows need telemetry and enforcement mechanisms in addition to that context.
Connect relevant inventory identifiers to security investigations so analysts can move from an identity or workload event to the deployment owner and approved scope. Preserve the distinction between a suspected anomaly, an investigated incident, a recommended action, and confirmed containment.
Vectra AI’s AI-native security and observability approach is relevant where agents operate through identities and infrastructure across connected environments. Its asset and identity visibility use case describes visibility across network, identity, cloud, and SaaS environments. This can provide supporting context when evaluating an inventory program; the specific agent mappings, telemetry, and integrations still need verification for the deployment.
If you are assessing that operational connection, request a Vectra AI demo focused on the identities, environments, and investigation workflows your agents use.
Yes. A spreadsheet can establish an initial inventory when the scope is manageable and owners maintain controlled records. Use stable identifiers, review dates, evidence references, and change history. Move to an integrated system when manual reconciliation can no longer keep pace with deployments and permission changes.
No. An MCP server generally belongs in the inventory as a tool or resource dependency linked to the agents that use it. Give it a separate agent record if it also independently performs agent functions under your organization’s counting convention. Preserve its identity and access relationships either way.
Update records when deployment, ownership, permissions, tools, or other material configuration changes occur. Supplement those updates with scheduled reconciliation and risk-based owner reviews. Choose intervals based on operational needs, and monitor collection failures so a missed refresh does not appear to be a quiet environment.
No. Network monitoring can reveal connections and activity patterns, but it cannot reliably identify every local, embedded, or externally hosted agent or establish every action from encrypted traffic. Combine it with platform records, identity information, endpoint evidence, and application logs, and document remaining gaps.
An inventory supports governance by documenting systems, ownership, access, and review evidence. It does not by itself establish compliance. Applicable obligations depend on the use case and jurisdiction, and broader requirements can include testing, oversight, data protection, incident handling, and documented risk decisions.