You Don't Know What AI Is Running in Your Org. And It Just Became a Security Problem.

Cisco, Palo Alto Networks, Wiz, CrowdStrike, and SentinelOne all shipped AI inventory tools within the same 60-day window. When five competing security vendors converge on the same product category simultaneously, it means their enterprise customers are asking for it urgently. The category is the AI Bill of Materials, or AI-BOM, and it exists because the traditional software bill of materials cannot account for models, agents, prompts, datasets, MCP servers, or the dependency chains that agentic workflows create.

If you cannot enumerate every AI asset running in your environment today, you have a gap that is now visible to auditors, regulators, and your security team's own scanning tools.

Why SBOMs stopped being enough

A software bill of materials tracks packages, libraries, and module dependencies. That works when the software supply chain is composed of deterministic, versioned components. AI systems break that model in every direction.

A single agentic workflow might call three different models, connect to two MCP servers, ingest a fine-tuned adapter, run prompts stored in a version-uncontrolled text file, and access enterprise systems through API credentials granted to a non-human identity. None of those components appear in a traditional SBOM. None are versioned the way a Python package is. Several can change behavior through prompt modification alone, with no code deploy required.

Then there is shadow AI. Employees and teams spinning up AI tools without formal IT approval. Vibe coding platforms. Personal ChatGPT accounts processing work data. Unsanctioned agents running in developer environments. Cisco's Amy Chang, head of AI threat intelligence and security research, told The Register that organizations trying to get their arms around AI security want, first and foremost, a way to identify what AI assets exist in their environment.

The AI-BOM is the answer to that identification problem. Per Palo Alto Networks, it is a machine-readable inventory covering every model, dataset, agent, SDK library, MCP server, ML framework, agentic skill, prompt, and AI tool in the environment, plus how these components interact with each other and connect to workflows.

What is actually shipping

Cisco's AI-BOM scanner, open-sourced as part of DefenseClaw, parses Python source code using libcst, resolves fully qualified symbols, and matches them against a DuckDB catalog of known AI framework components including LangChain, LangGraph, CrewAI, PyTorch, and scikit-learn. As detailed in Cisco's technical blog, it builds lightweight call graphs and derives relationship types: USES_TOOL, USES_LLM, USES_MEMORY, USES_RETRIEVER. For containerized deployments, it extracts the /app directory from Docker images. Cisco also shipped a Model Provenance Kit, effectively a fingerprint test for AI models, that compares models through metadata, tokenizer structure, and weight-level signals against a database of approximately 150 base models, per TechInformed.

Palo Alto Networks' Prisma AIRS takes a different approach, focusing on the identity layer. Rather than scanning source code, it ties AI inventories to cloud identities and access patterns, mapping which agents have which permissions and which data they can reach.

CrowdStrike announced AI Runtime Protection and Shadow AI Discovery at RSA 2026, targeting detection of unsanctioned AI tools running on endpoints. SentinelOne and Snyk introduced competing tools focused on the development pipeline, scanning for model supply chain risks before deployment rather than in production, per BuildMVPFast's RSA coverage.

The architectures differ, but the convergence point is the same: enterprises need to see what is running before they can secure it.

The gap between experimentation and production

Cisco's own data underscores the timing. Across enterprise customers, 85% are experimenting with AI agents while only 5% have them in production. The bottleneck is not technical capability. It is governance, specifically the inability to answer basic questions that security and compliance teams require before signing off on production deployment.

Which models are these agents calling? What data do they have access to? Which MCP servers are they connecting to? What happens when a model is updated by a third-party provider? Does the agent's behavior change without anyone approving it?

Without an AI-BOM, those questions do not have answers. With one, they become auditable. That is the difference between an AI initiative stuck in a pilot and one that clears security review.

The strongest case for waiting

The tooling is immature. Cisco's fingerprint database covers 150 base models, which is a fraction of what exists on Hugging Face. MCP server scanning is nascent. Prompt inventorying is barely standardized. Adding another scanning pipeline to security teams already overwhelmed by the conventional software supply chain is a real operational cost.

All true. None of it changes the trajectory. The EU AI Act's supply chain transparency requirements go into effect in phases through 2027. US state-level AI governance bills are proliferating. Enterprise customers in regulated industries, financial services, healthcare, defense, are already asking vendors for AI provenance documentation in RFPs. Waiting for the tooling to mature means falling behind on compliance timelines that are already set.

What to do starting Monday

Run a shadow AI audit. Before evaluating any AI-BOM product, start with discovery. How many employees are using AI tools that IT did not provision? What data is flowing into those tools? Most organizations do not have a confident answer, and the number is almost always higher than leadership assumes.

Evaluate which scanning approach fits your stack. If your AI applications are primarily Python-based and containerized, Cisco's open-source scanner is the most direct starting point. It is free and ships today. If your primary concern is identity and access governance across cloud-deployed agents, Palo Alto's approach is closer to the problem. If you are focused on pre-deployment pipeline security, look at SentinelOne or Snyk.

Add AI asset inventory to your security review checklist. Any new AI deployment moving toward production should have a documented bill of materials: which models, which data sources, which external dependencies, which permissions. Make this a gate in your deployment pipeline now, before a regulator or client makes it one for you.

Start tracking MCP server dependencies. This is the newest and least-governed attack surface. Agentic workflows connecting to external MCP servers are creating dependency chains that look, from a security perspective, exactly like the third-party software supply chain risks that SBOMs were invented to manage. Cisco's MCP Catalog and scanner are the first tools to address this directly.

The 85% experimenting, 5% in production gap will close. When it does, the organizations that can enumerate and govern their AI assets will move to production. The ones that cannot will stay stuck in pilots, or worse, discover their exposure during an incident rather than an audit.