Researchers showed local LLM systems leak prompts

You must now decide which data your own server must never leave, then verify that every component in the processing chain—memory, storage, interfaces and attestation—enforces that boundary. The hosting location alone does not determine what is protected.

An analysis of 6 November 2026 of local LLM systems leaking prompts via memory, storage and tenant isolation argues that the assumption that locally running language models keep sensitive prompts within their own walls is unfounded. The researchers examined consumer LLM serving systems and identified four concrete confidentiality failures that allowed prompts or prompt-derived data to remain exposed without requiring a cloud connection. In our assessment, this development matters because it forces a reframing: the question is not whether to run systems locally or in the cloud, but whether you can demonstrate a data boundary that holds across the entire processing chain you control.

What actually failed in the systems the researchers examined?

The researchers identified four separate leaks occurring on the same local machine. The common pattern was that the model itself ran locally, but the components surrounding it formed the actual exposure points. Runtime memory, plaintext storage, cross-tenant authorisation faults and shared prefix caching all allowed prompts or prompt-derived data to persist in accessible form. This matters because it means that choosing local deployment does not automatically isolate sensitive input from exposure—the hosting form alone says nothing about the protection of your data.

Which failure modes must your assessment now cover?

• Runtime memory exposure — prompts or intermediate results remaining accessible in unencrypted memory after processing.
• Plaintext storage — conversation state or derived data persisted to disk without encryption or access controls.
• Cross-tenant authorisation faults — shared infrastructure allowing one user's data to be accessed by another without explicit breach.
• Shared prefix caching — model optimisation techniques that cache partial inputs, creating unintended data retention across requests.
• Attestation gaps — absence of cryptographically verifiable statements about the measured environment in which processing occurs.

Can confidential computing mitigate these risks?

Two separate research efforts examined whether confidential computing—hardware isolation and memory encryption—can reduce exposure during processing. One study split inference between a client-verified confidential virtual machine, a shielded compute environment and public cloud infrastructure. The accuracy with which text could be reconstructed fell from more than 97.5 per cent to an average of 1.34 per cent, with identical model output. A second evaluation compared regular and confidential virtual machines for document-embedding inference using AMD SEV-SNP and Intel TDX, reporting no systematic performance degradation in the benchmark examined.

These results are specific to the research architectures and benchmarks tested. Confidential computing is designed to protect data during processing through hardware isolation and memory encryption, and attestation provides a cryptographically verifiable statement about the measured environment. However, metadata, key management, configuration, subprocessors and availability remain separate risks that you must control yourself. "We run on a confidential VM" is insufficient without verified attestation recorded per processing before sensitive data crosses the boundary.

What concrete controls must you be able to demonstrate?

1. Identify and document your data boundary — specify which data types may under no circumstances cross your controlled perimeter, and record this decision with the business rationale.
2. Verify runtime memory protection — confirm that the processing environment encrypts memory and that unencrypted prompts do not persist after inference completes.
3. Enforce storage encryption and access controls — ensure conversation state and derived data are encrypted at rest and that access is restricted to the authenticated user who initiated the request.
4. Validate tenant isolation — require suppliers to demonstrate that shared infrastructure lacks cross-tenant access paths, with inspection evidence rather than general statements.
5. Record attestation status per processing — document the cryptographically verifiable state of the environment before sensitive data is processed, and retain this record for audit.

What does this mean for your current risk assessment?

A survey among three hundred US AI leaders found that 61 per cent send sensitive data to public cloud AI, whilst 93 per cent are concerned about exposure to infrastructure providers. This gap between practice and concern points to a compliance opportunity. Your assessment should now treat runtime memory, prefix caching, tenant isolation and attestation as fixed assessment points for both local and cloud systems. Omitting these checks means you are auditing the wrong boundary and can miss the locations where prompts or prompt-derived data actually leaked in the research.

The through-line is this: do not start with the choice of local or cloud, but with the question of which data may under no circumstances cross the controlled boundary. Then work out per data type where and how it may be processed. The hosting location does not determine what is protected; the demonstrably enforced data boundary does.

Tooling can help you map and monitor these boundaries, but the decision about which data must never leave remains yours. No platform or service can make that choice for you, and no attestation report replaces your own verification that the boundary holds.