MITIGATION · m-sbom
Signed AIBOM: a cryptographically-bound inventory of every component an agent loads
An AI agent assembles itself at runtime from a model, prompt templates, plugins, and library dependencies, any of which can be tampered with before they arrive. A signed AI Bill of Materials (AIBOM) locks down that assembly: it records every component with a version and hash at build time, signs the manifest, and verifies it before the agent accepts traffic. A component that does not match its declared hash cannot silently enter the agent.
At a glance
TL;DR
- At build time, generate a signed AIBOM that records every model, prompt template, plugin, and library with its version and SHA-256 hash.
- Sign the manifest with Sigstore cosign so any consumer can verify it has not been modified.
- At startup, verify the signature and compare each loaded component's hash against the manifest. Refuse to start on any mismatch.
- Wire SBOM diffs into CI so a new or changed dependency that was not in the previous manifest blocks the build before it reaches production.
How it behaves
What it is
A Software Bill of Materials (SBOM) is the dependency manifest of a software artifact: every library, model, image, and plugin it includes, with versions and cryptographic hashes. MLBOM (Machine Learning Bill of Materials) and AIBOM (AI Bill of Materials) extend that concept to AI systems, adding model files, training data references, prompt templates, and the toolchain that produced them.
An agentic system assembles itself from more components than a conventional service: a foundation model, prompt templates, one or more plugins, and standard software dependencies. Any of those components can be compromised between the time a developer approved them and the time the agent loads them. Without a signed inventory, there is no way to detect the substitution. With one, the agent compares each loaded component's hash against the manifest at startup and refuses to proceed if anything does not match.
Detection signals
- Component hash mismatch at startup. Any loaded component whose hash does not match the signed manifest entry indicates the artifact was modified after the AIBOM was generated.
- SBOM diff in CI with an unreviewed new dependency. A dependency that appears in the current build but not in the previous manifest means something entered the supply chain without a deliberate change.
Threats it covers
-
WHY IT HELPS Supply Chain Compromise is the introduction of a vulnerable, malicious, or outdated upstream component into the agent. AIBOM addresses this directly by making the component inventory explicit and tamper-evident. A modified model file or poisoned library produces a hash mismatch against the signed manifest, blocking deployment before the agent handles any traffic.
-
WHY IT HELPS Plugin Vulnerability Leading to Agent Compromise relies on a malicious or vulnerable plugin entering the agent undetected. When every plugin dependency is declared in a signed AIBOM with a pinned version and hash, a tampered or newly introduced plugin produces a manifest diff. The vulnerability cannot persist silently in an undeclared dependency.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Supply-chain Security A signed AIBOM makes everything the agent is built from auditable and tamper-evident, refusing any component whose hash does not match its signed manifest.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Five verified paths, from a single-format CLI to a full per-agent provenance pipeline. Choose based on whether you need format flexibility, AI-specific fields, or a signed attestation layer.
CycloneDX with cdxgen Generates a CycloneDX BOM with a machine-learning-model component type for each model artifact. Supports dozens of package ecosystems and runs from CI with a single command. Use when you already have an npm, pip, or go pipeline and want SBOM generation with minimal new tooling.
Why choose it: Run cdxgen -t <ecosystem> -o bom.json in CI. The machine-learning-model component type accepts standard bom-ref, hashes, and supplier fields plus a properties array for custom AI metadata such as architecture and quantisation.
More details:
SPDX 3.0 AIPackage SPDX 3.0 adds a dedicated AIPackage class with model-provenance fields that go beyond CycloneDX's properties array: type of model, training information, hyperparameters, safety-risk assessment, and energy consumption. The specification is final; tooling is less mature than CycloneDX. Use when you need rich AI-specific metadata in a standards-compliant format.
Why choose it: Consume via the spdx-tools Python library or the spdx-java-library. The AIPackage class is defined in the SPDX 3.0.1 model and is backward-compatible with SPDX 2.x pipelines for the non-AI fields.
More details:
OWASP AIBOM A dedicated workstream building a structured inventory for AI components: models, datasets, agents, tools, guardrails, and runtime elements. Output is CycloneDX-compatible. Use when you want to align with the emerging AI-specific SBOM community standard rather than adapting a general-purpose format.
Why choose it: The project documents model lineage, training datasets, risks, and third-party dependencies, and collaborates with OWASP CycloneDX on the format, so existing CycloneDX tooling applies.
More details:
Sigstore cosign attestation Attaches a signed in-toto attestation to a container image in an OCI registry, with built-in support for both spdxjson and cyclonedx predicate types, so the AIBOM is stored alongside the image digest and verifiable by any consumer. Keyless signing via OIDC needs no key management. Use when the agent ships as a container image.
Why choose it: Run cosign attest --type cyclonedx --predicate bom.json <image> to attach, and cosign verify-attestation --type cyclonedx <image> to verify. The attestation lives in the registry next to the image, with no out-of-band file to distribute.
More details:
Self-built per-agent pipeline For agentic systems where prompts, tool manifests, and model configs are first-class runtime artifacts, build a custom pipeline: emit one AIBOM per agent at build time, sign it, and verify all component hashes at startup before accepting requests. Use when you run multiple agent personas with distinct prompt templates and need tamper-evident provenance for prompts specifically.
Why choose it: At build time, content-address each prompt template via SHA-256 and include the hash as a component entry. Sign the manifest with cosign sign-blob. At startup, verify with cosign verify-blob, then compare each loaded component's hash to its manifest entry before the agent opens for traffic.
More details:
Trade-offs
- Signature verification at startup is a one-time check and adds negligible latency to the request path.
- All tooling (cdxgen, cosign, the Sigstore public infrastructure) is free. The engineering cost ranges from under a day for a code-only SBOM to several weeks for full prompt and model provenance.
- An AIBOM is an ops and build-time concern, invisible to end users.
When NOT to use
- Prototype or single-use scripts where the full inventory is one model API call and two open-source libraries. The provenance overhead is not proportionate at that scale.
- When the threat is in-process tampering of loaded model weights at runtime. An SBOM records build-time state only; pair with runtime integrity monitoring for that threat.
- When prompts live in ad-hoc string variables rather than versioned, hashable files. An AIBOM that omits prompt provenance creates false confidence, so scope the manifest to what you can actually attest, or establish prompt versioning first.
Limitations
- An SBOM captures build-time state. A supply-chain compromise introduced after the SBOM is generated will not appear until the next build. Pair with Dependabot, Renovate, or OSV-Scanner in CI to catch post-build dependency vulnerabilities.
- Prompt and model-weight provenance in SBOM formats is not yet fully standardised. CycloneDX machine-learning-model and SPDX AIPackage are both in active development; treat AI-artifact provenance as best-effort until the tooling and schemas stabilise.
- Keyless cosign signing requires OIDC token availability. It is straightforward in GitHub Actions but needs additional setup in self-hosted or air-gapped environments.
- Most SBOM dashboards (Dependency-Track, Snyk) have limited support for the machine-learning-model component type today. Verify your dashboard's support before relying on it for AI component tracking.
Maturity tier reasoning
- Tier 1 fits because the core pattern is production-canonical: CycloneDX is an OWASP-governed standard with a published JSON schema, cdxgen is active open-source software, and cosign and Sigstore are CNCF projects in production use by major container registries.
- OWASP LLM Top 10 2025 (LLM03 Supply Chain) names AIBOM as a primary mitigation.
- The AI-specific metadata fields (SPDX AIPackage, CycloneDX MLBOM) are newer, but the underlying SBOM-plus-signing pattern is production-grade today, which is what keeps the control at Tier 1 rather than Tier 2.
Last verified against upstream docs: 2026-05-30.