If your organization has adopted large language models, embedding pipelines, or fine-tuned checkpoints anywhere in production, you likely already have an AI inventory problem you can't see. Security teams can no longer answer "which models are we running, where did they come from, and what's their license exposure" with a spreadsheet. Snyk's answer is an AI-BOM (AI Bill of Materials) API: a programmatic interface that lets teams enumerate models, datasets, and AI-related dependencies the same way they'd query a software bill of materials. Instead of manually clicking through a dashboard project by project, engineering and security teams can pull structured AI component data into CI pipelines, GRC tooling, or internal asset databases on a schedule. This post walks through how that API is built, what it exposes, and how the query model works mechanically — based on Snyk's publicly documented approach — without treating it as a competitive shootout.
What Is Snyk's AI-BOM API and What Problem Does It Solve?
Snyk's AI-BOM API solves the discovery gap created when AI components enter a codebase through means traditional SBOM tooling doesn't track well — model files pulled from Hugging Face, prompt templates, vector store configs, and fine-tuning datasets referenced in notebooks or IaC. Traditional SBOM generation, built around package managers like npm, PyPI, and Maven, was designed for dependency graphs where every artifact has a name, version, and registry. AI models don't fit that shape cleanly: a checkpoint might be referenced by a Hugging Face repo ID and commit hash rather than a semantic version, and a dataset might be a URL to cloud storage rather than a package. Snyk extended its bill-of-materials tooling to capture these AI-specific artifacts as a distinct component type, then exposed that inventory through the same REST API infrastructure Snyk already uses for SBOM export. The practical result: a security team managing hundreds of repositories can ask "which of our projects reference a model from an unverified source" as an API call rather than a manual audit.
How Does the API Represent AI Components Programmatically?
The API represents each AI component as a structured record with fields for artifact identity, source origin, and relationship to the enclosing project — mirroring how CycloneDX represents software components in a standard SBOM. Snyk has aligned its AI-BOM output with CycloneDX's machine-learning bill-of-materials (ML-BOM) extension, part of the CycloneDX 1.5/1.6 specification maintained by OWASP, rather than inventing a proprietary schema. That matters for programmatic queries because it means the JSON returned by the API maps onto fields the industry already has tooling for: component type (model, dataset, or library), supplier, version or commit reference, and declared license. When a team queries the API for a given project, they get back a component list where each AI artifact carries the same kind of metadata a package dependency would — but with additional attributes relevant to models, such as the training data lineage or model card reference where one is declared. This is what allows the output to be piped into a GRC system or a custom risk-scoring script without a translation layer.
What Can Teams Actually Query Once They Have API Access?
Teams can query AI component inventories at the organization, group, or individual project level, then filter results down to the fields they care about — source registry, license type, or component name. Because Snyk's platform already scopes SBOM and vulnerability data by org and project IDs, the AI-BOM endpoints follow the same scoping model: a request against a single project ID returns that project's AI components, while a request scoped to an org aggregates across every project the API token has visibility into. In practice this supports two common workflows. First, a point-in-time pull — "give me every model referenced across our 40 microservices right now" — useful for an audit or a compliance attestation. Second, a scheduled pull run nightly or on every merge to main, which lets a security team diff today's inventory against yesterday's and flag when a new, previously unseen model dependency shows up in a pull request. Both workflows only work because the data is exposed as an API rather than locked inside a dashboard view.
How Does Authentication and Access Control Work?
Access to the AI-BOM API is governed the same way as the rest of Snyk's REST API: scoped API tokens tied to a user or service account, with permissions inherited from the org and group role the token belongs to. Snyk's REST API uses a date-versioned scheme (requests specify an API version like a YYYY-MM-DD string) and returns responses in JSON:API format, with cursor-based pagination for endpoints that can return large result sets — a pattern documented in Snyk's public API reference and consistent across its SBOM, issues, and project endpoints. For a team automating AI-BOM pulls, this means the integration work looks identical to any other Snyk API integration already in place: generate a service account token scoped to the orgs you need visibility into, respect the pagination cursor when iterating over large component lists, and handle standard rate-limit responses with backoff. There's no separate authentication mechanism to build just for AI inventory data, which is part of why teams already using Snyk for SBOM or vulnerability data can extend into AI-BOM queries with comparatively little new integration code.
Why Does Exporting to CycloneDX Format Matter for Downstream Tooling?
Exporting AI-BOM data in CycloneDX format matters because it lets the output flow into the same downstream tools organizations already use for software supply chain risk management, rather than requiring bespoke AI-specific consumers. CycloneDX has become a de facto standard for machine-readable bills of materials, with parsers and validators available across the open-source ecosystem and support from bodies like OWASP and NTIA guidance on SBOM minimum elements. By emitting AI-BOM data as CycloneDX JSON (with the ML-BOM extension fields populated where applicable), a query result from Snyk's API can be dropped directly into a CycloneDX-compatible vulnerability correlation tool, an internal asset inventory, or an SBOM aggregation pipeline without a custom parser. For compliance teams tracking toward frameworks that increasingly expect AI component transparency — including emerging expectations tied to the EU AI Act's documentation requirements and U.S. federal guidance on AI risk management — having AI inventory data already in a standard, exportable format shortens the path from "we have the data" to "we can produce the artifact an auditor asked for."
What Are the Practical Limits Teams Should Plan Around?
The practical limit teams should plan around is that AI-BOM completeness depends on how discoverable a model reference is in source code, configuration, or infrastructure definitions — the API can only enumerate what Snyk's scanning has been able to detect and classify as an AI component. A model pulled via a well-known SDK call (such as a Hugging Face from_pretrained reference or a documented API client) is far easier to identify reliably than a model referenced through a custom internal wrapper, a hardcoded S3 path, or a runtime-only configuration value injected outside the repository Snyk scans. This is the same class of limitation that affects any static-analysis-driven SBOM: coverage is a function of what the scanner can see in the codebase at scan time, not a guarantee of every artifact loaded at runtime. Teams building automation on top of the AI-BOM API should treat query results as a strong starting inventory to reconcile against runtime observability, rather than as an exhaustive ground truth on day one.
How Safeguard Helps
Programmatic AI-BOM access is a meaningful step toward AI supply chain visibility, and the pattern Snyk has built — CycloneDX-aligned output, standard REST authentication, org-scoped queries — reflects where the broader industry is heading on software and AI transparency. Safeguard approaches this same problem from the software supply chain security side: continuously monitoring dependencies, build pipelines, and artifact provenance so that when a new component — AI-related or otherwise — enters your environment, it's flagged against your organization's risk policy in near real time rather than surfaced only at the next scheduled inventory pull. For teams that are already generating AI-BOM data through tools like Snyk, Safeguard focuses on the layer above raw inventory: correlating component-level signals with build integrity, SCM activity, and deployment context to help security teams prioritize what actually needs attention. If your team is investing in AI-BOM tooling as part of a broader supply chain security program, Safeguard is built to sit alongside that data and turn it into actionable, continuously monitored risk signal.