Course: Course 2B — Securing & Attacking Harnesses and LLMs
Module: SDD-B07 — Agent SBOM and Supply Chain Assessment
Duration: ~30 minutes (spoken at ~140 wpm)
Format: Verbatim transcript with [SLIDE N] cues. Read aloud or use as speaker notes.
[SLIDE 1 — Title]
Welcome to SDD-B07. Agent SBOM and Supply Chain Assessment. The thesis is one sentence: an agent is not a program, it is a dependency graph with a model at the center, and every node in that graph is a trust dependency an attacker can reach. The Software Bill of Materials was built to enumerate the components in a compiled binary. The AI Bill of Materials extends it to enumerate the components in an agent. And the agent's supply chain is its attack surface.
This deep-dive is the concrete inventory practice that makes B4's trust surfaces and B11's governance obligations operable. Forty-five minutes, three sub-sections.
[SLIDE 2 — The SBOM-to-AI-BOM extension]
Start with what you already know. A Software Bill of Materials is a formal, machine-readable inventory of the components in a piece of software. Name, version, supplier, a unique identifier, the dependency relationship, a cryptographic hash. Executive Order fourteen-oh-twenty-eight made SBOMs a procurement condition for software sold to the US federal government. The practice is now baseline.
The AI BOM extends this. The left column on the slide is the solved problem — libraries, frameworks, the build toolchain. The right column is the extension: the model, the training data, the tools, the MCP servers, and the harness. And here is the load-bearing insight. Every component in the AI BOM is a trust dependency an attacker can reach. The model is reachable via the prompt channel — prompt injection, SDD-B03. The tools are reachable via tool-call manipulation. The MCP servers are reachable via the agent's outbound connections and via the servers' own attack surface. The training data is reachable retroactively via data-poisoning. A component not in the BOM is a surface not assessed.
[SLIDE 3 — log4j was a failure of inventory]
The motivating analogy. Log4j. The organizations that did not know they shipped log4j could not patch it, because they did not know they had it. That was a failure of inventory, not a failure of patching. The AI BOM exists for the same reason. You cannot govern an MCP server you do not know your agent calls. You cannot assess a model checkpoint you do not know it loads. You cannot scope a red-team engagement against a supply chain you have not enumerated. The undeclared component — a tool or server the agent uses at runtime but the BOM does not declare — is the agent equivalent of the unknown transitive dependency that made log4j damaging.
[SLIDE 4 — B07.1 section title]
Sub-section one. What the AI BOM adds, beyond the software SBOM.
[SLIDE 5 — The four AI-BOM component classes]
Four component classes. First, model components. The base model — architecture, parameter count, checkpoint hash, supplier. Any fine-tune adapters, like LoRA weights, and their provenance. The quantization scheme. The inference runtime — vLLM, llama.cpp, TGI. For a frontier API model, you record the provider, the model id, and the pinned version. Second, data components. The training corpora, their provenance and licensing. The evaluation sets. The retrieval-store contents the agent grounds on. Data is a component because it shapes behavior — a data-poisoning finding from B1 is a supply-chain finding.
Third — and this is the one that maps most directly to the attack surface — tools and MCP components. Every function-call tool the agent exposes: its name, its description, its backing implementation, its supplier. And every MCP server the agent connects to: its identity, its transport, the tools it exposes, its supplier. This is where the AI BOM meets B4's trust surfaces. Each tool and each MCP server is a trust-surface node. Fourth, the harness and orchestration components — the agent framework, the sandbox, the orchestration code. For an agent, the harness is the governance layer, so its version and provenance are security-critical, not just maintenance-critical.
[SLIDE 6 — B07.2 section title]
Sub-section two. Standards, generation, and validation.
[SLIDE 7 — The standards landscape]
Two dominant formats. CycloneDX, from OWASP — a JSON or XML specification, extended for AI through the ML-BOM and AI-BOM profile, which adds model and data component types. It also has a crypto-material extension, CDX one-point-six, for the agent's keys and attestation materials. CycloneDX is the format most build-and-pipeline tooling emits natively. SPDX, from the Linux Foundation, is the other dominant format — an ISO standard, ISO/IEC five-nine-six-two. It has an AI profile and a System Package Bill of Materials for AI, the SAI work. SPDX is more common in governance, licensing, and standards-compliance contexts, where its ISO standardization matters for procurement. Many toolchains emit both. The choice is less important than the practice: have an AI BOM, in a standard format, with the model, data, and tool components declared.
The NTIA published a working-group output defining the minimum elements of an AI BOM. Model identity. Architecture and parameters. Training data. Evaluation. Software and runtime. These are the floor, not the ceiling. A deployer who cannot produce an AI BOM meeting these elements cannot answer the first question a regulator, a procurement officer, or a red-team will ask.
[SLIDE 8 — Generation & validation pipeline]
Generation has two parts. The software-component part is solved — existing SBOM tooling, Syft, cdxgen, the build plugins, produces it. The AI-component part is semi-manual today, and is where most AI BOMs are incomplete. In a mature deployment, the agent's config-as-code is the source of truth, and the AI BOM is generated from it in CI, the same way a container image's SBOM is generated from the Dockerfile.
Validation is the assessment, and it has four checks. Completeness: does the BOM declare every tool, every MCP server, every model? Version pinning and drift: is the model version pinned to a specific checkpoint, and does the runtime match? Provenance and signing: are the components attested — SLSA build provenance, signatures, the supplier's checksum? And vulnerability and policy: do any components have known issues, or violate the deployer's policy?
The critical point: validation is continuous, not one-time. A production agent that updates its model, adds a tool, or connects to a new MCP server changes its AI BOM. The CI pipeline regenerates the BOM, validation runs, and a drift or undeclared component gates the deployment. A BOM that has drifted from the runtime is worse than no BOM — it gives false confidence.
[SLIDE 9 — B07.3 section title]
Sub-section three. Supply-chain assessment in an engagement.
[SLIDE 10 — The undeclared-component finding]
The highest-value supply-chain finding is the undeclared component: a tool, MCP server, model version, or data source the agent uses at runtime but the AI BOM does not declare. You find it three ways. Runtime configuration diff: sandbox-start the agent, log every tool it registers, every MCP server it connects to, every model it loads, and diff against the BOM. Network-observation diff: observe the outbound connections and compare to the declared external references. And behavioral inference — for a black-box target, prompt the agent to enumerate its own tools, observe which services it calls, infer the model from its outputs. Noisier, but it produces findings when the deployer's BOM and the runtime diverge.
Severity scales with reachability. An undeclared MCP server the agent contacts on every turn is critical — it is an indirect-injection source that governance does not know about and the red-team did not scope. An undeclared tool with limited invocation is lower-severity, but it is still a gap governance must close.
[SLIDE 11 — Model-version drift]
A common variant of the undeclared component: model-version drift. The BOM declares model version N, pinned, with a checkpoint hash. At runtime, the agent calls version N-plus-one — the provider rotated the checkpoint, or the deployer's floating alias resolved to a newer version, or the deployer updated without regenerating the BOM. The assessed agent is not the deployed agent. This matters because the model version is the single most important reproducibility field — a finding against version N may not reproduce against N-plus-one, and N-plus-one may have new vulnerabilities N did not. The control is version pinning — the config pins a specific checkpoint, not a floating latest alias — combined with drift detection in the validation step.
[SLIDE 12 — The AI BOM is the bridge]
The AI BOM is the bridge between B4, the trust surfaces, and B11, the governance. B4's trust-surface map is populated by the BOM's components: each tool, MCP server, model, and data source is a node in the trust graph. B11's governance inventory is the BOM plus ownership and policy metadata. And for incident response — B0's reporting duties — the AI BOM is the blast-radius input. When an incident occurs, the first question is "what was in the affected agent," and the answer is the validated BOM. A deployer who cannot answer — because they have no AI BOM, or because it has drifted — cannot scope the incident, cannot report it accurately, cannot determine which of their other agents share the vulnerable component.
And for a red-team engagement: the first question you ask the deployer is "what is in your agent." The answer is the AI BOM. If they cannot produce one, that is itself the first finding. Without it, you are scoping against a black box.
[SLIDE 13 — Lab and what's next]
The lab has you generate an AI BOM in CycloneDX JSON from a representative agent configuration, validate it against a runtime snapshot — detecting undeclared tools, undeclared MCP servers, and model-version drift — produce an undeclared-component finding report, and map the BOM's components to B4's trust surfaces. Python three-point-ten plus, no GPU. Next: SDD-B08, NeMo Guardrails. The production guardrail framework behind NemoClaw. The rails are themselves evaluated by models — so they are subject to the same injection risks. The guardrail is a model, and models are injectable. Let's go.
# Teaching Script — SDD-B07: Agent SBOM and Supply Chain Assessment **Course**: Course 2B — Securing & Attacking Harnesses and LLMs **Module**: SDD-B07 — Agent SBOM and Supply Chain Assessment **Duration**: ~30 minutes (spoken at ~140 wpm) **Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes. --- [SLIDE 1 — Title] Welcome to SDD-B07. Agent SBOM and Supply Chain Assessment. The thesis is one sentence: an agent is not a program, it is a dependency graph with a model at the center, and every node in that graph is a trust dependency an attacker can reach. The Software Bill of Materials was built to enumerate the components in a compiled binary. The AI Bill of Materials extends it to enumerate the components in an agent. And the agent's supply chain is its attack surface. This deep-dive is the concrete inventory practice that makes B4's trust surfaces and B11's governance obligations operable. Forty-five minutes, three sub-sections. [SLIDE 2 — The SBOM-to-AI-BOM extension] Start with what you already know. A Software Bill of Materials is a formal, machine-readable inventory of the components in a piece of software. Name, version, supplier, a unique identifier, the dependency relationship, a cryptographic hash. Executive Order fourteen-oh-twenty-eight made SBOMs a procurement condition for software sold to the US federal government. The practice is now baseline. The AI BOM extends this. The left column on the slide is the solved problem — libraries, frameworks, the build toolchain. The right column is the extension: the model, the training data, the tools, the MCP servers, and the harness. And here is the load-bearing insight. Every component in the AI BOM is a trust dependency an attacker can reach. The model is reachable via the prompt channel — prompt injection, SDD-B03. The tools are reachable via tool-call manipulation. The MCP servers are reachable via the agent's outbound connections and via the servers' own attack surface. The training data is reachable retroactively via data-poisoning. A component not in the BOM is a surface not assessed. [SLIDE 3 — log4j was a failure of inventory] The motivating analogy. Log4j. The organizations that did not know they shipped log4j could not patch it, because they did not know they had it. That was a failure of inventory, not a failure of patching. The AI BOM exists for the same reason. You cannot govern an MCP server you do not know your agent calls. You cannot assess a model checkpoint you do not know it loads. You cannot scope a red-team engagement against a supply chain you have not enumerated. The undeclared component — a tool or server the agent uses at runtime but the BOM does not declare — is the agent equivalent of the unknown transitive dependency that made log4j damaging. [SLIDE 4 — B07.1 section title] Sub-section one. What the AI BOM adds, beyond the software SBOM. [SLIDE 5 — The four AI-BOM component classes] Four component classes. First, model components. The base model — architecture, parameter count, checkpoint hash, supplier. Any fine-tune adapters, like LoRA weights, and their provenance. The quantization scheme. The inference runtime — vLLM, llama.cpp, TGI. For a frontier API model, you record the provider, the model id, and the pinned version. Second, data components. The training corpora, their provenance and licensing. The evaluation sets. The retrieval-store contents the agent grounds on. Data is a component because it shapes behavior — a data-poisoning finding from B1 is a supply-chain finding. Third — and this is the one that maps most directly to the attack surface — tools and MCP components. Every function-call tool the agent exposes: its name, its description, its backing implementation, its supplier. And every MCP server the agent connects to: its identity, its transport, the tools it exposes, its supplier. This is where the AI BOM meets B4's trust surfaces. Each tool and each MCP server is a trust-surface node. Fourth, the harness and orchestration components — the agent framework, the sandbox, the orchestration code. For an agent, the harness is the governance layer, so its version and provenance are security-critical, not just maintenance-critical. [SLIDE 6 — B07.2 section title] Sub-section two. Standards, generation, and validation. [SLIDE 7 — The standards landscape] Two dominant formats. CycloneDX, from OWASP — a JSON or XML specification, extended for AI through the ML-BOM and AI-BOM profile, which adds model and data component types. It also has a crypto-material extension, CDX one-point-six, for the agent's keys and attestation materials. CycloneDX is the format most build-and-pipeline tooling emits natively. SPDX, from the Linux Foundation, is the other dominant format — an ISO standard, ISO/IEC five-nine-six-two. It has an AI profile and a System Package Bill of Materials for AI, the SAI work. SPDX is more common in governance, licensing, and standards-compliance contexts, where its ISO standardization matters for procurement. Many toolchains emit both. The choice is less important than the practice: have an AI BOM, in a standard format, with the model, data, and tool components declared. The NTIA published a working-group output defining the minimum elements of an AI BOM. Model identity. Architecture and parameters. Training data. Evaluation. Software and runtime. These are the floor, not the ceiling. A deployer who cannot produce an AI BOM meeting these elements cannot answer the first question a regulator, a procurement officer, or a red-team will ask. [SLIDE 8 — Generation & validation pipeline] Generation has two parts. The software-component part is solved — existing SBOM tooling, Syft, cdxgen, the build plugins, produces it. The AI-component part is semi-manual today, and is where most AI BOMs are incomplete. In a mature deployment, the agent's config-as-code is the source of truth, and the AI BOM is generated from it in CI, the same way a container image's SBOM is generated from the Dockerfile. Validation is the assessment, and it has four checks. Completeness: does the BOM declare every tool, every MCP server, every model? Version pinning and drift: is the model version pinned to a specific checkpoint, and does the runtime match? Provenance and signing: are the components attested — SLSA build provenance, signatures, the supplier's checksum? And vulnerability and policy: do any components have known issues, or violate the deployer's policy? The critical point: validation is continuous, not one-time. A production agent that updates its model, adds a tool, or connects to a new MCP server changes its AI BOM. The CI pipeline regenerates the BOM, validation runs, and a drift or undeclared component gates the deployment. A BOM that has drifted from the runtime is worse than no BOM — it gives false confidence. [SLIDE 9 — B07.3 section title] Sub-section three. Supply-chain assessment in an engagement. [SLIDE 10 — The undeclared-component finding] The highest-value supply-chain finding is the undeclared component: a tool, MCP server, model version, or data source the agent uses at runtime but the AI BOM does not declare. You find it three ways. Runtime configuration diff: sandbox-start the agent, log every tool it registers, every MCP server it connects to, every model it loads, and diff against the BOM. Network-observation diff: observe the outbound connections and compare to the declared external references. And behavioral inference — for a black-box target, prompt the agent to enumerate its own tools, observe which services it calls, infer the model from its outputs. Noisier, but it produces findings when the deployer's BOM and the runtime diverge. Severity scales with reachability. An undeclared MCP server the agent contacts on every turn is critical — it is an indirect-injection source that governance does not know about and the red-team did not scope. An undeclared tool with limited invocation is lower-severity, but it is still a gap governance must close. [SLIDE 11 — Model-version drift] A common variant of the undeclared component: model-version drift. The BOM declares model version N, pinned, with a checkpoint hash. At runtime, the agent calls version N-plus-one — the provider rotated the checkpoint, or the deployer's floating alias resolved to a newer version, or the deployer updated without regenerating the BOM. The assessed agent is not the deployed agent. This matters because the model version is the single most important reproducibility field — a finding against version N may not reproduce against N-plus-one, and N-plus-one may have new vulnerabilities N did not. The control is version pinning — the config pins a specific checkpoint, not a floating latest alias — combined with drift detection in the validation step. [SLIDE 12 — The AI BOM is the bridge] The AI BOM is the bridge between B4, the trust surfaces, and B11, the governance. B4's trust-surface map is populated by the BOM's components: each tool, MCP server, model, and data source is a node in the trust graph. B11's governance inventory is the BOM plus ownership and policy metadata. And for incident response — B0's reporting duties — the AI BOM is the blast-radius input. When an incident occurs, the first question is "what was in the affected agent," and the answer is the validated BOM. A deployer who cannot answer — because they have no AI BOM, or because it has drifted — cannot scope the incident, cannot report it accurately, cannot determine which of their other agents share the vulnerable component. And for a red-team engagement: the first question you ask the deployer is "what is in your agent." The answer is the AI BOM. If they cannot produce one, that is itself the first finding. Without it, you are scoping against a black box. [SLIDE 13 — Lab and what's next] The lab has you generate an AI BOM in CycloneDX JSON from a representative agent configuration, validate it against a runtime snapshot — detecting undeclared tools, undeclared MCP servers, and model-version drift — produce an undeclared-component finding report, and map the BOM's components to B4's trust surfaces. Python three-point-ten plus, no GPU. Next: SDD-B08, NeMo Guardrails. The production guardrail framework behind NemoClaw. The rails are themselves evaluated by models — so they are subject to the same injection risks. The guardrail is a model, and models are injectable. Let's go.