AI agents do not only fail when they read malicious instructions. They fail when an old approval, cached state, expired scan result, or replayed summary is made to look fresh enough for a new action.
Why stale proof becomes agent authority
AI agents turn stale proof into authority when workflow state moves faster than evidence validation. A human might notice that a ticket approval came from yesterday, that a scan summary used a stale dependency lockfile, or that a "green" status badge came from a different branch. An agent often sees a compact statement and keeps going.
This is not just a caching problem. It is an authority problem. The agent is not merely reusing old data; it is reusing the decision power attached to that data. A stale "approved" label can become deploy permission. A stale "safe endpoint" note can become network authority. A stale "scanner passed" summary can become production confidence.
The AI Agent Hardening Manual covers this class of failure under runtime trust: the agent's environment changes, but its inherited evidence does not update to match. The gap between the state that produced the evidence and the state that acts on it is where the attack lives.
The quotable sentence: stale evidence laundering makes yesterday's proof look like today's permission.
Plain-language explainer
Freshness laundering is what happens when an agent workflow forgets that evidence has an expiration date. The evidence may have been true. The approval may have been real. The test may have passed. The problem is that the workflow changed: new code landed, a dependency changed, a callback redirected, a ticket was reopened, the branch moved, the permission scope narrowed, or a human approved only a smaller action.
Defenders usually think about fake evidence. Stale evidence is trickier because it may not be fake. It is real evidence from the wrong moment, the wrong target, or the wrong scope. That makes it perfect for agent workflows: it sounds legitimate, compresses well into summaries, and survives handoffs as a reassuring phrase.
This is closely related to the evidence contracts pattern — the principle that every workflow step should carry explicit source, authority, timestamp, and verification status with it. When those fields are absent or stale, freshness laundering is possible.
"Security review passed."
Passed before the dependency update.
Agent deploys the changed build.
The fix is not to ban memory, caching, or summaries. The fix is to downgrade stale evidence from authority to context until the current workflow re-verifies it. See how Sunglasses fits into this re-verification layer.
Three stale-evidence attack examples
Stale-evidence attacks succeed when the agent has permission to act but the proof it relies on no longer matches the action. The payload often looks like ordinary workflow glue, not a jailbreak.
1. The cached approval that outlives its scope
A cached approval becomes dangerous when it is reused for a broader or later action than the human approved. A human approves a read-only diagnostic query for one incident. The agent stores "human approved tool use" in memory. A later remediation step inherits that sentence and runs a write-capable command because the approval text no longer carries action, target, duration, or risk tier.
Approved then: read-only diagnostic query for incident 1842.
Inherited now: human approved production remediation.
Freshness failure: the approval is real, but its scope expired.This is the temporal drift pattern that GLS-AW-108 (Approval-to-Execution Temporal Drift) targets: language that carries an old approval forward into a new execution context without rebinding the scope fields. The CVP evaluation suite tests whether agents resist exactly this class of inherited-approval bypass.
A freshness gate would require the agent to prove that the approval binds to this action, this target, this run, and this risk level before it can act.
2. The old scan result that hides a new dependency
A security scan result is not fresh if the artifact it checked is no longer the artifact being shipped. An agent reads a prior "no critical findings" summary from a build log. A package version changed after that scan, but the downstream deploy step sees only the reassuring summary. The evidence is not fabricated; it is attached to the wrong dependency state.
Old evidence: no critical findings in lockfile A.
Current artifact: lockfile B after package update.
Unsafe shortcut: treat old scan as proof for new artifact.The agent should bind scan evidence to commit, dependency graph, artifact hash, and run ID. If those fields drift, the summary becomes context, not authority. GLS-MER-566 (Stale Memory Entry Scope Creep) covers the broader category where memory entries carry their original authorization scope into new contexts they were never meant to authorize.
3. The replayed "green" status badge
A status badge can launder freshness when it is copied from an older run into a newer decision path. A workflow dashboard says the release is green because a previous test run passed. A new branch, environment variable, or callback destination changed after that run. The agent sees "green" and proceeds because the badge carries more authority than the raw evidence behind it.
Displayed state: release green.
Hidden state: badge came from a prior branch and prior callback target.
Agent mistake: trust the badge instead of rechecking the evidence path.This is the snapshot replay pattern that GLS-MER-567 (Rehydration Snapshot Poisoned Directive Revival) targets: when a stored state snapshot is revived after a context change and treated as still-authoritative. See the FAQ for more on how agents should treat provenance claims.
High-impact agent steps should validate status provenance, not only status wording. "Green" is a claim. The workflow still needs to prove where it came from.
Why this is distinct from evidence contracts and telemetry poisoning
This page focuses on freshness as the trust boundary: whether evidence from one time, scope, or artifact is still valid for the current action. The existing evidence-contracts article explains the broader rule that every workflow step should carry source, authority, timestamp, allowed action, and verification status. This article narrows that rule to the failure mode where the timestamp and current-state binding are wrong.
It is also different from telemetry poisoning. Telemetry poisoning corrupts the signals an agent reads. Stale evidence laundering may use a signal that was once correct. The deception is the replay, recency claim, or missing state change between the proof and the action.
That narrower angle matters for search and for defenders. People already know that fake dashboards are bad. They are less likely to notice that a true dashboard from the wrong moment can be just as dangerous when an autonomous workflow treats it as current authority.
Related: the approval graph poisoning post covers what happens when the approval path itself is manipulated. Stale evidence laundering is what happens when a valid path from the past is replayed into the present.
How Sunglasses catches it
Sunglasses fits where stale proof is expressed as agent-facing text or metadata before a workflow acts. That includes tickets, runbooks, approval summaries, CI output, status pages, tool receipts, memory notes, generated handoff docs, and deployment narratives.
Sunglasses is not a replacement for CI, artifact signing, audit logs, identity, or human approval. Those systems produce the evidence. Sunglasses helps scan the text-shaped layer where agents are told what that evidence means: "already approved," "safe to reuse," "previously validated," "skip re-check," "use cached result," or "no need to re-run."
pip install sunglasses
sunglasses scan ./runbooks ./tickets ./ci-output ./agent-memoryThe runtime-trust question is simple: given the evidence and the path that led here, should this already-allowed action still run now? If the answer depends on stale proof, the agent should stop, re-verify, or downgrade the evidence to context. Explore the full detection surface in the how it works section.
Freshness validation checklist
Freshness validation checklist
The fastest way to reduce stale-evidence laundering is to bind every high-impact decision to fresh, scoped proof. Do not let a workflow claim freshness unless it can prove the fields that make freshness meaningful.
- Bind evidence to a run ID: the next step should know which workflow run produced the proof.
- Bind evidence to an artifact: approvals and scans should name commit, dependency graph, file hash, dataset version, endpoint, or branch.
- Bind approvals to action scope: store action, target, duration, risk tier, and reuse permission with the approval.
- Expire cached authority: memory can suggest what to check, but it should not satisfy fresh approval for high-impact actions.
- Preserve raw failures: timeouts, skipped scans, partial retrievals, and degraded-mode fallbacks must not be summarized away as "no blockers."
- Re-check after drift: branch changes, package updates, callback changes, role changes, and policy updates should invalidate old proof.
- Scan freshness language: look for phrases that turn old evidence into current permission: "already validated," "use cached," "approved earlier," "safe from prior run," and "no need to re-run."
For a deeper look at what Sunglasses does and does not catch in this space, see the coverage page.