In May 2025, Snyk launched an AI Bill of Materials (AI-BOM) capability inside its AI Trust Platform, aimed at a question most security teams can't yet answer about their own environment: how much AI is actually running in the codebase. A developer wires up a Hugging Face transformer during a weekend prototype, drops an OpenAI API key into a proof of concept, or lets an agent framework spin up autonomous tool calls — and none of it necessarily shows up in a traditional SBOM, because none of it necessarily touches a package manifest. Snyk's own research, drawn from analysis of more than 500 enterprise environments, claims that for every AI model an organization formally deploys, it unknowingly picks up nearly three times as many hidden components alongside it. This piece walks through, mechanically, how Snyk's AI-BOM finds that shadow AI: what it scans, what engine does the detection, how it handles MCP servers, and what a security team is supposed to do with the output.
What is Snyk AI-BOM, and what problem is it actually solving?
Snyk AI-BOM is an automated inventory feature, part of the AI Trust Platform Snyk announced on May 28, 2025, that produces a bill of materials for AI components the same way a software bill of materials (SBOM) does for open-source dependencies — except most of what it's looking for was never declared anywhere. It sits under what Snyk calls AI Security Posture Management (AI-SPM), a category built around the premise that AI adoption inside engineering orgs is happening faster than governance can track it. According to Snyk's February 2026 AI Security Fabric announcement, 82% of AI tools in the environments it analyzed were sourced from external packages, and the "nearly 3x hidden components per deployed model" figure comes from that same dataset. The framing isn't that developers are doing something malicious — it's that a model card reference, a locally cached embedding store, or a smol-ai agent scaffold accumulates the same way shadow IT always has: quietly, and outside the systems that were built to catch it.
How does AI-BOM find AI usage that isn't declared in any manifest?
It finds it by running static code analysis instead of manifest parsing, which is the mechanical detail that separates it from a standard software composition analysis (SCA) scan. Traditional SCA tools read requirements.txt, package.json, or a lockfile and match declared entries against vulnerability databases — which works fine until the AI usage in question was never declared, because someone ran pip install interactively or imported a client library without pinning it anywhere. Snyk AI-BOM is powered by Snyk's DeepCode engine, the same semantic analysis engine behind Snyk Code, applied here to recognize AI-specific patterns directly in source: a from transformers import statement, an OpenAI client instantiated with a gpt-4 model string, a smol-ai agent definition, or a dataset path referenced from a model card. Because the detection happens at the code level rather than the dependency-manifest level, it can surface AI usage "even when there's no clear manifest or package reference to guide the scan," in Snyk's own description — which is precisely the blind spot shadow AI exploits.
What actually counts as an AI component in the resulting inventory?
The inventory spans six categories that Snyk documents publicly: models and model APIs, training datasets, AI libraries and frameworks, agent frameworks, prompts and policies, and embeddings stores or vector databases, alongside the retrieval paths and runtime configuration that connect them. For each detected component, the report attaches version, license, supplier, and usage context — the same metadata fields a security or legal team would expect from an open-source SBOM. Output is generated in CycloneDX format, the same standard widely used for software SBOMs, specifically so the AI-BOM can be ingested by existing SBOM tooling, audit pipelines, and compliance workflows rather than requiring a parallel review process. That compatibility choice matters mechanically: it means an AI-BOM doesn't have to be a standalone artifact nobody looks at — it can flow into whatever process already consumes a CycloneDX SBOM today.
How does AI-BOM handle MCP servers and agentic tool chains?
Snyk extended AI-BOM to detect Model Context Protocol (MCP) usage on August 4, 2025, scanning for the standard Python mcp library's ClientSession, stdio_client, and streamablehttp_client calls, as well as integration libraries including pydantic-ai, openai-agents, langchain-mcp-adapters, and smolagents. From those signals it assembles a dependency graph running from the client through the MCP server down to the individual tools and resources being invoked — a chain that's otherwise invisible once an agent is calling out to a third-party server at runtime. Snyk frames the risk in concrete terms: hidden instructions embedded in a tool's description can exfiltrate data, a server can redefine its own instructions after an application has already trusted it, and MCP-connected tools can be scoped to read sensitive local files such as SSH keys or configuration secrets. The underlying argument is that every MCP connection exposes an AI application to untrusted inputs and outputs, no differently than an unvetted third-party package would — the AI-BOM just makes that exposure visible before it turns into an incident.
What can a security team actually do with an AI-BOM report?
A team runs it either through the snyk aibom CLI command against a single repository or through the API for org-wide, scaled scanning, and gets back a structured, human-readable CycloneDX report it can search and filter. Snyk's own documentation walks through an example query returning "45 total targets in the organization," narrowed to 8 matching a keyword search — illustrating the intended workflow: point AI-BOM at every repo in the org, then filter for a specific provider (say, "openai" or "anthropic") to find every place that provider shows up, sanctioned or not. From there, the stated use cases are license auditing, tracking known vulnerabilities in AI libraries the same way SCA tools track them in open-source packages, monitoring API usage and cost exposure across LLM providers, and planning migrations off a model or vendor. Worth noting: as of its current documentation, Snyk flags the CLI feature as experimental and "subject to breaking changes without notice," which is a reasonable caveat for a capability still expanding its detection coverage.
How Safeguard Helps
The mechanism Snyk's AI-BOM demonstrates — finding software components through code-level analysis rather than trusting a declared manifest — is the same principle Safeguard applies across the software supply chain more broadly, not just for AI. Shadow AI is really a specific instance of a general problem: any component that enters a codebase without going through a declared, reviewed path is a component your provenance and policy controls can't see. Safeguard's approach is to treat AI models, agent frameworks, and MCP connections as first-class supply chain artifacts alongside open-source packages and container images — subject to the same attestation, policy gates, and CI/CD enforcement rather than a separate, bolted-on review process. For teams evaluating tools like AI-BOM, the practical takeaway is to ask whether an AI inventory is a one-time report or a continuously enforced gate: visibility into shadow AI is only as useful as the workflow that acts on it before an undeclared model or an untrusted MCP server ships to production.