A CycloneDX JSON file listing forty AI models, six datasets, and a dozen MCP servers is technically complete and practically unreadable. Security engineers scanning a repo for shadow AI usage do not want to grep nested arrays for bom-ref values — they want to see, at a glance, which application talks to which MCP server, and which tools that server can invoke on the model's behalf. Snyk's answer, shipped as part of the snyk aibom CLI command, is a single flag: --html. Instead of (or alongside) the standard CycloneDX v1.6 JSON output, it renders the same inventory as an interactive diagram of models, agents, tools, and MCP dependency chains. This piece walks through what the flag actually does, what it requires, what it draws, and where it currently falls short — based only on Snyk's published documentation, not speculation about internal rendering code.
What does the snyk aibom --html flag actually do?
It embeds the AI-BOM's components and relationships into a self-contained HTML file instead of leaving them as raw JSON. The documented command is:
snyk aibom --org=<ORG_ID> --html > ai_bom.html
Running it against a scanned project produces a file you open directly in a browser, showing an interactive node-link view of everything the CycloneDX-format scan found: foundation and open-source models, AI-specific libraries, agent frameworks, and Model Context Protocol (MCP) endpoints. Snyk's own worked examples — run against the GroundingDINO and OpenHands open-source repositories — show the visualization surfacing model names (BERT variants, ResNet architectures, entries from the Claude, GPT, and Gemini families), library dependencies (PyTorch, Transformers, TIMM, Gradio, vLLM), and dataset references (BookCorpus, Wikipedia) pulled from code-level evidence rather than manifest metadata alone. Without --html, snyk aibom prints or saves the identical data as CycloneDX v1.6 JSON — the flag changes presentation, not detection.
Why does an AI-BOM need a graph view instead of a flat list?
Because the dependency that matters most in an AI stack — the chain from an application to an MCP client to an MCP server to the specific tools and resources that server exposes — is inherently relational, not tabular. A JSON array can list "mcp-server: filesystem-server" and "tool: write_file" as siblings, but it takes a human reading closely to realize the second is reachable through the first, and that the application in question can therefore write to disk through a dependency it may not have vetted. Snyk's documentation describes the HTML output as illustrating exactly this: dependency chains that show application → MCP client → MCP server → tool relationships, plus the broader graph of models, agents, and datasets tied to each component. This category of risk is why MCP visibility was added to aibom as what Snyk calls a new layer in the AI supply chain — one that traditional SBOM tooling, built around package managers and container layers, was never designed to represent as a graph.
What do you need installed before you can use it?
Snyk CLI version 1.1298.3 or later, plus an active internet connection, since aibom calls out to Snyk's backend rather than running as a fully offline scan. The command supports Python, Java, JavaScript, and Go projects. One flag's requirements shifted recently: --experimental was required to unlock aibom in earlier CLI builds but was marked deprecated as of CLI v1.1304.0, meaning current versions expose the command without it. If you're following an older blog post or internal runbook that still shows snyk aibom --experimental --org=<ID> --html, it will likely still work during the deprecation window, but new documentation omits the flag. Teams standardizing scan scripts in CI should pin a CLI version and check Snyk's changelog before assuming flag behavior is stable, since this is an actively evolving, explicitly experimental feature rather than a long-frozen interface.
How does the HTML output connect to Snyk's hosted view?
It doesn't have to — the file is a standalone artifact, but Snyk also offers a persistence path that lands the same data in its hosted UI. Running snyk aibom --upload --repo https://github.com/<owner>/<repo> (alongside --org) pushes the generated AI-BOM into your Snyk Organization, where it becomes viewable per-repository inside what Snyk refers to as its Evo web interface. That upload path is separate from --html: you can generate a local visualization file without ever touching your Snyk org's hosted inventory, or you can persist the scan centrally and view it there instead of opening a local file. Teams evaluating the tool for CI pipelines should note this distinction, because --html alone produces something you have to distribute yourself (email, artifact storage, static hosting), while --upload --repo produces something colleagues can pull up in a browser without you sending them a file at all. A separate --json-file-output flag, available from CLI v1.1303.0 onward, writes the JSON to a named file path rather than relying on shell redirection — useful if --html output is also being generated in the same run.
What happens when the scan finds nothing, or fails?
The CLI returns one of three documented exit codes: 0 for success, 2 for a failure you should retry with the -d debug flag, and 3 specifically when no supported files are found in the target directory. That last code matters for CI gating — a pipeline that treats any non-zero exit as a hard failure will block on repos that simply have no Python, Java, JavaScript, or Go AI dependencies to scan, which is a different situation than a scan that errored out partway through. Since --html and --upload sit on top of the same underlying scan, an exit code 3 means neither a visualization file nor an uploaded record gets produced — there is nothing to render a graph from. Anyone scripting aibom --html into an existing SBOM pipeline should branch on exit code before treating a missing HTML file as a bug in the visualization step itself.
Does the HTML flag replace the need for a CycloneDX SBOM?
No — it's an alternate rendering of the same CycloneDX v1.6 data, not a separate format standing in for it. Everything the graph draws (models, agents, tools, MCP servers, datasets) is sourced from the identical scan that produces the JSON, so organizations that consume SBOMs downstream — compliance tooling, vulnerability databases, procurement questionnaires — still need the JSON export, since CycloneDX is the interchange format those systems parse. The HTML file is built for a human sitting at a browser during triage or an architecture review, not for a pipeline stage that ingests machine-readable output. In practice that means most teams will want both: --json-file-output for the artifact that feeds automated checks, and --html for the artifact that gets pulled up when someone asks "wait, what can this AI agent actually reach?"
How Safeguard Helps
Reading a vendor's AI-BOM output — whether it's a CycloneDX file, an HTML graph, or a hosted dashboard entry — answers "what AI components exist here" but not "should any of them be there, and what changed since last week." Safeguard treats AI dependencies, MCP integrations, and agent tool-calling permissions as first-class entries in a continuously monitored software supply chain, correlating what a scanner like aibom discovers with build provenance, commit history, and policy rules that flag newly introduced MCP servers or tool permissions before they reach production. Rather than requiring engineers to periodically regenerate and eyeball a static HTML file, Safeguard's platform keeps that inventory current automatically and raises an alert the moment an agent's reachable tool set expands — turning a point-in-time visualization into an ongoing control.