Shadow AI has become a real headache for companies.
While teams adopt artificial intelligence tools without going through IT or security review, the model inventory grows in the shadows — with no control, no tracking, and often without anyone knowing exactly what is running in corporate environments. Developers connect APIs from external models, analysts use AI platforms without formal approval, and entire teams operate with tools that never went through any kind of risk assessment process. The result is a parallel AI ecosystem inside organizations, invisible to the people who should be managing security.
This scenario has put the traditional SBOM in check — that machine-readable inventory that maps out components, libraries, and software modules. For years, the SBOM worked really well as a transparency tool for development environments, allowing security teams to know exactly what was present in each system. It works great for code. But AI is not just code. Models change with prompts, datasets, fine-tuning, and agent permissions, and this creates a layer of complexity the SBOM simply was not designed to cover.
That is where the AI-BOM comes in — the AI Bill of Materials — which extends that logic to cover everything that makes up and influences an artificial intelligence system, from models and datasets to agents, cloud infrastructure, and identities. And this is not just theory. Companies like Cisco, Wiz, and Palo Alto Networks are already building concrete tools for this, while initiatives like the EU AI Act, NIST, and OWASP are pushing for clearer documentation and security standards in AI. The market is moving fast, but standards are still taking shape. 🚀
Why Shadow AI is such a serious problem today
The speed at which AI tools hit the market over the past two years created an adoption window that ran right over practically every traditional corporate governance process. Platforms like ChatGPT, Copilot, Gemini, and dozens of other specialized solutions are available to anyone with a credit card and internet access, which means an employee can start using a language model to process sensitive company data without the IT department even knowing it is happening. This dynamic created what the industry calls Shadow AI — a set of tools, models, and integrations operating outside institutional visibility and control.
The problem goes way beyond a compliance issue or violated internal policies. When a team uses an external model to process contracts, customer data, or financial information, that data can be used to train future models, can end up stored on third-party servers, or can be exposed in the event of a security breach at the provider. Without a structured model inventory, the company has no way of knowing which data went where, which models had access to which systems, and what risks were introduced over time. It is like trying to run a security audit without knowing what is installed on the company computers.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The situation gets even more complicated with the rise of AI agents — systems that do not just answer questions but take autonomous actions, access APIs, execute code, and interact with other systems. A misconfigured or undocumented AI agent can have excessive permissions, can connect to critical systems, and can generate consequences far beyond what any individual user could cause. Shadow AI in this context is no longer just a visibility issue — it is a matter of a real and growing attack surface inside organizations. 🔐
What is the AI-BOM and how it solves the model inventory problem
The AI-BOM concept starts from a simple premise: if you do not know what you have, you cannot protect it. Just as the SBOM maps software dependencies to ensure known vulnerabilities can be identified and patched quickly, the AI Bill of Materials does the same for the components that make up an artificial intelligence system. This includes the base model being used, the training and fine-tuning datasets, the system prompts, the connected tools and APIs, the identities and permissions of agents, and the cloud infrastructure where everything runs. It is a complete snapshot of everything that touches the AI system — not just the code.
In practice, a well-structured AI-BOM lets security teams ask questions that were previously impossible to answer with any precision. What version of the model is in production? Was this model trained on data that includes proprietary company information? Which agents have access to which systems? If a vulnerability is discovered in a specific model, how many internal systems depend on it? These answers are critical for any incident response and for any risk assessment process involving AI. Without this inventory, the company is operating in the dark — and in the dark, any surprise tends to be an unpleasant one.
IBM describes the SBOM as a machine-readable list of components, libraries, and modules in a software product. The AI-BOM builds on top of that idea, but the AI system being tracked is not just code. Wiz defines the AI-BOM as an inventory of models, training datasets, software dependencies, infrastructure, and related components that shape the system behavior. Documenting all of this in a traceable, auditable way is exactly what the AI-BOM proposes — creating a chain of accountability and visibility that the traditional SBOM simply cannot cover because it was designed for a world where software was static and deterministic.
The tools leading the charge
Cisco open-sourced an AI-BOM scanner that analyzes codebases, container images, and cloud environments to produce a structured inventory of models, agents, tools, servers and MCP clients, datasets, prompts, guardrails, secrets, and other AI assets. The GitHub project supports Python, JavaScript, TypeScript, Java, Go, Rust, Ruby, and C#, and generates reports in formats like JSON, CycloneDX, SARIF, SPDX, HTML, Markdown, and CSV. This scope is much broader than a conventional SBOM, precisely because what needs to be tracked in AI goes far beyond code.
Palo Alto Networks describes the AI-BOM as a machine-readable inventory covering every dataset, model, and software component used to build and operate an AI system, with records of versions, sources, and relationships. The company also states that the AI-BOM supports model lineage, data provenance, and compliance evidence generation. This is an important point because AI systems, unlike conventional software, change through prompts, datasets, fine-tuning, agent permissions, and external model dependencies — expanding everything companies need to keep track of.
Tracking provenance and regulatory risk
Cisco is also targeting the provenance side with its Model Provenance Kit, which compares two models through metadata, tokenizer structure, and weight-level signals, or scans a model against a fingerprint database. The company reported that the initial database covers around 150 base models, spread across more than 45 families and over 20 publishers. The tool has been linked to risks related to repackaged models, licensing, regulatory exposure, and supply chain integrity. In many cases, organizations simply do not know whether a model was trained from scratch, copied, modified, or derived from another model.
On the regulatory side, the EU AI Act already establishes documentation and transparency requirements for high-risk AI systems that, in practice, point directly to the need for something like the AI-BOM. NIST published its AI Risk Management Framework with guidelines that include inventory and traceability of AI components, and OWASP has been developing specific resources for security in applications that use LLMs, including recommendations on model documentation and access control. This combination of regulatory pressures and reference frameworks is accelerating the adoption of more structured AI governance practices in organizations, especially those operating in regulated industries.
Connecting identity and cloud infrastructure
Wiz contributes the cloud context surrounding this record. The company guidance says that a useful inventory maps AI systems to data, identities, infrastructure, and owners — rather than stopping at model names. Wiz also states that a modern AI inventory needs to update continuously, because AI systems emerge, change, and get decommissioned rapidly. This identity layer is becoming central to AI governance, requiring Shadow AI discovery, configuration checks, and identity permission mapping tied to each workload.
Google Cloud incorporated this idea into its partnership with Wiz. The company stated that the dynamic AI-BOM from Wiz inventories AI models, AI development tools, and IDE extensions, helping organizations track approved tools like Gemini Code Assist and GitHub Copilot while also discovering unapproved Shadow AI plugins. Meanwhile, Palo Alto Networks is tackling the same problem from the runtime security side with Prisma AIRS 3.0, which discovers agents, models, and AI connections across cloud environments, SaaS platforms, and local endpoints.
A real-world example shows why this is no longer theoretical. According to Ian Swanson, VP of AI Security Products at Palo Alto Networks, an incident involved attackers using AI for reconnaissance, gaining access to the system prompts of an internal AI workload, and modifying those prompts to steal data and send it to an external email account. Swanson argued that an AI-BOM could help defenders compare the system prompt used at one point in time with an altered state later on, quickly revealing the manipulation.
Sora and the challenge of tracking cutting-edge models
Sora is a perfect example of why model inventory needs to evolve. OpenAI video generation model represents a new category of AI systems that combine multiple modalities, process complex inputs, and generate outputs that can be used in highly varied ways. When a company integrates Sora into a content production workflow, for instance, it is introducing a component with very specific behavioral characteristics, limitations, and risks that need to be documented with the same seriousness as any other critical software dependency. The problem is that most existing security tools were not built to track this kind of component.
Access to Sora via API also raises important questions about corporate usage control. If a marketing team starts using the model to generate campaign videos without the legal department reviewing the terms of service, without IT knowing what data is being sent to the API, and without security evaluating the intellectual property risks involved — that is Shadow AI in action. And the AI-BOM would be exactly the mechanism to ensure that adoption is recorded, assessed, and monitored on an ongoing basis — not just at the initial integration moment, but throughout the entire lifecycle of the model usage within the organization.
Multimodal models like Sora also introduce risks that go beyond traditional data privacy concerns. The ability to generate realistic visual content from text instructions creates risk surfaces related to misinformation creation, improper representation of brands and people, and unauthorized use of visual assets. A robust model inventory needs to capture not only where the model is being used but how it is being used — with what permissions, for what purposes, and with what output controls active. That level of granularity is what separates an effective AI-BOM from a simple list of approved tools.
Moving toward industry-wide standards
The standards layer is still not fully defined. The OWASP AIBOM Generator produces AI bills of materials for Hugging Face models in CycloneDX format aligned with SPDX, and the OWASP GenAI Security Project says its AIBOM initiative aims to turn the concept into open tools, completeness checks, and practical guidance for practitioners. In parallel, there is an SBOM for AI Tiger Team, facilitated by CISA but not adopted as official U.S. government policy, which has published use cases for compliance, incident management, open-source model risk, third-party AI risk, intellectual property, and model lifecycle management.
As AI agents become more common and more autonomous, the pressure for model inventory will increase proportionally. An environment with dozens of agents operating in parallel — each with its own connections, permissions, and behaviors — is an environment that simply cannot be managed manually. Automated discovery and continuous mapping tools for AI components will become as essential as vulnerability scanners are today, and companies that start building this capability now will have a significant advantage when regulatory requirements become more specific and more demanding.
The good news is that the path to implementing an effective model inventory does not have to start from scratch. Organizations that already have mature SBOM management processes can extend those processes to cover AI components, adding the specific dimensions that models require. The main challenge is cultural and organizational: convincing product, engineering, and business teams that declaring AI tool usage is not red tape — it is protection. When an incident happens and the company needs to respond quickly, having an updated and reliable AI-BOM can be the difference between a coordinated, effective response and weeks of investigation trying to figure out what was running where. The AI-BOM is no longer just an interesting idea for the future. It is an operational necessity for any organization that takes the security of its artificial intelligence environments seriously today. 🎯
