AI Data Bill of Materials (DBOM): Why AI Security Needs a Data Supply Chain

A Data Bill of Materials, or DBOM, is an inventory of every dataset that fed an AI model. It records the source of each dataset, the processing steps applied, the sensitivity level, the contractual terms governing use, and the model or agent the data ultimately shaped.

Pranava Adduri, Co-Founder and CTO of Bedrock Data, described it directly on episode 95: “In that same way, models have a DBOM, a data bill of materials. What data made its way into the training phase? Where did that data come from? What sets of processing did that data go from — original data to refined data to get it to a stage where it was training ready?”

That definition matters because most enterprise AI programs today have no usable inventory of the data feeding their models. They have spreadsheets, lineage tools for the warehouse, and informal documentation — but nothing that survives an auditor asking which customer records ended up in the latest fine-tune. A DBOM closes that gap.

Why an SBOM doesn’t cover AI training risk

The Software Bill of Materials has had a decade of regulatory attention. Executive Order 14028 formalized SBOM expectations; tools like Syft and Trivy make generation routine. None of that helps when the risk lives in the data, not the code.

An AI model can be wrapped in clean, well-audited software and still expose the business if the training data contained customer PII that should never have left a regulated zone. The binary is identical whether the model was fine-tuned on synthetic data or a leaked production dump. The SBOM can’t tell you which one happened. That’s why the agentic AI security conversation now extends past the agent’s permissions and into the training set itself. DBOM is the layer SBOM doesn’t cover.

What belongs in a DBOM

A useful DBOM lists more than dataset names. The minimum fields:

• Source — internal system, third-party vendor, public corpus, customer-uploaded, synthetic.
• Licensing and contract terms — granularity caps, geographic restrictions, retention limits.
• Sensitivity classification — tied to your existing scheme.
• Processing steps — anonymization, de-identification, sampling, filtering, augmentation.
• Training stage — pretraining, fine-tuning, RAG grounding, evaluation.
• Consuming model or agent — the downstream artifact that inherited this data’s risk.
• Owner — a named person accountable for the dataset’s accuracy and compliance.

Adduri extends this into the vendor contracts themselves: “In certain domains where the company might be procuring data from data vendors, there might be terms around what granularity of data can be used when training a model.” A DBOM that lists only internal datasets misses the contractual risk that comes with procured ones.

The failure mode DBOM prevents

The clearest failure is tainted training data. A dataset enters the training phase before its anonymization step ran. Customer emails, account IDs, or partial card numbers end up baked into the model weights. The model passes evaluation and ships. Six months later, an attacker uses prompt extraction to surface the original PII.

George Gerchow, CSO at Bedrock Data, framed why a CSO cares: “What’s the first thing that pops into mind during a security incident? Did any sensitive data ever get out? Is that data being misused, mishandled?” When the answer requires reconstructing the training pipeline from chat logs and Jira tickets, it arrives too late. When the answer is a DBOM query, it arrives in minutes.

From DBOM to guardrails: the gap analysis

A DBOM on its own is documentation. It becomes a security control when paired with runtime guardrails on the model’s output. Adduri described the pattern Bedrock built into its ArgusAI product: on the left, compute the DBOM — everything that went in. On the right, look at what the guardrails block and allow. The gap between the two is the exposure window. Anything sensitive that the DBOM proves was in training, that the guardrails don’t actively block, is a known leak path waiting to be triggered. Without a DBOM, that gap analysis can’t be computed, and guardrails are an act of faith rather than a control. It’s the same shape as the failure pattern in vibe coding, where the absence of a clear inventory of what an agent touched made the vulnerabilities hard to catch.

How to start without boiling the ocean

You don’t need a perfect DBOM on day one — a minimum viable one covering the highest-risk models first:

1. List the models and agents in production. A real census usually finds far more AI workloads than the security team knew about.
2. Pick the three highest-risk workloads by exposure to customer data, regulated workflows, and external-facing surface — the same scoping discipline that separates winning AI programs from the rest.
3. Document the data feeding those three first — source, licensing, sensitivity, processing, stage, owner. Pick a template; don’t harmonize the whole company.
4. Connect the DBOM to the guardrails for those three. Compute the gap. Close the highest-severity items.
5. Expand only after the first three are in steady state. Three models covered well beats fifty covered poorly.

Inventory, classify, monitor, remediate — the discipline is old. The novelty is that the inventoried asset is data, not endpoints. This is the visibility layer that makes AI compliance provable rather than aspirational, and it’s exactly where SOC 2 and audit readiness meet AI in practice.