Black Hat 2026: Why AI software bills of materials are essential to AI trust

COMMENTARY: In the runup to Black Hat 2026, IT and security leaders have been weighing the recent Hugging Face-OpenAI security incident, in which an OpenAI model reportedly escaped its testing environment to perform an autonomous breach.

The rhetoric around the event has not been overblown: it's a disturbing development. But few commentators have addressed a particular weakness it exposes: the need for more ubiquitous AI software bills of materials (AI SBOMs) to speed responses to AI-related security events.

The origins of SBOM

The SBOM became common practice in the early 2020s, just before the launch of ChatGPT, largely in response to incidents like Log4Shell, which showed how hard it was to locate vulnerable components across complex enterprise environments. In 2021, President Biden issued an executive order requiring software vendors who sell to the federal government to offer an SBOM, making this a standard practice across much of the industry.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

It's a simple idea: SBOMs are an “ingredients list” for enterprise software, showing security teams which components, libraries, dependencies, and third-party code sit inside an application so they can see where they’re exposed when one ingredient becomes vulnerable.

With the advent of highly-advanced AI, the old software supply chain problem that an SBOM was designed to address has not gone away. In fact, it’s only become more complex as SaaS platforms, third-party services, open-source components, APIs, plugins, cloud infrastructure, and autonomous agents now operate together inside business-critical workflows.

That’s why the conversation about SBOMs needs to shift to address AI more directly.

Evolving the SBOM for AI

AI changes the inventory problem because an AI system isn’t only a model or an application. It’s the full operating stack: models, datasets, prompts, retrieval sources, APIs, plugins, identities, permissions, SaaS integrations, agentic workflows, data protection controls, and the enterprise data the system can consume or create. In an agentic environment, those dependencies can also take action across systems, sometimes with limited human review.

From a CISO’s perspective, that makes an AI SBOM less of a compliance "nice-to-have" and more of a practical control. We’re not just looking at whether models are safe or whether an application passed a review. We now have to question whether the organization can prove what’s inside the AI system, what it can reach, which data it depends on, what third parties or tools shape its behavior, and who’s accountable when something changes. 

The 2026 State of AI Report shows why this matters now. Nearly half of employees already rely on AI agents daily or weekly, yet 88.4% of organizations experienced at least one agent-related security incident in the past year. The report also found that 21.1% of organizations do not know whether employees are using unsanctioned tools to create AI agents.

These statistics send a clear message: organizations lack the visibility needed to use AI safely. For AI to work, this needs to change, and AI SBOMs are a part of that shift.

Operationalizing trust

For AI SBOMs to have some use to security teams, they must operate as living, machine-readable inventory of a full AI system. This includes its models, datasets, components, APIs, plugins, agent tools, permissions, owners, data sources, data protection requirements, and update cycles. We have to refresh all those components during development, procurement, deployment, and major model or workflow changes, not pulled together after an incident.

In a perfect world, AI SBOMs would become part of everyday security operations: buyers would request them from vendors, engineering teams would update them through CI/CD and MLOps pipelines, governance teams would map them to approved-use policies, and incident responders would use them to find affected systems when a model, dependency, cloud service, or SaaS integration becomes unsafe.

The Hugging Face-OpenAI incident shows why that matters: when an AI system behaves unexpectedly, teams need to quickly trace the models, tools, permissions, data sources, and hosted services involved.

However, this won’t happen through voluntary good intentions alone; organizations should start now because they own the risk, but government and industry pressure will likely determine how consistent adoption becomes. The federal government has already pushed SBOMs through procurement policy and guidance, and CISA’s 2026 AI SBOM minimum-elements guidance gives public and private organizations a practical foundation, even though it’s not a universal mandate.

At Black Hat 2026, we have an opportunity to push this conversation forward.

As SaaS supply chains, AI supply chains, and multi-tenant cloud environments converge, security leaders need proof of what their AI systems are made of, what those systems can access, and how quickly they can respond when a dependency becomes unsafe.

AI SBOMs won’t eliminate supply-chain risk, but they can make it manageable. It’s part of a broader project of AI trust that’s very much still in progress today.

Dana Simberkoff, chief risk, privacy, and information security officer, AvePoint

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.