What Is AI Asset Discovery for Enterprise AI

Only 19% of security leaders report full visibility into where and how AI is used across their organization, according to a 2026 survey of more than 400 security leaders, even as nearly every one of those organizations is already using or piloting AI coding assistants. That gap between adoption and visibility is what AI asset discovery exists to close.

AI asset discovery is a continuously updated catalogue of every AI asset an organization touches, including models, endpoints, datasets, coding assistants, MCP servers, and dependencies, along with the relationships, risks, and owners that connect them. It's not a one-time inventory exercise. It's an ongoing process, because the AI footprint of a modern enterprise changes daily, often in places security teams never think to look.

What Counts as an "AI Asset"?

The cleanest way to scope an AI asset inventory is to split it into two categories. The AI you build covers models your organization trains or fine-tunes, custom agents your engineering teams develop, internal APIs that wrap third-party models, and the datasets those systems are trained or grounded on. The AI you consume covers everything else: SaaS products with embedded AI features, browser extensions that add AI capabilities, AI coding assistants running in developer IDEs, and consumer AI tools employees adopt on their own initiative.

Both categories carry real risk, but they surface through different channels. The AI you build tends to show up in code repositories, cloud consoles, and CI/CD pipelines. The AI you consume tends to show up in network traffic, browser activity, and OAuth grants, often without ever touching a system the security team monitors directly. An inventory that only covers one half of this split gives a false sense of completeness.

Why This Is Broader Than Just "Models"

Treating AI asset discovery as a model-registry problem misses most of what actually needs tracking. A complete inventory includes the models themselves, but also the datasets feeding them, the prompts and system instructions shaping their behavior, the software dependencies and libraries they're built on, the inference endpoints serving them, the agents and coding assistants calling them, and the MCP servers and tools those agents connect to.

Each of these is a separate point of risk. A model can be perfectly secure even if the dataset it was fine-tuned on contains sensitive customer data that nobody flagged. An agent can pass every safety test while the MCP server it connects to has no authentication at all. Scoping discovery narrowly to models alone leaves every one of these adjacent risks invisible.

Why AI Asset Discovery Became Urgent

The 19% Visibility Gap

The 19% figure isn't an outlier. Related research from Cycode's 2026 State of Product Security report found that 81% of security teams lack visibility into AI usage across the software development lifecycle, even though all of the organizations surveyed confirmed having AI-generated code in their codebases. Separate research puts full AI usage visibility as low as 25% to 30% across broader enterprise functions, not just development.

The reason this gap persists isn't a lack of effort. It's structural. AI adoption happens faster and more distributed than any previous wave of enterprise technology, since anyone with a browser can add an AI capability without provisioning new infrastructure or requesting IT approval. Security architectures built for traditional software, meaning centralized deployment through known channels, were never designed to catch that pattern.

How MCP Expanded the Scope of What Needs Discovering

The Model Context Protocol has significantly changed the shape of this problem. Before MCP became the default way agents discover and call external tools, an organization's AI footprint was largely bounded by which models it used and which applications embedded them. MCP turned that into an open-ended integration surface, since any agent can now connect to any MCP server that exposes a compatible interface, often configured locally by an individual developer, with no central record of the connection.

This matters for discovery because MCP servers frequently run outside the environments traditional asset management tools scan. A developer might configure an MCP server directly in their IDE, granting an AI coding assistant access to internal repositories, databases, or APIs, entirely outside any cloud console or network monitoring point. Discovery approaches that only scan cloud infrastructure miss this layer completely, and it's rapidly become one of the largest sources of unaccounted AI risk in enterprise environments.

The Six Surfaces of AI Discovery

Effective AI asset discovery needs to cover distinct surfaces, since no single scanning method reaches everywhere AI assets live.

Code and Cloud (The AI You Build)

This surface covers source code repositories, CI/CD pipelines, and cloud infrastructure. Discovery here means scanning for model dependencies pulled into codebases, fine-tuning jobs running in cloud ML platforms, custom agent code, and the infrastructure-as-code definitions that provision AI-related cloud resources. This is the most mature discovery surface, since it maps closely onto existing cloud security posture management and software composition analysis practices.

Network, Browser and Endpoint (The AI You Consume)

This surface covers the AI tools employees adopt directly: browser extensions, SaaS applications with embedded AI features, and consumer AI tools accessed through personal or unmanaged accounts. Discovery here relies heavily on network traffic analysis to identify connections to known AI service domains, browser-level monitoring to catch extensions and web-based tools, and OAuth grant discovery to surface which third-party AI applications employees have authorized to access corporate data.

Memory and Runtime State

The least mature but increasingly critical discovery surface covers what's happening while AI systems are actually running: an agent's short-term and long-term memory, the runtime state of active agent sessions, and the tool calls and MCP connections an agent makes dynamically during execution rather than at configuration time. Static discovery methods, meaning scans that run once and capture a snapshot, miss this entirely, since runtime behavior can differ meaningfully from what a system's configuration files suggest it should do. This surface requires continuous, not periodic, monitoring.

From Discovery to AI-BOM

What an AI-BOM Actually Contains

Discovery on its own produces a list. An AI Bill of Materials, or AI-BOM, structures that list into something usable: a machine-readable inventory that records not just what AI components exist, but how they relate to each other and who's responsible for each one. A complete AI-BOM typically includes model metadata (name, version, provenance, and a hash of the weights where available), dataset lineage showing what data trained or grounds each model, the software dependencies and libraries each component relies on, the inference endpoints and APIs exposing each model, and the agents, tools, and MCP connections that call into the system at runtime.

The concept borrows directly from the Software Bill of Materials, or SBOM, which does the equivalent job for traditional software dependencies. But an AI-BOM has to go further, since AI systems introduce dependencies an SBOM was never built to capture: training data, fine-tuning lineage, prompt versions, and the non-deterministic behavior that comes from a model rather than static code. Standards work here is still maturing, with both CycloneDX and SPDX extending their schemas to accommodate AI components, though no regulator has formally mandated a single format yet.

Why an Inventory Alone Isn't the End Goal

A static AI-BOM, generated once and left unchanged, has a short shelf life. Models get retrained, datasets get refreshed, agents get new tool integrations, and dependencies shift, often multiple times per day in an actively developed system. An AI-BOM that isn't continuously updated becomes inaccurate almost as soon as it's produced, which defeats its purpose as a compliance or security artifact.

The real value of an AI-BOM comes from what organizations do with it: mapping relationships between components to understand blast radius, assigning clear ownership so every asset has an accountable party, and feeding that structured data into risk assessment and remediation workflows. An inventory that sits in a spreadsheet, disconnected from ongoing risk decisions, provides much less value than one wired into how the organization actually manages AI risk day to day.

Why Manual Discovery Doesn't Work Anymore

Manual discovery methods, meaning periodic surveys, spreadsheet tracking, and one-off scans conducted ahead of an audit, were adequate when organizations ran a handful of centrally managed AI systems. They break down almost immediately at current scale and pace.

The core problem is velocity. New AI assets get created continuously: a developer adds a model dependency to a repository, a business user connects a new SaaS tool with an embedded AI feature, an agent gets configured with a new MCP server. A quarterly or even monthly manual review captures a snapshot that's already stale by the time it's compiled. Pattern-matching approaches, such as searching for known AI vendor domains in network logs, catch only the tools someone thought to look for, missing anything using a less obvious integration path or a self-hosted model.

Continuous, automated discovery solves this by treating AI asset inventory the way modern security teams treat cloud asset inventory: an always-on process that updates as the environment changes, rather than a project that gets redone every few months. This shift matters because the gap between a manual inventory and reality tends to widen, not narrow, over time as AI adoption accelerates.

The Regulatory Case for AI Asset Discovery

AI asset discovery increasingly isn't optional from a compliance standpoint, even where no regulation names it directly. The EU AI Act requires providers of high-risk AI systems to maintain detailed technical documentation under Article 11 and to implement a risk management system under Article 9, both of which presuppose the organization actually knows which AI systems it operates and what they depend on.

NIST AI RMF's Map function similarly asks organizations to document a system's context, components, capabilities, and limitations before meaningful risk assessment can happen, making an accurate asset inventory a practical prerequisite rather than an optional add-on. ISO/IEC 42001, the international standard for AI management systems, is more explicit still: a compliant AI Management System requires a structured, continuously updated inventory of AI systems as a foundational control, not a supporting document produced once for certification.

None of these frameworks specify exactly how discovery should work, and this guide isn't the place for a deep dive into any of them individually. The point is simpler: every major AI governance framework assumes an accurate inventory exists, and for a growing share of enterprises, that assumption doesn't currently hold.

How This Relates to AI-SPM, Agent Inventory, and MCP Discovery

AI asset discovery sits at the top of a hierarchy of related, narrower disciplines, and it's worth being explicit about how they connect rather than treating them as interchangeable.

AI Security Posture Management, or AI-SPM, uses the output of discovery to continuously assess the security configuration of discovered AI assets, such as checking whether a model endpoint is publicly exposed or whether a dataset contains unmasked sensitive data. Agent inventory is a narrower discipline focused specifically on cataloguing autonomous agents, their permissions, and their tool access. MCP discovery narrows further still, focusing specifically on identifying MCP servers, their configurations, and the trust boundaries they introduce.

Each of these builds on a complete AI asset inventory rather than replacing the need for one. An organization can't meaningfully practice AI-SPM without first knowing what assets exist to assess, and agent-specific or MCP-specific discovery are best understood as focused views into the broader asset inventory rather than standalone efforts.

How Akto Approaches AI Asset Discovery

Akto treats AI asset discovery as a continuous process spanning all six discovery surfaces rather than a point-in-time scan. Across code and cloud, Akto identifies model dependencies, custom agents, and AI-related infrastructure as they're introduced into repositories and cloud environments. Across network, browser, and endpoint, it surfaces the AI tools employees are actually using, including unsanctioned SaaS products and browser-based tools that never touch a managed device.

Akto pays particular attention to the surface most discovery tools miss: MCP servers and the agents connecting to them, cataloguing these connections as they appear rather than relying on a static configuration record that goes stale. Discovered assets feed directly into risk assessment, with findings mapped to frameworks including the EU AI Act, NIST AI RMF, and ISO/IEC 42001 so the resulting inventory functions as usable compliance evidence, not just a list. From there, the same discovered assets and their relationships become the foundation for Akto's continuous red teaming, closing the loop between knowing an asset exists and actually testing whether it's secure.

FAQs: AI Asset Discovery for Enterprise AI

What is AI asset discovery?

AI asset discovery is the continuous process of identifying and cataloguing every AI component an organization uses or operates, including models, datasets, endpoints, coding assistants, agents, and MCP servers, along with the relationships, risks, and owners connecting them. It's an ongoing process rather than a one-time inventory, since AI assets change too frequently for a static snapshot to stay accurate.

What counts as an "AI asset" beyond just models?

A complete AI asset inventory includes the models themselves, the datasets they're trained or grounded on, the prompts and system instructions shaping their behavior, the software dependencies they're built on, the inference endpoints serving them, and the agents, tools, and MCP servers that connect to them at runtime. Scoping discovery to models alone leaves most of the actual risk surface unaccounted for.

What's the difference between "the AI you build" and "the AI you consume"?

The AI you build covers models, agents, and systems your organization develops internally, typically surfacing through code repositories and cloud infrastructure. The AI you consume covers third-party and consumer AI tools employees adopt, typically surfacing through network traffic, browser activity, and OAuth grants. Both require different discovery methods, and an inventory covering only one half misses significant risk.

How many organizations actually have full visibility into their AI usage?

A 2026 survey of more than 400 security leaders found only 19% reported full visibility into where and how AI is used across their organization. Related research puts the figure at a similar range across broader enterprise functions, with the majority of security teams acknowledging significant blind spots despite near-universal AI adoption.

What is an AI-BOM, and how does it relate to AI asset discovery?

An AI-BOM, or AI Bill of Materials, is a machine-readable inventory that structures the output of AI asset discovery into a usable format, recording model metadata, dataset lineage, dependencies, and the relationships between components. Discovery produces the raw findings; an AI-BOM organizes those findings into something that supports risk assessment, ownership assignment, and compliance reporting.

Why did MCP expand the scope of what AI discovery needs to cover?

Before MCP, an organization's AI footprint was largely bounded by which models and applications it deployed centrally. MCP lets any agent connect to any compatible external tool, often configured locally by an individual developer with no central record, which turned agent-to-tool integration into an open-ended surface that traditional discovery methods don't reach.

What are the six surfaces AI discovery typically scans across?

Code and cloud, network and browser and endpoint, and memory and runtime state, spanning both the AI an organization builds internally and the AI it consumes from third parties, plus the dynamic runtime behavior of active agent sessions that static configuration scans miss entirely.

Why doesn't manual discovery or spreadsheet tracking work for AI assets?

New AI assets get created continuously, often multiple times a day in an actively developed environment, which means a periodic manual review is stale almost as soon as it's compiled. Pattern-matching approaches also only catch tools someone thought to search for, missing anything using a less obvious integration path such as a self-hosted model or a locally configured MCP server.

What regulations effectively require organizations to maintain an AI inventory?

The EU AI Act's Article 11 technical documentation and Article 9 risk management requirements presuppose an accurate inventory for high-risk systems. NIST AI RMF's Map function requires documenting a system's context and components before meaningful risk assessment can occur. ISO/IEC 42001 explicitly requires a structured, continuously updated AI system inventory as a core element of a compliant AI Management System.

Is AI asset discovery the same as AI security posture management (AI-SPM)?

No. AI asset discovery identifies and catalogues what AI assets exist. AI-SPM uses that inventory to continuously assess the security configuration of those discovered assets, such as checking for exposed endpoints or unmasked sensitive data. AI-SPM depends on discovery having already happened; it doesn't replace it.

How does general AI asset discovery relate to agent-specific inventory or MCP-specific discovery?

Agent inventory and MCP discovery are narrower disciplines that sit underneath the broader AI asset discovery umbrella, focusing specifically on autonomous agents and MCP server connections respectively. Both depend on a complete AI asset inventory as their foundation rather than functioning as standalone replacements for it.

How does Akto perform continuous AI asset discovery across an enterprise?

Akto scans across code and cloud, network and browser, and endpoint and runtime surfaces on an ongoing basis, with particular attention to MCP servers and agent connections that most discovery tools miss. Discovered assets are mapped to regulatory frameworks including the EU AI Act, NIST AI RMF, and ISO/IEC 42001, and feed directly into Akto's continuous red teaming so the inventory connects to active risk testing rather than sitting as a static record.