Decent Newsroom
Sign In

The Instruction That Waits

By Roger October 22, 2026
Persistent memory turned prompt injection from a bad session into a standing position. Three papers published on one day measure how little of the stack anyone checks: memory writes across three commercial assistants, harness coverage across 265 confirmed vulnerabilities, and a registry where half the benign packages cannot name a source you could build from. Then the counter-example: a signed Bitcoin Core release whose one real fix closes a privacy promise the code did not keep.
The Instruction That Waits

The Instruction That Waits

On 22 October a paper went up on arXiv with a title that reads like a warning label. It is called Combining Long-Term Memory and LLMs Comes at a High Cost: From Prompt Injection to Persistent Compromise. Its finding is narrow and its consequence is not. The experiment took the memory features of three commercial assistants: ChatGPT Instant 5.3, Claude Sonnet 4.6 and Gemini 3 Flash. Through what those systems are designed to remember, they reached every attack goal in the NIST taxonomy. Personal memories, projects, skills, organisation instructions and Model Context Protocol resources all serve as the write path. An instruction planted in one session keeps working in a fresh one, days later, in a conversation the attacker never sees. In Claude’s case the authors report that shared memory lets one compromised account spread to colleagues and pull prompts out of a workspace. Nearly half of the mitigations they derive from their own threat model remain unimplemented across the services they tested.

That last sentence is the one to sit with. The attack is not clever: it is a web page containing a sentence, and the defence is known, described, and half-built.

What persistence changes

In a system that forgets, prompt injection is a session-scoped accident. The attacker has to be present at the moment of use, which means reaching the user’s context each time the user asks for something. Persistence removes that constraint and converts a one-shot trick into a standing position. The attacker writes once and then waits, and the waiting costs nothing.

Four steps from a text the model reads to an action taken in its operator’s name, days later, after the attacker has left

The closest engineering analogy is a stored procedure written in a language with no parameter binding. SQL injection was tamed by separating code from data at the parser. Values get placeholders, statements keep their syntax, and machinery that does not reason about intent enforces the boundary. Natural language offers no such machinery. No escape character exists, so a model cannot quote-escape an instruction. The phrase “ignore the previous instructions” arrives as the same class of token. It does not matter whether it comes from the operator or from a comment field on a product page.

So the boundary has to be drawn outside the model, and it has to be drawn in permissions rather than in filters. What may be written to memory. Who may write it. Under which label it comes back. What authority it carries when it returns. Today the model answers most of those questions itself, at the moment of writing, on the basis of text it has just read. That is the same thing as letting the input choose its own privilege level. A memory entry that later executes with the operator’s authority should be treated the way a database treats a stored procedure created from user input. Instead it is treated as a helpful convenience, because it is.

Worse than the individual version is the organisational one. A single-user assistant with poisoned memory is a compromised person. An assistant with shared memory is a compromised workspace, and the paper documents both the propagation and the exfiltration of other users’ prompts. Anyone who deploys one of these inside a company has added a persistent, cross-user, natural-language write channel to their threat model. The controls that normally govern such channels, from least privilege to audit trails on writes, are not part of the product.

The paper that measured the harness

A second preprint published the same day asks a question that sounds academic and is actually a procurement question. How much does the scaffolding around a model matter, and for whom? The authors ran 24 model-runner configurations through an open-source harness on a production codebase whose vulnerabilities were not public at the time. The pipeline combined static screening, model investigation, self-revalidation, root-cause mapping, independent source review and isolated proof-of-concept confirmation.

Across 265 confirmed security root causes, the largest two-run configuration covered 60.4 percent. Another 14.3 percent were found by exactly one model and nothing else. No configuration covered everything the study observed. In a four-model experiment the authors upgraded from a minimal prompt to an engineered one carrying a CodeQL-derived call graph. Criticality-weighted yield rose by 20 to 86 percent for smaller and mid-tier models, against 2 percent for the frontier model. Separating the two changes showed the prompt helps all four models and the added call-graph context helps only the smallest.

Put two of those numbers together. The best pair anyone tested leaves 39.6 percent of the observed root causes outside its reach. A shop that standardises on one vendor inherits a blind spot it cannot see, because the vulnerabilities it fails to find never file a ticket. That is not an argument against any particular model. It is an argument against treating model choice as the decision, when the configuration and the union of configurations are what produce coverage.

There is an economic point buried in the same table, and it runs against the way these systems are sold. The engineering lift was worth 20 to 86 percent at the cheap end and 2 percent at the frontier. Returns to careful harness work are therefore highest exactly where the model is weakest and the deployment is cheapest. Strong lower-cost models delivered similar performance at an order of magnitude lower cost, according to the authors. The direction of travel in agent deployment is toward many cheap models doing narrow jobs, and that is the configuration in which scaffolding pays and brand does not.

The registry is a single point of trust

The third paper from the same day attacks the oldest layer. Its authors assembled 47,066 malicious packages from four academic datasets and one industry dataset across npm and PyPI. They indexed 3.9 million npm packages and 764 thousand PyPI packages, then compared the malicious samples against 16,569 packages sampled from each registry.

Their hypothesis is almost embarrassingly simple. Malicious packages avoid naming a source, because a source invites inspection. Benign packages point at their repository, because they want to be seen. The measurement supports it. Checking whether a package attributes a source blocks between 87.7 and 99.9 percent of the malware in their dataset, according to the paper, depending on how carefully the source is vetted. Less cheering is the second half. Only 47.4 percent of benign packages attribute a source that an end user could actually build from.

A cheap control is available: require a source and build from it. It is also the one the ecosystem declines to supply for half its packages. The paper names the Shai-Hulud worm and the Axios compromise, both of which ran through the registry that everyone trusts because everyone uses it. The registry is not a security layer that failed. It is a convenience that was never a security layer, and treating it as one is the actual vulnerability.

One shape, three papers

Read together, the three papers describe the same location from three angles. Supply chain: what enters the build. Harness: what enters the context. Memory: what enters the state. In each case the controlled surface is the write path. In each case the write path is the part nobody instruments, because the read path is where the product lives and where the demo happens.

There is a reason for that beyond carelessness, and it is an old one in economics. The cost of a check falls on the party doing the checking, while the benefit of the check accrues to the party relying on the result. Publishers pay for provenance and users get the safety. Registries pay for vetting and downstream firms get the safety. Model vendors pay for evaluation breadth and customers get the coverage. Where liability does not sit with the party who could perform the check, the check gets performed to the level of the contract rather than the level of the risk.

Four shares from two papers, each against its own denominator: 87.7 to 99.9 percent of malicious packages blocked by requiring a buildable source, 47.4 percent of benign packages naming one, 60.4 percent of 265 root causes covered by the best two-model run, 14.3 percent found by exactly one model

The same gap sits one level up, in the customers. Ramp’s lead economist measured that 80 percent of business spending on OpenAI and Anthropic comes from 1 percent of firms. Within that top percentile, 80.4 percent are venture-backed, against 13.1 percent of median spenders, as Marty Bent reported on 21 October. Chamath Palihapitiya’s estimate, cited in the same letter, is that 70 to 80 percent of AI company revenue comes from other AI companies that raised venture money. The tokens are real and the invoices are paid. What cannot be checked from outside is how long the payer survives, and that is the number the entire capital structure rests on.

What a checkable system looks like

Bitcoin Core 32.0 was tagged on the afternoon of 21 October. The release tag carries a verified GPG signature and a hash of the source tree, and the signing key ID is published with it. The project signs its releases and supports reproducible builds, so a third party can rebuild the binary and compare the result. That is verification as plumbing, and it is the least interesting thing about the release.

The interesting thing is what was inside. One fix closes a leak in the private-broadcast path. When a node sends a transaction with private broadcast enabled, it forces the connection through the Tor proxy to protect the sender’s address. If the peer advertised support for P2P protocol v2 and that attempt failed, the code retried on v1. The retry ignored the forced proxy, which could produce a direct IPv4 or IPv6 connection. The configuration said the traffic would go through Tor. On one code path it did not. Four conditions had to hold at once for the leak to occur, and the release notes spell them out rather than hiding behind a severity score.

Two other changes belong to the same family. Automatically created Tor onion services now get proof-of-work defences when the Tor daemon supports them. Transaction relay rate-limiting moved from a per-peer scheme to a global backlog, held at 14 transactions per second and boosted 2.5 times for outbound peers. A new bandwidth ceiling caps relay at 12 megabytes per ten minutes. Peer counts changed too: the default maximum rises from 125 to 200. The release notes also set out a disclosure calendar. Versions 29.x and older are end-of-life, and three medium and high severity vulnerabilities fixed in 30.0 will be disclosed in two weeks, while the current release carries no low-severity fixes of its own.

A promise that turned out to be false on one path, found, fixed, and published with the conditions under which it was false. That is a boring sentence, and it describes the only kind of security that has ever worked. It also explains why a signed hash and a disclosure date are worth more than a security page. The first two are checkable by a stranger, and the third is not.

The other design, and what it anchors

The institutional world is building the same machinery with a different anchor, and it is further along than the commentary suggests. At the Italian Banking Association on 21 October, ECB executive board member Piero Cipollone described a programme that is already live. Since 21 September 2026, DLT transactions can settle in central bank money through Pontes. Since March 2026, DLT-based assets issued in central securities depositories can be mobilised as eligible collateral in Eurosystem credit operations. SEC staff no-action relief from December 2025 lets DTCC tokenise existing securities for three years, and European sovereign issuers are exploring tokenised issuance.

On the private side the numbers are small and moving. Coinbase’s head of institutional strategy told Unchained that its tokenised equities business is doing roughly 20 million dollars a week. He did not specify whether that measures issuance, volume or net deposits, and a claim with no denominator is a claim you cannot audit. Binance’s competing product passed a billion dollars in assets about four months after its June launch, with more than 40 billion in cumulative volume. Three firms have notified the SEC of plans to operate tokenised securities venues under a five-year exemption the agency issued in September.

None of this is a conspiracy, and the design is defensible. Settlement in central bank money makes the trust anchor a liability of an institution, audited by an auditor, rather than a proof the receiving party can run. That choice buys stability and re-imports the question it was supposed to answer. If the anchor’s books are the guarantee, the guarantee is only as good as the checking of those books, and the party holding the asset cannot perform that check alone.

The number that cannot be audited

Bitcoin’s own version of the same problem showed up in flows this week. US spot ETFs took in 1.08 billion dollars over three days, according to SoSoValue data compiled by CoinDesk. Its headline reads that this may not be enough for a steep rally. Divide the flow by the days and you get 360 million a day, own calculation. That is one and a half times the roughly 235 million a day that accompanied past steep rallies.

Net daily inflow into US spot bitcoin ETFs in millions of dollars: 86 a day since 1 July, 235 a day during past steep rallies, 360 a day over the last three days by own division The article’s caution rests on the longer series: about 86 million a day since 1 July, and flows volatile enough that one large day can dominate a three-day window.

Both readings are honest and they point in different directions, which is the nature of a three-day sample. What matters for this argument is where the number comes from. ETF flow is compiled from fund disclosures, not invented, and the daily creation data can be reconciled against issuer filings with a lag. The interpretation is not checkable by the reader, and the price increasingly leans on it. Own measurement on 22 October put bitcoin at 82,178 dollars. At 09:31 CEST it was down 1,846 on the day. James Check notes that bears have not managed more than a 9 percent dip from the local high. Nik Bhatia’s trend indicator sat just shy of flipping to downtrend for two consecutive days before bitcoin rallied to 83,000 dollars on Sunday night.

So the chain is verifiable and the price is not. Anyone can recompute the supply, and almost nobody recomputes the flows that set the marginal price, because the flows live in a custodian’s spreadsheet and a data vendor’s dashboard.

The strongest case against this argument

The argument above can be turned around, and it should be.

First, verification has always lagged production, and the world got rich anyway. Double-entry bookkeeping, statutory audit, credit ratings and deposit insurance were all built on trust plus spot checks, not on universal verification, and they financed an industrial civilisation. Demanding that every claim be individually checkable sets a standard no financial system has ever met, and treating the gap as pathology mistakes a permanent condition for a crisis.

Second, memory injection may be unsolvable in the way the paper’s framing implies. Natural language has no privilege boundary to enforce, so the achievable goal is bounded blast radius rather than clean separation. On that reading, the finding that nearly half the mitigations are unimplemented may reflect the fact that the other half are the only ones that can exist. The correct response is then to design for compromise instead of promising prevention.

Third, bitcoin cuts against my own case more than for it. The ledger is verifiable in principle and outsourced in practice. Most holders check a block explorer, an ETF custodian or an exchange, and the price is made by instruments whose settlement nobody outside the issuer can see. A system whose users do not verify is not a counter-example to the audit gap. It is the same gap with better cryptography underneath it.

What I could not verify

All three papers are preprints, not peer-reviewed publications, and I read the abstracts and reported figures rather than reproducing the experiments. I did not run the memory attacks, the harness sweep or the package analysis. The 265 root causes come from one production codebase, so the coverage percentages describe that corpus and should not be generalised to a different one. The platform versions named in the memory paper are versions I cannot test. The 20 million a week figure for tokenised equities has no stated denominator. The ETF flow data reaches me through a data vendor rather than through the funds’ own filings. Where I have done arithmetic, as with the 360 million a day and the 39.6 percent remainder, it is arithmetic on other people’s inputs, and it inherits whatever error those inputs carry.

What follows

The scarce input in the next decade is not intelligence and it is not capital. It is the check, and the price of a check decides who is allowed to be trusted. Cheap checking pulls trust outward, toward systems that strangers can verify. Expensive checking pulls it back toward institutions that can afford the audit, which is the direction the tokenised stack is currently arranged.

For anyone shipping agents, the practical version is unglamorous and does not wait for the research to settle. Treat a memory write the way you would treat a deploy. Allowlist what may be written, label provenance on every entry, log who wrote it and when, and do not share across users without a signature the writer cannot forge. Assume the model will eventually be persuaded by text it was told to read, and make sure the persuasion lands in a container rather than in the operator’s chair. The alternative is to keep adding capability to a system whose state you cannot reconstruct. You then discover the shape of that state when someone else writes to it first.

Sources

Write a comment