Agent BOM

You wouldn’t deploy a container without knowing what’s inside it. Why deploy an AI agent without knowing what tools, models, and dependencies it carries?

Most agent stacks have no inventory. Tools are installed from community sources, model references are scattered across config files, and dependencies accumulate over time. When a tool gets flagged as malicious, there’s no fast way to know which deployments are affected.

SOC 2 auditors and AI Act regulators are starting to ask: what’s in your agent stack? The Agent BOM is your answer.

What is an Agent BOM?

A Bill of Materials (BOM) is an inventory document. In software, a Software Bill of Materials (SBOM) lists every package a piece of software depends on. An Agent BOM extends this concept to AI agent stacks: it lists not just software packages, but also the tools, skills, plugins, servers, and models that make up the agent system.

Firmis generates Agent BOMs following the CycloneDX 1.7 specification, a widely adopted open standard for SBOM interchange. Because it’s standard CycloneDX, it integrates directly with existing compliance tooling.

Why AI agents need BOMs

Traditional software supply chain tooling accounts for code dependencies. AI agent stacks introduce a second supply chain: the tools and models the agent uses at runtime. This second supply chain is invisible to npm audit, dependabot, and every other conventional dependency scanner.

Problem	How an Agent BOM helps
Audit trail	SOC 2 Type II and AI Act Article 13 compliance reviews require knowing exactly which tools were installed and when. A BOM gives you a dated record at every deployment.
Supply chain visibility	When a new malicious tool advisory drops, a BOM tells you in seconds whether you’re affected — without grepping through deployment configs.
Drift detection	Comparing BOMs across deployments reveals which components were added, removed, or updated between releases — the kind of change that introduces supply chain risk.
CI/CD gating	Automated pipelines can reject deployments if a new component lacks a known-good BOM entry or introduces an untrusted source.
Incident response	When a tool is flagged as malicious, a BOM tells you exactly which agent deployments are affected and which version was running at the time.

What goes into the BOM

A Firmis Agent BOM contains four sections:

Components

Each AI agent tool, skill, or plugin discovered during the scan is listed as a CycloneDX component. Component fields include:

Field	Description
`type`	Component type: `library`, `service`, or `application`
`name`	Component name from the manifest or directory name
`version`	Version from `package.json`, `skill.json`, or `pyproject.toml`
`description`	Short description from the manifest
`purl`	Package URL if the component is a published npm or PyPI package
`hashes`	SHA-256 hash of the component directory for integrity verification

Dependencies

npm and pip packages referenced in package.json, requirements.txt, and pyproject.toml are enumerated and listed as dependency components. These are the packages the agent’s tools depend on at runtime — the ones most likely to carry supply chain risk.

Models

When a model reference is detected in a configuration file (e.g., "model": "claude-3-5-sonnet-20241022" in a skill config), it is recorded as a component of type machine-learning-model. This is the part of the agent stack that has historically been completely invisible to compliance tooling.

Metadata

The BOM metadata section records:

Field	Value
`timestamp`	ISO 8601 scan time
`tools`	Firmis version and configuration
`component`	The root project being inventoried

Generating a BOM

# Generate BOM for the current directory (stdout)
npx firmis bom

# Save BOM to a file
npx firmis bom --output agent-bom.json

# BOM for a specific platform only
npx firmis bom --platform mcp --output mcp-bom.json

The output is a valid CycloneDX 1.7 JSON document:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-05T10:00:00Z",
    "tools": [{ "name": "firmis", "version": "1.3.0" }]
  },
  "components": [
    {
      "type": "library",
      "name": "my-search-tool",
      "version": "0.2.1",
      "description": "Web search tool for Claude",
      "hashes": [{ "alg": "SHA-256", "content": "e3b0c44..." }]
    }
  ],
  "dependencies": [
    { "ref": "my-search-tool", "dependsOn": ["axios@1.6.0"] }
  ]
}

Using the BOM in CI/CD

The firmis ci command runs the full discover → BOM → scan → report pipeline in one step:

npx firmis ci --fail-on high

This generates a BOM as an artifact alongside the SARIF scan results. You can archive the BOM in your CI system to maintain a history of exactly what was deployed at each run.

- name: Run Firmis
  run: npx firmis ci --fail-on high --sarif --output results.sarif

- name: Upload BOM artifact
  uses: actions/upload-artifact@v4
  with:
    name: agent-bom
    path: agent-bom.json

- name: Upload SARIF
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: results.sarif

Consuming the BOM

Because the output is standard CycloneDX 1.7 JSON, it integrates with any tool that supports the format. You’re not locked into Firmis’s reporting — the BOM is yours to use.

Tool	Use case
OWASP Dependency-Track	Continuous vulnerability tracking against the component inventory
Grype	Vulnerability matching against the BOM
GitHub Dependency Graph	Import as an SBOM to populate the dependency graph
Custom automation	Parse the JSON to extract component names, versions, and hashes for your own compliance workflows

What Firmis does NOT include in the BOM

The BOM reflects what Firmis can discover statically. It does not include:

Tools installed or loaded dynamically at runtime
Components referenced only via environment variables (e.g., process.env.TOOL_URL)
Third-party model API calls where the model name is constructed at runtime

For complete runtime visibility, combine the Agent BOM with runtime monitoring.