Paper 116 · Security, identity and resilience

The Agentic Supply Chain

Rajesh Ranjan Mahapatra

An agent can change without a code diff: its model endpoint, prompt, corpus, evaluator, identity broker or human operating service may have moved underneath it.

© 2026 Rajesh Ranjan Mahapatra. 24 min read

The Agentic Supply ChainAll Research Essays
Paper 116 · Security, identity and resilience

The Agentic Supply Chain

An agent can change without a code diff: its model endpoint, prompt, corpus, evaluator, identity broker or human operating service may have moved underneath it.

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.

Software SBOM expands into an Agentic Bill of MaterialsA software package inventory expands into fourteen behavioural, data, identity, human, infrastructure and legal component classes.SOFTWARE SBOMSOURCE · PACKAGEBUILD · ARTEFACT1 BUSINESS CAPABILITY2 AGENT + ORCHESTRATION3 MODEL SERVICE4 PROMPT + POLICY5 DATA + RETRIEVAL6 MEMORY + STATE7 TOOLS + CONNECTORS8 IDENTITY + CREDENTIALS9 GUARDRAILS + EVALS10 HUMAN SERVICES11 EXTERNAL AGENTS12 SOFTWARE + BUILD13 INFRASTRUCTURE14 COMMERCIAL + LEGALAGENTIC BILL OF MATERIALS · TRANSITIVE · VERSIONED · QUERYABLE
Figure 1. The software SBOM remains inside a broader map of components that can change the agent's behaviour, authority, evidence or permitted use.

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.

Table 1 · Component identity and decisive change signal
ClassMinimum stable identityMaterial change signal
Managed modelProvider, endpoint, effective model, configuration, region and resolved timeAlias, routing, safety configuration, data handling or deprecation changes
Prompt, policy or evaluatorDigest, semantic version, owner, precedence or threshold and release bindingInstruction priority, schema, judge model, threshold or test population changes
Data, embedding or indexSource snapshot, rights, transformation, model, index and entitlement versionLicence, source composition, embedding model, deletion, freshness or access changes
Tool, identity or human serviceOperation or service identity, authority, provider chain, location and ownerSide effect, issuer, privileged access, subcontractor, location or training changes
Software and infrastructureSource, builder, subject digest, deployment identity, cloud, region and shared serviceBuild step, signature identity, deployment subject, region or control-plane changes
Transitive Trust GraphA business capability connects through models, prompts, data, tools, identities, evaluators, people, software and infrastructure with typed edges.BUSINESSCAPABILITYMODELPROMPTDATATOOLSIDENTITYEVALUATORHUMANSSOFTWARE + INFRABUILT FROM · CONFIGURED BY · RETRIEVES FROM · ACTS THROUGH · AUTHENTICATED BY · EVALUATED BY
Figure 2. Typed edges make the graph useful for impact analysis; an untyped list cannot distinguish who configures, evaluates, authenticates or can replace what.

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.

Managed-service change without software changeAn unchanged application, container and package set leads to a changed managed model and changed behaviour over time.APP CODEUNCHANGEDCONTAINERUNCHANGEDPACKAGESUNCHANGEDMODEL ALIASRESOLVES DIFFERENTLYSOFTWARE EVIDENCE STILL VALIDBEHAVIOURAL + RELEASE EVIDENCE INVALIDATEDEMPTY CODE DIFF · MATERIAL PRODUCT CHANGE
Figure 3. Managed services require effective-version and behavioural change evidence because application artefacts can remain identical.

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.

Table 2 · Evidence planes cannot compensate for one another
PlaneQuestionNon-substitute
Integrity and provenanceDid the expected source and builder produce this exact subject?A valid signature cannot establish behavioural fitness or permitted use
Behaviour and evaluationDoes this version support the release claim and known limits?Passing tests cannot cure unknown origin or unapproved deployment subject
Licence, data and geographyMay the organisation use, transform, retain and transfer the component here?Availability and technical compatibility do not preserve rights
Authority and changeWhat can it do, who can change it and how is revalidation triggered?Documentation without enforcement cannot contain a privileged component
Continuity and exitCan the component be isolated, substituted and retired with evidence?A vendor alternative is not a tested recovery path
Change Blast-Radius QueryA component event traverses to capabilities, decisions, populations, credentials, evaluations, releases, regulatory evidence and recovery plans.COMPONENTEVENTCAPABILITIES + DECISIONSPOPULATIONS + AUTHORITYCREDENTIALSEVALUATIONS + CONTROLSRELEASES + DEPLOYMENTSPROVIDER CHAINREGULATORY EVIDENCECONTINUITY + EXIT
Figure 4. The query follows typed invalidation edges from one event to the claims, releases and recovery paths that now need action.

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.

Cryptographic integrity versus behavioural assuranceA signed and provenance-verified artefact on the left can still fail behavioural, rights and deployment checks on the right.CRYPTOGRAPHIC INTEGRITYBEHAVIOURAL ASSURANCEEXPECTED SIGNER?APPROVED SOURCE + BUILDER?EXACT SUBJECT + DEPLOYMENT?EXPECTED BEHAVIOUR?RIGHTS + AUTHORITY VALID?EVALUATION + RECOVERY PROVEN?SIGNED ≠ SAFE · UNSIGNED ≠ AUTOMATICALLY MALICIOUS · VERIFY EACH CLAIM
Figure 5. Integrity evidence is indispensable but cannot answer whether a component is fit, authorised, licensed or recoverable for the business use.

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.

Hidden concentration across nominal providersThree suppliers converge on one cloud region, identity issuer, evaluator and human operation.PROVIDER APROVIDER BPROVIDER CCLOUD REGIONIDENTITY ISSUEREVALUATOR FAMILYHUMAN SERVICETHREE CONTRACTS · ONE FAILURE CLUSTERDIVERSIFY THE DECISIVE EDGE, NOT THE LOGO
Figure 6. Diversification requires independent decisive dependencies or a deliberate, evidenced acceptance of the shared failure.
Supply-Chain Admission RuleA component passes identity, provenance, licence, authority, change, evidence and substitution gates before release admission.IDENTITYPROVENANCELICENCEAUTHORITYCHANGEEVIDENCESUBSTITUTEDEPTH SCALES WITH CONSEQUENCE AND RECOVERY NEEDADMIT · STRENGTHEN · ISOLATE · SUBSTITUTE · BLOCK
Figure 7. Admission is a conjunction of decision-relevant evidence, not a sum in which strong signatures cancel missing rights or containment.

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.

Table 3 · Admission actions by evidence condition
ConditionAdmission actionClosure evidence
Bounded, traceable and reversible dependencyAdmit within the named capability and authority envelopeIdentity, version, owner, integrity, rights, monitoring and retirement record
Identity known; provenance, pinning or evidence incompleteHold promotion or limit exposure while evidence is strengthenedResolved source, effective version, evaluation and change trigger
Useful component with authority or provider uncertaintyIsolate behind a deterministic or human-controlled boundaryEnforced interface, receipts, tested containment and bounded data access
Shared decisive failure with tested alternativeSubstitute or dual-source based on recovery needIndependent dependency, migration, rehearsal and residual-loss evidence
Unknown, prohibited or compromised dependencyBlock admission or withdraw affected releasesRemoval, 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.

Current admission decision

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.

Agentic Supply-Chain Admission Board outcomesTwelve component and impact inputs route to five outcomes and affected release actions.LIVE COMPONENT RECORDIDENTITY + PROVIDER CHAININTEGRITY + BEHAVIOURRIGHTS + AUTHORITYCHANGE + CONCENTRATIONIMPACT + EXITFIVE ADMISSION OUTCOMESADMIT BOUNDED DEPENDENCYSTRENGTHEN EVIDENCEISOLATE BEHIND BOUNDARYSUBSTITUTE OR DUAL-SOURCEBLOCK OR WITHDRAW
Figure 8. The board turns transitive component evidence into one bounded admission, containment, substitution or withdrawal action.

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.

Table 4 · Minimum operating receipts for a live agentic supply chain
Decision pointAccountable ownerReceipt that keeps the map operational
Capability designProduct and risk ownersNamed decision, population, authority, consequence, recovery need and required component depth
Component admissionComponent and control ownersResolved identity, provider chain, rights, evidence planes, containment and retirement state
ReleaseRelease authorityBinding from accepted component versions and graph edges to the deployed release
Change or incidentIncident and business ownersBlast-radius paths, containment actions, reconciled effects and evidence-closure receipts
Substitution or retirementContinuity and service ownersRehearsed 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.

  1. NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices.
  2. NIST SP 800-218, Secure Software Development Framework Version 1.1.
  3. NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models.
  4. NIST AI Risk Management Framework 1.0.
  5. NIST AI 600-1, Generative Artificial Intelligence Profile.
  6. ISO/IEC 42001:2023, Artificial Intelligence Management System.
  7. European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act.
  8. SLSA Specification Version 1.2, approved.
  9. in-toto Attestation Framework.
  10. SPDX Specification Version 3.0.
  11. CycloneDX Specification Version 1.7.
  12. Sigstore Documentation.
  13. OWASP LLM03:2025, Supply Chain.
  14. CISA, Secure by Design.
  15. MITRE ATLAS, Adversarial Threat Landscape for AI Systems.
  16. Mitchell, M. et al., Model Cards for Model Reporting.
  17. 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.