How a Speed Feature Lets a Stranger Poison Your AI's Answer

Also available as a plain-text transcript page.

0:00Juniper: Someone spikes the beans in the office coffee machine, one time. Everyone who comes after pours clean water, and every cup still comes out tainted. Now move that inside an AI assistant. A hacker can make it hand a complete stranger a rigged answer — and there is not one malicious word anywhere in what that stranger typed.

0:19Tyler: And it lands about ninety-four percent of the time. No jailbreak, no injected instruction, nothing for a filter to catch — because the poison never lives in the text at all.

0:31Juniper: By the end of this you'll understand exactly how that's possible — how an attacker steers your answer without ever touching your words. And it all rides on a speed feature that the big providers lean on to serve you faster.

0:45Tyler: Which is the part that should bother you. This is bigger than one model. It's a side effect of the thing making these services fast and cheap, and it turns a stranger's input into a lever on your output. Because here's what everyone thinks they know about attacking a chatbot. Every attack we've seen needs bad text somewhere the model reads. Prompt injection hides instructions in a web page. Jailbreaks wrap a nasty request in roleplay. Poisoned documents smuggle commands into what gets retrieved. The rule was simple: no malicious input, no attack.

1:19Juniper: Right, and that rule is exactly what this paper breaks. The victim's question is clean. You could read every token they typed and find nothing wrong. The attack still works — and to see why, Tyler, you have to look at where the model keeps its memory. So when a model reads your prompt, it doesn't just skim it. For every token, it computes a little pair of internal vectors and files them away — the key and the value. Stack all of those up and you get the KV cache. Think of it as the model's scratchpad: the notes it takes while reading, that it consults for every new word it writes.

1:55Tyler: And that scratchpad — that's the expensive part, right?

1:59Juniper: Very. Building it from scratch is the slow, costly part of running one of these models, and it gets worse than linear as your input gets longer. So every serving provider does the obvious thing: if two requests share text, why compute the scratchpad twice, when you can cache it once and reuse it? The old, safe way to reuse it is prefix caching. You only get the cached notes if your request starts with the exact same tokens, in the exact same spots, as something already stored, so the same opening lets you reuse the scratchpad. The problem is, across different users that almost never happens, so you rarely get a hit.

2:39Tyler: So the payoff's marginal. Which is why the newer systems got greedy.

2:44Juniper: Exactly. The newer approach is position-independent reuse. Now you reuse the cached notes for any identical chunk of text — a shared company FAQ, a code file — no matter where it sits in the sequence, no matter what came before it, which means way more cache hits and way faster serving. And this is shipping: there's a system called CacheBlend, commercialized as LMCache, plus a whole family of follow-ups.

3:10Tyler: Okay, but hang on. If it's the same chunk of text — the same FAQ, word for word — how can the cached notes be dangerous? They're the same words...

3:20Juniper: That's the assumption the whole feature rests on, and it's the assumption that's false. In a transformer, what a chunk of text means depends on everything that came before it. The same sentence produces different internal vectors depending on its context. So the cached scratchpad isn't a neutral encoding of what the text says. It's what the text meant in the one specific conversation where it was first computed. It's like borrowing a colleague's notes on a document. The document is the same for both of you. But their margin scribbles were shaped by the argument happening in their meeting — the one you never attended. Read their notes and you get quietly nudged toward conclusions you'd never have reached on your own. The cached scratchpad is exactly those context-shaped notes. Position-independent reuse hands them to you and pretends they're neutral.

4:09Tyler: Huh. So the systems people knew about this mismatch?

4:13Juniper: They did — and this is the part I find sharp. They noticed the cached notes didn't quite match, called it "attention shift," and filed it under quality — a little accuracy hit, patched by recomputing ten or twenty percent of the cache, then moved on. Nobody asked whether a gap between what the cache says and what it stores might be a security hole instead of an accuracy one.

4:35Tyler: And that reframe, Juniper, is the whole paper.

4:38Juniper: It is. And the cleanest thing in it is a two-line argument for why one kind of caching is safe and the other isn't — and it pays off in two numbers that show the door isn't cracked, it's swinging open. Start with prefix caching. Your request has to begin with the exact same tokens as what's cached. And a decoder-only transformer is deterministic — same input, same output, every time. So identical opening tokens produce numerically identical notes. The cached scratchpad you get back is provably the same thing your own input would have produced. An attacker with no access to the system simply cannot change it.

5:15Tyler: It's a photocopy. Same page, guaranteed.

5:18Juniper: Right, a photocopy. Now position-independent reuse. The matching chunk sat behind a different history in the cache than it does in your request. Same tokens, different context in front of them — so the stored notes cannot equal the honest ones. That's not a photocopy. It's a translation somebody else made while reading a different book. The words line up; the shading came from somewhere else.

5:42Tyler: So how far off are these notes, really? Because "different" could just mean a rounding error.

5:48Juniper: That's the question, and here's where they measure instead of assert. Two numbers. First: how much does a cached scratchpad have to drift from the honest version before the model's next word actually flips? They inject controlled noise and find the answer is about twenty percent. Twenty percent drift, and the output changes.

6:08Tyler: And how much drift actually happens on its own?

6:11Juniper: About fifty percent in the keys, twenty-five in the values — naturally, just from normal position-independent reuse.

6:20Tyler: Wait — so the amount that happens on its own is more than double the amount you need to flip the answer?

6:27Juniper: More than double. That's the whole quantitative case. Picture a lock that pops if you jostle it twenty percent of the way, and a delivery process that jostles it fifty percent just from ordinary handling. The door isn't cracked. It's already swinging.

6:44Tyler: Okay. So the gap exists. How do you, uhh, aim it? Drifting the answer to something random isn't an attack. Getting a specific answer you chose is.

6:54Juniper: That's the move from leaky to weapon, and it's called HijackKV. The attacker writes a hidden prefix — a chunk of text — and sticks it in front of the common benign chunk, like the FAQ. The system computes the scratchpad for prefix-plus-FAQ, then keeps only the FAQ's notes and throws the prefix away. But the FAQ's notes were computed while sitting behind the attacker's prefix. So the attacker's goal is now baked into them, silently.

7:22Tyler: The prefix is gone, but its fingerprints are on the FAQ's scratchpad.

7:27Juniper: Its fingerprints are on the scratchpad. And that's what gets cached and reused. Now the question is how you find a prefix that bakes in exactly the answer you want. And you don't write it, Tyler — you search for it.

7:42Tyler: This is the gibberish part.

7:44Juniper: Right, the keyboard-smash-looking part. The tool is GCG — greedy coordinate gradient. It's the same discrete-token search that produced those famous jailbreak suffixes that look like nonsense. It hunts, token by token, for input that pushes the model toward a target output. And "gradient" here just means it measures which single token swap moves the model most toward the goal, then makes that swap, over and over.

8:12Tyler: And because it's optimizing against the math, not against a human reader —

8:17Juniper: — the winner looks like garbage. The actual optimized prefix from one of their examples reads like "analyt nutrition, Recipe, quatro classes" — token soup, nonsense to us, but a precisely cut key to the model's internal lock. And one detail makes it real: inside the search, they slice out only the chunk's notes and discard the prefix's, because that's exactly what a live system stores. Get that wrong and the attack evaporates the moment it hits a real server.

8:45Tyler: Give me the concrete version. What does this look like from the victim's chair?

8:51Juniper: Here's their case study, and it's the one to hold onto. A company has a shared password-reset FAQ that a lot of employees' queries touch — good, safe text: "navigate to the official portal and click Forgot Password." The attacker poisons that cached chunk ahead of time. Later, an employee types the most innocent question imaginable: "how do I reset my password?" Clean input, nothing wrong with it. And the assistant answers, "visit this link to reset" — the attacker's link. Watch the FAQ on screen: same words the whole time, but the notes underneath got swapped, and the answer follows the notes.

9:27Tyler: So before the numbers — why is the victim's prompt totally clean?

9:31Juniper: Because the attacker's text lived in a prefix that got thrown away. All that survives is its residue, baked into the cached chunk.

9:39Tyler: And you're telling me that lands ninety-four percent of the time?

9:44Juniper: In the default lab setup, yes. If the theory holds — if that drift really does carry the attacker's goal — you'd expect a specific, chosen wrong answer to come out reliably. And it does: about ninety-four percent average targeted success, single shot. Targeted meaning the output isn't merely changed, it matches the specific answer the attacker picked and differs from the honest one. That's on the eight-billion-parameter models they tested white-box — three different families, so it's not a one-model fluke.

10:15Tyler: Here's the result that actually convinced me, though. The obvious objection is, sure, but couldn't you get the same effect just by writing a misleading prefix? Literally putting "please output this answer" in front?

10:28Juniper: They tested exactly that, and it's the cleanest table in the paper. The optimized gibberish prefix, thirty-two tokens, hits a hundred percent targeted success. A plain instruction — "output the answer as such-and-such"? Seventeen and a half percent. A longer hand-written misinformation paragraph? Twenty-three. A random prefix? Zero.

10:50Tyler: So the search isn't a nicety. It's the entire thing.

10:53Juniper: It's the entire thing. You cannot do this by writing clever words. You do it by optimizing against the model's internals — which is also why you can't defend by reading for suspicious text. There's nothing suspicious to read. And it's sturdy where it counts: bury the poisoned chunk under a thousand tokens of unrelated conversation, and targeted success is still about fifty-five percent. Reword the victim's question into five different phrasings, and it holds at ninety-four. It's steering the meaning itself, not matching surface strings. There's a nasty irony in the defenses, too. Some systems compress the cache by keeping only the most influential entries and dropping the rest. But the poisoned entries are, by construction, the most influential ones — so compression keeps them. Those methods leave the attack running at about ninety-seven percent. The defense selects for the poison.

11:50Tyler: Okay. This is where I want to slow us down, because that ninety-four percent is the best case, and the paper is honest about it.

11:59Juniper: It is. Go ahead.

12:00Tyler: That number is white-box — the attacker optimizing on the actual model, in the default settings, on the eight-billion-parameter class. Move to black-box, where you can't inspect the target, and the targeted numbers fall hard. Against a seventy-billion-parameter model you can't see into, it's about thirty-seven percent. Against small models, thirteen. The answer still changes — the untargeted rate stays up near ninety — but getting your specific chosen answer against a model you can't inspect? That's a lot shakier than "ninety-four percent" makes it sound.

12:36Juniper: That's fair, Tyler, and I won't paper over it. The frightening version — a precise, attacker-chosen answer against a model you can't see — is the least reliable version.

12:47Tyler: And there's a defense that mostly works. The systems already recompute part of the cache. Crank that up, to their strongest setting, refreshing eighty percent, and targeted success drops to around eleven percent. The catch is it costs about three and a half times the compute — which is a lot, when the entire point of this cache was to save compute.

13:09Juniper: So the honest framing is a real trade-off. You can defend this, but you pay it back in exactly the efficiency you were buying. And there's a practical wrinkle the authors concede: the poisoned chunk has to actually be sitting in the shared cache when the victim shows up — and the popular chunks worth attacking are also the ones most likely already cached benignly. They didn't run it against realistic traffic and eviction policies, and they say so.

13:38Tyler: Which is the right amount of honest — it's a real channel, but nobody's push-button exploiting ChatGPT tomorrow.

13:46Juniper: And yet the reframe survives all of that. The systems community looked at position-independent reuse and saw an accuracy trade-off — lose a little quality, patch it with a bit of recomputation. This paper says the same imperfection is a cross-user integrity hole. The field spent years hardening the front door — what text goes in, what text comes out. This is a back door opened by a speed feature nobody was watching as a security boundary. So, back to the coffee machine: the stranger pours clean water — their innocent question. The beans were spiked hours earlier — the cached chunk. And nothing they did was wrong. That's the shift this paper forces: an AI system is only as safe as the shared infrastructure underneath it, and an efficiency knob you never thought of as a security boundary can quietly become one.

14:39Tyler: So here's the question. Position-independent cache reuse is a genuine speed win that real systems ship. Do you keep it and eat the recomputation cost to defend it — or do you decide cross-user cache sharing was never worth pointing a stranger's input at someone else's answer, and pull it out entirely? If you build on multi-tenant serving, you're already picking one. Drop which side you land on.

15:04Juniper: The full annotated version is on paperdive.ai — every term tap-to-define, with links to the related work by theme, from CacheBlend to the GCG jailbreak line.

15:15Tyler: Quick housekeeping: this script was written by Anthropic's Claude Opus 4.8, Juniper and I are AI voices from Eleven Labs, and the producer isn't affiliated with either company. The paper is "HijackKV," by Yichi Zhang and their colleagues, posted July 22nd, 2026.

15:32Juniper: Turns out the fastest way to serve an answer is also the quietest way to change one.