AI Bill of Materials: How to Generate and Use AIBOM

A surprising amount of AI governance still starts with a spreadsheet, even though the strongest evidence now comes from source code. The AI Bill of Materials is moving toward a standards-based, machine-readable provenance graph, not a hand-written inventory, and the Linux Foundation's SPDX 3.0 work explicitly includes AI BOM support. That shift matters because it replaces “what a team says is running” with a structured record of models, datasets, dependencies, configuration, and deployment context that can be traced across security and compliance workflows (Linux Foundation research on AI BOM).

Table of Contents

• What an AI Bill of Materials Actually Is
  • Why this is different from an SBOM for AI
• The Six Elements Every AIBOM Must Capture
• How an AIBOM Is Generated from Source Code
  • What the Scan Does
• What Static Dependency Lists Miss in Agent Code
• Mapping AIBOM Evidence to Controls and Audits
  • What auditors need to see
• Prompt Injection and Indirect Prompt Injection as AIBOM Risks
  • Where the risk enters
• Using AIBOM Evidence to Govern Agent Adoption
  • A decision pattern that works
• Frequently Asked Questions
  • What is the difference between an AIBOM and an SBOM for AI?
  • Does an AIBOM require runtime access to be useful?
  • How often should an AIBOM be regenerated?
  • What evidence should an AIBOM tool export for auditors?
  • Can an AIBOM help with prompt injection risk?

What an AI Bill of Materials Actually Is

A useful AI Bill of Materials is a machine-readable provenance graph that shows how an AI system was assembled, trained, validated, and deployed. That matters because a text model card or spreadsheet usually records intent, while an AIBOM has to preserve the assets and relationships that drive exposure.

The value is traceability. A proper AIBOM ties models, datasets, code, hardware, data-processing pipelines, and governance metadata together so teams can trace lineage, licensing, and deployment context. Standards work around SPDX 3.0 and AI support points toward an interoperable artifact that fits broader software bill of materials practices instead of a one-off governance template.

Practical rule: if the record can't answer what changed, who approved it, and what it depends on, it's documentation. It's not yet an AIBOM.

A text-based model card can still be useful, but it usually stops at description. A real AIBOM needs to connect versions, sources, and runtime context so downstream teams can reason about security and incident response. That is the difference between a narrative about an AI system and a structured record that can support audit and triage.

Why this is different from an SBOM for AI

An SBOM for AI is a close cousin, but the AI version has to account for model lineage, data dependencies, and governance metadata that ordinary software inventories never capture. Cross-border policy work frames the topic as a supply-chain concern, extending beyond a simple vendor best practice, which is why public-sector procurement teams care about it too (European Commission and partner governments on SBOM for AI).

For regulated workloads, that difference is practical. A list of packages does not show which model was fine-tuned, which dataset was used, or which external service is reached during inference. An AIBOM does.

The Six Elements Every AIBOM Must Capture

A defensible AIBOM starts with the same question every reviewer asks in an audit, incident, or procurement review. What exactly does this system rely on, and where can it fail?

The minimum answer set is broader than many anticipate. Guidance from BSI's minimum-elements work includes fields such as SBOM version, data format name and version, author signature, tool name and version, generation context, timestamp, and dependency relationship, which makes the artifact auditable rather than descriptive (BSI minimum elements for AI SBOM). That is the right direction for governance, because evidence has to survive review.

A model entry without lineage is weak. A dependency list without version pinning is weaker. A runtime record without governance metadata leaves reviewers guessing whether the system was approved or merely deployed.

If a field does not change a decision, it is probably not enough. If a missing field would slow incident response, it belongs in the AIBOM.

The strongest version of the artifact connects those element classes into a single provenance graph. That is what lets security teams answer different questions with the same record. Procurement wants ownership and licensing. AppSec wants transitive dependency risk. GRC wants approval evidence. Incident response wants the blast radius.

How an AIBOM Is Generated from Source Code

Generation starts in the repository. A practical workflow reads manifest files, resolves the dependency tree, follows import statements, detects embedded models or hosted inference calls, and then enriches the findings with runtime-relevant metadata such as tool bindings and external services.

That sequence matters because declared dependencies are only the first layer. The useful inventory comes from transitive resolution and relationship mapping, which is where hidden model calls and indirect service use become visible. A source-code-derived record can also attach file and line references, which makes later review much faster than arguing over a manually assembled spreadsheet.

What the Scan Does

A zero-touch, read-only repository scan gives a cleaner pre-adoption view than runtime observation alone. Runtime telemetry tells teams what happened in production. Source code tells teams what is capable of happening before anything is deployed. For evaluation work, that inside-out view is the one that matters first.

The scan should surface the following:

• Declared dependencies, so the team knows what the developer intentionally added.
• Transitive dependencies, so hidden libraries and nested services are not missed.
• Embedded model references, including hosted endpoints and packages that wrap external inference.
• Tool bindings and permissions, so the system's reach can be mapped to capabilities.
• Data paths and external services, so downstream risk is visible before adoption.

The difference shows up in procurement and review. A static manifest says that a package exists. A source-code-derived AIBOM shows whether that package calls an external model, whether the model is hard-coded or environment-driven, and where the call path flows.

Practical rule: code-level evidence buys precision. Runtime-only observation buys timing. Regulated teams need both, but they should start with code because it explains intent and reach before deployment.

A free first scan is the fastest way to see that difference in practice, especially when teams need to compare a declared manifest against the actual AI surface area. The repository scan is the primary check.

What Static Dependency Lists Miss in Agent Code

A declared package list is not the same thing as the effective AI surface. In Agntz's dataset of 10,000+ public open-source agent repositories, that gap shows up again and again. Repositories often name one thing in metadata while the code reaches into model endpoints, tool layers, and service wrappers that never appear in the manifest.

A chatbot can pull a hosted embedding model from an environment variable and never mention it in a requirements file. A tool wrapper can call an external inference endpoint that only exists inside a function body. An MCP connection can route requests to a vendor that nobody approved during dependency review. A flat dependency list misses all of it.

The failure is in effective reach.

Security teams need to know where the agent can send data, which models it can invoke, and which external services it depends on at runtime. That reach is often buried in config files, environment variables, import chains, and tool definitions. A manifest sees package names. It does not show how those packages are used.

A representative repository pattern makes the gap obvious:

• Declared dependency says one vendor. The code imports a second inference SDK through a helper library.
• Tool binding says “search.” The actual tool call passes retrieved text into a model with broader output rights.
• Requirements file is clean. The application still reaches an external hosted model through an environment variable.
• Package list looks small. The import graph pulls in transitive vendors that were never reviewed.

That is why flat SBOM-style thinking fails for agents. It records names, not reach.

A source-code scan has to treat the repository as evidence. It should read manifests, follow imports, resolve transitive dependencies, and map tool bindings to capabilities and permissions. That is how shadow vendors and hidden inference paths surface before runtime. The output is a control-relevant provenance graph, not a static inventory.

Shadow AI in your codebase is the right mental model for the review. Hidden AI use is usually not malicious. It is undocumented, and undocumented code still creates audit risk, incident risk, and procurement risk.

Mapping AIBOM Evidence to Controls and Audits

AIBOM evidence only matters when a reviewer can use it. The output has to map to specific controls, not just to framework names. A useful evidence package carries file references, line references, call-path provenance, and explicit control mapping, so a compliance lead can defend the conclusion without re-running engineering analysis.

Code-level provenance also changes how reviews happen. A file and line reference shows where the behavior lives. A call path shows how the code is reached. The control mapping shows why the finding matters under the chosen framework.

What auditors need to see

Different frameworks ask for different evidence, but the underlying artifact stays the same. An AIBOM can support ISO/IEC 42001, NIST AI RMF, ISO/IEC 27001, SOC 2, HIPAA, CMMC, SR 11-7, and ITAR when it ties the technical record to the control intent. The goal is not to claim framework coverage by label. The goal is to show verifiable code state behind the label.

A defensible export usually includes:

• Component identity, so the reviewer knows what model, dataset, or tool was assessed.
• Source location, so the reviewer can trace the finding back to repository evidence.
• Call path, so the reviewer can see how the component is used.
• Control reference, so the reviewer can tie the issue to a named requirement.
• Approval or exception record, so the reviewer can see whether risk was accepted.

The best audit artifact answers three questions at once. What is it, where is it, and who signed off on it?

That structure helps procurement too. Vendors should be able to export evidence on demand without hand-curating a response packet. If the export cannot support sign-off, incident response, and control review from the same record, the artifact is not mature enough for regulated adoption.

For teams that want a quick exposure read before audit work begins, the AI risk calculator can provide a first pass. It estimates exposure. The AIBOM is the evidence layer that explains it.

Prompt Injection and Indirect Prompt Injection as AIBOM Risks

Prompt injection is not just an application-layer bug. It is a path problem. If an agent can read untrusted text, call tools, and return results, the AIBOM needs to show those paths explicitly. A list of models and libraries cannot answer whether those paths are exposed.

Where the risk enters

Direct prompt injection enters through user input. Indirect prompt injection enters through external content that the agent consumes, such as retrieved documents, web pages, or vendor feeds. The second class is especially important because the attack payload is hidden inside data that looks legitimate to the system.

A concrete example is easy to trace. An agent retrieves a third-party document, sends it to a model, and then uses the model output to trigger a tool call. The AIBOM should record the retrieval tool, the model, the data source, and the autonomy loop. What it cannot safely omit is the untrusted content boundary, because that is where injected instructions can exfiltrate context or redirect execution.

Guidance from security-oriented AIBOM publications points toward the same conclusion. The useful unit of governance is not the model alone. It is the model plus tool binding plus data path plus runtime identity. If any of those are missing, the team cannot tell where injected instructions may land or what they can reach.

A good AIBOM also helps teams spot the places where agents over-trust external inputs. That includes document loaders, search tools, browser connectors, and MCP integrations. Those are the paths that need review before deployment, not after a suspicious response appears in logs.

AI agent security risks become much easier to reason about once the source code has been turned into a capability map. The code reveals the entry points. The AIBOM reveals the reach. Together, they show whether prompt injection would be noisy or catastrophic.

Using AIBOM Evidence to Govern Agent Adoption

A good adoption decision starts with inside-out evidence, then adds outside-in observation once a system is already live. The inside-out view comes from source code. It produces the AIBOM, the capability map, and the blast-radius picture. The outside-in view comes from runtime observation. It confirms what is executing.

Those two views serve different decisions. Source code shows what an agent can do before it runs. Runtime shows what it did after deployment. For regulated adoption, the primary question is whether the declared capability set is acceptable, and that is separate from whether telemetry looks clean.

A decision pattern that works

The strongest pattern is straightforward.

1. Scan the repository. Resolve declared and transitive dependencies. Surface embedded models, tool bindings, data paths, and external services.
2. Review the AIBOM. Check model lineage, dataset sources, dependency chains, and governance metadata.
3. Score blast radius. Map each capability to the assets it can touch, especially sensitive data and external endpoints.
4. Correlate vulnerabilities. Link relevant dependency issues to the paths the agent uses.
5. Decide and record. Approve, restrict, or decline with a rationale tied to controls and evidence.

This workflow creates a durable record for R&D, security, and GRC. If the agent is approved, the AIBOM becomes the baseline for drift detection. If the agent is restricted, the risky path is explicit. If the agent is declined, the evidence explains why without argument over package names alone.

A source-code-derived AIBOM is useful because it makes hidden reach visible before rollout. In practice, that means you can spot shadow vendors, transitive models, and tool chains that never show up in a static manifest. On a dataset of 10,000+ open-source agent repositories, that code-level view is what separates a clean dependency list from a real provenance graph.

The fastest way to get that baseline is a first scan that turns repository evidence into a reviewable inventory. Teams that need a quick pre-review estimate can use the risk calculator as a secondary read. The governing principle stays the same. Approvals should follow code-level evidence, not vendor reassurance.

Frequently Asked Questions

What is the difference between an AIBOM and an SBOM for AI?

An AIBOM goes beyond a software inventory. It captures models, datasets, tool bindings, governance metadata, and the relationships between them. An SBOM for AI can help with structure, but it usually stops earlier. For regulated AI systems, the extra provenance is what supports traceability, incident response, and defensible reviews.

Does an AIBOM require runtime access to be useful?

No. A source-code-derived AIBOM is valuable before deployment because it shows declared dependencies, transitive reach, and embedded AI paths. Runtime access adds confirmation, but it doesn't replace code-level evidence. For pre-adoption decisions, source review is the better starting point because it reveals intent and exposure before the system runs.

How often should an AIBOM be regenerated?

It should be regenerated whenever code, dependencies, models, datasets, or tool bindings change. In practice, that means on every meaningful repository update, not on a fixed annual cycle. If the AIBOM lags behind the codebase, the inventory stops being evidence and becomes stale documentation.

What evidence should an AIBOM tool export for auditors?

Auditors usually need file references, line references, call paths, component identities, and the control mapping used to interpret the finding. Approval records and exception records help too. The key is that the export must show verifiable code state, not just a framework tag or a summary statement.

Can an AIBOM help with prompt injection risk?

Yes, if it includes tool bindings, external data sources, and autonomy loops. Prompt injection risk becomes much easier to reason about when the record shows where untrusted content enters and what tools the agent can reach. A model list alone won't surface that exposure.

---

Agntz reads source code to build an AI Bill of Materials, map capabilities, and score blast radius before runtime. It gives security and governance teams evidence-backed visibility into models, tools, data paths, and external services so adoption decisions don't rely on guesses. Visit Agntz to run a free first scan and see what your repository is exposing.