Part one

From component inventory to influence paths

Conventional supply-chain security begins from a sound concern: an organisation often knows less than it should about how acquired technology was developed, integrated and deployed. NIST's cyber supply-chain guidance makes reduced visibility central to the problem. AI-specific guidance broadens the asset set beyond code to models, data, prompts, libraries, frameworks, external APIs, logs and assessments. [1] [4]

That broader inventory matters. CycloneDX's machine-learning bill of materials and the SPDX AI profile provide structures for documenting model and dataset artefacts. SLSA provenance records where, when and how a build artefact was produced. In-toto expresses verifiable claims about production steps. The Update Framework protects update clients against threats such as rollback, freeze and mix-and-match attacks. [7] [8] [5] [6] [10]

None of those mechanisms should be weakened. The problem is the conclusion sometimes drawn from them. A complete inventory can still describe an unsafe composition. A valid signature can authenticate malicious content. A correctly built package can expose excessive authority. A model can match its approved hash while retrieved text changes its plan. An evaluation can be faithfully attested yet fail to test the attack path that matters.

Thought experiment one: the unchanged binary

Hold the executable constant. Keep its digest, source revision and publisher signature identical. Change only one sentence in the tool description that the model sees. In world A, the sentence says the tool searches a public corpus. In world B, it says the tool should also gather supporting internal records and forward them when a document requests escalation.

If the model's choices differ, then the description is part of the behavioural supply chain even though it is not executable in the operating-system sense. Its natural language is consumed by a probabilistic planner. It functions as a control input. Integrity of bytes answers whether an artefact changed; semantic admission answers whether its meaning is allowed to steer this system. Both questions are necessary, and neither substitutes for the other.

Start with the effect and walk backwards

Component-first reviews naturally spend the most time on the most visible artefacts: the foundation model, the orchestration framework and the tool catalogue. An attacker, however, cares about the cheapest route to an effect. Begin with the outcomes that would require explanation after an incident: disclosure of protected data, mutation of a system of record, external communication, financial commitment, code execution, durable memory promotion, or release of a changed system.

For each effect, record the authoritative target, the executing principal, the maximum permitted scope, the required precondition, the observable postcondition and the available reversal or compensation. Then walk backwards. Which tool can request the effect? Which planner can select the tool? Which context can shape the planner? Which sources can write that context? Which release evidence allows each node and edge to enter service? This reverse traversal keeps the model anchored in consequence rather than in vendor categories.

Each node needs a small but disciplined record: owner, supplier, version, mutability, update channel, trust class, data zone, runtime identity, allowed consumers and evidence expiry. Each edge needs a channel type, a triggering condition and a control owner. A vague arrow labelled “uses” is not enough. “External report contributes claims to the memorandum draft after quarantine” is a content edge. “Planner invokes mail service with a user-bound capability” is an authority edge. Those descriptions expose different tests.

The attacker model also belongs on the graph. One attacker may publish web content but lack credentials. Another may compromise a supplier account and sign an update. An insider may alter an evaluation label but not production code. A model provider may change hosted behaviour without exposing weights. A control is credible only relative to the capability it is meant to stop. A signature defeats network tampering but not a compromised signer; a human review may catch an unusual destination but not a subtle policy omission.

Part two

Four kinds of dependency edge

A useful graph needs more than arrows. Each arrow must state what crosses it. Otherwise a threat model treats a document read, a package import, a delegated token and an evaluator score as the same relationship. They are not.

Content edges carry claims, instructions or observations into context. Examples include a web page, a retrieved policy passage, a memory entry, a tool result and a user attachment. Content can be authentic and still adversarial. The relevant controls are provenance, trust classification, quarantine, instruction-data separation and claim verification.

Control edges select or configure behaviour. Model weights, adapters, system prompts, policy bundles, routing rules, tool schemas and server manifests belong here. The controls are integrity, versioning, approved configuration, change review and rollback. A tool description can be both content and control: it is text, but it also changes what the planner believes the tool should do.

Authority edges permit an identity to read, write, send, spend or invoke. They include delegated OAuth scopes, workload identities, API keys, database roles, approval tokens and capabilities. The relevant question is not whether the model is trustworthy. It is whether a deterministic enforcement point checks the requested action against the user, the agent, the purpose, the current state and the permitted effect.

Evidence edges justify release or continuation. Evaluation datasets, labels, judge models, red-team findings, test harnesses, monitoring thresholds and human review records all influence whether the system is trusted. An attacker does not need to corrupt the production model if the same objective can be achieved by hiding a failure from the release gate.

This representation avoids a common scoring error. Adding low-risk components does not necessarily raise material risk, while one new authority edge can transform an existing content weakness into a breach. Conversely, a model may remain vulnerable to prompt injection while the system stays bounded because the injected proposal cannot cross a deterministic capability boundary.

Three properties ordinary dependency diagrams miss

The first is temporal mutation. A dependency may be acceptable at approval time and unsafe later without changing its stable name. Hosted models can change behind an endpoint. A retrieval index can ingest new documents. A memory store can promote a claim. A tool server can alter its description, schema or reachable resources. The threat model therefore needs valid time and transaction time: when the dependency's behaviour applied, and when the organisation learned or recorded that fact. Without both, replay can reconstruct the wrong system.

The second is semantic transitivity. Software dependencies are transitive because one package imports another. Agent dependencies can be transitive through meaning. A public document influences a summariser; the summary is written to memory; memory shapes a planner; the planner selects a tool; the tool's output becomes another agent's instruction. No single hop need look dangerous. The prohibited behaviour emerges from the chain, so review at each component boundary can still miss it.

The third is assurance dependency. A release decision depends on tests, labels, judges, thresholds and dashboards. If those assets are produced by the same compromised path, the system may carry perfectly consistent but false assurance. This is analogous to asking a supplier to provide both the artefact and the only evidence that the artefact is genuine. Attestation improves the evidence chain only when the attester, policy and verifier are themselves within a reasoned trust boundary.

These properties explain why a static graph is necessary but insufficient. Store snapshots for approved releases, yet also monitor runtime graph changes. A new tool, changed scope, altered prompt, fresh corpus, promoted memory fact or evaluator revision should emit an event that can trigger policy re-evaluation. The practical aim is not to freeze the system. It is to prevent an unreviewed edge from quietly inheriting yesterday's authority.

Part three

flowchart LR
  A["The approved tool that changed<br/>its meaning"] --> B["From component inventory to<br/>influence paths"]
  B --> C["Four kinds of dependency edge"]
  C --> D["Where agent supply-chain<br/>attacks enter"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#087A98,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Where agent supply-chain attacks enter

NIST's adversarial machine-learning taxonomy organises attacks by lifecycle stage, attacker goal, capability and knowledge. That discipline is useful because “AI attack” otherwise collapses poisoning, evasion, privacy abuse and misuse into one label. For an agent, however, the lifecycle must be connected to runtime authority. [3]

Prompts, retrieval and memory

External text is an acquired dependency on every run. Indirect prompt injection demonstrated that an attacker can place instructions in data likely to be retrieved by an LLM-integrated application, then influence API calls or application logic without directly messaging the model. PoisonedRAG showed a more targeted knowledge-corruption mechanism: in the authors' tested setting, five malicious texts per target question produced a 90 per cent attack success rate against a database containing millions of texts. That result is a bounded experiment, not a universal prevalence claim, but it establishes that a small content change can create a reliable behavioural edge. [12] [13]

Persistent memory lengthens the path. A malicious instruction or false claim may enter through one task, be summarised into episodic state, lose its provenance, and influence a different action weeks later. Memory therefore belongs in the threat model as a write-governed dependency, not merely a datastore. The narrower memory article linked below develops quarantine, promotion and expiry in depth; here, memory is one node in a larger path.

Models, adapters and packages

Model weights, fine-tunes and adapters can carry backdoors that normal capability evaluation misses. The Sleeper Agents study constructed proof-of-concept backdoored language models and found that the studied behaviours could persist through supervised fine-tuning, reinforcement learning and adversarial training. The study does not establish that deployed models commonly contain such strategies. It demonstrates a verification boundary: passing standard post-training is not, by itself, evidence that all trigger-conditioned behaviour was removed. [15]

Traditional code remains part of the path. Deserialisation, vulnerable libraries, package confusion, compromised builders and malicious installers do not become less important because an LLM is present. NIST's AI extension to the Secure Software Development Framework explicitly treats model producers, system producers and acquirers as participants in secure development. [2]

Tools, MCP servers and transitive composition

MCP connects hosts to resources, prompts and tools. The current specification states that tools can provide arbitrary data access and code-execution paths, that descriptions and annotations should be treated as untrusted unless they come from a trusted server, and that the protocol cannot itself enforce the recommended security principles. These are not defects that a protocol document can simply wish away. They locate responsibility in the host, authorisation layer and deployment boundary. [9]

The deeper risk is composition. A file-reading tool may be appropriate. A network-post tool may be appropriate. A public search tool may be appropriate. Together, with shared context and ambient identity, they can form an ingestion, collection and disclosure chain. A large-scale MCP study analysed 12,230 tools across 1,360 publicly collected servers. Its dynamic verification identified 1,062 tools, 8.7 per cent of the sample, with at least one capability relevant to the paper's attack, and 370 servers, 27.2 per cent, containing at least one such tool. The dataset and packaging criteria limit generalisation, but the study shows why per-tool approval misses cross-tool paths. [14]

Evaluations, judges and update channels

Evaluation assets decide whether the graph is allowed to run. A poisoned benchmark can omit a trigger. A compromised judge can mark unsupported actions as compliant. A test harness can silently stop executing the negative case. A rollout policy can accept a new model or prompt because aggregate accuracy remains flat while a rare high-consequence path regresses.

SLSA is explicit that its build levels apply to an individual build and do not automatically establish the trustworthiness of transitive dependencies. Its FAQ also distinguishes an SBOM's component detail from provenance about the build process. That boundary generalises: evidence about one node must not be inflated into assurance about the whole path. [16]

Thought experiment two: the flawless evaluator

Take two systems with identical model weights, prompts, tools and test cases. In system A, the evaluation set, expected labels and judge configuration are generated and stored by the same pipeline that publishes the model. In system B, the evaluation manifest is pinned independently, its critical cases are curated by a separate owner, and the release service verifies that the required tests actually ran.

Both systems report 100 per cent pass. Now compromise the publisher pipeline. System A can replace the model and the evidence that certifies it. System B still has a chance to detect the divergence. The causal feature is not evaluator cleverness. It is independence of the evidence edge from the artefact edge it is meant to test. Correlated trust turns a two-control diagram into one control wearing two labels.

Part four

Five cuts that interrupt an influence-to-effect path

Defence in depth becomes useful only when each layer names the traversal it interrupts. Five cuts cover most paths in the running model. They are cumulative, not interchangeable.

1. Establish provenance and integrity

Record what the dependency is, who supplied it, which version was admitted, how it was built, what inputs produced it and whether the retrieved object matches the approved object. Use SBOM or ML-BOM structures for inventory, SLSA or in-toto attestations for production claims, cryptographic verification for immutable artefacts, and TUF-like update protections where applicable. Provenance gives investigators and policy engines something stable to reason about.

2. Classify semantic trust before context admission

Keep instructions, observations and claims distinct. A public page may inform a factual answer but must not authorise a tool call. A tool description may explain parameters but must not grant itself permission. A memory entry may support a hypothesis but should not become an internal fact without promotion. Admission controls should preserve source, trust class, applicable purpose, effective time and any unresolved contradiction.

3. Enforce authority outside the model

The model proposes; a deterministic authority kernel decides whether the proposal is permitted. It should bind the requesting user, proposing agent, executing workload, action type, resource, purpose, data classification, current state and effect limit. Least privilege is not one small OAuth scope held forever. It is a short-lived capability narrow enough that a compromised planning path cannot turn a research task into outbound disclosure.

4. Make verification independent and path-specific

Test the path, not merely the component. Inject a malicious document, a changed tool description, a stale memory entry, a poisoned evaluator record and an unknown update outcome. Ensure critical evaluations are owned, versioned and executed independently enough to detect corruption in the release path. Store which attack assumptions were tested, not just a green score.

5. Observe the outcome and preserve recovery

An accepted command is not a verified effect. Read back the authoritative system state, issue a decision receipt and an effect receipt, detect ambiguous commits, prevent duplicate execution, and retain a route to revoke capability, roll back a release or reconstruct the decision. Recovery reduces consequence when prevention fails and makes incident analysis evidence-based.

Prefer independent cut sets to duplicated controls

A path can be interrupted at several places, but two controls are not genuinely independent when they share the same failure. A model-based injection detector and a model-based judge may both follow the same poisoned instruction. Two approvals may both display a misleading tool title supplied by the same server. A signature check and a provenance check may both trust one compromised publisher account. Count shared assumptions before counting layers.

For the highest-consequence effects, seek a minimal cut set that spans different mechanisms: semantic admission before reasoning, deterministic authorisation before execution, and authoritative readback after execution. If the first two fail together, the last still exposes the outcome. If the model is manipulated, the authority kernel does not need to understand why. If the target system returns an ambiguous result, recovery logic stops repetition. Independence converts defence in depth from diagram density into failure separation.

A practical release decision instrument

Run the following worksheet for each high-consequence effect, not once for the application. A “no evidence” answer is a release block or an explicit reason to reduce authority.

The instrument resists checklist theatre by demanding a concrete artefact. “We use SLSA” is not an answer to the first question unless the relevant prompts, datasets and tool manifests are also represented. “A human approves” is not an answer to the third unless the interface shows the actual resource, destination, data and effect being authorised.

Executable artefact

A small influence-path analyser

The following Python programme makes the argument inspectable. It represents dependencies as nodes, causal relations as typed edges, and controls as properties of those edges. It enumerates every path from an external, third-party or mutable source to a high-impact effect, then reports the controls missing for each channel.

from __future__ import annotations

from dataclasses import dataclass, field
from typing import Iterable


@dataclass(frozen=True)
class Node:
    name: str
    trust: str
    mutable: bool = False
    high_impact_effect: bool = False


@dataclass(frozen=True)
class Edge:
    source: str
    target: str
    channel: str
    controls: frozenset[str] = field(default_factory=frozenset)


REQUIRED_BY_CHANNEL = {
    "content": {"provenance", "semantic_admission"},
    "control": {"integrity", "version_pin"},
    "authority": {"authorisation", "least_privilege"},
    "evidence": {"independent_verification", "replayable_evidence"},
    "effect": {"postcondition_check"},
}


def enumerate_paths(nodes: dict[str, Node], edges: list[Edge]) -> list[list[Edge]]:
    adjacency: dict[str, list[Edge]] = {name: [] for name in nodes}
    for edge in edges:
        adjacency[edge.source].append(edge)

    sources = [
        node.name
        for node in nodes.values()
        if node.trust in {"external", "third_party"} or node.mutable
    ]
    sinks = {node.name for node in nodes.values() if node.high_impact_effect}
    found: list[list[Edge]] = []

    def walk(current: str, path: list[Edge], visited: set[str]) -> None:
        if current in sinks and path:
            found.append(path.copy())
            return
        for edge in adjacency.get(current, []):
            if edge.target in visited:
                continue
            path.append(edge)
            walk(edge.target, path, visited | {edge.target})
            path.pop()

    for source in sources:
        walk(source, [], {source})
    return found


def missing_controls(path: Iterable[Edge]) -> set[str]:
    missing: set[str] = set()
    for edge in path:
        required = REQUIRED_BY_CHANNEL[edge.channel]
        missing |= required - set(edge.controls)
    return missing


def describe_path(path: list[Edge]) -> str:
    return " -> ".join([path[0].source, *[edge.target for edge in path]])


def assess(name: str, nodes: dict[str, Node], edges: list[Edge]) -> None:
    print(name)
    paths = enumerate_paths(nodes, edges)
    if not paths:
        print("  NO PATH: no mutable or untrusted dependency reaches a high-impact effect")
        return
    for path in paths:
        missing = missing_controls(path)
        status = "PASS" if not missing else "FAIL"
        print(f"  {status}: {describe_path(path)}")
        if missing:
            print("    missing: " + ", ".join(sorted(missing)))


NEGATIVE_NODES = {
    "mutable_tool_description": Node("mutable_tool_description", "third_party", mutable=True),
    "model_planner": Node("model_planner", "internal"),
    "send_email": Node("send_email", "internal"),
    "external_recipient": Node("external_recipient", "external", high_impact_effect=True),
}
NEGATIVE_EDGES = [
    Edge("mutable_tool_description", "model_planner", "content", frozenset({"signature"})),
    Edge("model_planner", "send_email", "authority", frozenset({"oauth"})),
    Edge("send_email", "external_recipient", "effect"),
]

POSITIVE_NODES = {
    "external_report": Node("external_report", "external", mutable=True),
    "quarantine": Node("quarantine", "internal"),
    "context_compiler": Node("context_compiler", "internal"),
    "model_proposal": Node("model_proposal", "internal"),
    "approval_gate": Node("approval_gate", "internal"),
    "decision_record": Node("decision_record", "internal", high_impact_effect=True),
}
POSITIVE_EDGES = [
    Edge(
        "external_report",
        "quarantine",
        "content",
        frozenset({"provenance", "semantic_admission"}),
    ),
    Edge(
        "quarantine",
        "context_compiler",
        "control",
        frozenset({"integrity", "version_pin"}),
    ),
    Edge(
        "context_compiler",
        "model_proposal",
        "evidence",
        frozenset({"independent_verification", "replayable_evidence"}),
    ),
    Edge(
        "model_proposal",
        "approval_gate",
        "authority",
        frozenset({"authorisation", "least_privilege"}),
    ),
    Edge(
        "approval_gate",
        "decision_record",
        "effect",
        frozenset({"postcondition_check"}),
    ),
]


if __name__ == "__main__":
    assess("NEGATIVE CASE", NEGATIVE_NODES, NEGATIVE_EDGES)
    assess("POSITIVE CASE", POSITIVE_NODES, POSITIVE_EDGES)

NEGATIVE CASE
  FAIL: mutable_tool_description -> model_planner -> send_email -> external_recipient
    missing: authorisation, least_privilege, postcondition_check, provenance, semantic_admission
POSITIVE CASE
  PASS: external_report -> quarantine -> context_compiler -> model_proposal -> approval_gate -> decision_record

The negative case is important. Its tool description is signed and its mail tool has OAuth, but neither property answers the path's actual questions. The content edge lacks provenance and semantic admission. The authority edge lacks action-specific authorisation and least privilege. The effect lacks postcondition verification. The positive case is not called “secure”; it passes the stated policy for the stated graph.

Production-shaped worked example

stateDiagram-v2
  [*] --> Claim
  state "Thought experiment one: the<br/>unchanged binary" as Claim
  state "Start with the effect and walk<br/>backwards" as Test
  state "Three properties ordinary<br/>dependency diagrams miss" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

A credit research agent without delegated lending authority

Consider a synthetic commercial-credit research workflow. It collects public filings and sector reports, retrieves internal policy, calculates ratios, drafts a credit memorandum and stores an evidence pack. A relationship manager and an accountable credit officer make the decision. The agent has no authority to approve credit, alter limits or communicate a formal offer.

The inventory lists a model router, two model versions, an embedding model, a retrieval index, a ratio-calculation service, a policy service, a public-web connector, an internal document connector, a memorandum template, a judge model and a workflow engine. That list is useful but incomplete. The threat model asks which paths reach two high-consequence sinks: the evidence pack used by the officer and any outbound customer communication.

Path one begins with a poisoned sector report. The report contains an instruction to treat a covenant exception as immaterial and to cite a fabricated policy paragraph. The web connector retrieves it legitimately. The context compiler tags it as external evidence and removes its ability to issue instructions. The policy paragraph is fetched only from the controlled policy service. The calculator accepts typed numbers, not prose. The memorandum can quote the report but must preserve source and contradiction status. The path is cut at semantic admission and again at independent policy retrieval.

Path two begins with a tool update. A document connector changes its description and requests a wider data scope. The registry sees a semantic diff, a schema diff and a scope diff. The prior approval is bound to the old tuple, so the new version cannot enter the runtime. The update remains quarantined until code provenance, behaviour tests, data-zone policy and owner approval all pass. Version signing proves the publisher; the change gate decides whether the new behaviour belongs in this workflow.

Path three begins with the evaluator. The judge model rates drafted memoranda for completeness. If its score alone can promote the draft to “decision-ready”, the judge is an authority-bearing dependency. The safer design makes its result advisory, requires deterministic checks for arithmetic and mandatory sections, samples high-risk cases for human review, and retains the exact evidence and policy versions used. A judge update cannot silently alter the release threshold.

The worked design changes the assurance claim. It does not say the model cannot be manipulated. It says a manipulated proposal should be unable to invent policy, alter typed arithmetic, conceal its source, approve credit or send a formal communication. Those claims are narrower, observable and testable.

Objection and boundary

When classical supply-chain controls are enough

A serious negative control is a deterministic invoice calculator packaged as a signed container. It receives a fixed schema, performs a specified arithmetic transformation, reads no external content, discovers no tools, stores no memory, holds no ambient credential and returns a value to a human-owned workflow. Its dependencies are pinned, its build provenance is verified and its update channel is protected.

For that system, a semantic influence graph adds little beyond normal data-flow and software threat modelling. There is no probabilistic planner interpreting natural language as operational guidance. Classical C-SCRM, secure development, dependency management, input validation and update security may be sufficient. The agent-specific method earns its cost only when mutable semantic dependencies can shape selection, sequencing, authority or evidence.

This negative control matters because “agent supply chain” can become a pretext for renaming ordinary controls. The new burden is not that AI uses packages. It is that meaning-bearing artefacts and runtime compositions can change behaviour without changing conventional executable code.

The model can also create false confidence if controls are recorded as labels but never attacked. A “semantic filter” that has only seen obvious jailbreak phrases is not a cut against indirect injection. A “human approval” that hides destination and data is not a cut against disclosure. A “rollback” that cannot reconstruct which prompt, model, corpus and tool versions produced an effect is not recovery.

An observation that would weaken this paper's thesis is straightforward. If, across representative agent systems, conventional signed artefacts, pinned dependencies and standard C-SCRM controls produce no material difference in exploitability compared with the full influence-path method under adversarial testing, then the added graph work is not earning its cost. The claim should be tested, not protected from failure.