Why Do Enterprises Need an AI Agent Inventory?

Agents now enter the enterprise through SaaS copilots, serverless functions, coding assistants, and scripts an employee builds in an afternoon, and each one can hold credentials that security and compliance teams may never have reviewed. An AI agent inventory is a live catalog of every agent running in the enterprise, recording who owns it, what it can reach, and where it sits in its lifecycle. It lets security teams find those credentials and gives compliance teams the system records auditors ask for. Operations teams use the same record to attribute spend and retire agents that no longer serve a purpose.

What an AI Agent Inventory Is and Why It Matters Now

Here, inventory has nothing to do with product stock. The closer analogy is the model inventory used in banking model risk management, with one difference. Inventory entries for agents take actions, call tools, and hold credentials instead of only producing scores.

Agent counts grow quickly because agents arrive in several forms, and each form multiplies differently. This piece uses four working categories:

• Task agents: Single-purpose agents perform one defined job, such as triaging tickets or reconciling invoices, and teams build many of them because each is cheap to stand up.
• Assistive agents: Copilots embedded in SaaS tools and IDEs act on a person’s prompt, and they often appear as a feature toggle inside an application the company already licenses.
• Autonomous agents: These agents plan multi-step work, call tools, and act with limited human approval.
• Multi-agent systems: An orchestrator delegates to sub-agents, so one deployment can look like a single application while running several agents with separate tool permissions.

No analyst or standards body publishes these four categories as one official taxonomy. They are useful here because each needs a different depth of review: an assistive copilot that drafts email warrants a lighter record than an autonomous agent with write access to a payments system. Gartner’s guidance on agent sprawl makes a centralized agent inventory, built by discovering and categorizing sanctioned and shadow agents, its second step after setting governance policies, and says adaptive controls can be built once an agent inventory exists, based on the risk each agent presents [1].

Shadow Agents: Why Security Teams Cannot Protect What They Cannot See

Gartner describes shadow AI agents in three forms: agents embedded in existing enterprise software, agents consumed directly from the internet, and agents employees create through vibe coding and similar tools [2]. The same Gartner article finds that 75% of organizations report unauthorized use of AI coding assistants and 50% report employee access to public SaaS GenAI agent platforms [2].

Survey data from the Cloud Security Alliance (CSA) shows how far perception trails reality. In its January 2026 survey, 82% of organizations had unknown AI agents running in their infrastructure, even though 68% believed they had strong visibility [3]. Nearly two in three (65%) had an AI agent-related incident in the previous 12 months, and CSA lists data exposure (61%) among the business impacts of those incidents [3].

Shadow agents tend to collect around three surfaces, and each one carries access:

• SaaS copilots: OAuth grants connect them to mail, files, CRM records, and chat, often approved once by a single user.
• Cloud functions: Serverless code calls model APIs under a service principal that may hold broad cloud permissions.
• Developer scripts: Local agents and Model Context Protocol (MCP) servers run on laptops with provider keys in environment files or committed to repositories.

Data exposure from these agents reaches well beyond traffic to a model provider. It can occur in prompts, tool returns, file reads, outputs, and coding-agent sessions. Security controls for any of these depend on the agent having a record, because policy, evidence, and accountability all attach to a known entity. That is why security sits inside the governance frame. An agent missing from the inventory sits outside every control the governance program defines.

Why Agents Are Non-Human Identities That Need Named Owners

When an agent authenticates to Salesforce, AWS, or GitHub, it does so as a non-human identity (NHI), such as a service account, API key, OAuth token, or workload identity. Treating each agent as its own identity, instead of letting it run on a developer’s credentials or a shared team key, is what makes its actions attributable. CSA’s AI identity checklist recommends bringing agents into the user directory with “a unique identifier, owner, and documented purpose for each agent,” and states that “Explicitly defining ownership and intent eliminates anonymity, making it possible to audit agent behavior.” [4]

Least privilege follows from the documented purpose. An agent that summarizes support tickets needs read access to the ticketing system and nothing in the billing database. Scope each credential to the tools and data domains the purpose requires, and record those scopes in the inventory entry.

The inventory then becomes the input to three recurring controls:

• Access reviews: A reviewer compares the scopes an agent holds against its documented purpose and removes the difference.
• Ownership checks: When an owner leaves or changes teams, the record flags the agent for reassignment before it becomes an orphaned identity.
• Revocation: Responders can disable every credential tied to one agent because the record lists them in one place.

The same record caps autonomy. An agent should not receive more autonomy than its owner and the monitoring around it can oversee, and the autonomy field in the inventory makes that limit explicit and reviewable.

Which Regulations and Frameworks Expect an Inventory of AI Systems

None of the major texts uses the phrase “AI agent inventory,” yet each asks for records that an inventory can supply. The EU AI Act sets out several relevant obligations:

• Automatic logging: Article 12 requires high-risk AI systems to technically allow the automatic recording of events over the system’s lifetime, with logs that support identifying risk situations, post-market monitoring, and the deployer monitoring described in Article 26(5) [5].
• Monitoring and retention: Article 26(5) requires deployers to monitor operation and suspend use when they have reason to consider that use according to instructions may present a risk under Article 79(1). Article 26(6) requires deployers to keep logs under their control for a period appropriate to the intended purpose, at least six months unless applicable Union or national law provides otherwise [5].
• Registration: Public-authority deployers must register their use of Annex III high-risk systems, except those in point 2 of Annex III, in the EU database under Article 49 [5].
• Application dates: Regulation (EU) 2026/1744 moved the application of Chapter III, Sections 1, 2 and 3, except Article 6(5), to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for high-risk systems covered by Annex I [6].

The AI Act does not say “inventory,” so the link is an inference. A deployer cannot retain logs, monitor operation, or confirm registration for high-risk systems it has not identified. The classification field in each record is where compliance teams determine which obligations apply to which agent.

The NIST AI Risk Management Framework 1.0 is explicit. GOVERN 1.6 reads: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” [7]

The Playbook’s suggested actions include naming “a specific individual or team that is responsible for maintaining the inventory,” inventorying all systems instead of only high-risk ones, and recording attributes such as documentation, links to source code, incident response plans, data dictionaries, and AI actor contact information [7]. GOVERN 1.7 adds procedures for decommissioning.

The table below summarizes what each text asks for and which inventory records supply it:

ISO/IEC 42001:2023 places resource documentation among its Annex A controls. BSI training material lists A.4.2 Resource documentation, A.4.3 Data resources, A.4.4 Tooling resources, A.4.5 System and computing resources, and A.4.6 Human resources, alongside A.3.2 AI roles and responsibilities and the clause 6.1.4 AI system impact assessment [8]. For an agent, tooling resources correspond to the tools and MCP servers it calls, and data resources correspond to the data domains its credentials reach.

These mappings show where an inventory supplies evidence. They are not legal advice, and an inventory does not by itself establish compliance with any regulation or certification requirement.

What Each Record in an AI Agent Inventory Should Capture

Each record should let a reviewer answer, without opening another system, who is accountable for the agent, what it can touch, and when it was last checked. The following fields cover that minimum:

• Agent ID and owner: Each agent gets a unique identifier, a named human owner, and a backup owner who can approve access changes.
• Business unit and purpose: The record names the team that funds the agent and states its purpose in one sentence, which reviewers compare against its access.
• Model and version: The record lists the underlying model, provider, and version, so a model change triggers re-review.
• Tools and APIs: Every tool, API, and MCP server the agent can call is listed with the operations it is permitted to perform.
• Credentials: The record references each service account, API key, and OAuth grant by identifier and vault location, never by value, along with its expiry.
• Data access level: The record states which data classes the agent can read or write, such as customer PII, financial records, or source code.
• Hosting: The record says where the agent runs, whether in a SaaS tenant, a cloud function, a container, a developer laptop, or a third-party service.
• Autonomy level: The record states whether the agent suggests, acts with human approval, or acts alone, and which actions require approval.
• Risk tier and regulatory classification: The record states the agent’s risk tier and which regulatory obligations apply to it, such as whether it is part of a high-risk system under the EU AI Act.
• Lifecycle status: Each agent is marked as testing, live, or retired, and retired entries keep their history.
• Review date: The record holds the last review date, the reviewer, and the next scheduled review.

Start with these fields for every agent. Add depth, such as an impact assessment reference or a regulatory classification rationale, only for agents whose data access or autonomy puts them in a higher risk tier. A short record covering every agent is worth more than a detailed one covering a third of them, which matches the Playbook’s observation that partial inventories may not provide the value of a full inventory [7].

How to Discover Shadow Agents and Keep the Inventory Current

Continuous automated discovery should populate the inventory, and periodic audits should confirm what discovery cannot infer: who owns an agent and whether it still needs its access. Each shadow surface has a matching signal:

• SaaS copilots: Pull OAuth grants and connected apps from the identity provider and SaaS admin APIs.
• Cloud functions: Watch for new service principals and outbound calls to model provider endpoints.
• Developer scripts: Scan repositories for provider keys and committed MCP configuration files.

Gartner’s fifth step in managing sprawl is establishing ongoing visibility into agent usage, detecting anomalous behavior, and correcting agents that exceed their intended scope or risk tolerance [1]. The two approaches cover different failure modes, compared below:

The simplest viable setup uses signals most enterprises already have: gateway traffic and identity provider data. Add endpoint and repository scanning when evidence shows agents running outside the gateway, such as provider keys in commits or model traffic from unmanaged hosts. Route every newly discovered agent without an owner into a registration workflow with a deadline, so discovery produces accountable records and not a growing alert queue.

What an Inventory Unlocks: Oversight, Lifecycle, and Cost Control

Once each agent has a record, several controls become routine operations:

• Kill switches and revocation: Responders can disable an agent at the gateway and revoke every credential listed in its record in one action.
• Per-agent monitoring: Telemetry tagged with an agent ID lets teams compare each agent’s tool calls, error rates, and data access against its documented purpose.
• Decommissioning: Retirement follows a defined path, and the NIST Playbook notes that decommissioned systems may be stored in the inventory alongside active ones for an established length of time [7].
• Token spend attribution: Model usage maps to an owner and business unit, so finance can see which agents drive cost and whether that cost tracks to output.
• Duplicate agents and license creep: Records reveal when three teams built agents for the same task, or when copilot seats stay licensed after the work moved elsewhere.

Decommissioning matters for governance as much as for cost. An agent that stopped doing useful work but kept its OAuth grant remains an open path into a system of record, and the lifecycle field is what surfaces it.

Salesloft Drift: How an Inventory Shortens Incident Response

Between August 8 and August 18, 2025, a threat actor used OAuth credentials tied to the Salesloft Drift integration to exfiltrate data from customers’ Salesforce instances [9]. Salesloft states that the actor’s main objective was stealing credentials, specifically AWS access keys, passwords, and Snowflake-related access tokens, and that customers who did not use the Drift-Salesforce integration were not affected [9].

Drift powers an AI chatbot that corporate websites use to turn conversations into Salesforce leads. Krebs on Security reports that the stolen tokens also covered services customers integrate with Salesloft, including Slack, Google Workspace, Amazon S3, Microsoft Azure, and OpenAI [10].

Google advised that organizations using Salesloft Drift “should consider their data compromised” [10]. Salesforce blocked Drift from integrating with its platform on August 28 [10]. How the attackers obtained the tokens remained unclear in that reporting [10].

Drift is a chat integration, and nothing in the reporting shows an agent acting on its own, but the exposure pattern is similar to what an uncataloged agent creates: an AI integration connected by OAuth, holding standing tokens into several systems of record, and approved by a business team. The first hours of a response like this depend on questions an inventory answers by lookup:

1. Which tenants and business units connected the integration, and who approved each connection.
2. Which credentials and OAuth scopes it holds, and in which systems.
3. Which data domains those scopes reach, which sets the scope of the exposure review.
4. Who owns each connection and can approve revocation immediately.
5. Which downstream agents or workflows depend on it, so revocation does not break unrelated processes without warning.

Without the record, responders rebuild these answers from identity provider logs, SaaS admin consoles, and interviews while the tokens remain valid. With it, revocation, rotation, and the notification decision start from a known list. The log of what was revoked, when, and by whom then serves as evidence in the post-incident review.

How Fiddler Enables Agent Governance at Scale

Fiddler gives teams the controls and evidence to govern AI in production, starting from the telemetry agents already emit. The Fiddler AI Observability and Security platform builds its view of agents from the same data it uses for monitoring and enforcement, so each agent’s record reflects what it does in production. Coverage spans first-party agents teams build, third-party agents the enterprise deploys, and coding agents developers use.

Standardized telemetry is the foundation beneath the four capabilities and organizes events in the agentic hierarchy of application, session, agent, trace, and span. Instrumentation is OpenTelemetry-native, with SDKs for LangGraph, LangChain, AWS Strands Agents, and Google ADK plus REST endpoints.

Teams can deploy Fiddler directly or through the LLM or MCP gateway they already run, such as LiteLLM, AgentGateway or Kong Gateway, so deployment needs no new infrastructure, agent-side integration or SDK to embed, including for third-party agents a team cannot modify.

• Reliable Evaluation: Batteries-included Fiddler Centor Models score prompts and responses in-environment, with no external LLM call. Centor Models can evaluate 100% of prompts and responses by default instead of relying on a sample.
• Continuous Monitoring: Per-agent traces show LLM calls, tool calls, and token usage, so an application-level alert can be followed to the exact agent and span. For coding agents, fleet analytics include cost per pull request, adoption versus purchased seats, and model usage across the developer fleet.
• Enforceable Policy: Fiddler Guardrails checks the request before the model is invoked and the response before it reaches the user or a downstream system, with under 80ms response time. Actions are allow, block, or redact depending on the policy. Coverage includes secret detection and PII/PHI detection and redaction.
• Auditable Governance: Teams can keep track of their first-party agents, third-party agents and coding agents in a registry built from the telemetry Fiddler already ingests, including each agent’s model, tools, ownership and lifecycle status. Audit trails record every enforcement decision with contextual metadata, including who triggered the event and what action or policy was applied.

Fiddler deploys as SaaS, in a VPC (including as an Amazon SageMaker Partner App), on-premise or in AWS GovCloud. It is SOC 2 Type 2 certified.

Request a demo to review how these controls would fit the existing agent architecture and deployment environment.

References

[1] Gartner, “Gartner Identifies Six Steps to Manage AI Agent Sprawl,” Gartner Newsroom. Accessed: Oct. 28, 2026. [Online]. Available: https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl

[2] Gartner, “AI Agents Are Outrunning Cybersecurity Oversight,” Gartner, Sep. 30, 2026. Accessed: Oct. 28, 2026. [Online]. Available: https://www.gartner.com/en/articles/agentic-ai-oversight

[3] Cloud Security Alliance, “New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments,” Cloud Security Alliance, Apr. 21, 2026. Accessed: Oct. 28, 2026. [Online]. Available: https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments

[4] Cloud Security Alliance, “AI Identity Security Compliance Checklist,” Cloud Security Alliance. Accessed: Oct. 28, 2026. [Online]. Available: https://cloudsecurityalliance.org/articles/ai-identity-security-compliance-checklist

[5] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 (Artificial Intelligence Act),” EUR-Lex. Accessed: Oct. 28, 2026. [Online]. Available: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

[6] European Parliament and Council of the European Union, “Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI),” Official Journal of the European Union, Jul. 8, 2026. Accessed: Oct. 28, 2026. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF?uri=OJ%3AL_202601744

[7] National Institute of Standards and Technology, “AI RMF Playbook: Govern,” NIST AI Resource Center. Accessed: Oct. 28, 2026. [Online]. Available: https://airc.nist.gov/airmf-resources/playbook/govern

[8] BSI Group, “ISO/IEC 42001:2023 Public Webinar,” BSI webinar presentation, 2025. Accessed: Oct. 28, 2026. [Online]. Available: https://www.bsigroup.com/siteassets/pdf/th-th/products-and-services/th-as-cross-lg-ict-dt-mpd-mp-iso42001webinar-1025-ppt.pdf

[9] Salesloft, “Clari/Salesloft Trust Center,” Salesloft. Accessed: Oct. 28, 2026. [Online]. Available: https://trust.salesloft.com

[10] Krebs on Security, “The Ongoing Fallout from a Breach at AI Chatbot Maker Salesloft,” Krebs on Security, Sep. 2025. Accessed: Oct. 28, 2026. [Online]. Available: https://krebsonsecurity.com/2025/09/the-ongoing-fallout-from-a-breach-at-ai-chatbot-maker-salesloft