Securing LLM and Agentic AI Supply Chains: Lifecycle Frameworks and Execution-Bound Advisory

Introduction

Cryptographic provenance for artifacts, graph-aware reasoning over what artifacts contain, and continuous identity-based verification of where they run are the three foundations established in the companion articles. A production LLM system stresses all three at once because its supply chain is not code alone.

An LLM system depends on curated datasets, preprocessing pipelines, fine-tuning workflows, checkpoints, registries, model-serving APIs, retrieval systems, and orchestration interfaces [1]. The code is only one node in that chain. This part examines two peer-reviewed works that extend supply chain security into this lifecycle: a five-layer security framework for LLM supply chains with hybrid post-quantum artifact signing [1], and an execution-bound advisory pipeline that classifies exploitability for agentic AI from runtime telemetry [2].

The thesis of both papers is the same in different registers: presence is not exploitability. A component being present and signed does not mean it is safe, and a vulnerable artifact listed in a bill of materials does not mean it is exploitable in a specific running system.

This article is educational and not legal advice.

Why Classical Supply Chain Tooling Is Not Enough for Models

The layered framework paper starts from a precise boundary claim. Established mechanisms such as Sigstore, in-toto, SLSA, and TUF provide strong guarantees for artifact integrity and provenance, but they were designed for conventional software artifacts and do not fully capture AI-specific lifecycle threats such as data poisoning, training pipeline compromise, and retrieval-augmented prompt manipulation [1].

The failure is structural, not incidental. Unlike traditional packages, an LLM system is not produced from source code alone. Sigstore does not natively address dataset provenance, fine-tuning semantics, inference abuse, or prompt injection [1]. In-toto provides a strong provenance model for expressing which steps were performed, by whom, and in what order, which is highly relevant to the training layer, but it remains a general framework [1]. The guarantee stops at the artifact boundary, and in an LLM lifecycle the threats begin before artifacts exist and continue after they are deployed.

There is also a cryptographic horizon. Most artifact signing infrastructure relies on classical algorithms such as RSA or ECDSA. These are secure today, but they may be threatened by future large-scale quantum computers, which is why NIST standardised ML-DSA as a post-quantum signature scheme [1].

The Five-Layer Lifecycle Framework

The response is a layered security framework that models LLM security as a lifecycle control problem spanning five layers: Data, Training, Model, Inference, and Application [1]. For each layer, the framework identifies representative assets, threat classes, and defensive controls [1].

The threat taxonomy organises five classes across the layers [1]:

The Data layer covers collection, ingestion, curation, labeling, transformation, and metadata management, and is a primary target for poisoning and contamination because LLMs are highly sensitive to training signals [1]. Controls at this layer include lineage tracking, dataset validation, source reputation management, reproducible preprocessing, and provenance attestations [1]. The Application layer inherits the general theme with agentic detail, where retrieval-augmented and tool-calling systems add prompt injection, leakage, and tool abuse [1].

The framework is explicit that it is not a replacement for existing supply chain technologies but an organisation of them into a lifecycle-aware architecture [1].

A Poisoning Scenario Across the Layers

The central argument of the framework is best demonstrated by the representative poisoning scenario it constructs, which shows how an attack propagates across all five layers [1].

Step 1 is a Data layer compromise. The attacker introduces poisoned samples containing hidden triggers into a publicly sourced dataset used for fine-tuning, designed to activate specific model behaviours when certain prompts appear during inference [1]. Step 2 is Training layer propagation. The poisoned dataset is ingested into a training pipeline without sufficient validation, so the training process embeds the malicious behaviour into the model parameters [1].

Step 3 is Model layer persistence. The trained model is exported as a checkpoint and distributed through a model registry. Even if artifact signing ensures the artifact has not been modified after export, the embedded backdoor remains intact because the malicious logic was introduced earlier in the lifecycle [1]. Step 4 is Inference layer exposure: the compromised model is deployed behind an inference API, behaves correctly under normal prompts, and triggers hidden behaviour on crafted inputs [1]. Step 5 is Application layer exploitation, where the triggered behaviour leads to unsafe outputs, data leakage, or malicious tool invocation in retrieval-augmented or agent-based systems [1].

The point is direct: artifact integrity mechanisms alone cannot prevent lifecycle-origin attacks [1]. A signature proves a checkpoint is untampered after export; it says nothing about whether the parameters were malicious before export.

Hybrid Post-Quantum Signing as a Layer-Specific Control

Within this framework, hybrid post-quantum signing is positioned at the Model layer, at the artifact distribution stage. In a hybrid scheme, a model artifact is signed with both a classical digital signature, such as ECDSA, and a post-quantum signature, such as ML-DSA [1]. Verification policies can then require both signatures or define phased acceptance rules depending on ecosystem maturity [1].

The design carries two advantages. It maintains compatibility with current verification tooling and trust stores, so the transition does not demand a fork of the whole ecosystem. And it introduces long-term resilience against future quantum attacks, which matters for long-lived artifacts, archived checkpoints, and models used in regulated or critical systems [1].

The authors frame hybrid signing as most operationally relevant to long-lived artifacts and regulated settings, not as a universal defense [1]. The framework is equally explicit about the boundary of signing itself. It complements, but does not replace, the layered lifecycle controls, because signing addresses persistence and distribution, not the earlier poisoning, pipeline, and runtime threat classes.

Moving from Presence to Execution-Bound Exploitability

Where the five-layer framework organises a lifecycle, the AIBOM-driven advisory paper attacks a different deficiency in the same space: advisory reasoning. Current SBOM and AIBOM tooling answers the presence question, whether a vulnerable component exists. The proposed framework redefines the question as whether a vulnerability is actually exploitable in a specific execution context [2].

The contribution extends Software Bills of Materials to AI-specific artifacts with an Artificial Intelligence Bill of Materials (AIBOM), which acknowledges that AI systems require extended scope to include models and datasets [2]. The limitation the paper addresses is that AIBOM and SBOM workflows remain largely static, correlating declared components with vulnerability databases, and do not bind runtime context, execution telemetry, and advisory generation into one coherent lifecycle [2].

That gap produces three concrete failures the paper names: inflated remediation cycles, inconsistent exploitability claims, and limited reproducibility of security assessments [2].

The Three Conditions and the Tri-Protocol Architecture

Exploitability is classified by evaluating three conditions simultaneously [2]:

1. Whether the vulnerable component exists in the declared artifacts.
2. Activation. Whether the component is actually used during execution, from runtime telemetry.
3. Feasibility. Whether the environment allows the exploit to occur, from policy constraints.

Only when all three conditions are satisfied is a vulnerability classified as exploitable. This is the shift from presence-based to execution-bound reasoning [2].

The architecture is composed of three coordinated layers partnered with three protocols [2]: deterministic environment and artifact capture through the Model Context Protocol (MCP); structured runtime observation and agent coordination through the Agent2Agent (A2A) protocol; and governance, signing, and traceability enforcement through the AGNTCY orchestration layer.

MCP facilitates pre-execution capture of analytic context, dependency metadata, and model artifacts [2]. A2A enables secure delegation of actions between agents within bounded trust scopes [2]. AGNTCY coordinates registration, governance, and policy anchoring, and with dynamic provenance from the other layers produces the cryptographically verifiable advisory records [2].

The pipeline proceeds as a six-stage process: deterministic environment capture through MCP, runtime telemetry collection through A2A, vulnerability correlation, execution-bound exploitability inference, CSAF-VEX advisory generation through AGNTCY, and reproducibility validation [2]. The input has three classes: static artifact inventories including dependency lists, model hashes, prompt commit identifiers, tool endpoint definitions, and vector tables; and runtime telemetry from A2A sidecar agents such as system call events, dynamic library loads, outbound connection records, tool invocation traces, and observed privilege levels [2].

What the Evaluation Measured

The evaluation used approximately 10,000 component entries across synthetic agentic AI workloads ranging from 50 to 5,000 components, incorporating OSV, GitHub Advisory, KEV, and EPSS datasets [2].

The headline results are bounded but specific. The combined AIBOM-and-telemetry pipeline achieved an F1-score of 0.93, with precision 0.96 and recall 0.92, and reduced false positives by up to 42 percent relative to static SBOM-CVE matching without runtime validation [2]. Extending the bill of materials to AI-specific artifacts altered exploitability outcomes in 31 percent of AI-specific artifact cases [2].

The execution-bound reasoning also changed prioritisation. A hybrid risk tiering rule combining observed activation with EPSS probability and KEV presence reduced the set of high-priority alerts to a focused subset of approximately 18 percent of matched vulnerabilities, and an expert triage panel found the high-priority items materially more actionable than low-priority ones in 86 percent of sampled cases [2].

Two design disciplines keep these numbers honest. Every advisory record includes an MCP envelope hash, a deterministic justification built from feature conditions and activation evidence, and a signature anchored to the Sigstore transparency log, with justification text generated through deterministic templating rather than probabilistic natural language, preserving auditability [2]. And the sealed execution envelope enables exact replay, where re-execution of the envelope reproduces the same advisory output, which makes the reported reproducibility property testable rather than asserted [2].

Boundary Conditions Both Papers Acknowledge

Neither paper oversells its scope. The five-layer framework is paired with a prototype-oriented evaluation describing how controls can be instantiated in a reproducible pipeline and quantifying the practical overhead of hybrid signing, rather than a claim of production maturity [1]. The advisory pipeline reports results under controlled experimental conditions on synthetic workloads, and its authors identify that supervised predictions are measured for consistency with deterministic rules rather than against an independent ground truth, explicitly avoiding conflating classification performance with unverifiable external labels [2].

Two real-world complications anchor the honest reading. First, poisoning illustrates why signing and presence are necessary but not sufficient, because the malicious logic can be embedded before any artifact exists [1]. Second, runtime telemetry can itself be incomplete or noisy, which is precisely why the pipeline evaluates a deterministic rule-based baseline and a supervised variant, and why false-positive reduction rather than raw accuracy is the operational headline metric [2].

Putting Lifecycle Controls and Execution-Bound Advisory into Production

Both frameworks are prototype-oriented, which makes them suitable for incremental adoption rather than wholesale replacement of existing artifact integrity, SLSA, and TUF controls [1][2].

For the five-layer lifecycle, map each layer to an enterprise control you already operate and fill the gap rather than creating a parallel programme [1]. Data layer controls attach to dataset governance: lineage tracking, source reputation, validation and reproducible preprocessing, with provenance attestations recorded alongside the dataset rather than only on the derived model [1]. Training layer controls map to pipeline hardening where in-toto can express which steps were performed, by whom, and in what order, scoped to the training workflow [1]. Model layer controls are where hybrid post-quantum signing sits: sign model artifacts at distribution with both ECDSA and ML-DSA, and define a verification policy that requires both signatures or a phased acceptance rule depending on registry and verifier maturity [1]. Prioritise long-lived artifacts, archived checkpoints, and models used in regulated or critical settings for hybrid signing first, since those are where quantum resilience and verifiability over time matter most, and keep the scheme compatible with current trust stores so the transition does not fork the ecosystem [1]. Inference layer controls belong in the serving gateway with extraction and inversion monitoring, and Application layer controls belong in the retrieval and tool-calling perimeter where prompt injection, leakage, and tool abuse arise [1].

For execution-bound advisory, implement the six-stage pipeline as an evidence chain that can be audited, not as a black-box classifier [2]. Capture deterministic environment and artifact context through MCP before execution, including dependency lists, model hashes, prompt commit identifiers, tool endpoint definitions, and vector tables; collect runtime telemetry through A2A sidecars such as system call events, dynamic library loads, outbound connections, tool invocation traces, and privilege levels; correlate against OSV, GitHub Advisory, KEV, and EPSS; apply execution-bound inference that requires existence, activation, and feasibility together before a vulnerability is classified as exploitable; generate CSAF-VEX advisories through AGNTCY; and retain the sealed execution envelope for replay [2]. Every advisory should retain its MCP envelope hash, deterministic justification built from feature conditions and activation evidence, and Sigstore-anchored signature, with justification text produced by deterministic templating rather than probabilistic language generation so that audit does not depend on model output stability [2]. The pipeline achieved F1 0.93 with 42 percent false-positive reduction over static matching in synthetic evaluation across approximately 10,000 component entries, altered outcomes in 31 percent of AI-specific artifact cases, and narrowed high-priority alerts to about 18 percent of matches with 86 percent expert-rated actionability, which are useful pilot targets but remain controlled-condition results to be remeasured on enterprise data [2]. Start with AIBOM inventory for models and datasets, add execution telemetry for the highest-risk agentic tools first, and expand coverage as the 42 percent false-positive reduction and the 18 percent high-priority subset are validated against operational triage load.

So What: The Lifecycle Extends the Foundations

This article completes the series argument by extending the three foundations to the hardest case.

The provenance foundation extends to hybrid post-quantum signing at the model distribution stage, so that long-lived artefacts stay verifiable against both current and future cryptographic risk [1]. The reasoning foundation extends from SBOM graphs to AIBOM-driven execution-bound inference, so that exploitability reflects observed behaviour rather than declared presence [2]. The continuous verification foundation extends from workload posture to running agentic behaviour, where activation and feasibility become first-class inputs alongside existence [2].

The unifying lesson of the three-part series is that supply chain security fails when a system is treated as a point-in-time artifact. Signing the artifact, inventorying its contents, and checking the running workload are each necessary. The LLM lifecycle makes the same lesson unmissable, because the threat enters at the data stage, persists through training, survives signing, and only becomes visible at inference [1].

Conclusion

AI and agentic systems do not create a different kind of supply chain risk; they concentrate it. The five-layer framework shows that lifecycle-origin attacks such as poisoning traverse the data, training, model, inference, and application layers, and that artifact integrity alone cannot stop them, which motivates lifecycle-aware controls and hybrid post-quantum signing for long-lived model artifacts [1]. The execution-bound pipeline shows that exploitability can be decided from runtime evidence, with measurable reductions in false positives and reproducible, signed advisory output [2].

Both works are early-stage frameworks with explicitly bounded evaluations, and both point the same direction: in software supply chain security, the artifact is not the unit of analysis. The lifecycle is.

Technical Appendix