Skip to main content
CybersecurityInfrastructure

AI-BOMs Tackle Shadow AI Risks in Enterprise Supply Chains

Industrial supply chain setting with traditional and modern tech, featuring a partially disassembled machine.

"You don't know the recipe, you don't know the ingredients, you don't know the baker. Would you eat a slice of that cake?" Ian Swanson, vice president of AI security at Palo Alto Networks, asked in an interview with The Register.

Why traditional SBOMs no longer capture the AI stack, per Ian Swanson

Swanson and others in the field say a conventional software bill of materials (SBOM) — which inventories packages and dependencies — misses the new layers introduced by AI. The term gaining traction is the "AI-BOM," defined to include models, datasets, SDK libraries, MCP servers, machine‑learning frameworks, agents, agentic skills, prompts and other AI tools, plus the relationships among them. Swanson summed the operational risk: "If you don't have visibility of these workloads, then you can't really understand what it is to protect."

Cisco's open-source AI-BOM and Model Provenance Kit

Cisco has publicly released an AI-BOM implementation to scan codebases, container images and cloud environments, and on Friday made available a Model Provenance Kit intended to trace model lineage. Cisco researchers described the provenance tool as a "DNA test for AI models" and said it runs in two modes:

  • Compare mode — compares two models across metadata, tokenizer structure and weight-level signals to produce a similarity score.
  • Scan mode — matches a single model against a database to identify closest lineage candidates; Cisco published a model fingerprint database covering about 150 base models across more than 45 families and over 20 publishers to support this.

Amy Chang, Cisco's head of AI threat intelligence and security research, described two gate checks used by the kit: first, metadata-level comparisons linking base and fine‑tuned models; second, weight‑based signifiers to provide a verifiable attestation that deployed models are the ones expected and within an organisation's risk tolerance.

Chang pointed to a public example: Cursor's Composer 2, which she said is partly built on Kimi 2.5, a Chinese open source model. "They were very quick to admit that, yes, we used the Chinese model to build this," she told The Register, adding that such provenance can carry "regulatory or compliance risk." The piece notes the European Union's AI Act mandates documentation of training data, training methodology characteristics and risk assessments for "high‑risk systems."

Wiz: extending BOMs to developer tools and non-human identities

Ziad Ghalleb, technical product marketing manager at Wiz, told The Register that Wiz's AI‑BOM approach reaches beyond final artifacts to include the AI tools used during development — for example, a developer's laptop or integrated development environment. He also stressed the importance of identity: agents, models and tools are tied to non‑human identities inside an environment, and those identities and permission sets must be inventoried alongside resources.

Active threats: model/skills poisoning, agentic reconnaissance, and poisoned packages

The Register's reporting links AI‑centric visibility gaps to a set of active threats. Sherrod DeGrippo, Microsoft's general manager of global threat intelligence, warned that criminals use AI to automate reconnaissance, manage attack infrastructure and "come back to me with everything you've seen" on targeted networks. Swanson described a Palo Alto Networks incident in which attackers obtained system prompts for an internal AI workload, modified those prompts to force data theft, and sent sensitive information to an external email account.

Supply chain attacks that affect AI are already practical: Swanson and others noted model and skills poisoning, manipulation of coding assistant skills, and the need to detect when a skill that should provide a weather forecast instead exfiltrates credentials. The article cites recent poisoned npm and PyPI packages and earlier Shai‑Hulud worm credential‑stealer campaigns as examples of compromised open‑source code commonly integrated into AI applications.

Ghalleb highlighted a operational benefit: even where no CVE exists, an AI‑BOM enables queries for "related libraries or packages" so teams can identify and remove malicious versions to contain evolving threats.

What this means for security teams, regulators, and enterprises

  • Security teams and technologists — Need to build AI‑BOMs that scan artifacts continuously, detect state changes (including system prompt modifications), and monitor runtime communications to spot manipulated models or agent behavior.
  • Regulators and compliance officers — Provenance tooling and model fingerprints can provide the documentation and attestations referenced in regulatory frameworks like the European Union's AI Act.
  • Enterprises and procurement leaders — Must account for "shadow AI" — unsanctioned platforms, agents and external chatbots that employees run — and include developer workstations and non‑human identities in inventories to assess permissions and risk.

Absent a comprehensive inventory of AI ingredients, defenders risk discovering malicious changes only after damage occurs. The advocates quoted in The Register argue that AI‑BOMs, provenance kits and continuous scanning create the visibility needed to detect tampering and contain supply‑chain compromises — but the practical task remains large: uncovering shadow AI, tracking model lineage across hundreds of base models, and monitoring runtime state for changes that signal abuse.

https://go.theregister.com/feed/www.theregister.com/2026/05/04/ai_bom_supply_chain/