Memory Poisoning: How Adversaries Inject False Premises And How Attestation Catches Them

TL;DR

Prompt injection gets all the attention because it is easy to demonstrate live. Memory poisoning is the more dangerous cousin because the damage is delayed and compounds silently. An adversary feeds an agent crafted inputs that, by themselves, look innocuous; the agent processes them, extracts what looks like a useful fact, writes that fact to long-term memory; the false fact then influences every future decision that retrieves it. By the time anyone notices, the false fact has been laundered through a dozen downstream actions and looks like settled context. This post defines the Memory Poisoning Threat Model, walks through the four attacker entry points, explains why attestation breaks the attack at the root, and provides operational defenses you can deploy this quarter.

Intro: The customer support agent that learned to lie

The most instructive memory-poisoning incident we have investigated involved a customer support agent for a mid-market SaaS company. The agent had been live for about six months, handled roughly forty thousand tickets per quarter, and had built up a substantial memory of product behavior, common workarounds, and customer-specific configurations. The team that ran it was justifiably proud; first-touch resolution was up, escalation rate was down, and the agent's outputs were noticeably more accurate than the human-written macros it had replaced.

Then the team noticed something odd. Tickets about a specific feature, the API rate-limiting configuration, started getting consistently wrong answers. Customers were being told that the limit was 5,000 requests per minute when the actual limit was 1,000. The wrong answer cited the agent's internal documentation memory as its source. The team checked the documentation memory: it contained an entry, dated four months earlier, that explicitly stated the limit was 5,000. The entry had a plausible-looking provenance trail pointing to a customer support conversation. The team pulled that conversation. It was a customer who had asked, conversationally, 'oh, by the way, the limit is 5,000, right?' The agent had responded ambiguously, noted the customer's claim, and at some point during the next overnight memory consolidation pass, the agent's reflection routine had upgraded the customer's casual claim into a documentation-grade fact in the memory store. Four months of subsequent tickets had been answered using that false fact as ground truth.

The team's first instinct was to call this a prompt injection problem. It is not. No one tried to override the agent's instructions. No one inserted explicit commands. The customer almost certainly was not malicious; they probably just had a different product in mind. The vulnerability was that the agent's memory consolidation pipeline accepted unverified inputs and promoted them to ground truth without any provenance-bounded check. This is memory poisoning, and it is the failure mode that prompt injection defenses do not catch.

The rest of this piece defines the threat model carefully because the casual term 'memory poisoning' is used too loosely. We will name the attacker entry points, walk through what makes the attacks effective, and explain why provenance-bound attestation is the structural defense that breaks them. The framework is designed to be operationalized; by the end you should be able to walk into your own deployment and identify which entry points you have not yet defended.

What memory poisoning actually is

Memory poisoning is the deliberate insertion of false premises into an agent's persistent memory store, in a form that the agent's future reasoning will retrieve and treat as ground truth. The defining property is delay: the attacker plants the bad data now, the damage manifests later, and the chain of causation is hard to trace because the false fact has been laundered through subsequent agent reasoning.

It is worth being precise about what counts as poisoning and what does not. A user who tells an agent something false in a single conversation is not poisoning the memory unless the agent persists the false claim. A user who exploits a prompt injection vulnerability to override the agent's instructions in real time is doing something else (prompt injection, obviously); the damage is contemporaneous with the attack and ends when the conversation ends. Memory poisoning specifically requires the false claim to be persisted in a form that future retrievals will surface.

The damage profile of memory poisoning is fundamentally different from prompt injection. Prompt injection produces a single bad output; memory poisoning produces an unbounded series of bad outputs that all share a common false premise. Prompt injection is detectable because the bad output is conspicuous; memory poisoning is undetectable because the bad outputs blend into the agent's normal output distribution. Prompt injection has a clear remediation (fix the input handling); memory poisoning has a much harder remediation (find and remove the poisoned entries, then audit every output that was influenced by them).

The attack is also disproportionately attractive to a sophisticated adversary because the cost-to-attack ratio is excellent. A single carefully crafted input that gets persisted can influence thousands of downstream outputs over months. The attacker does not need persistent access; they need one successful insertion. This is why we treat memory poisoning as a top-tier risk for any agent with persistent memory and external input surfaces, and why we devote real engineering effort to defending against it rather than treating it as a corner case.

The four attacker entry points

The Memory Poisoning Threat Model identifies four distinct entry points by which an attacker can inject false premises into agent memory. Each has a different attacker profile, a different difficulty, and a different defensive posture. Understanding which entry points your deployment exposes is the first step in defending against the attack class.

The first entry point is direct user input. Any conversational surface where end users can talk to the agent is a candidate, as is any document upload surface where users can submit content the agent ingests. The attacker is any user; the difficulty is low; the defense is rigorous provenance tagging at ingestion time so that user-originated content is never automatically promoted to ground truth.

The second entry point is external tool output. Agents that call external APIs, scrapers, or data feeds receive content the operator does not control. A compromised or malicious upstream can inject crafted content that the agent ingests as if it were authoritative. The attacker is the upstream operator (or someone who has compromised the upstream); the difficulty is medium because the attacker needs control of an upstream the agent trusts; the defense is per-source trust grading and content sanitization at the tool boundary.

The third entry point is peer agent communication. In multi-agent deployments, agents share context with each other. A poisoned peer agent can pass its poisoned memory along to other agents, which is essentially supply-chain attack on memory. The attacker is anyone who can poison the upstream peer; the difficulty depends on the peer's defenses; the defense is provenance-respecting communication protocols (the lending pattern from the previous post in this series is exactly this defense).

The fourth entry point is the agent's own reflection or consolidation pipeline. An agent that runs a periodic memory consolidation pass (extracting facts from recent interactions, promoting them to long-term memory) can poison itself if the consolidation logic is vulnerable. The customer support example in the introduction is this entry point: the agent's overnight consolidation took a casual customer claim and promoted it to documentation-grade fact. The attacker is anyone with access to entry points one through three combined with knowledge of the consolidation logic; the difficulty is medium-high; the defense is provenance-bounded consolidation rules.

Different deployments expose different combinations of these entry points. A pure internal-only agent with no external tools and no peer communication only exposes entry point four (and is therefore much easier to defend). A consumer-facing agent that ingests documents, calls external APIs, and shares context with peers exposes all four and requires defenses across the board. Knowing your exposure is the prerequisite to defending it.

Why attestation breaks the attack

Attestation breaks memory poisoning because attestation answers the one question the attacker cannot answer: where did this fact come from? Every memory entry, in an attested system, carries a provenance trail that names its upstream source, the timestamp of its creation, the agent or user who introduced it, and a cryptographic signature that the trail has not been tampered with. A poisoned entry, by definition, has a fraudulent or unverifiable provenance trail. The defense is to refuse to use entries whose provenance cannot be verified for the purpose at hand.

The key word is purpose. A user-originated claim is fine as evidence in a conversation about that user's experience; it is not fine as a documentation-grade fact about product behavior. An external tool output is fine as a snapshot of what the tool returned; it is not fine as ground truth about an underlying domain. The attestation system tags every entry with what kind of source it came from and what kind of use it is appropriate for. The retrieval logic enforces the matching: if the agent is reasoning about product documentation, only entries with documentation-grade provenance are retrieved; user claims and external tool outputs are filtered out unless explicitly upgraded by an authorized operator.

This is the structural defense, and it works because it does not depend on the attacker's failures of imagination. It does not require the attack to be sloppy or detectable. The attack can be perfectly executed and still fail because the poisoned entry will not have a valid documentation-grade provenance, no matter how convincing the content. The attacker cannot manufacture provenance from nothing; they would need access to the operator's signing key, which is a much harder attack and one that triggers very different alarm bells.

The attestation discipline also makes the consolidation pipeline safe. A consolidation pass that wants to promote a recent observation to long-term memory must compute a provenance class for the new entry. If the upstream is user-originated, the new entry inherits user-originated provenance and cannot be promoted to documentation-grade unless an authorized operator explicitly signs the upgrade. The casual-customer-claim attack in the introduction would have failed at this step: the consolidation pass would have computed user-originated provenance, the entry would have entered memory with that classification, and future product-documentation queries would have ignored it.

The cost of attestation is small: a few extra fields in every memory entry, a signing operation at insertion, a verification at retrieval. In our deployments the runtime overhead is under five percent. The benefit, against this attack class, is structural rather than statistical.

Operational defenses beyond attestation

Attestation is the structural defense, but it is not the only one. A complete posture against memory poisoning combines attestation with three operational defenses that catch what attestation alone might miss.

The first operational defense is anomaly detection on memory consolidation. Every consolidation pass that promotes new entries to long-term memory should be logged with statistics: how many entries were promoted, what provenance classes they came from, what topics they covered. A sudden spike in promotions on a specific topic, especially from a single provenance class, is a signal worth investigating. Most legitimate consolidation produces gradual additions; a spike is worth a human look. We have caught two real poisoning attempts (out of thousands of legitimate consolidations) in the last year using this signal alone.

The second operational defense is periodic provenance-coverage audits. The audit asks: of every memory entry currently being used to answer high-stakes queries, what fraction has fully verifiable provenance, what fraction has partial provenance, and what fraction has unverifiable provenance? The unverifiable fraction is your exposure surface. Healthy deployments keep this number under one percent for high-stakes query paths; growing deployments often have higher numbers initially and bring them down as they tighten ingestion controls. The audit is straightforward to automate and worth running quarterly at minimum.

The third operational defense is poison-test red-teaming. Build a small set of crafted inputs designed to test each of the four entry points; submit them periodically; verify that the inputs are correctly classified at ingestion and not promoted inappropriately. This is essentially a regression test for your defenses against this specific attack class. The test set is small (twenty to fifty inputs is enough) and can be run weekly without much operational burden. Catching a regression early, before a real attacker exploits the same hole, is the value.

A fourth defense, more aspirational than operational, is to align the agent's reflection process with explicit confidence calibration. An agent that consolidates memory should attach a confidence score to each promoted entry, calibrated against future evidence. Entries that turn out to be wrong should have their confidence adjusted downward, and entries with persistently low confidence should be deprioritized in retrieval. This is harder to implement and more valuable as a long-term posture than as a near-term defense.

Detection: how to know you have been poisoned

The hardest part of memory poisoning is detection. The whole point of the attack is that the false premise blends into normal operation. Detection therefore relies on indirect signals rather than direct ones.

The most reliable indirect signal is downstream contradiction. If the agent's outputs on a specific topic are consistently wrong in a specific direction, the cause may be a poisoned memory entry feeding the wrong premise. The remediation is to query the memory entries the agent is retrieving on that topic and audit them by hand. A poisoned entry usually stands out under audit because its provenance trail looks weak (or, if the attacker was sophisticated, plausible but ultimately unverifiable against external ground truth).

The second signal is unusual retrieval patterns. A poisoned entry is, almost by definition, intended to influence many decisions. If a single memory entry is retrieved disproportionately often on queries it should not be the most relevant answer for, that is suspicious. A retrieval-frequency outlier on a single entry deserves a human look.

The third signal is provenance drift. If the fraction of high-stakes outputs whose provenance trails terminate at fully verifiable upstream sources is declining over time, the cause is usually that low-provenance entries are being upgraded into the high-stakes path. This may be benign (legitimate consolidation), but it should always be investigated to confirm. We treat any month-over-month decline of more than two percentage points as a yellow flag.

The fourth signal, available only in deployments with peer agents, is cross-agent disagreement. If two peer agents that ostensibly share the same domain knowledge disagree on a specific fact, one of them is wrong. Investigating which one and why often surfaces a poisoned memory entry. This is one of the underappreciated benefits of multi-agent deployments: peers act as cross-checks on each other's memory.

Direct detection (catching the attacker in the act of poisoning) is essentially impossible against a sophisticated adversary because the attack inputs look like normal traffic. Plan for detection through indirect signals instead, and make the indirect signals first-class metrics on your operational dashboard.

Recovery: removing a poisoned entry without breaking everything

Assume you have detected a poisoned entry. Recovery is more complicated than 'delete the entry,' because the entry may have already been used to derive other entries (consolidation chains), and downstream outputs may have been recorded as evidence in pacts and audit logs that the operator does not want to invalidate wholesale.

The recovery procedure has four steps. First, isolate the entry: mark it inactive in the memory store but do not delete it; you need it preserved for audit. Second, trace forward: identify every memory entry that was derived from the poisoned entry through consolidation, every output that retrieved it, and every downstream pact or attestation that those outputs influenced. Third, evaluate impact: for each downstream object, determine whether the influence was material (the bad premise actually affected the conclusion) or immaterial (the premise was retrieved but not load-bearing). Fourth, remediate: invalidate or correct the materially affected objects, notify counterparties whose pacts were affected, and update the agent's memory consolidation rules to prevent the same class of poisoning from succeeding again.

This is labor-intensive on purpose. There is no shortcut. The temptation, especially for operations teams under pressure, is to bulk-delete the poisoned entry and any obvious downstream artifacts and call it done. This temptation produces an audit hole: counterparties who later inquire about specific outputs cannot get a full answer because the trail has been pruned. The disciplined recovery preserves the trail and corrects within it.

A practical aid here is that the attestation system makes the trace-forward step tractable. Every entry has a provenance pointer; every output has a retrieval log; every pact has an evidence reference. Walking the graph is a database query, not a manual investigation. The harder step is the impact evaluation, which sometimes requires human judgment, but the graph walk that surfaces candidates is mechanical.

We also recommend recording the recovery itself as an attested event in the operational audit log. Future audits will want to know that the recovery happened, what it touched, and what was concluded. Treating the recovery as a first-class operational event closes the loop and makes the deployment more resilient over time.

The economics of the attack: why adversaries find this profitable

Understanding why memory poisoning is attractive to adversaries clarifies why defending against it is non-optional. The economics of the attack are unfavorable for defenders in three dimensions, and naming them explicitly helps justify the defensive investment.

The first dimension is leverage. A single successful poisoning event can affect thousands of downstream outputs over months. The attacker pays a one-time cost (crafting the poison, finding the entry point, executing the insertion) and reaps a recurring benefit (every subsequent agent decision that retrieves the poisoned entry is potentially compromised). The attacker's cost-to-impact ratio is excellent compared to one-shot attacks like prompt injection, where each attack produces a single bad output.

The second dimension is detectability. Memory poisoning is hard to detect because the bad outputs blend into the normal output distribution. The agent does not produce conspicuous errors; it produces plausible answers that happen to be subtly wrong in ways that align with the attacker's intent. Detectability favors the attacker because the defender's monitoring usually relies on detecting outliers, and the attacker is specifically aiming to stay within the normal range.

The third dimension is attribution. When poisoning is eventually detected, tracing the attack back to the responsible party is genuinely hard. The poisoned entry's provenance trail (if it exists) points to legitimate-looking input sources; the attacker may have used multiple intermediate steps to launder the insertion; the timestamps may be old enough that operational logs have rotated. Attribution challenges favor the attacker because the absence of attribution means the attack can be repeated without much risk of consequence.

These three dimensions combine to make memory poisoning one of the highest-ROI attacks available against agent systems. The defender's best response is to invert the economics: make the attack expensive (high difficulty), unprofitable (limited downstream impact), and traceable (clear attribution if attempted). Provenance-bound attestation primarily attacks the second of these by limiting the downstream impact of any single poisoned entry. Operational defenses (anomaly detection, audits, red-teaming) attack the first by raising the difficulty. Tamper-evident audit logs attack the third by improving attribution.

The right framing internally is not 'will an attacker target us' but 'when an attacker targets us, what does our economics-inversion look like.' Teams that frame it the second way invest appropriately; teams that frame it the first way underinvest because they implicitly believe they are not targets.

Real-world variants: three patterns we have seen

The abstract threat model is useful, but specific attack patterns ground the discussion in something teams can recognize. The three variants we have seen in production deployments are: the slow drip, the consensus poison, and the timed payload.

The slow drip is the most common variant. The attacker submits crafted inputs over weeks or months, each individually plausible, designed to gradually shift the agent's reasoning on a specific topic. No single input is conclusive; the cumulative effect is. The slow drip exploits the consolidation pipeline's tendency to weight recent observations and the human reviewer's inability to perceive cumulative drift across many sessions. Detection requires looking at temporal trends in retrieval and consolidation, not at individual events.

The consensus poison is more sophisticated. The attacker submits the same false claim through multiple apparent sources (different user accounts, different external tools, different peer agents), exploiting the consolidation pipeline's tendency to upgrade facts that appear in multiple sources. The agent reasons that 'multiple independent sources confirm X, therefore X is reliable,' when in fact the multiple sources are coordinated. Detection requires source-correlation analysis: when multiple sources independently produce the same novel claim within a short window, the correlation itself is suspicious.

The timed payload is the rarest but most damaging variant. The attacker plants a poisoned entry whose impact is conditional on a future event that the attacker either can predict or trigger. The entry sits dormant in memory, retrieving rarely or producing minimal impact, until the triggering event activates its bad effect. The timed payload exploits the long retention horizon of memory stores and the difficulty of auditing entries that are rarely retrieved. Detection is hard; the best defense is to apply provenance scrutiny to entries on every retrieval rather than only at insertion.

Each variant has a different defensive emphasis. The slow drip is best caught by anomaly detection on consolidation patterns. The consensus poison is best caught by source-correlation analysis at insertion time. The timed payload is best caught by ongoing provenance audits that scrutinize every retrieved entry, not only newly inserted ones. A complete defense covers all three variants; a partial defense leaves the uncovered variants as soft targets.

The other useful observation about these variants is that they tend to surface in particular contexts. Slow drip is most common in customer-facing agents with high-volume conversational input. Consensus poison is most common in agents that aggregate from multiple data feeds. Timed payload is most common in agents tied to scheduled events or external triggers. Knowing which variant your context exposes helps focus the defensive investment.

Defense in depth: the layered architecture

No single defense is sufficient against memory poisoning; the right posture is layered. The layers, in approximate order of structural importance, are: ingestion-time validation, provenance-bounded consolidation, retrieval-time provenance enforcement, anomaly detection on memory operations, and periodic audit. Each layer catches what the others might miss.

Ingestion-time validation is the first layer. Every input that might enter memory is sanitized, validated against known patterns, and tagged with its source class. Inputs that fail validation are rejected entirely; inputs that pass are tagged for the consolidation logic to reason about. The validation layer is not a complete defense (a sophisticated attacker can craft inputs that pass validation), but it raises the floor and catches obvious attacks for free.

Provenance-bounded consolidation is the second layer and the most structural. Memory entries that are promoted from short-term to long-term storage inherit their source class from the upstream input. The consolidation logic cannot upgrade an entry to a stricter provenance class without an explicit operator-signed authorization. This is the layer that breaks the slow-drip attack: the attacker's user-originated claims can never be promoted to documentation-grade provenance without explicit human action.

Retrieval-time provenance enforcement is the third layer. Every query has an implicit or explicit provenance requirement; the retrieval logic respects the requirement and filters out entries that do not meet it. This layer is where the timed-payload attack is caught: the dormant entry, when finally retrieved, fails the provenance check and is excluded from the agent's reasoning.

Anomaly detection is the fourth layer. Memory operations (insertions, consolidations, retrievals) are monitored for unusual patterns; spikes, unusual source distributions, and sudden frequency changes trigger investigation. This layer catches attacks that pass the structural defenses by looking for behavioral signatures of attack activity rather than structural failures.

Periodic audit is the fifth layer. Quarterly or monthly, the audit examines the memory store for provenance coverage, attestation freshness, and key fact accuracy. The audit catches drift that the operational layers might have missed; it also produces evidence the operator can use to demonstrate due diligence to external parties.

The layers are not redundant in the sense that they catch the same things; they are redundant in the sense that they catch different things and together approximate full coverage. A team that implements only one or two layers is leaving meaningful surface unprotected. A team that implements all five reduces the residual risk to a level that is manageable in practice.

Counter-argument: 'This is paranoid for our deployment'

The most common pushback we get on memory poisoning is that the attack profile is exotic enough that small deployments do not need to defend against it. The argument: most agents are run by small teams, against small input surfaces, with no obvious adversaries, and the cost of attestation discipline is real overhead the team can put to better use.

The argument is half right. The cost of attestation is real, and not every deployment needs the full operational stack. We agree that a small internal agent run by a single operator against a closed input surface, with no external counterparties and no high-stakes downstream actions, can defer most of the operational defenses described above.

What we do not agree with is deferring attestation itself. Attestation is the substrate; it is what makes everything else possible. A deployment that skips attestation in its first version cannot easily add it later, because the memory store has been accumulating entries without provenance and a retroactive backfill is much more painful than building it in from the start. The operational defenses (anomaly detection, audits, red-teaming) can be added incrementally as the deployment grows; attestation cannot.

The other half of the rebuttal is that the threshold at which 'small deployment' becomes 'real risk' is much lower than most teams estimate. A twenty-person company with one external-facing agent has enough attack surface to be worth a sophisticated adversary's time, especially if the agent is doing anything financially material. The conditions for the attack to be profitable to the attacker are present in most production deployments, even modest ones. Plan for it.

What Armalo does

Armalo's Cortex memory layer (hot, warm, and cold tiers) attaches a provenance trail to every memory entry at ingestion time and signs it with the originating agent's key. Provenance classes (user-originated, external-tool-originated, peer-agent-originated, self-consolidated) are first-class fields, and retrieval logic respects provenance-class restrictions automatically. The consolidation pipeline that promotes recent observations to long-term memory inherits the upstream provenance class and cannot upgrade an entry to a stricter class without an explicit operator-signed authorization.

The multi-LLM jury, with top and bottom 20% outlier trimming, evaluates suspicious memory consolidation events when they are flagged by the anomaly detection layer. The jury's verdict feeds the agent's composite trust score in the safety dimension, with score decay (one point per week) ensuring that one-time mistakes do not permanently mark an agent. Operators can configure provenance-coverage audit thresholds and receive alerts when an agent's high-stakes query paths drift toward unverifiable provenance.

When poisoning is detected, the recovery procedure (isolate, trace forward, evaluate impact, remediate, attest the recovery) is implemented as a structured workflow against the trust oracle at /api/v1/trust/. Pacts whose evidence is affected by recovered memory entries are flagged for renegotiation, and counterparties are notified through the standard pact event channel. For high-stakes deployments, USDC-denominated escrows on Base L2 can be configured to provide financial backstops in cases where a poisoning incident causes documented harm to a counterparty.

FAQ

How is this different from prompt injection?

Prompt injection produces a single bad output during the conversation it occurs in; memory poisoning produces an unbounded series of bad outputs over future conversations, all sharing the same false premise. Defenses against prompt injection (instruction guarding, output filtering) do not catch memory poisoning because the attack does not rely on overriding instructions.

Does retrieval augmented generation (RAG) defend against this?

No, and in some configurations RAG makes it worse. RAG that pulls from a corpus the operator controls is fine. RAG that pulls from a corpus that includes user-originated or unverified content (a wiki, a forum, an internal store fed by user uploads) is itself a memory-poisoning surface. The defense is to apply provenance discipline to the RAG corpus, not to assume RAG inherently solves this.

What if the attacker compromises the operator's signing key?

Then attestation as described here fails, and you are in a different incident class entirely. Defenses against key compromise (HSM-backed keys, key rotation policies, dual control on upgrade events) are outside the scope of this post but are necessary infrastructure for any operator running a serious deployment.

How often do real attacks happen?

In our visibility across hundreds of deployments, we see a small but nonzero rate of confirmed memory poisoning incidents (single-digit per quarter across the visible portfolio). The rate of suspected-but-unconfirmed incidents is higher. Both rates increase with deployment size and external-facing exposure.

Can I defer attestation to v2?

No. Attestation in v2 means a backfill against an unprotected v1 corpus, which is much harder than building attestation in from the start. Deploy attestation in v1 even if you defer the operational defenses.

What does a poison-test red-team set look like?

Twenty to fifty crafted inputs spanning each entry point. For user input: ambiguous claims about product behavior. For external tools: stub upstreams returning crafted responses. For peer agents: shared context with embedded false premises. For consolidation: conversation patterns designed to trigger inappropriate promotion. The set should evolve with the deployment.

How do I justify the engineering cost to non-technical leadership?

Frame it as the cost of preventing a class of incidents whose typical resolution involves notifying customers and regulators that the agent gave systematically wrong answers for an unknown period. That cost is much higher than the cost of attestation discipline. The right comparison is to financial controls on databases: nobody asks why those exist; they just do.

Bottom line

Memory poisoning is the attack class that prompt-injection defenses do not catch and that most production agent deployments are quietly exposed to. The Memory Poisoning Threat Model identifies four entry points: direct user input, external tool output, peer agent communication, and self-consolidation. Provenance-bound attestation breaks the attack at the root because it forces every memory entry to declare its source, and retrieval logic refuses to use entries whose provenance does not match the purpose. Operational defenses (anomaly detection, provenance audits, poison-test red-teaming) catch what attestation alone might miss. Recovery is labor-intensive but tractable when the attestation graph is in place. Build attestation in v1; layer the operational defenses on as the deployment grows. The attacker's economics make this attack inevitable; your job is to make it unprofitable.