A preview of the Boot Security Mastery Conference (BSM) 2026 session, 25 September
I am giving a talk at BSM on 25 September about a part of the inference stack that almost no threat model lists as an asset, and which turns out to hold the entire conversation.
This post is the short version of the argument, so you can decide whether the session is worth your time, and so that if you attend, we can spend the room’s time on the hard parts rather than the setup.
The Claim
The KV cache is not a performance structure. It is a lossy but invertible encoding of the prompt.
Lossy, because it is a projection into a learned space. Invertible, because that projection has to retain what the tokens were and where they sat: that is precisely what attention consumes from it. Information sufficient to reconstruct the prompt is not incidental to the cache; it is the cache’s entire function.
Which produces the sentence the talk is built around:
Whoever holds the KV cache holds the conversation. Not a summary of it. The dialogue, recoverable.
If that is true, and there is published work demonstrating both halves of it, then every place the cache is at rest in plaintext is a place your customers’ conversations are at rest in plaintext. DRAM. Bounce buffers. Spilled NVMe. The wire. Most data-handling documents have not been updated to say so, because the cache was filed as an implementation detail.
What the Session Covers
Two public attacks, read and write. Recovering exact tokens from a cache dump, and the nastier inverse: modifying cached blocks to poison a model’s memory of a conversation that already happened, so every later turn attends to content the user never typed and which appears in no request log. Prompt-injection defenses inspect the incoming prompt. This does not arrive in the prompt.
Why confidential computing does not currently close it. Measured boot attests the platform as it came up (firmware, bootloader, kernel) and generates its evidence once, before any inference has happened. The cache is created per session, minutes or hours later, in tiers that were never measured.
What a control would look like instead of a clause. Zero Data Retention today is a contractual promise audited annually by sample. The proposal in the talk is to make it a per-turn technical control: encryption policy, block integrity, and platform state verified before the request proceeds, with enforcement on the client, so a provider that cannot attest never receives the prompt. Not “receives it and is trusted to discard it.”
Where the boundary is drawn. Ciphertext everywhere except inside the GPU, including DRAM bounce buffers and before the DMA on the wire, so the guarantee does not depend on the fabric or the NIC firmware being honest. Keys sealed to a measured platform state. Fail closed, with no degraded mode, because a control with a bypass gets bypassed under load and then permanently.
Why it needs an open interface to be possible at all. Every engine currently hand-rolls its own copy loops to every storage tier. There is no boundary, which means there is nowhere to attach encryption, integrity, or attestation. You cannot secure an abstraction that does not exist.
What I Will Say Plainly in the Room
This is a proposal and a reference-implementation roadmap, not a shipping feature. I would rather present it at the stage where it can still be argued with than announce it when the design is fixed and the mistakes are expensive.
The open questions I most want argued, and which I will put up as open:
- Latency budget. The target is under 10 ms added to time-to-first-token. On a long-context turn, that is invisible; on a short one, it is a visible fraction, and caching attestations across turns weakens the guarantee it exists to provide.
- Granularity. Per block is strongest and most expensive. Per session leaves a window. Per turn is the current compromise and not obviously the right one.
- Key delivery to the accelerator boundary. The hardest unsolved piece, and the one most likely to constrain what ships first.
- Revocation. Too strict and every legitimate firmware update breaks every client; too loose and the measurement stops meaning anything.
If you work on confidential computing, attestation, firmware, or inference infrastructure, those four are where the design most needs adversarial review, and the session is structured to leave time for it.
Who Should Come
- Security and compliance leads who sign or rely on ZDR clauses, and who would like recourse that arrives before disclosure rather than after.
- Firmware and platform engineers: the measured-boot-to-runtime gap is the crux, and it is your territory more than mine.
- Inference providers who would have to satisfy an attestation request, and who should have a say in what is reasonable to demand.
- Public-sector buyers for whom “the data cannot leave” is a requirement rather than a preference.
And one question worth putting to your current inference provider before you arrive, because the answer tends to be revealing:
What evidence can you give me, per request, that my KV cache was encrypted at rest and did not outlive the turn?
Most providers can answer where the cache lives and whether it is encrypted, from a policy document. Almost nobody can currently answer that third question, which is the gap the talk is about.
See you on the 25th. The slides will be posted afterward, and the specification is open for comment before and after.