For open-source program offices and platform engineers building AI agent stacks, a Software Bill of Materials (SBOM) is essential—not just for compliance, but for operational clarity. An SBOM for an agent stack goes beyond listing packages (e.g., PyTorch, FastAPI) to include components like fine-tuned models, proprietary datasets, custom prompts, and third-party tool integrations. Without a comprehensive SBOM, teams risk blind spots in security, licensing, and dependency management, particularly when agents interact with external APIs, cloud services, or custom-built components. Below is a structured approach to defining, generating, and maintaining an SBOM for AI agent stacks, with practical steps and decision rules for immediate implementation.
What belongs in an SBOM for an AI agent stack
The SBOM for an AI agent stack must capture all components that contribute to functionality, security, and compliance. Below is a checklist of elements to include, categorized by type:
- Models:
- Fine-tuned or pre-trained models (e.g., Llama 2, Mistral, or custom embeddings). Document the model architecture, training data (if public), and any proprietary components (e.g., custom tokenizers, quantization layers). Include metadata like version, license terms, and whether the model is open-source or closed-source.
- Model weights (e.g., `.bin`, `.pt`, `.safetensors`). Specify the format, compression method, and whether the weights are derived from third-party sources.
- Model inference libraries (e.g., Hugging Face `transformers`, ONNX Runtime, or custom C++ bindings). Note dependencies like CUDA, cuDNN, or other hardware-specific requirements.
- Datasets:
- Public datasets (e.g., RedPajama, S2ORC). Note the source, license (e.g., CC-BY, MIT), and whether the data is modified (e.g., filtered, anonymized). Include a hash (SHA-256) of the dataset file if it’s stored locally.
- Private or proprietary datasets. Document ownership, licensing restrictions, and whether the data is encrypted or stored in a secure environment (e.g., AWS S3 with KMS). If the dataset is generated internally, note the process (e.g., web scraping, synthetic data).
- Data preprocessing pipelines (e.g., PyTorch `datasets`, custom scripts). Include the codebase, version, and any third-party tools (e.g., `datasets` library, `pandas`) used in the pipeline.
- Prompts and Instruction Tuning:
- Custom prompts or few-shot examples used for fine-tuning or inference. Document the prompt structure, length, and whether they are hardcoded or dynamically generated. If prompts are sensitive (e.g., PII), note their classification and storage location.
- Instruction tuning data (e.g., aligned examples for zero-shot or few-shot learning). Include the dataset name, license, and whether the tuning process involved proprietary methods (e.g., reinforcement learning from human feedback).
- Prompt engineering libraries (e.g., `langchain`, `PromptFlow`). Note dependencies like `python-prompts` or custom scripts.
- Tool Plugins and Integrations:
- Third-party APIs (e.g., Google Search, GitHub API, Twilio). Document the API key management (e.g., environment variables, secrets managers), rate limits, and whether the API is public or private. Include the SBOM for the underlying library (e.g., `google-api-python-client`).
- Cloud services (e.g., AWS Lambda, GCP Functions). Note the runtime environment, permissions (e.g., IAM roles), and any proprietary SDKs (e.g., AWS SDK for Python). Include the SBOM for the SDK and any dependencies (e.g., `boto3`).
- Custom plugins or wrappers around third-party tools. Document the codebase, version, and whether the plugin is open-source or closed-source. If the plugin interacts with external systems, note the communication protocol (e.g., HTTP, gRPC).
- Local utilities (e.g., data validation scripts, logging tools). Include the code repository, commit hash, and any third-party dependencies (e.g., `requests`, `logging`).
- Infrastructure and Deployment:
- Container images (e.g., Dockerfiles, `buildx`). Document the base image (e.g., `python:3.10-slim`), layers, and any proprietary components (e.g., custom startup scripts). Include a hash (e.g., `sha256`) of the image for reproducibility.
- Orchestration tools (e.g., Kubernetes, Docker Compose). Note the version, manifests, and any custom configurations (e.g., `values.yaml` for Helm charts). Include the SBOM for the orchestration tools (e.g., `kube-bench`).
- Monitoring and observability tools (e.g., Prometheus, OpenTelemetry). Document the version, metrics collected, and whether the tools are open-source or proprietary.
- Security and Compliance:
- Vulnerability scanning results for all components (e.g., model weights, datasets, plugins). Note the scan date, tools used (e.g., `snyk`, `trivy`), and any mitigations applied.
- License compliance for all third-party components. Use a tool like `licensed` or `deplist` to audit licenses and generate a compliance report.
- Data protection measures (e.g., encryption at rest, in-transit, or in-use). Document the encryption keys, algorithms, and storage locations for sensitive data (e.g., model weights, prompts).
Put it into practice
The SBOM Starter Templates from SourceLattice collects the templates and checklists behind this guide in ready-to-use form, so your team can apply the framework without drafting from scratch.