SBOMs fall short for AI-native systems without data and model lineage

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Codenotary's blog post: Classical SBOMs remain useful for code, but are incomplete for AI-native systems because they miss data, model, inference, integration, and ownership details.

Why it matters: IAM, cloud, and AI governance teams need a fuller inventory model because access control, accountability, and incident response all depend on knowing which AI assets exist and who can reach them.

Context

SBOMs were built to answer a narrow but important question: what software components make up the thing we ship? That model still matters, but AI-native systems add data, models, endpoints, integrations, and runtime controls that a code-only inventory cannot describe. In practice, the security gap is not missing packages alone, but missing governance over the full AI asset chain, including identity and access to those assets.

A stronger inventory model has to treat AI systems as living production services rather than static artifacts. That means provenance, approval, ownership, and reachability all become security data, not documentation overhead. Where traditional SBOM thinking stops at build composition, AI governance has to extend into AI supply chain and AI-BOM concerns.

Key questions

Q: How should security teams govern AI systems when SBOMs only cover code artifacts?

A: Treat SBOMs as the starting point, not the control model. AI systems also need governed records for datasets, models, inference endpoints, integrations, and owners. That lets teams connect build provenance to runtime exposure, answer audit questions faster, and make incident response possible when outputs, data, or access paths change without a code release.

Q: Why is data lineage so important for AI governance?

A: Because AI outputs inherit risk from the data that feeds them. If teams cannot trace inputs, ownership, and changes over time, they cannot reliably explain model behaviour or defend decisions. Lineage gives governance teams the evidence needed to spot drift, judge trustworthiness, and know when a use case has moved outside its approved boundary.

Q: What are the signs that an AI inventory is too shallow to support security decisions?

A: A shallow inventory usually stops at packages and code repositories. If teams cannot identify dataset ownership, model versions, endpoint reachability, or downstream consumers, they are missing the operational layer that drives exposure. That gap usually appears first during incident response, when no one can quickly answer what was used, by whom, and where it flowed.

Q: How do IAM teams reduce blast radius for APIs and pipelines?

A: Scope each identity to a single resource set or workflow, remove broad administrative permissions, and disable identities that are inactive. Add monitoring for unusual token use, privilege escalation, and cross-environment access. The goal is to make one compromised credential far less capable of moving laterally.

Technical breakdown

Why classical SBOMs break down for AI-native systems

A traditional SBOM records code dependencies, libraries, and transitive packages. That is useful for vulnerability correlation, but it does not explain how an AI application behaves in production. AI systems also depend on datasets, trained models, inference endpoints, orchestration layers, and downstream integrations. Those elements can alter output, exposure, and compliance posture even when the underlying code is unchanged. The technical issue is scope: software composition alone is no longer the whole control surface. For AI, inventory has to represent both build-time assets and runtime dependencies. See the SBOM Guide.

Practical implication: Extend inventory scope beyond code artifacts so governance and security teams can assess the full AI control surface.

Why data provenance and model lineage matter

Data provenance tells you where training or operational data came from, whether it was approved, and whether it carries licensing, regulatory, or privacy constraints. Model lineage tracks base model origin, fine-tuning history, version identifiers, and update path so teams can trace outputs back to a specific lineage. In AI-native environments, these are not optional metadata fields. They are the evidence chain for accountability, debugging, and risk analysis. Without them, a clean code inventory can still mask an ungoverned model or a dataset that introduces legal or security exposure.

Practical implication: Record dataset provenance and model lineage as first-class governance data, not as ad hoc documentation.

Why inference endpoints and ownership metadata become control points

An AI system can be technically sound yet operationally unsafe if its endpoints are broadly reachable, poorly monitored, or unclear in ownership. The article points to access policies, observability hooks, downstream consumers, and accountable owners as part of the inventory. That is the right framing because runtime exposure and accountability determine who can interact with the system and who must respond when it misbehaves. In security terms, the issue is not just what was built, but who can invoke it and who owns the blast radius when it is used incorrectly.

Practical implication: Tie every AI endpoint to an owner, access policy, and monitoring path before it reaches production.

Threat narrative

Attacker objective: The objective is to exploit blind spots in AI supply chain visibility so harmful outputs, unauthorized access, or compliance failures are harder to detect and contain.

1. Entry occurs when an AI system is introduced with incomplete inventory coverage, so datasets, models, and endpoints are not fully governed from the outset.
2. Credential and access exposure follow when inference endpoints or downstream integrations are documented poorly, leaving unclear who can reach or influence the system.
3. Impact appears when teams cannot rapidly answer which dataset or model produced an output, slowing incident response and increasing compliance and governance failure.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SBOM-only governance creates an AI supply chain blind spot: code inventories are necessary, but they no longer describe the assets that actually shape AI behaviour. Datasets, models, inference endpoints, and runtime integrations are part of the operational trust boundary, which means AI governance has to treat them as inventory items with lifecycle status and access controls. Practitioners should stop asking whether their SBOM is complete and start asking whether their AI asset inventory is real.

Data provenance is the missing control plane for AI accountability: once a dataset can introduce licensing, privacy, or regulatory exposure, provenance becomes a security requirement rather than a records-management task. The same is true for model lineage, because a versioned model can change output risk without any code change. AI governance controls become materially stronger when teams can tie each AI artefact to origin, approval, and ownership. Practitioners should treat provenance as part of the evidence chain.

Operational visibility is the new AI blast-radius control: the article is right to connect inference endpoints, observability, and downstream systems to incident response. That is where AI systems differ from static software: the exposure surface is shaped by live reachability and consumption paths, not just build composition. When teams cannot see who can call a model or where its output goes, they cannot bound the blast radius. Practitioners should govern AI runtime exposure as aggressively as model content.

Ownership metadata is a governance control, not an admin convenience: ambiguity over who approved a dataset or owns a model slows both audits and response. In practice, missing ownership means no clear decision path for revocation, rollback, or exception handling. That is why AI governance programmes should require named accountability for each major component. Practitioners should make ownership mandatory before deployment, not after an incident.

From our research library:

• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

AI supply chain governance now has to include runtime reachability: the article captures a wider shift in which inventory is no longer a static bill of materials but a live map of what an AI system can touch and how it is consumed. That matters because access policy, observability, and ownership now influence security outcomes as much as the model itself.

Identity controls become more important when AI components are operationalised: every dataset, endpoint, and model version needs a lifecycle owner and a clear permission boundary. If organisations already struggle with service account visibility, they will struggle even more when AI assets are added to the same operational estate. The governance lesson is to extend inventory discipline before AI sprawl becomes normalised.

AI-BOM thinking should become a procurement and incident-response requirement: build-time transparency is not enough when the business depends on model lineage, licensing status, and downstream integrations. Teams that can only inventory code will miss the exposure created by data and runtime dependencies, so procurement and security reviews should insist on those fields up front.

For practitioners

• Define AI inventory scope beyond code Include datasets, model versions, inference endpoints, integrations, and downstream consumers in the asset register so the inventory reflects production reality.
• Record dataset provenance and approval status Capture source, licensing terms, classification, regulated-data flags, and approval evidence for every dataset used in training or inference pipelines.
• Track model lineage as a controlled asset Maintain base model origin, fine-tuning history, version identifiers, and update history so outputs can be traced back to a specific lineage.
• Bind access policy to every inference endpoint Document who can interact with each endpoint, what controls protect it, and which monitoring hooks record its use.

Key takeaways

• AI-native systems broaden the control surface beyond source code, so SBOM-only governance misses material security and compliance dependencies.
• The operational risk is visibility failure, not just dependency sprawl, because datasets, models, endpoints, and owners all affect exposure and accountability.
• Security teams should inventory AI artefacts as living assets so they can trace outputs, bound blast radius, and answer audit questions quickly.

Related NHI Mgmt Group resources: AI Supply Chain Security and AI-BOM Guide · SBOM Guide · Agentic AI Compliance Guide

Key terms

• AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.
• Data provenance: Data provenance is the record of where data came from, how it was created, and how it changed over time. In security and governance, it tracks source systems, transformations, ownership, and access history so teams can verify integrity, support auditability, and judge whether data is trustworthy for identity, AI, or operational decisions.
• Model Lineage: Model lineage is the traceable record of what data, code, training runs, evaluations, and approvals produced a deployed AI model. It is the trust chain for machine learning operations, because it lets security and risk teams verify provenance, investigate changes, and support rollback or audit requirements.
• Inference endpoint: An inference endpoint is the interface where a model receives input and returns an output. Because it exposes live behaviour, it becomes a security boundary that can be abused through weak authentication, prompt injection, traffic abuse, or data extraction if not monitored and constrained.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, helps practitioners connect identity governance to machine identities, secrets, and agentic AI controls. It is relevant for teams that need to align AI governance with broader identity security programmes.