Researchers showed local LLM systems leak prompts without requiring a cloud connection

No. Researchers showed that local LLM systems still leak prompts via runtime memory, plaintext storage, a cross-tenant authorisation fault and shared prefix caching. The defensible choice is not local versus cloud, but a demonstrable data boundary: decide which data your own server must never leave and check memory, storage, interfaces and attestation of every processing component.

A recent academic study, "The Illusion of Local Privacy", undermines an assumption that many organisations hold: that a locally running language model keeps sensitive prompts within its own walls by itself. In the consumer LLM serving systems examined by the researchers, four concrete confidentiality failures allowed prompts or prompt-derived data to remain exposed without requiring a cloud connection. That affects every director, lawyer, doctor or CISO who was sold local running as a privacy guarantee.

For the record: this does not mean that cloud AI is safer. It means that the hosting form alone says nothing about the protection of your data. The protection boundary lies not at "local" or "cloud", but at the full processing chain that you demonstrably control.

Which leaks did researchers find exactly in local LLM systems?

The researchers behind "The Illusion of Local Privacy" describe four separate leaks on the same local machine.

• Runtime memory: prompt remnants remained in memory after inference had completed.
• Persistent storage: wrappers, the software around the model, wrote prompts to disk in plain, readable text.
• Tenant isolation: an authorisation fault let one user restore another user's stored conversation state, in all two hundred controlled trials.
• Prefix caching: shared prompt-prefix caching produced a distinguishable timing signal that could reveal information about a shared prompt prefix under the examined conditions.

The common denominator: the model itself ran locally, but the components around it formed the actual leaks. Our analysis is therefore that an assessment should reach further than the question "where does the model run".

Does cloud AI with confidential computing then offer more protection?

Cloud inference can expose prompts and intermediate results to the service provider, but two academic publications show that technology can limit that exposure during processing. That is a mitigation, not automatic compliance or sovereignty.

In the study "Your Inference Request Will Become a Black Box" the authors split inference between a client-verified confidential virtual machine, a shielded compute environment, and the public cloud. In their specific evaluation 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 study, published via the Sociedade Brasileira de Computação, compared regular and confidential virtual machines for document-embedding inference on Google Cloud with AMD SEV-SNP and Intel TDX and reported no systematic performance degradation in the benchmark examined.

Important: both results concern specific research architectures and benchmarks. They are not a universal guarantee. Confidential computing is designed to protect data during processing through hardware isolation and memory encryption; attestation provides a cryptographically verifiable statement about the measured environment, subject to the attestation design, verifier and trust assumptions. But metadata, key management, configuration, subprocessors and availability remain separate risks that you must control yourself.

What does this mean for directors, lawyers and CISOs who must justify AI use?

Our analysis is that, because the reported failures involved memory, storage and the serving layer rather than a demonstrated failure of the model's learned behaviour, the accountability assessment should cover the whole chain. CISOs could extend their AI risk assessment with runtime memory, persistent storage, authentication, tenant isolation and prefix caching. In the examined configuration, the reproducible cross-tenant result demonstrates a risk where shared infrastructure lacks demonstrably effective isolation, so lawyers could require that suppliers demonstrate that conversation state is shielded per user, with concrete inspection evidence rather than a general statement. Confidential computing only offers protection within a correctly configured trust boundary; "we run on a confidential VM" is insufficient without verified attestation, so directors could require that the attestation status is recorded per processing before sensitive data crosses the boundary. A survey published by Fortanix among three hundred US AI leaders found that 61 per cent send sensitive data to public cloud AI, while 93 per cent are concerned about exposure to infrastructure providers. Our analysis is that this points to a visible gap between practice and concern that compliance officers could translate into a recorded data boundary.

In our assessment the most important consequence is that auditors should consider runtime memory, prefix caching, tenant isolation and attestation as fixed assessment points for both local and cloud systems. Omitting these points checks the wrong boundary and can miss the locations where prompts or prompt-derived data leaked in the study.

How do I decide which data my own server must never leave?

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.

1. Distinguish between model files, prompts, attachments, retrieval context, embeddings, outputs, logs, telemetry, error messages, backups and support data; each can leak separately.
2. Record that "local" only has meaning if memory, storage, wrappers, interfaces, updates, administrator accounts and outbound telemetry also fall within your boundary.
3. Prohibit raw sensitive prompts in uncontrolled cloud endpoints; let only minimised, segmented or controllably masked data cross the boundary.
4. Allow external processing only when purpose, necessity, contract, location, retention period, deletion and attestation are recorded.
5. With cloud inference, check not only the model, but also key management, subprocessors and metadata; our previous analysis explains how you demonstrate which subprocessors and model routes your AI system actually uses.

This approach ties in with what has already emerged elsewhere. Our reading: an AI ban does not stop uploads of sensitive data, so that only a technically enforced data boundary protects what policy on paper does not hold. Controlled masking additionally requires knowledge of the rules and methods for pseudonymisation under the GDPR. More background can be found in our topic hub on AI privacy and the GDPR. The through-line remains: the hosting location does not determine what is protected; the demonstrable data boundary does.

Sources: The article relies on the arXiv study "The Illusion of Local Privacy", the ACL publication on confidential inference, an SBSeg evaluation of confidential computing and a survey published by Fortanix.