Attestation Lineage Poisoning: A Valid Signature on the Wrong Lineage Is Not Runtime Trust

This article is grounded in public supply-chain attestation docs, not private product claims. The SLSA provenance specification describes provenance as verifiable information about where, when, and how software artifacts were produced — an attestation that a build platform produced artifacts through a buildDefinition, with fields such as builder.id, externalParameters, resolvedDependencies, and subject. SLSA explicitly says external parameters are untrusted and must be verified downstream.

The SLSA verification summary attestation docs add the delegation layer: a verifier can evaluate an artifact and a bundle of attestations against a policy, then communicate the verified level and dependency levels. That is exactly why lineage matters to agents. A verification summary can be useful evidence, but only if the agent verifies which artifact, dependency chain, policy, and verifier decision it refers to.

The in-toto Statement specification provides the cleanest boundary language: a Statement binds an attestation to a particular subject and identifies the type of the predicate through predicateType. The attack is not “attestations are bad.” The attack is a binding failure: the agent follows a signed-looking statement, pointer, or verification summary as if it proved the current action, when it actually proves a different subject, dependency, build definition, policy, or time.

Imagine a package promotion bot. It sees a signed attestation and a verification summary that appear to say the dependency passed the required build policy. A human might pause and ask: which artifact does this evidence describe? Which digest? Which dependency version? Which build definition? Which verifier? Which policy? Was the attestation produced before this release, or attached later? Does it cover the action the bot is about to take?

An AI agent may not ask those questions unless the runtime forces it to. It may see “signed,” “verified,” “SLSA,” “provenance,” “in-toto,” “trusted builder,” or “verification summary,” then treat the evidence as a green light. Attestation lineage poisoning exploits that shortcut: keep the evidence formal enough to look trustworthy while shifting what lineage the evidence actually proves.

This can happen through pointer swaps, stale verification summaries, transitive dependency confusion, renamed artifacts, policy-scope drift, or subject/predicate mismatches. The words may sound dry. The effect is not: the agent deploys the wrong thing, imports the wrong dependency, suppresses a warning, trusts a malicious fallback, or forwards secrets because evidence for one lineage was laundered into authority for another. Attestation is evidence about a chain. Runtime trust asks whether this chain authorizes this action.

Sunglasses already covers provenance chain fracture: forged receipts, checksum manifests, canonicalization drift, chain-of-custody breaks, and evidence trails that lie. Attestation lineage poisoning is narrower and more surgical. It targets the attestation chain itself: the subject binding, dependency binding, build-definition pointer, predicate type, verification-summary relationship, or trusted-builder scope.

That distinction matters for search and for defense. General provenance pages teach “do not over-trust paper trails.” This page teaches the specific supply-chain lesson: even signed attestations and verification summaries are not action authority unless the current runtime checks that the lineage is the right lineage.

A deployment agent receives a signed provenance bundle. The signature is valid, but a pointer inside the workflow makes the agent associate the bundle with a different artifact digest than the one being promoted. The agent sees “verified build” and proceeds. The runtime-trust check should compare the artifact digest, subject, build definition, and requested deploy target before treating the attestation as relevant.

A verifier previously issued a summary for dependency version A. A later workflow processes version B with a similar name and reuses the older summary through a cache, alias, or copied metadata field. Nothing about the summary proves version B. If the agent only checks that a VSA exists, stale lineage becomes current authority.

An agent reviews a transitive dependency chain. A malicious package presents itself as the dependency that was verified upstream, while the real resolvedDependencies relationship points elsewhere. The attack is not “break cryptography.” It is to make the agent follow the wrong dependency edge and import, suppress, or approve based on evidence for another node.

The high-signal shape is not the presence of SLSA or in-toto terms by themselves — those are normal and good. It is attestation language plus lineage rebinding plus an instruction to skip, suppress, approve, deploy, import, or trust without checking the current action binding.

Sunglasses is a content-layer input filter for AI agents. In this category, the defense sentence is: attestations can prove provenance, but runtime trust decides whether the proven lineage authorizes the agent's next action.

The agent should not treat a signed statement, verification summary, cache hit, or dependency note as self-executing permission. The runtime should bind the evidence to the current artifact digest, dependency path, build definition, verifier identity, policy scope, timestamp, user intent, and action risk. If any of those bindings are missing, mismatched, stale, or supplied only by untrusted text, the safe answer is to stop or ask for fresh approval.

Eight patterns in the provenance/identity family ship in this release: GLS-ALP-001 (in-toto/SLSA attestation lineage pointer swap), GLS-OCES-001 (OIDC discovery-document token-endpoint substitution), GLS-SMP-018 (source-map sourcesContent metadata poisoning), GLS-LCEPP-001 (long-context policy pivot via stale OCSP certificate evidence), provenance-chain rows GLS-V3-012, GLS-V3-014, and retrieval-provenance rows GLS-V3-059, GLS-V3-063 — searchable in the pattern database. This article does not claim SLSA, in-toto, Sigstore, or any supply-chain tool is inherently vulnerable.