Executive briefThe application did not change, but the product did
TLDR
- An agentic supply chain includes models, prompts, policies, data, memory, tools, identities, evaluators, people, protocols, software, infrastructure and legal rights.
- A conventional software bill of materials remains valuable, but cannot describe every dependency that changes behaviour, authority, evidence or permitted use.
- A fourteen-class Agentic Bill of Materials connects each business capability to versioned components, provider chains, integrity, rights, change feeds and retirement.
- A Transitive Trust Graph and Change Blast-Radius Query turn component events into affected decisions, populations, credentials, releases, controls and recovery actions.
- Admission depends on consequence: a component needs traceable identity, provenance, licence, authority, change control, evidence and containment or substitution.
A customer-support agent began escalating more cases and selecting a broader tool route. The application repository, container digest, package lockfile and deployment manifest were unchanged. Its software bill of materials matched the approved release. The cause was a managed-model alias that now resolved to a different effective model and safety configuration. The provider had delivered a valid service, yet the system's behaviour and evidence envelope no longer matched the approved product.
Agentic systems import behaviour and authority through more than software. System instructions determine precedence. Retrieval corpora supply facts and embedded instructions. Tool schemas expose operations and side effects. Identity brokers issue credentials. Evaluators influence release decisions. Human reviewers supply judgements. Peer agents bring protocols and trust assumptions. Managed endpoints can alter routing, configuration and underlying models without creating a customer-visible artefact.
A component can remain available, signed and uncompromised while still invalidating the system. A corpus licence can expire. A prompt can change tool selection. A connector can add a write behind an unchanged method. An evaluator can change threshold. A moderation subcontractor can move processing location. A cloud failover can shift jurisdiction. These are supply-chain events because externally or internally supplied dependencies changed the product's operating claims.
The enterprise therefore needs a transitive, versioned map from business capability and decision to the components, providers, evidence and authority on which it depends. The map must answer a release question, an incident question and an exit question. It should identify which deployments relied on a changed evaluator, which populations were exposed to an alias, which credentials trust a compromised broker and which recovery plans share the same region.
This paper introduces a fourteen-class Agentic Bill of Materials, a Transitive Trust Graph, a Change Blast-Radius Query and a consequence-sensitive Supply-Chain Admission Rule. The aim is not exhaustive cataloguing. It is decision relevance: enough identity, relationship and evidence to contain a component, revalidate an affected claim, substitute a dependency or withdraw a capability.
The strongest rival: inventories decay faster than they help
Exhaustive dependency catalogues can become expensive repositories of stale detail. Mature software supply-chain systems already represent source, packages, containers, build provenance, signatures, vulnerabilities and licences. SLSA, in-toto, SPDX, CycloneDX and Sigstore supply important, machine-readable foundations. Rebuilding those capabilities in an AI register would increase cost while weakening verification.
The answer is selective extension. Preserve authoritative software and asset systems, then add decision-relevant model, prompt, data, tool, evaluator, human, identity, provider and change relationships. A low-impact internal parser may need only a narrow set of edges. A consequential agent that commits payments or handles regulated data needs deeper provider, authority, evidence, continuity and exit traversal. The map earns its upkeep by answering concrete questions, not by maximising component count.
Agentic Bill of MaterialsFourteen component classes anchored to a business decision
1. Business capability
Name the outcome, decision, authority, population, environment, consequence and recovery need. This is the root of materiality, not another technical component.
2. Agent and orchestration
Record agent definition, planner, state machine, routing logic, runtime, limits and version. Include configuration that changes sequencing or delegation.
3. Model service or artefact
Identify provider, endpoint, model, weights, adapter, configuration, region and effective version. A family or marketing alias is not a release identity.
4. Prompt and policy artefacts
Version system instructions, templates, policies, schemas, examples, priority and integrity. Diff semantics as well as text.
5. Data and retrieval
Map corpus, licence, transformations, chunks, embeddings, index, entitlements, freshness, location and deletion. Derived stores retain source obligations.
6. Memory and state
Record case state, checkpoints, conversations, summaries, long-term memory, persistence service, retention and restoration semantics.
7. Tools and connectors
Name server, operation, schema, side effects, dependencies, owner and version. Method compatibility does not prove unchanged business effect.
8. Identity and credentials
Trace trust domain, issuer, workload identity, broker, certificate, token and secret lifecycle. Link compromise to every dependent action route.
9. Guardrails and evaluators
Identify classifier or judge model, rules, test set, thresholds, provider, version, limitations and decision authority. Evaluation is itself supplied behaviour.
10. Human services
Map reviewers, annotators, red teams, support and moderation, including location, training, access, subcontractor and continuity.
11. External agents and protocols
Record peer identity, agent card, task contract, protocol release, authentication, delegation and trust assumptions. Interoperability never supplies enterprise authority.
12. Software and build
Retain source, packages, containers, builders, steps, signatures, attestations, deployment subjects and vulnerability evidence from existing systems.
13. Infrastructure
Connect cloud, region, accelerator, network, storage, observability and shared control services. Hidden common infrastructure creates correlated failure.
14. Commercial and legal
Record supplier, sub-provider, licence, data and training rights, change terms, evidence rights, continuity, geographic constraints and exit.
Every component record carries identity, version, owner, source, integrity evidence, licence, configuration, provider chain, data access, authority, consequence relevance, known vulnerabilities, unresolved findings, change feed, substitutes, last verification and retirement state. The fields can point to authoritative repositories rather than copy their contents. The bill of materials is a federated view with stable identifiers and typed relationships.
Completeness is claim-specific. A container inventory may be complete for package vulnerability response but incomplete for a release claim that depends on a managed evaluator and human-review service. The record states which component classes and provider depths were resolved for the business capability, what remains unknown and who accepted any bounded uncertainty. Unknown does not silently become low risk.
| Class | Minimum stable identity | Material change signal |
|---|---|---|
| Managed model | Provider, endpoint, effective model, configuration, region and resolved time | Alias, routing, safety configuration, data handling or deprecation changes |
| Prompt, policy or evaluator | Digest, semantic version, owner, precedence or threshold and release binding | Instruction priority, schema, judge model, threshold or test population changes |
| Data, embedding or index | Source snapshot, rights, transformation, model, index and entitlement version | Licence, source composition, embedding model, deletion, freshness or access changes |
| Tool, identity or human service | Operation or service identity, authority, provider chain, location and owner | Side effect, issuer, privileged access, subcontractor, location or training changes |
| Software and infrastructure | Source, builder, subject digest, deployment identity, cloud, region and shared service | Build step, signature identity, deployment subject, region or control-plane changes |
Transitive Trust GraphMake every imported behaviour and authority traversable
The graph uses typed edges: built from, configured by, retrieves from, acts through, authenticated by, evaluated by, operated by, hosted on, supplied by, shares failure mode with, can replace and invalidates when changed. Direction matters. A model service may be supplied by one provider, hosted on another cloud, authenticated by a third issuer and evaluated by a judge from the first model family. A flat vendor list hides those relationships.
Edges carry scope and time. A prompt configures one agent version in production from a stated date. An index retrieves from a licensed corpus snapshot. A credential broker authenticates selected tools. A human-review service operates only a high-consequence queue in one jurisdiction. A substitute edge states tested equivalence, conversion need, recovery time and residual loss. Without time and scope, a correct graph becomes misleading after the next release.
Graph writers remain distributed. Build systems write provenance and deployment subjects. Model gateways resolve managed endpoints. prompt and policy repositories write digests. Retrieval systems record corpus, embedding and index lineage. Identity systems publish issuer and broker relationships. Procurement records provider and rights chains. Human-operations owners record subcontractors, location and training. The graph rejects anonymous nodes and marks missing links rather than inventing them.
A trust edge is not an endorsement. “Evaluated by” means the release depended on that evaluator; it does not certify the evaluator as correct. “Signed by” proves a verified signer relationship when policy validates it; it does not prove source approval, builder integrity, deployment match or behavioural fitness. “Can replace” is a tested contingency claim, not a catalogue suggestion.
Graph quality is measured by decision utility. Can the team identify every release that used a changed prompt? Can incident responders find agents whose tools rely on a compromised issuer? Can procurement see that nominal competitors share a region? Can an exit rehearsal locate data, state, evaluation and evidence assets? If not, the missing node or edge is material even when the total inventory is large.
Evidence planesCryptographic integrity and behavioural assurance answer different questions
Artifact integrity asks whether a subject came from the expected source and builder and remained untampered. SLSA defines approved source and build tracks and recommended provenance formats. in-toto provides verifiable statements about a subject and predicates. Sigstore associates signing with identity and transparency evidence. SPDX 3.0 and CycloneDX 1.7 can represent software, models, data, services, licences and relationships. These mechanisms strengthen traceability and verification.
They do not prove that a prompt chooses the right tool, an evaluator reflects the affected population, a model alias preserves behaviour, a dataset licence permits the current use or a human reviewer follows the required practice. A signed container can faithfully contain an unapproved build step. A valid signature can bind the wrong deployment subject. Provenance can accurately show that a disallowed source produced the artefact. Verification policy must check expected identity, source, builder, predicate, parameters and subject before integrity evidence is accepted.
Behavioural assurance asks whether the component and composition meet the capability's claims under expected and adversarial conditions. It links identity and version to evaluations, limitations, operating envelope, human role, tool effects and recovery. Model cards and datasheets can describe intended use, performance, composition and maintenance, but they remain bounded evidence supplied for defined artefacts and populations. They do not certify the enterprise use.
Licence and data evidence asks whether source, derived artefact, training, embedding, retention, transfer and commercial use remain permitted. Authority evidence asks which component can read, decide, act, approve or issue credentials. Change evidence asks how updates are notified, resolved, pinned, canaried, rolled back and revalidated. Continuity evidence asks whether containment, substitution and retirement work. A single supply-chain score would conceal which plane failed.
| Plane | Question | Non-substitute |
|---|---|---|
| Integrity and provenance | Did the expected source and builder produce this exact subject? | A valid signature cannot establish behavioural fitness or permitted use |
| Behaviour and evaluation | Does this version support the release claim and known limits? | Passing tests cannot cure unknown origin or unapproved deployment subject |
| Licence, data and geography | May the organisation use, transform, retain and transfer the component here? | Availability and technical compatibility do not preserve rights |
| Authority and change | What can it do, who can change it and how is revalidation triggered? | Documentation without enforcement cannot contain a privileged component |
| Continuity and exit | Can the component be isolated, substituted and retired with evidence? | A vendor alternative is not a tested recovery path |
Change Blast-Radius QueryTurn a provider event into a bounded action list
A blast-radius query begins with an event identity, effective time, observed or suspected state and confidence. It traverses typed edges to affected capabilities, decisions, populations, tools, credentials, evaluations, releases, control tests, regulatory evidence, continuity plans and owners. Results separate direct dependence, transitive dependence, shared failure and uncertain lineage. Each hit carries the edge path so an owner can challenge why it was included.
A managed-model alias update traverses from endpoint resolution to agent versions, behavioural evaluations, security tests, human operating instructions, release approvals and exposed populations. Software-build provenance may remain valid. A changed evaluator instead traverses from judge identity and threshold to every evidence item and release decision that used its result. Re-running application unit tests would miss both events.
A credential-broker compromise follows authenticated-by edges to workload identities, tokens, tools and receiving resources, then to actions during the possible exposure window. It joins the credential lifecycle in Paper 114 with the component map. An expired corpus licence follows retrieves-from and derived-from relationships into chunks, embeddings, indexes, evaluations, prompts and released products. Technical availability does not stop the legal blast radius.
The query produces actions, not merely matches. Contain a route, hold a release, rotate an identity, re-evaluate a claim, notify an owner, narrow exposure, substitute a component, preserve evidence, retire an artefact or accept a bounded exception. Each action has deadline, authority, evidence and closure receipt. Unknown lineage opens investigation and blocks automatic promotion where consequence warrants it.
Change feeds arrive through provider notices, resolved endpoint fingerprints, repository events, data-rights systems, vulnerability records, identity telemetry, human-service attestations and monitoring. A feed is not trusted solely because it is automated. Events are signed or authenticated where possible, correlated with observed state and deduplicated. The system records when supplier notice was absent or too late because that gap affects future admission.
Provider chains and shared failureVendor count is not diversification
Two model providers may run in the same cloud region, depend on the same identity issuer, use the same evaluator family and route moderation to the same human service. Procurement sees two contracts; the Transitive Trust Graph sees correlated failure. Concentration analysis therefore follows model, cloud, region, accelerator, network, identity, data, evaluator, integration and human-operation edges.
A shared failure mode can be technical, behavioural, commercial or operational. One region outage can stop both routes. One compromised issuer can authenticate both. One model family can reproduce the same failure. One data supplier can contaminate evaluation and production. One legal term can restrict both services after an acquisition. One scarce internal team can be the only group able to operate recovery.
Substitution evidence is concrete. The alternate component has a resolved identity, compatible decision contract, migrated data and state, equivalent control placement, current evaluations, known residual loss and a rehearsed cutover. It may be slower or narrower. A nominal competitor that has never processed the task is not a substitute. A second route sharing the same decisive failure is not a dual source.
Human services belong in the graph because they can change access, location, judgement and continuity. The record identifies the contracting entity and operational subcontractor, work location, training, privileged data access, quality process, identity controls, turnover and fallback. A move to another country or subcontractor can change rights and risk without a software event. Human oversight is not an invisible externality.
Concentration can be accepted when duplicate operation would cost more than the bounded consequence and recovery need. The decision records which shared failure remains, maximum exposure, monitoring, contingency, trigger and expiry. It does not disappear into a weighted score or a claim that three supplier names equal resilience.
Supply-Chain Admission RuleScale evidence and containment to consequence
A component may enter an agentic release only when its identity, provenance, licence, authority, change channel, evidence, owner and containment or substitution path meet the capability's consequence tier. The rule is conjunctive for mandatory boundaries. An excellent evaluation cannot compensate for unknown provenance. A strong contract cannot compensate for an unrestricted tool. A signature cannot compensate for the wrong subject.
Low-consequence, reversible dependencies can be admitted with proportionate records, automatic integrity checks and ordinary change monitoring. Higher-consequence components require resolved provider chains, pinned or observable effective versions, independent evaluations, bounded authority, change notice, canary or hold controls, incident cooperation, continuity tests and retirement evidence. Unknowns lead to a stronger evidence request, isolation or block depending on potential effect and recovery.
Isolation changes the architecture. A tool is placed behind a narrow service, a model is limited to recommendation, a human supplier sees tokenised cases, a data source is accessed through a governed query, or an evaluator can advise but not decide release alone. The boundary has its own identity, policy, receipts and recovery. A diagram box without enforcement is not isolation.
Admission expires. Component identity, rights, findings, provider chain and evidence freshness are rechecked on change triggers and scheduled review. A release binds the exact accepted states. Provider updates enter a canary, shadow or hold path according to consequence. Rollback includes state and business reconciliation; it is not assumed because a previous model name remains selectable.
| Condition | Admission action | Closure evidence |
|---|---|---|
| Bounded, traceable and reversible dependency | Admit within the named capability and authority envelope | Identity, version, owner, integrity, rights, monitoring and retirement record |
| Identity known; provenance, pinning or evidence incomplete | Hold promotion or limit exposure while evidence is strengthened | Resolved source, effective version, evaluation and change trigger |
| Useful component with authority or provider uncertainty | Isolate behind a deterministic or human-controlled boundary | Enforced interface, receipts, tested containment and bounded data access |
| Shared decisive failure with tested alternative | Substitute or dual-source based on recovery need | Independent dependency, migration, rehearsal and residual-loss evidence |
| Unknown, prohibited or compromised dependency | Block admission or withdraw affected releases | Removal, revocation, effect review, replacement or capability closure |
Ten worked casesUpdate the map, traverse impact and act
1. Managed model alias moves
The endpoint name, application code and packages remain unchanged, but provider resolution shows a new effective model and safety configuration. The bill records the resolved version and provider event. The graph reaches behaviour tests, agent routes, human guidance and releases. Software provenance remains valid while behavioural evidence is invalidated. Promotion pauses for targeted evaluation and pinning or an observable fingerprint. Outcome: require stronger provenance, pinning or evidence.
2. Retrieval corpus rights expire
The source files, chunks, embeddings and index remain available and cryptographically intact after the commercial licence expires. The bill updates rights and effective time. Derived-from edges identify every index, evaluation, answer product and release using the corpus. Access stops, affected artefacts are quarantined and a licensed source is substituted or the feature is withdrawn. Outcome: block or withdraw the untraceable or compromised dependency.
3. Prompt changes precedence
A template edit moves a tool instruction above a policy constraint and changes which operation the planner selects. The prompt digest and semantic diff update the bill. Configured-by edges reach agent versions, tool tests and release approvals. The change is held until precedence, injection, authority and regression cases pass and the effective version is pinned. Outcome: require stronger provenance, pinning or evidence.
4. Connector adds a side effect
A connector retains its method name and schema shape but now sends a notification after updating a record. The operation identity and side-effect contract change. Acts-through edges reach every agent using the connector. Until a narrow wrapper exposes update and notification as separate authorised effects with receipts, the component cannot sit on the direct action path. Outcome: isolate the dependency behind a controlled boundary.
5. Evaluator changes model and threshold
A third-party evaluator changes its judge model and default threshold. The release artefact and production model do not change, yet earlier assurance decisions relied on the old evaluator. Evaluated-by edges locate evidence items, control gates and releases. The team preserves prior results for history, re-runs decision-relevant cases and prevents the new evaluator from silently approving promotion. Outcome: require stronger provenance, pinning or evidence.
6. Human reviewer service relocates
A review supplier moves work to a subcontractor in another location with different access and training practice. Operated-by and supplied-by edges reach queues containing personal and confidential data. The service is restricted to tokenised, lower-sensitivity cases behind a supervised interface while legal, training, identity and continuity evidence is resolved. Outcome: isolate the dependency behind a controlled boundary.
7. Hidden concentration across suppliers
Two model providers appear independent but share one cloud region and identity issuer; both use the same evaluator family. Shares-failure-mode edges expose the cluster. A third route with independent hosting, identity and evaluation is tested against the decision contract and kept warm for consequential traffic. Logo count does not drive the decision. Outcome: substitute or dual-source the concentrated component.
8. Signed container, wrong build subject
A container signature verifies and the transparency entry is valid, but the attestation names an unapproved build step and the deployed digest differs from the reviewed subject. Integrity machinery worked; verification policy rejected the source, builder and subject relationship. Built-from edges identify affected deployments, which are stopped and replaced from the approved pipeline. This is the integrity-pass, assurance-fail case. Outcome: block or withdraw the untraceable or compromised dependency.
9. Credential broker compromise
The broker that issues downstream tokens is compromised. Authenticated-by edges traverse agents, connectors, tool resources and releases. New exchange stops, credentials and derived sessions are revoked, actions in the possible exposure window are reconciled and unaffected workloads move to an independently tested broker route. A new certificate alone would not close the business effects. Outcome: block or withdraw the untraceable or compromised dependency.
10. Unknown component origin
An internal agent depends on a copied evaluation model with no owner, source, licence, change feed or retirement path. The file hash is known but its provenance and permitted use are not. No reliable graph traversal or incident contact exists. The component is removed from promotion, releases that relied on it are reopened and a traceable alternative is evaluated. Outcome: block or withdraw the untraceable or compromised dependency.
11. Bounded deterministic parser
A deterministic internal parser has repository, reviewed source, reproducible build, signed subject, constrained inputs, no external authority, named owner, current licence scan, monitored vulnerabilities, tested rollback and a simple replacement. It supports a reversible formatting step in a low-consequence capability. The bill and graph are complete for its claim. Outcome: admit the bounded low-risk dependency.
Interactive decision artefactAgentic Supply-Chain Admission Board
The board selects an admission action and reports the path from component to affected release. It does not produce a universal supply-chain score, treat a signature as safety or assume that protocol compatibility establishes trust.
Admit the bounded low-risk dependency
Agentic Bill of Materials: traceable parser, reviewed source, verified build subject, named owner and bounded use.
Transitive dependencies: internal repository, approved builder and reversible formatting capability.
Integrity and behavioural evidence: signature, reproducible build, constrained-input tests and rollback verified.
Licence and data constraints: current licence scan; no external data or training use.
Shared failure modes: no material common dependency for the bounded claim; simple replacement exists.
Affected capabilities and releases: one low-consequence formatting step and its current release.
Change, containment and substitute: repository feed, pin, rollback and replacement are ready.
Retirement and accountable owner: component owner can disable, replace and close the bill record.
Operating cadenceKeep the map alive through decisions, events and retirement
At capability design, product and risk owners define the business decision, population, authority, consequence and recovery need. Architects identify which of the fourteen classes can change the claim. Procurement and security resolve provider chains, evidence rights, change feeds, containment and exit before a dependency becomes operationally indispensable.
At component admission, the platform records identity, version, owner, source, integrity, configuration, provider chain, data access, authority, findings, rights, substitutes and retirement. Verification checks expected source, builder, signer and subject. Behavioural, rights, authority and continuity evidence are assessed separately. The accepted states bind to the release.
At every release, automation resolves managed endpoints, prompt and policy digests, data and index lineage, tool schemas, identity services, evaluator versions, human operating services and deployment subjects. Missing or changed nodes trigger the admission rule. The release evidence pack points to the live Agentic Bill of Materials and blast-radius state.
During operation, event feeds monitor model aliases, provider notices, vulnerabilities, licence dates, data deletion, embedding and index rebuilds, tool side effects, issuer health, threshold changes, subcontractors, locations, cloud dependencies and evidence freshness. Observed changes are compared with supplier notice. Material gaps affect future terms and admission.
On incident or change, the query traverses to capabilities, populations, credentials, releases, controls and evidence. Owners contain, revalidate, substitute or withdraw, then record closure receipts. Affected business actions are reconciled where necessary. Updating the inventory without acting on the blast radius is not incident response.
At rehearsal and retirement, teams prove that components can be isolated, data and state migrated, evidence preserved, authority revoked and residual access closed. Substitute edges are renewed through real tests. Obsolete prompts, indexes, evaluators, identities, accounts and provider access are removed rather than left as undocumented fallback paths.
| Decision point | Accountable owner | Receipt that keeps the map operational |
|---|---|---|
| Capability design | Product and risk owners | Named decision, population, authority, consequence, recovery need and required component depth |
| Component admission | Component and control owners | Resolved identity, provider chain, rights, evidence planes, containment and retirement state |
| Release | Release authority | Binding from accepted component versions and graph edges to the deployed release |
| Change or incident | Incident and business owners | Blast-radius paths, containment actions, reconciled effects and evidence-closure receipts |
| Substitution or retirement | Continuity and service owners | Rehearsed cutover, migrated data and state, revoked authority, preserved evidence and closed access |
Primary evidenceReferences
Links and live status were checked on 2 September 2026. NIST SP 800-161 Revision 1 Update 1 replaces the withdrawn original Revision 1 page. NIST AI RMF 1.0 remains current while revision is under way. The Agentic Bill of Materials, Transitive Trust Graph, Change Blast-Radius Query, Admission Rule and Board are this article's synthesis.
- NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices.
- NIST SP 800-218, Secure Software Development Framework Version 1.1.
- NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models.
- NIST AI Risk Management Framework 1.0.
- NIST AI 600-1, Generative Artificial Intelligence Profile.
- ISO/IEC 42001:2023, Artificial Intelligence Management System.
- European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act.
- SLSA Specification Version 1.2, approved.
- in-toto Attestation Framework.
- SPDX Specification Version 3.0.
- CycloneDX Specification Version 1.7.
- Sigstore Documentation.
- OWASP LLM03:2025, Supply Chain.
- CISA, Secure by Design.
- MITRE ATLAS, Adversarial Threat Landscape for AI Systems.
- Mitchell, M. et al., Model Cards for Model Reporting.
- Gebru, T. et al., Datasheets for Datasets.
About this paperMap what can change the decision
The Agentic Bill of Materials, Transitive Trust Graph, Change Blast-Radius Query, Supply-Chain Admission Rule and Admission Board are this article's synthesis. They extend software supply-chain and provider-governance systems rather than replace them. The design does not treat signatures, protocol compatibility, provider count or inventory size as proof of agentic supply-chain safety.