A developer adds three lines of code calling the OpenAI API, wires up an MCP server to give an agent filesystem access, and pulls a fine-tuned model off Hugging Face — none of it touches package.json, requirements.txt, or any other manifest a traditional SCA scanner reads. That's the blind spot Snyk built AI-BOM to close. Announced through Snyk Labs and shipped as a CLI command (snyk aibom, minimum CLI v1.1298.3), the tool scans source code directly, using the same DeepCode static analysis engine behind Snyk Code, to build a CycloneDX v1.6 inventory of every model, dataset, agent, tool, and MCP server it finds. This piece walks through the publicly documented mechanics of how that discovery actually works — what it looks for in code, which frameworks it recognizes, how it reconstructs MCP dependency chains, and where the approach still depends on pattern recognition rather than runtime observation.
What Problem Is AI-BOM Actually Solving?
Snyk built AI-BOM because a single API call can introduce a powerful, unvetted model without ever appearing in a dependency manifest. A line like openai.ChatCompletion.create(model="gpt-4") has no package installation, no lockfile entry, and no version pin that a conventional software composition analysis (SCA) tool would flag — it's just a string inside a function call. Traditional SBOM tooling was built to parse package manifests and lockfiles, so it has nothing to latch onto. Snyk's own materials describe this as the reason SCA tools "often miss" AI dependencies: the risk isn't a vulnerable library, it's an entire foundation model, dataset, or third-party tool integration hiding in plain application logic. AI-BOM's answer is to treat the source code itself, not the manifest, as the primary source of truth, applying the same code-scanning approach Snyk uses to find security bugs to the separate problem of finding AI components.
How Does DeepCode Find AI Components Without a Manifest?
DeepCode finds AI components by recognizing code patterns associated with known AI libraries and API calls, rather than by resolving declared dependencies. Because the engine already performs semantic analysis of source code for vulnerability detection, Snyk extended it to recognize a second category of signal: imports, client instantiations, and API call shapes that match known AI SDKs. Publicly described examples include detecting Hugging Face transformers usage, OpenAI API calls referencing models like GPT-4, and agent frameworks such as smol-ai. The output captures not just that a model is used, but metadata around it — version, license, supplier, and usage context — assembled into a structured, human-readable report. This is fundamentally a static-analysis exercise: the scanner reads code paths and matches them against a catalog of recognized libraries and call patterns, which is also why coverage is currently concentrated on four ecosystems — Python, Java, JavaScript, and Go — rather than being language-agnostic.
How Does It Reconstruct an MCP Chain From Client to Tool?
Snyk AI-BOM reconstructs an MCP chain by parsing the client-side connection code and following it through to the servers and tools it exposes. The Model Context Protocol has become a common way to wire agents to external tools, and Snyk's documentation walks through a concrete example: code that builds a StdioServerParameters object pointing at a local script (args=["/path/to/your/math_server.py"]) is recognized as an MCP client instantiation, and that script path is captured as a dependency of the client. The scanner recognizes this pattern across several libraries beyond the official mcp Python SDK, including pydantic-ai, openai-agents, langchain-mcp-adapters, and smolagents. Where the client code calls introspection methods like session.list_tools(), AI-BOM extends the chain one hop further, recording the individual tools a server exposes. The resulting CycloneDX graph expresses this as a literal dependency chain — root application depends on the MCP client, the MCP client depends on the MCP server, and the MCP server depends on (provides) each tool, for example tool:add. Snyk added this MCP-specific detection as a named capability on top of the original AI-BOM release, reflecting how much agent tooling now routes through MCP rather than direct API calls.
What Does the Output Actually Look Like?
The output is a CycloneDX v1.6 JSON document, optionally rendered as an HTML visualization with the --html flag. Running snyk aibom against a local project produces a spec-compliant AI-BOM covering four component categories: models (foundational models like GPT-4 alongside open-source models like Llama-4, each with model-card and license data where available), agents (flagged by matching known agent-library patterns), tools (flagged by matching common tool-calling patterns), and MCPs (detected via the official MCP SDK "and other popular ways of building MCPs," per Snyk's documentation). Results can be written to a file with --json-file-output (available from CLI v1.1303.0) or pushed into a Snyk Organization with --upload and --repo for centralized tracking. The command returns exit code 0 on success, 2 on failure, and 3 when no supported files are found in the target directory — a useful signal that a repo simply doesn't contain code the scanner recognizes, as distinct from a scan actually failing.
How Does Snyk Find Shadow AI Across an Entire Organization?
Snyk finds shadow AI at the organization level by running AI-BOM generation across every connected repository and then keyword-searching the aggregated results, rather than requiring anyone to scan individual projects by hand. This capability, made available on August 4, 2025, works through a five-step sequence: authenticate against the Snyk organization, page through the full list of connected repositories via the API, kick off AI-BOM generation for each one, poll asynchronously until each job completes, and then run a case-insensitive, partial-match keyword search across the combined output. Container images and manually uploaded artifacts are skipped, since AI-BOMs are generated from source, and the initial platform support covers GitHub and GitLab. In a published usage example, a search for the terms "deepseek, openai, anthropic" across an organization with 45 target repositories surfaced 8 repositories using one of those providers — the kind of result meant to catch a team that adopted a model or API without going through a review process. This is the mechanism Snyk frames as the entry point into AI Security Posture Management (AI-SPM): inventory and visibility first, then risk scoring against a Model Risk Database and OWASP's LLM Top 10, then policy enforcement to block unapproved models.
What Are the Practical Limits of Static Discovery?
The practical limit is that AI-BOM discovers what's written in source code, not what's actually running in production, so it can miss models, agents, or tools that are configured dynamically, injected at deploy time, or introduced through infrastructure outside the scanned repositories. Snyk's own materials note the tool can surface models "deployed dynamically via agents or MCP servers, even if they never enter the code repository" in some cases, but pattern-based detection is inherently bounded by the list of libraries, SDKs, and call shapes it has been taught to recognize — a bespoke internal agent framework, a private model-serving wrapper, or a tool integration built without any of the named libraries won't match a signature the scanner knows about. The four-language coverage (Python, Java, JavaScript, Go) also means organizations running AI workloads in other languages currently sit outside the scan surface entirely. None of this is unique to Snyk; it's the standard tradeoff of static, pattern-based inventory tools versus runtime observability, and it's worth factoring into how much weight a single AI-BOM scan should carry as a completeness guarantee versus a strong starting inventory.
How Safeguard Helps
Understanding how a static AI-BOM scanner reasons about your codebase — what it can see, what it infers from patterns, and where the edges of that inference sit — is directly useful when you're deciding how to build out AI supply chain visibility for your own organization. Safeguard approaches software supply chain security with the same principle AI-BOM tooling is built on: you can't secure what you haven't inventoried, and an inventory built purely from declared dependencies will always miss the components introduced through code-level integrations, embedded API calls, and agent-to-tool wiring that never touch a manifest. Safeguard's platform extends this thinking across the broader software supply chain, correlating what's declared against what's actually present in source and build artifacts, so that AI components, third-party tools, and their provenance are tracked alongside the rest of your dependency graph rather than in a separate silo. For teams evaluating AI-BOM tooling generally, the mechanics above are a useful checklist: ask any vendor which languages and frameworks their detection actually covers, whether MCP chains are traced to the tool level or only to the server, and how gaps between static discovery and runtime reality get reconciled over time.