What Is an AI-BOM and Why Does the Model Supply Chain Matter?

An AI bill of materials is a structured inventory of the model artefacts and software dependencies behind an AI application. It records context such as provenance, version and licence position, and can flag unsafe serialised formats for review. Its purpose is visibility and traceability, not a guarantee that every component is safe.

The endpoint is what users and applications call, but it hides the composition beneath it. A named application may depend on model weights, an inference runtime, retrieval dependencies, tokenisation packages and agent tool bindings. When one of those changes, the risk and review context can change even if the endpoint URL stays the same.

Cerberus connects this supply-chain view to a registered AI endpoint, application or agent, its owner, environment and assessment history. That lets a reviewer ask what changed and which named system is affected.

Model provenance describes where an artefact came from and how it entered the controlled environment. Version identifies the specific artefact in use. Licence context gives procurement and legal teams information they can assess rather than leaving the dependency invisible.

Software dependencies matter because model behaviour is delivered through code. The inference runtime and related packages become part of the operational supply chain. Unsafe serialised model formats deserve explicit attention because loading them can carry code execution risk.

Agent tool bindings add another dimension. They describe the capabilities an application can invoke around the model. Recording them does not replace runtime authorization, but it helps reviewers see whether the application surface changed from interpretation to action.

• 01Model artefact and version
• 02Provenance and provider context
• 03Licence context
• 04Inference and retrieval dependencies
• 05Serialisation format
• 06Agent tool bindings

Adversarial testing asks how the application behaves under crafted inputs. It can surface prompt injection, information disclosure, excessive agency and other application-level failure modes. It does not, by itself, explain the composition and provenance of the artefacts behind the target.

Supply-chain review asks a different question: what is this system made from, and what changed since the last review? The two views complement each other. Cerberus reports AI-BOM results alongside mapped adversarial findings against the same registered system.

Neither view establishes regulatory conformity. Framework mapping, inventory and signed evidence help security, risk and procurement teams conduct their own review. They do not confer certification or remove the need for organisational judgement.

The inventory is most useful when it is tied to a named application, owner and environment. A new model version, dependency change, retrieval component or tool binding can then become an explicit trigger for review.

A review may preserve the current scope, require another adversarial assessment, change permitted tool access or stop use until the new dependency is understood. The response depends on policy and consequence, not on the mere fact that a version changed.

Cerberus produces signed PDF and JSON reporting with an evidence bundle that can be verified offline. The signature supports integrity checking of the delivered record. It does not certify the underlying model or application.

Ask whether the system has a named owner, whether model and dependency versions are identifiable, where artefacts came from, what licence information is available, whether unsafe formats are detected, and what change triggers another review.

Also ask where the inventory and assessment evidence live. For sensitive and disconnected environments, generating the AI-BOM locally avoids exporting model artefacts or findings to an external analysis service.

The goal is not a perfect list that never changes. It is a controlled record that changes visibly and stays connected to assessment, ownership and remediation.