Software Bill of Materials (SBOM) for AI Agents: Adapting SBOM Standards to LLM-Based Systems

On May 12, 2021, President Biden signed Executive Order 14028, "Improving the Nation's Cybersecurity." Section 4(e) required that software sold to the federal government include a Software Bill of Materials — a formal, machine-readable inventory of the software components that make up a given product. The NTIA (National Telecommunications and Information Administration) subsequently published the minimum elements for an SBOM: supplier name, component name, version, unique identifiers, dependency relationships, author of SBOM data, and timestamp. Tools like SPDX and CycloneDX provided the interchange formats. By 2023, SBOM requirements were filtering into commercial procurement contracts across industries.

These standards work well for traditional software. A compiled binary with known dependencies on specific library versions maps cleanly to the SPDX component model. But when organizations began asking how to apply SBOM requirements to AI agent systems, they discovered a fundamental conceptual mismatch.

What is the "component" version of a fine-tuned large language model? What is the "supplier" of a model that was pre-trained by OpenAI, fine-tuned on proprietary data by the deploying organization, quantized by a third-party tool, and served through a cloud inference API? What are the "dependencies" of a neural network — and how do you enumerate the training data that shaped its behavior? How do you create a machine-readable inventory of a system whose most important "components" are encoded in billions of floating-point parameters through a process that no individual supervised?

These questions do not have clean answers, but they have workable answers — and the organizations that figure out AI SBOM will have significant governance advantages over those that don't. This document works through the technical and conceptual challenges systematically, proposing practical extensions to existing SBOM standards that address AI-specific characteristics while remaining compatible with existing tooling and processes.

TL;DR

• Standard SBOM formats (SPDX, CycloneDX) address code dependencies well but have significant gaps for AI-specific components: model weights, training data, fine-tuning procedures, embedding models, and behavioral specifications.
• CycloneDX v1.5+ includes a Machine Learning BOM (ML-BOM) extension that provides the most comprehensive existing standard for AI component documentation — but adoption is nascent and tooling is immature.
• Training data must be treated as a first-class SBOM component, with provenance information capturing: data source, collection date, license, filtering procedures, and cryptographic hash of the curated dataset.
• Model cards (Mitchell et al., 2019) should be standardized as a required SBOM component with machine-readable formats, not just narrative PDFs.
• SBOM automation for AI agents is achievable at SLSA Level 2 today with existing tooling; Levels 3–4 require additional investment in training pipeline instrumentation.
• Armalo's signed behavioral attestation system provides the behavioral dimension of AI SBOM that technical inventory standards do not address — completing the picture for compliance and governance.

Why Standard SBOM Is Insufficient for AI Agents

Before proposing extensions, it is worth articulating precisely why the NTIA minimum elements are insufficient for AI agent systems. Understanding the gaps drives the design of the extensions.

The Component Identity Problem

SPDX and CycloneDX identify components by: supplier, name, version, and optionally a package URL (PURL). For traditional software:

SPDXID: SPDXRef-requests
name: requests
version: 2.31.0
supplier: Organization: Kenneth Reitz
packageURL: pkg:pypi/requests@2.31.0

This works because software packages have canonical identities: a specific version of requests at version 2.31.0 is the same artifact everywhere. Hash verification confirms you have the right artifact.

For a fine-tuned LLM:

name:???
version:???
supplier:???
packageURL:???

• The name might be "Our Fine-tuned Llama-3.1-70B" — but this doesn't identify the specific model artifact
• The "version" is typically the fine-tuning date or a git commit hash of the training code — but the model artifacts aren't versioned by these
• The "supplier" is complex: Meta (pre-training), your organization (fine-tuning), NVIDIA (quantization tooling)
• There is no standard PURL scheme for LLM model weights

The component identity problem is particularly acute for fine-tuned models because fine-tuning is not deterministic — the same code, data, and hyperparameters run twice will produce slightly different weights due to floating-point nondeterminism. This means hash verification — the primary integrity mechanism in traditional SBOM — cannot be applied to model weights in the straightforward way.

The Training Data Invisibility Problem

The behavior of an LLM is primarily determined by its training data. But training data is invisible in standard SBOM. A model card might document that a model was trained on "a curated subset of Common Crawl, Wikipedia, and proprietary data" — but this is not machine-readable, not verifiable, and not specific enough to assess security implications.

From a security perspective, knowing which version of Common Crawl (there have been over 100 monthly snapshots) was used, whether it was processed through the C4 or Dolma filtering pipeline, what proprietary data was included, and whether any of those sources have since been identified as compromised — this information is security-relevant. Standard SBOM provides no mechanism to capture it.

The Behavioral Specification Gap

Traditional SBOM documents what software is present. For AI agents, what the software does is often more security-relevant than what it is. Two agents with identical component lists — same model, same plugins, same runtime libraries — can behave in entirely different ways depending on their system prompts, fine-tuning objectives, and behavioral constraints.

Standard SBOM has no concept of behavioral specification. A complete AI agent SBOM needs to include not just what components are present, but what behavioral commitments those components make — what the agent is designed to do, what it is designed not to do, and how those commitments have been verified.

CycloneDX ML-BOM: The Most Relevant Existing Standard

CycloneDX v1.5, released in June 2023, introduced the Machine Learning Bill of Materials (ML-BOM) extension. This is the most comprehensive existing standard for AI component documentation and provides the foundation for AI SBOM implementations.

ML-BOM Component Types

CycloneDX ML-BOM defines new component types beyond the standard library, framework, application types:

machine-learning-model: Represents an ML model as a component. Includes fields for:

• Model type (generative, discriminative, etc.)
• Model architecture (transformer, LSTM, CNN)
• Model parameters (parameter count, quantization format)
• Training data reference (link to training data documentation)
• Model cards (reference to model card documentation)
• Performance metrics (benchmark results)

data: Represents datasets as components. Includes fields for:

• Content type (text, image, tabular, etc.)
• Data format
• Content identifier (hash or URI)
• Data license
• Data governance information (sensitivity classification, collection method)

ai-model: A specialized machine-learning-model type for foundation models and fine-tuned variants. Additional fields for:

• Hyperparameter configuration
• Training procedure description
• Evaluation results reference

ML-BOM Example: A Fine-Tuned GPT-4 Agent

<?xml version="1.0"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.5"
     xmlns:ml="http://cyclonedx.org/schema/ext/ml-bom/1.0"
     version="1" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79">
  <metadata>
    <timestamp>2026-05-10T00:00:00Z</timestamp>
    <component type="application">
      <name>enterprise-ai-agent-v2</name>
      <version>2.4.1</version>
      <supplier><name>Acme Corp</name></supplier>
    </component>
  </metadata>
  <components>
    <!-- Base model component -->
    <component type="machine-learning-model">
      <supplier><name>OpenAI</name></supplier>
      <name>gpt-4o-mini</name>
      <version>2024-07-18</version>
      <purl>pkg:mlmodel/openai/gpt-4o-mini@2024-07-18</purl>
      <ml:modelCard>
        <ml:considerations>
          <ml:useCases>Enterprise document analysis, task automation</ml:useCases>
          <ml:users>Internal employees via enterprise AI agent</ml:users>
        </ml:considerations>
        <ml:performance>
          <ml:metric type="MMLU">0.82</ml:metric>
          <ml:metric type="HarmBench-Safety">0.94</ml:metric>
        </ml:performance>
      </ml:modelCard>
      <hashes>
        <!-- Behavioral hash (hash of outputs on fixed evaluation set) -->
        <hash alg="SHA-256">a3f1c2...</hash>
      </hashes>
    </component>
    <!-- Fine-tuning dataset component -->
    <component type="data">
      <name>acme-enterprise-finetune-v3</name>
      <version>2026-03-15</version>
      <supplier><name>Acme Corp Data Team</name></supplier>
      <description>Fine-tuning dataset for enterprise document analysis tasks</description>
      <ml:dataGovernance>
        <ml:dataLicenses>
          <ml:license><expression>Proprietary</expression></ml:license>
        </ml:dataLicenses>
        <ml:dataHolders>
          <ml:organization><name>Acme Corp</name></ml:organization>
        </ml:dataHolders>
      </ml:dataGovernance>
      <hashes>
        <!-- Hash of fine-tuning dataset at time of training -->
        <hash alg="SHA-256">b7d2e4...</hash>
      </hashes>
    </component>
    <!-- Runtime library components (standard SPDX/CycloneDX) -->
    <component type="library">
      <name>langchain</name>
      <version>0.3.14</version>
      <purl>pkg:pypi/langchain@0.3.14</purl>
      <hashes>
        <hash alg="SHA-256">c9f3a1...</hash>
      </hashes>
    </component>
    <!-- Plugin components -->
    <component type="library">
      <name>acme-document-retrieval-plugin</name>
      <version>1.2.0</version>
      <supplier><name>DocumentVendor Inc</name></supplier>
      <purl>pkg:generic/documentvendor/acme-doc-plugin@1.2.0</purl>
      <ml:behavioralAttestation>
        <ml:issuer>DocumentVendor Inc</ml:issuer>
        <ml:timestamp>2026-04-01T00:00:00Z</ml:timestamp>
        <ml:commitments>
          <ml:commitment>Plugin does not log or transmit credentials</ml:commitment>
          <ml:commitment>External calls limited to api.documentvendor.com</ml:commitment>
        </ml:commitments>
      </ml:behavioralAttestation>
    </component>
  </components>
</bom>

CycloneDX ML-BOM Limitations

Despite being the most comprehensive available standard, CycloneDX ML-BOM has limitations for production AI agent SBOM:

1. No training data provenance chain: The data component type records a single hash of the dataset, but provides no mechanism for recording the provenance chain (where the data came from, how it was processed, what was filtered out).

2. No behavioral specification: There is no standardized way to express what the model is supposed to do in machine-readable form.

3. No evaluation attestation: The performance section can record benchmark scores, but there is no standardized structure for recording the evaluation procedure, the evaluation date, the evaluating party, and a cryptographic signature.

4. Tooling immaturity: As of 2026, tooling for generating CycloneDX ML-BOM is limited. The main generator (cyclonedx-bom Python package) has basic ML support, but the ML-specific fields require manual population.

SPDX 3.0 for AI: The Emerging Standard

SPDX 3.0, released in April 2024, introduced an AI and Dataset profile that extends the SPDX data model for AI systems. The AI profile adds:

AI Package: A specialized package type for AI/ML models with fields for:

• autonomyType: The level of autonomy of the AI system (fully autonomous, semi-autonomous, human-delegated)
• domain: Application domain (natural language processing, computer vision, etc.)
• hyperparameter: Training hyperparameters
• informationAboutTraining: Reference to training documentation
• limitation: Known limitations of the model
• metric: Performance metrics
• modelExplainability: Explainability characteristics
• safetyRiskAssessment: Risk assessment according to applicable frameworks
• standardCompliance: Compliance with relevant standards (EU AI Act risk categories, etc.)

Dataset Package: Extended package type for datasets with:

• dataCollectionProcess: Description of how data was collected
• dataPreprocessing: Preprocessing steps applied
• dataset: Dataset name/identifier
• datasetAvailability: Access controls and availability restrictions
• datasetCategory: Type of data (text, image, audio, etc.)
• datasetNoise: Known noise or quality issues
• datasetSize: Size of the dataset
• datasetType: Training, testing, validation
• intendedUse: Intended use of the dataset
• knownBias: Known biases in the dataset
• sensitivePersonalInformation: Whether dataset contains sensitive personal information

The SPDX 3.0 AI/Dataset profile is more comprehensive than CycloneDX ML-BOM for certain metadata fields, particularly around dataset characterization. However, CycloneDX has stronger tooling support and a more active adoption community for AI use cases as of 2026.

Training Data as a First-Class SBOM Component

The most important extension to existing SBOM standards for AI security is treating training data as a first-class, auditable component with provenance tracking.

Training Data Provenance Chain

A complete training data provenance record should capture:

Level 1 — Source Identification:

• Canonical name of each data source (Common Crawl CC-MAIN-2024-10, Wikipedia English 2024-03-01, proprietary CRM data export v2.1.4)
• Collection date range
• Collection method (web crawl, API export, manual curation, licensed purchase)
• License or terms of use
• Contact information for data source operator

Level 2 — Processing Record:

• Filtering procedures applied (toxicity filtering, deduplication, quality scoring)
• Tools used for each processing step (with version numbers)
• Rejection criteria and rejection rate
• Any transformations applied (format conversion, tokenization scheme)
• Record of who performed each processing step and when

Level 3 — Integrity Anchors:

• Cryptographic hash of the raw data at collection time
• Cryptographic hash of the processed dataset ready for training
• Size statistics (document count, token count) that can be independently verified
• Sample of data (or a commitment to provide samples for audit purposes)

Level 4 — Chain of Custody:

• Record of all entities who had access to the training data
• Transfer logs (who transferred data between systems, when, with what protections)
• Storage and access control documentation
• Any known incidents involving the dataset (accidental exposure, access by unauthorized parties)

Machine-Readable Training Data Manifest Format

The following is a proposed machine-readable format for training data manifests, designed to be embeddable in CycloneDX or SPDX documents as an extension:

{
  "trainingDataManifest": {
    "manifestVersion": "1.0",
    "manifestTimestamp": "2026-05-10T00:00:00Z",
    "manifestAuthor": {
      "organization": "Acme Corp AI Team",
      "contact": "ai-security@acme.com"
    },
    "manifestSignature": "ed25519:base64signature...",
    "dataSources": [
      {
        "sourceId": "cc-main-2024-10",
        "name": "Common Crawl CC-MAIN-2024-10",
        "type": "web_crawl",
        "collectionDate": "2024-10",
        "license": "CC0",
        "rawHashSHA256": "a1b2c3...",
        "rawSizeDocuments": 3200000000,
        "rawSizeTokens": 4800000000000,
        "filteringPipeline": [
          {
            "step": "language_filter",
            "tool": "fasttext-lid.176.bin",
            "toolVersion": "0.9.2",
            "parameters": {"language": "en", "confidence_threshold": 0.65},
            "docRetentionRate": 0.42
          },
          {
            "step": "quality_filter",
            "tool": "ccnet",
            "toolVersion": "1.0.0",
            "parameters": {"min_perplexity": 10, "max_perplexity": 1000},
            "docRetentionRate": 0.28
          }
        ],
        "processedHashSHA256": "d4e5f6...",
        "processedSizeDocuments": 840000000,
        "processedSizeTokens": 1344000000000
      },
      {
        "sourceId": "wikipedia-en-20240301",
        "name": "Wikipedia English Dump 2024-03-01",
        "type": "curated_encyclopedia",
        "collectionDate": "2024-03-01",
        "license": "CC-BY-SA-4.0",
        "downloadUrl": "https://dumps.wikimedia.org/enwiki/20240301/",
        "rawHashSHA256": "g7h8i9...",
        "rawSizeDocuments": 6800000,
        "filteringPipeline": [],
        "processedHashSHA256": "j1k2l3...",
        "processedSizeDocuments": 6800000
      }
    ],
    "combinedDataset": {
      "hashSHA256": "m4n5o6...",
      "totalSizeDocuments": 848800000,
      "mixingWeights": {
        "cc-main-2024-10": 0.85,
        "wikipedia-en-20240301": 0.15
      }
    }
  }
}

Why Training Data Provenance Matters for Security

Training data provenance serves three distinct security purposes:

Vulnerability Impact Assessment: When a data source is later discovered to have been compromised (e.g., a web domain that contributed to Common Crawl was found to have served poisoned content), organizations with training data provenance documentation can determine whether that source contributed to their models, assess the likely impact, and make informed decisions about retraining.

License and Legal Compliance: Several high-profile lawsuits in 2024–2025 involved training data used without proper licensing. Complete training data provenance documentation is the foundation of legal defensibility.

Bias and Safety Auditing: Understanding the composition and processing of training data is prerequisite to meaningful auditing for biases, safety risks, and capability mismatch. Regulators under the EU AI Act will require this documentation for high-risk AI system deployments.

Model Cards as SBOM Components

Model cards (Mitchell et al., 2019) were originally proposed as a mechanism for communicating information about ML models in a standardized, human-readable format. For SBOM purposes, model cards must be formalized as machine-readable, versioned, signed documents that are integral parts of the AI component's SBOM entry.

The Current State of Model Cards

As of 2026, model cards exist on a spectrum from detailed and rigorous (Google's own model cards, Hugging Face cards for well-maintained models) to minimal and uninformative (a paragraph of generic text with no specific evaluation results).

The problems with current model cards for SBOM purposes:

• They are primarily human-readable, not machine-readable
• They are typically narrative documents without structured fields that automated tools can process
• They are not cryptographically signed, so there is no way to verify that the model card was issued by the model's creator and has not been modified
• They are not versioned as part of the model artifact — the model card can be updated without updating the model

Machine-Readable Model Card Structure

A machine-readable model card for SBOM purposes should include:

Identity Section:

{
  "modelCard": {
    "modelId": "urn:uuid:...",
    "modelName": "acme-enterprise-assistant-v2",
    "modelVersion": "2.4.1",
    "baseModel": "meta-llama/Meta-Llama-3.1-70B-Instruct",
    "fineTuningMethod": "LoRA",
    "fineTuningDate": "2026-03-15",
    "publisher": "Acme Corp",
    "publisherContact": "ai-security@acme.com"
  }
}

Intended Use Section:

{
  "intendedUse": {
    "primaryUses": ["Document analysis", "Task automation for enterprise workflows"],
    "primaryUsers": ["Enterprise employees via approved agent interface"],
    "outOfScopeUses": ["Medical advice", "Legal advice", "High-stakes financial decisions without human review"],
    "prohibitedUses": ["Surveillance", "Discriminatory decision-making", "Generation of harmful content"]
  }
}

Performance and Evaluation Section:

{
  "evaluationResults": [
    {
      "evaluationTimestamp": "2026-03-20T00:00:00Z",
      "evaluator": "Acme Corp Red Team",
      "evaluatorIndependence": "internal",
      "benchmarks": [
        {"name": "MMLU", "score": 0.81, "subset": "all"},
        {"name": "TruthfulQA", "score": 0.74},
        {"name": "HarmBench", "score": 0.96, "category": "standard"},
        {"name": "PromptInjectionResistance", "score": 0.88, "testSuite": "ACME-PIR-v1"}
      ],
      "redTeamSummary": {
        "testCasesExecuted": 1240,
        "testCasesPassed": 1198,
        "failureCategories": ["occasional instruction following failures on complex multi-step tasks"],
        "criticalFailures": 0
      }
    }
  ]
}

Limitations Section:

{
  "limitations": {
    "technicalLimitations": ["Context window: 128k tokens", "Knowledge cutoff: 2025-12"],
    "biasConsiderations": ["Model trained on primarily English-language data; performance degrades on non-English inputs"],
    "safetyConsiderations": ["Model may produce incorrect factual information; human review required for high-stakes outputs"],
    "additionalConsiderations": []
  }
}

Signature Section:

{
  "signature": {
    "algorithm": "Ed25519",
    "publicKeyUrl": "https://acme.com/ai-signing-keys/model-card-signing.pub",
    "signature": "base64encodedEd25519signature..."
  }
}

Model Card Signing and Verification

Model cards should be signed with a well-established key pair maintained by the model publisher. The signing key should:

• Be distinct from code signing keys (separate key material, separate HSM or KMS entry)
• Have a clear rotation policy (annual rotation recommended)
• Have a published revocation mechanism (CRL or OCSP-like endpoint)
• Be independently verifiable without trusting the publisher's current website (use a transparency log like Sigstore's Rekor)

# Sign model card using Sigstore/cosign (keyless, OIDC-based)
cosign sign-blob --output-signature model-card.json.sig \
  --output-certificate model-card.json.crt \
  model-card.json

# Verify model card signature
cosign verify-blob --signature model-card.json.sig \
  --certificate model-card.json.crt \
  --certificate-identity-regexp ".*@acme.com" \
  --certificate-oidc-issuer https://accounts.google.com \
  model-card.json

SBOM Automation for AI Agent Pipelines

Manual SBOM generation is not sustainable at scale. AI agent deployments are updated frequently — new model versions, new plugin versions, configuration changes — and SBOM should be generated automatically at each update.

Automated SBOM Generation in CI/CD

A comprehensive SBOM generation pipeline for AI agents should run at every build and deployment:

Step 1: Runtime Dependency SBOM

# Generate SBOM for Python runtime dependencies
pip-sbom generate --format cyclonedx --output runtime-sbom.json

# Alternative: use syft for container-based deployment
syft packages dir:. -o cyclonedx-json > runtime-sbom.json

Step 2: ML Component SBOM

This step requires custom tooling or manual population for model-specific metadata:

# Python script to generate ML component SBOM fragment
from cyclonedx.model.component import Component, ComponentType
from cyclonedx.model.bom import Bom
from cyclonedx.model.license import LicenseExpression
import json

def generate_ml_sbom_fragment(model_config: dict) -> dict:
    """
    Generate CycloneDX ML-BOM fragment for an AI model component.
    model_config: dictionary with model metadata from deployment configuration
    """
    return {
        "type": "machine-learning-model",
        "name": model_config["model_name"],
        "version": model_config["model_version"],
        "supplier": {"name": model_config["model_supplier"]},
        "purl": f"pkg:mlmodel/{model_config['model_supplier']}/{model_config['model_name']}@{model_config['model_version']}",
        "properties": [
            {"name": "ml:model-type", "value": model_config.get("model_type", "llm")},
            {"name": "ml:architecture", "value": model_config.get("architecture", "transformer")},
            {"name": "ml:parameter-count", "value": str(model_config.get("parameter_count", "unknown"))},
            {"name": "ml:training-data-manifest", "value": model_config.get("training_data_manifest_hash", "")},
            {"name": "ml:fine-tuning-method", "value": model_config.get("fine_tuning_method", "none")},
            {"name": "ml:behavioral-hash", "value": model_config.get("behavioral_hash", "")}
        ]
    }

Step 3: SBOM Merge and Signing

# Merge runtime and ML SBOM fragments
cyclonedx-bom merge \
  --input runtime-sbom.json \
  --input ml-components.json \
  --output full-agent-sbom.json

# Sign the merged SBOM
cosign sign-blob --output-signature full-agent-sbom.json.sig \
  full-agent-sbom.json

# Store SBOM alongside deployment artifact
aws s3 cp full-agent-sbom.json \
  s3://company-sbom-store/${AGENT_NAME}/${BUILD_ID}/sbom.json
aws s3 cp full-agent-sbom.json.sig \
  s3://company-sbom-store/${AGENT_NAME}/${BUILD_ID}/sbom.json.sig

Step 4: SBOM Verification in Deployment Pipeline

# Before deployment: verify SBOM signature
cosign verify-blob --signature full-agent-sbom.json.sig \
  --certificate-identity-regexp ".*@company.com" \
  full-agent-sbom.json

# Scan SBOM for known vulnerabilities
grype sbom:full-agent-sbom.json \
  --output sarif \
  --fail-on high \
  > vuln-report.sarif

SBOM Continuity: The Behavioral Hash

One AI-specific challenge for SBOM automation is that model weights cannot be verified by hash in the same way as compiled software. The behavioral hash provides a partial solution: instead of hashing the model weights (which may differ between runs even with identical training), hash the model's outputs on a fixed evaluation set.

def compute_behavioral_hash(model, evaluation_prompts: list[str]) -> str:
    """
    Compute a stable hash of model behavior for SBOM identity purposes.
    
    The behavioral hash is computed as SHA-256 of the JSON-serialized
    ordered list of (prompt, response) pairs on a fixed evaluation set.
    The evaluation set should be canonical, deterministic, and version-controlled.
    """
    import hashlib, json
    outputs = []
    for prompt in evaluation_prompts:
        response = model.generate(prompt, temperature=0.0)  # Greedy decoding for determinism
        outputs.append({"prompt": prompt, "response": response})
    
    canonical_json = json.dumps(outputs, sort_keys=True, ensure_ascii=True)
    return hashlib.sha256(canonical_json.encode()).hexdigest()

The behavioral hash is not a cryptographic integrity proof (two different models could produce the same behavioral hash if they have similar outputs on the evaluation set), but it provides a stable identifier for "this model's behavior on this evaluation set at this point in time" — sufficient for SBOM tracking purposes and for detecting behavioral drift.

Regulatory Context: EU AI Act and SBOM Requirements

The EU AI Act (Regulation (EU) 2024/1689, effective August 2024 with staged compliance dates through 2027) imposes specific technical documentation requirements on high-risk AI systems that are directly relevant to AI SBOM.

Annex IV — Technical Documentation Requirements

For high-risk AI systems, the EU AI Act requires technical documentation covering (Annex IV):

1. A general description of the AI system — directly maps to SBOM metadata
2. A detailed description of the elements and the development process — maps to training data provenance and model component documentation
3. Information about the training, testing, and validation data used — directly maps to training data SBOM components
4. Information about the monitoring, functioning, and control of the AI system — maps to behavioral monitoring and evaluation documentation
5. A description of the risk management system — maps to adversarial evaluation documentation
6. A description of the human oversight measures — maps to behavioral specification in model card

Organizations deploying AI agents classified as high-risk under the EU AI Act will need AI SBOM capabilities to satisfy Annex IV requirements. The machine-readable formats described in this document — CycloneDX ML-BOM and SPDX 3.0 AI profiles — provide the technical foundation for this compliance documentation.

NIST AI RMF and SBOM Alignment

NIST's AI Risk Management Framework (AI RMF 1.0, January 2023) provides governance principles that align closely with AI SBOM requirements. The GOVERN, MAP, MEASURE, and MANAGE functions of the AI RMF each have documentation requirements that an AI SBOM program supports:

• GOVERN: Organizational policies and practices for AI risk management — AI SBOM provides the inventory foundation
• MAP: Identifying and categorizing AI risks in context — training data provenance supports bias and risk assessment
• MEASURE: Analyzing and quantifying AI risks — behavioral hashes and evaluation attestations support measurement
• MANAGE: Prioritizing and treating AI risks — SBOM enables risk-based prioritization when vulnerabilities are discovered

How Armalo Completes the AI SBOM Picture

Technical SBOM standards capture what AI components exist and their static properties. What they do not capture — and what is often more security-relevant — is how those components behave in practice.

Armalo's signed behavioral attestations fill this gap, providing the behavioral dimension of AI SBOM that technical inventory standards cannot address alone.

Behavioral Attestations as SBOM Components

An Armalo behavioral attestation can be referenced as a component in a CycloneDX ML-BOM:

{
  "type": "attestation",
  "name": "armalo-behavioral-attestation",
  "version": "2026-05-10",
  "supplier": {"name": "Armalo AI"},
  "attestationUri": "https://armalo.ai/api/v1/trust/attestation/agent:acme-enterprise-assistant@2.4.1",
  "properties": [
    {"name": "armalo:trust-score", "value": "87.4"},
    {"name": "armalo:last-evaluation", "value": "2026-05-01T00:00:00Z"},
    {"name": "armalo:pact-count", "value": "12"},
    {"name": "armalo:supply-chain-integrity", "value": "verified-slsa-level-2"}
  ]
}

This reference links the technical SBOM to the behavioral attestation record, creating a complete picture: what the agent is made of (technical SBOM) plus how it has been verified to behave (Armalo behavioral attestation).

The Trust Oracle as SBOM Verification Service

When a consuming organization receives an AI agent SBOM, they need to verify it. Armalo's trust oracle provides an API endpoint for SBOM-linked verification:

GET /api/v1/trust/verify-sbom?
  agent_id=agent:acme-enterprise-assistant@2.4.1&
  sbom_hash=sha256:m4n5o6...&
  as_of=2026-05-10T00:00:00Z

The response includes:

• Whether the SBOM matches the agent's registered component inventory
• Whether the behavioral attestation is current and valid
• Supply chain integrity score (SLSA level achieved, dependency scan results)
• Any known issues with components listed in the SBOM

This verification API enables downstream consumers — marketplaces, enterprise buyers, compliance teams — to programmatically verify the accuracy and currency of an AI agent's SBOM before deployment.

Conclusion: SBOM as the Foundation of AI Agent Governance

Software Bill of Materials for AI agents is not a solved problem — the standards are evolving, the tooling is immature, and the conceptual challenges around training data provenance and behavioral specification do not have clean solutions yet. But the direction is clear, the regulatory pressure is building, and the organizations that invest in AI SBOM now will be positioned ahead of the compliance curve when requirements become mandatory.

The practical path forward:

1. Start with what you can automate today: Runtime dependency SBOM is achievable now with existing tooling. Implement CycloneDX generation for all AI agent deployments and store SBOMs with deployment artifacts.

2. Formalize model card documentation: Even if machine-readable model cards are aspirational today, structured model card documentation with versioning is achievable and provides immediate governance value.

3. Begin training data provenance tracking: For future model training and fine-tuning, implement training data manifests from the start. Retroactively documenting provenance for existing models is worth the effort for the most critical deployments.

4. Integrate behavioral attestation: Technical SBOM without behavioral verification is incomplete. Use Armalo's attestation system to add the behavioral dimension to AI SBOM programs.

5. Track the standards: CycloneDX and SPDX are actively evolving to better support AI. Subscribe to the working groups and implement new fields as they are standardized.

The SBOM for AI is ultimately about accountability — the ability to say, after the fact, exactly what went into an AI system and verify that the components behaved as intended. That accountability is the foundation of trusted AI deployment.