Key Insights
According to IBM's 2026 breach report, security incidents involving shadow AI more than doubled, rising from 20% to 43%. Employees adopt AI chat tools, vendors enable AI features in existing software, and developers wire models into products, often without a central record. An AI inventory is that central record, tying each system to an owner, its data, and a governance decision.
This guide follows an illustrative AI use case, a customer support ticket summarizer, from first discovery through a later change. It also compares discovery methods and shows what system and agent records contain. It then explains how records feed risk review, which duties are legal rather than voluntary, and how to keep the inventory current.
What Is an AI Inventory?
An AI inventory is an organized record of the AI systems an organization uses or builds, along with documents that explain what each system does, who is accountable for it, and what it depends on. A system, such as a support assistant, is what people interact with, and its underlying model may be third-party, open-source, or trained in-house. Each business purpose gets its own entry, because drafting internal notes and screening job applicants carry different risk. The inventory covers sanctioned tools, shadow AI, AI features embedded in SaaS products, models, datasets, and agents.
Model cards and AI bills of materials (AIBOMs) feed the inventory without replacing it. A model card documents a model's intended use and evaluation results, while an AIBOM lists models, datasets, dependencies, and provenance. The organization-wide inventory adds the business owner, the approval decision, and its conditions, which neither carries.
Why an AI Inventory Supports Security and Governance
An AI inventory supports security and governance because incident response, vendor review, and policy decisions all start with identifying the system involved and the person responsible. When a model provider discloses a flaw, responders need every system that uses that model and an owner who can say what changed.
Ownership records also surface duplication that complicates AI spend management, such as three teams paying for overlapping tools. Abnormal's AI Governance can help build those ownership records by discovering approved and shadow AI tools and attributing ownership.
The inventory works best as an evidence chain, in which each discovered activity becomes a linked record that names its owners and dependencies and supports a documented decision. A record with no owner stands out immediately.
How AI Discovery Methods Reveal Different Parts of the Inventory
Each AI discovery method sees one slice of AI activity, so an inventory built from several correlated sources covers more ground than any single scan. A SANS analysis of AI visibility explains that connection metadata can show a device talking to a model provider, but without Transport Layer Security (TLS) decryption, network sensors cannot inspect prompts or tool-call contents. AI traffic can also hide in locally run Model Context Protocol (MCP) servers or command-line tools. Each method's blind spots are what the next one has to cover:
Discovery Method | Evidence Found | Blind Spots |
|---|---|---|
Network, Domain Name System (DNS), and proxy telemetry | Provider-domain connections, egress logs | No prompt content, and misses local tools |
SaaS catalog and OAuth consent review | AI apps, permission grants, consenting users | A grant shows access, not activity |
Identity and single sign-on (SSO) logs | Sign-ins, OAuth grants, API-key issuance | Partial view that needs correlation |
Endpoint and browser telemetry | Extensions, generative AI site visits, local agent runtimes | Covers only onboarded devices |
Cloud asset records and API audit logs | AI workloads, model endpoints, model callers | Some inference logging is off by default |
Code repository and dependency scanning | Machine learning (ML) libraries, model files | Keyword matching is noisy |
Procurement review | Purchase requests and contracts for AI tools | Free-tier use never appears |
Findings from one method are leads, not conclusions. An identity log, cloud audit record, or conversation with the likely owner then confirms what a proxy log entry shows.
Network and Identity Evidence for External AI Use
Network and identity sources each show part of who is using AI and which account they use. In the illustrative case, proxy and DNS logs show requests from the support team's network segment to a model provider's API domain.
A SaaS consent review shows that a team lead granted an AI summarization app read access to the helpdesk through an OAuth access token. Sign-in logs show a service account authenticating to a cloud AI platform.
Together, the proxy, consent, and sign-in evidence still does not establish the use case. A connection to a provider domain could be a sanctioned feature inside another SaaS product, since one domain can serve both. An OAuth grant shows permission scope and says nothing about whether the app has ever read a ticket, and without decryption, the network view carries no prompt content.
Network and identity discovery produces a draft record with three pieces of evidence attached. The inventory owner also asks the team lead what the app does and who decided to use it, and the record stays in draft until a named approver answers.
Endpoint, Cloud, and Repository Evidence for Local and Built AI
Endpoint, cloud, and code evidence reach AI that never crosses the network as an obvious AI request. These sources also tie an AI call to a specific deployment rather than to a traffic pattern.
For the summarizer, the cloud audit log confirms the service account calls the model, and the helpdesk integration's repository lists the provider's AI library as a dependency. Together they identify the deployment, its credential, and the code a developer would change. An engineer's laptop also shows a ticket-summarizing browser extension, which may be a separate use case.
Each source has limits that shape how findings enter the inventory. Some cloud services log inference operations only when an administrator turns on logging, and configuration determines whether the logs capture prompt content. Detecting an extension also says little about what it does inside a connected application.
The extension therefore enters the inventory as an unresolved discovery and goes to the engineer's manager for confirmation. Keeping it as its own entry stops anyone from folding it into the approved summarizer record, where nobody would review its data flows.
What an AI Inventory Record Should Capture
An AI inventory record should capture enough to answer who owns a system, what it runs on, what data it touches, how it was discovered and where its governance stands. The National Institute of Standards and Technology (NIST) Generative AI Profile, a voluntary framework, suggests recording foundation models with versions and access modes, data provenance, sensitive data considerations, human oversight roles, and known issues from incident databases.
System, Use-Case, and Data Records with Named Owners
A system record ties each AI use case to a named owner, the data it touches, and the evidence that found it. In the illustrative summarizer record, each field answers a question a reviewer or responder will ask:
Use Case: The integration summarizes inbound support tickets as internal drafts for human agents.
Owner: A named support operations manager owns the use case, and a named engineer is the technical contact.
Model or Service: The integration reaches a third-party foundation model through a cloud AI service and pins the version in configuration.
Deployment Context: The integration runs in the production helpdesk, and a dedicated service account calls it.
Data Sources: The integration sends ticket text and customer contact fields and excludes payment fields by design.
Supporting Documentation: The record links vendor model documentation, a data-flow diagram, and data-retention terms.
Discovery Evidence: The evidence includes proxy log entries, the OAuth grant, cloud audit records, and the repository dependency.
Risk Status: The record documents assessment and approval with conditions.
OAuth scopes show what the app can read, service-account permissions show what the integration can reach, and the code shows which fields it sends. Together, those records let responders find every system that receives customer contact data.
Agent Records with Identities and Bounded Permissions
Agent records add the agent's identity and permissions because an agent can change systems and answer questions. In the illustrative case, when the support team proposes letting the summarizer set ticket priority and merge duplicates through an MCP server, the summarizer becomes an agent with write access. The SANS visibility analysis cited earlier says every agent needs "a named owner, a defined purpose, and an explicit scope of authority." No widely adopted standard defines a full agent schema, so these fields build on that SANS baseline:
Agent Identity: A distinct credential, separate from shared service accounts, traces every action to the agent.
Sponsor: A named business sponsor is accountable for the agent's purpose and lifecycle.
Scope of Authority: The record states what the agent can change on its own and what requires human approval.
Tools and Connectors: The record lists each connection and MCP server with its owner and version.
Data Access: Read and write scopes per data store let reviewers compare access against the stated purpose.
Lifecycle Status: Testing, production, suspended, or retired status tells responders whether a credential should still work.
Action Logs: Tool-call logs link each action to the agent identity.
With these fields, a reviewer can check whether the agent's reach matches its job. Abnormal's AI Agent Security, in private preview, is designed to discover agents, map their ownership, and track the privileges and data each one can reach.
How Inventory Records Support Risk Review and Approval
Inventory records support risk review by giving reviewers the context, evidence, and decision owner they need to judge risk per use rather than per tool. No widely adopted standard prescribes these steps, but each builds on the one before:
Registration: The owner submits the use case, or a discovery finding creates a draft record for the owner to complete.
Contextual Risk Assessment: Reviewers rate impact, data sensitivity, and autonomy for this specific use.
Policy Mapping: The record lists applicable policies and external obligations and flags gaps as open items.
Review: Security, privacy, or legal reviewers examine linked data flows and vendor terms.
Documented Decision: A named decision owner approves, approves with conditions, or rejects, and records the outcome.
Reassessment Trigger: The decision states which changes send it back for review.
For the summarizer, the support director approves with security sign-off. Approval requires excluding payment data, pinning the model version, and turning on audit logging, and any new write permission or model change triggers reassessment.
Which AI Inventory Obligations Apply to Your Organization?
AI inventory obligations depend on who an organization is and how it uses AI. A few rules, such as US federal AI policy and the EU AI Act, impose inventory or registration duties. For most organizations, inventory practice rests on voluntary frameworks rather than law.
Under the Office of Management and Budget (OMB) federal AI inventory policy, issued in April 2025, most US Executive Branch agencies must inventory their AI use cases at least annually, submit the inventory to OMB, and post it publicly. The policy does not bind private companies.
The EU AI Act separately requires providers of certain high-risk systems to register them in an EU central database. The AI Omnibus amendments, in force since 27 July 2026, simplify registration for exempted systems and apply Annex III high-risk rules from 2 December 2027. An internal inventory is where an organization first identifies which systems might fall into scope.
How to Keep an AI Inventory Current and Useful
An AI inventory stays current when the processes that already encounter new AI feed it directly. A named individual or team maintains the inventory and connects procurement intake, IT asset records, discovery findings, and third-party risk reviews.
Material change is the main trigger for reassessment, and risk-based scheduled reviews act as a backstop. In the illustrative case, the agent proposal and a provider's version upgrade change the model, tool, and data-access fields. Because the original approval assumed read-only access, the decision returns to the support director with the new evidence attached. When the old summarizer endpoint shuts down, its record moves to decommissioned with a retirement date.
Three internal measures show whether the inventory still works. They count records lacking a reachable owner, entries past scheduled review, and discoveries unresolved beyond a set window. Each organization sets its own thresholds, since no widely adopted standard defines a completeness percentage.
Build an AI Inventory That Traces Every System to an Owner
A working AI inventory lets reviewers compare permissions with purpose and gives responders a path from a model or data dependency to its accountable owner. What separates an inventory from a list is that every entry carries a reachable owner and a review decision someone can date.
AI Governance, generally available in Abnormal's AI Security suite, is designed to discover approved and shadow AI tools, assign ownership, and track compliance gaps. Explore the AI Security platform to see how Abnormal maps the AI tools already in use.
Frequently Asked Questions
Can IT asset management tools hold an AI inventory?
Yes, if the asset management tool stores the needed fields and links records to owners, data sources, and decisions. The harder part is the process, because a named owner has to update records after every change. An actively maintained spreadsheet is often more useful than an expensive platform full of outdated entries.
Does every AI inventory record need a model card?
No, model cards are a recommended documentation practice, not a universal legal requirement. When a model card exists, the inventory entry links to it as supporting evidence, and for third-party models, vendor documentation may serve a similar purpose.
Should decommissioned AI systems remain in the AI inventory?
Yes, keeping the record, its approvals, and its supporting documents preserves traceability for audits and investigations into past activity.