Can Deleted Local AI Chats Be Recovered? What ORISA Found in Android Memory
Georgia Tech's ORISA recovered deleted local-AI context from Android process memory. Here is what the study proves, what it does not, and how users should respond.
Can Deleted Local AI Chats Be Recovered? What ORISA Found in Android Memory
Short answer: Sometimes—under a specific forensic scenario. Georgia Tech researchers showed that deleting a conversation from the interface of a still-running local AI app did not immediately erase every representation of that conversation from the app's process memory. Their ORISA system recovered token data and attention-state information from acquired Android memory images, then rebuilt a working AI session that could recall some information the original limited-context session had already forgotten.
That is a meaningful privacy finding, but it is not a universal undelete button. The study did not show that a random person can remotely recover any deleted AI chat. Its threat model assumes physical seizure of an Android device while the local-LLM process is still running, followed by specialist acquisition of process memory and app storage. The lab evaluation used a rooted Google Pixel 6 and forensic instrumentation.
The practical lesson is narrower and more useful: “runs locally” and “deleted from the chat list” do not automatically mean “all traces are gone.” Local AI changes where your data is exposed. It does not abolish volatile-memory, device-compromise, backup, malware, or physical-access risk.
Research cutoff: October 14, 2026. This article analyzes the published paper, project materials, and public announcement available by that date. It is not legal or forensic advice.
The Finding in One Minute
The Georgia Tech research announcement and the peer-reviewed IEEE Symposium on Security and Privacy paper describe a framework called ORISA—short for On-device Recovery of Interactions and Session Attention.
Here is what the team reported:
- ORISA takes an acquired local-LLM process-memory image and app storage as inputs.
- It searches for batch tokens, which can reconstruct text, and key-value cache tensors, which encode the model's attention state for prior context.
- The researchers tested 60 configurations: 10 Android local-LLM apps, three model architectures, and two small context-window settings.
- In those configurations, ORISA recovered 100% of the tested tokens and KV-cache tensors inside the active context window after the conversation was deleted from the app UI.
- It also recovered, on average, 32.60% more tokens and 38.59% more KV-cache tensors from context the model had logically evicted but that had not yet been physically overwritten.
- Rehosted sessions exposed an average of 169.6% as many planted facts as the original limited-context sessions could return at the comparison point.
- In one ChatterUI demonstration, a reconstructed “Project Note Keeper” session returned 26 of 100 planted facts. The original session, constrained by its active context window, returned 14.
Those percentages need careful interpretation. The reconstructed session did not recover every fact. “169.6%” means it returned about 1.696 times the planted facts still retrievable from the original limited-context session—not 169.6% of all information ever supplied.
What Is Confirmed
UI deletion did not immediately clear the tested process memory
The strongest result is straightforward. The researchers deleted conversations through the tested apps' interfaces, acquired the still-running processes' memory, and found conversation-related structures remaining there.
The paper explains why. Local LLMs use token buffers to represent the text being processed and KV caches to preserve attention state across tokens. Deleting a chat record from an app's user interface can remove the app-visible session and its disk record while leaving previously allocated process memory intact until it is reused or overwritten.
This is a familiar computing distinction applied to a new class of apps: a logical deletion operation can remove references to data without immediately zeroing every byte that once held it.
The study covered multiple apps and models
This was not a one-app screenshot demonstration. The authors evaluated 10 Android apps that could run user-selected GGUF models through llama.cpp. They paired those apps with lightweight Llama 3.2, Qwen 2.5, and Gemma 2 variants and used 256- and 512-token test context windows, producing 60 configurations.
The context windows were intentionally small so the researchers could measure both active and logically evicted context in a controlled experiment. Each session was fed enough synthetic project-note material to exceed 1,024 processed tokens before deletion and acquisition.
That design supports the paper's core forensic claim. It does not establish a population-wide failure rate for every Android AI app, every model size, every runtime, or normal consumer context setting.
ORISA recovered more than readable chat text
Recovering token IDs can reveal prior prompts and responses. ORISA goes further by recovering and realigning the KV cache, rebuilding a session file, loading the original model, and continuing inference with the reconstructed state.
That matters because KV-cache contents are not a conventional transcript. They are numerical attention-state tensors. ORISA's contribution is the combination of token recovery, cache reconstruction, context extension, and session rehosting.
The result is also why the privacy question is larger than “is there a text file left behind?” The paper describes information remaining in runtime state even after the app-visible conversation and disk artifacts were cleared.
The rehosted session could expose logically forgotten context
In the ChatterUI case study, the team created a fictional note-taking character, supplied 100 made-up project facts, exceeded the model's active context, deleted the conversation, and acquired memory. ORISA recovered 429 tokens and millions of tensor values, including material outside the 256-token active context.
After rehosting the session with a larger context window, the model correctly returned 26 planted values. The original constrained session could return 14. The recovered result was therefore larger than what the original active window exposed at that point, but it was still far from all 100 facts.
The paper also tested semantic consistency by asking 450 questions of original and rehosted sessions. The authors report matching false-positive and false-negative patterns between the paired sessions. That suggests the rehosting preserved model behavior in their test. It does not turn a generated answer into an infallible transcript: both original and reconstructed models can hallucinate or fail to recall information.
The acquisition requirement is substantial
The paper's threat model assumes that the device is seized while the LLM app process is still running. ORISA itself starts from a memory image and a disk image acquired by investigators.
For the lab evaluation, the team used a rooted Pixel 6 running Android 15. It acquired process-memory images with Frida and Objection and granted superuser access with Magisk. The authors say ORISA does not inherently require a device that was already rooted because law enforcement may use third-party acquisition tools or exploits to obtain memory images.
That distinction is essential. The finding demonstrates forensic recoverability after specialist acquisition. It does not demonstrate a remote attack that any website, nearby stranger, or ordinary app can perform against a properly secured phone.
What Is Still Unclear
How long useful artifacts remain recoverable in everyday use
Georgia Tech says recovery becomes harder as memory is overwritten by other activity. The paper does not provide a universal countdown such as “deleted chats remain recoverable for 30 minutes.”
The interval will depend on the app, runtime, device memory pressure, model, context configuration, subsequent app activity, OS behavior, and whether the process exits. A successful controlled acquisition immediately after deletion should not be generalized into permanent recoverability.
What happens after a force-stop, reboot, shutdown, or memory pressure
The study's main threat model keeps the relevant process running. It does not establish the same recovery outcome after the process is terminated, the phone is rebooted, memory is reclaimed, or the device has remained powered off.
It would be reasonable to expect those events to change volatile-memory availability, but the paper does not support a simple guarantee that one action securely eliminates every copy. Disk artifacts, swap-like mechanisms, crash dumps, backups, app databases, screenshots, notification history, or other systems can create separate retention paths outside ORISA's tested focus.
Whether newer app and runtime versions clear memory differently
The research evaluates specific app, model, runtime, device, and configuration combinations. It does not publish a current remediation matrix for every named app. The public ORISA source repository also does not by itself establish that each app vendor has reproduced, accepted, or patched the behavior.
Developers could reduce exposure by explicitly zeroing sensitive buffers before releasing them, avoiding unnecessary copies, minimizing retained state, and testing deletion across UI, disk, and process-memory layers. Whether a particular app does that today requires app-specific evidence.
How well the approach transfers beyond llama.cpp
All 10 main evaluation apps used llama.cpp. The researchers separately adapted ORISA to the mllm inference engine and recovered a test session there, which shows the design is not inseparable from one runtime.
But adapting the technique required new structure signatures. MediaPipe, vendor-specific accelerators, encrypted or obfuscated memory, different model architectures, and future runtime changes could require additional engineering or defeat current recovery methods.
How courts should treat answers generated after rehosting
The paper is written for digital investigators and argues that matching behavior can make a reconstructed session useful evidence. Legal admissibility, reliability, chain of custody, reproducibility, disclosure obligations, and the difference between recovered tokens and newly generated answers are separate questions.
A recovered token sequence is not the same thing as a model's later answer to a new interrogation prompt. The latter remains a probabilistic output. Any real investigation would need to preserve the original memory image, document the reconstruction process, distinguish recovered artifacts from generated inferences, and apply the jurisdiction's evidence rules.
Does This Mean Local AI Is Not Private?
No. It means “local” is one architectural property, not a complete privacy verdict.
Running a model on-device can remove routine cloud transmission and provider-side storage from the normal inference path. That can be a major advantage. It can also leave the phone as the concentrated source of prompts, responses, models, cache state, and app data.
The relevant comparison is not:
- local equals private; and
- cloud equals exposed.
It is a threat-model comparison:
- Local AI can reduce provider exposure while increasing the importance of device security, app implementation, physical access, malware resistance, memory handling, backups, and secure deletion.
- Hosted AI requires network and provider processing and may create server-side logs or account history, depending on the service, while reducing the amount of local inference state on the user's device.
- Browser-local history with hosted inference separates where normal history is stored from where active requests are processed. It still has browser, endpoint, provider-processing, and physical-access risks.
No label eliminates every path.
What This Does Not Prove
The ORISA research does not prove that:
- all deleted AI conversations can be recovered;
- all Android AI apps retain the same artifacts;
- ordinary attackers can remotely read local-LLM memory;
- powered-off or overwritten memory remains available;
- deleting a chat is pointless;
- local models are less private than hosted models in every threat model;
- browser-local history has the exact same llama.cpp KV-cache exposure;
- every answer from a reconstructed model is historically true; or
- the affected apps suffered a public breach or active exploitation.
The study demonstrates a technically important residual-data path under controlled acquisition conditions. Turning it into a claim about universal, easy, or remote recovery would overstate the evidence.
What Users Should Do
Decide whether your threat includes device seizure or compromise
For many people, the highest-probability risks are accidental sharing, malicious links, weak account security, oversharing with a provider, or malware—not advanced live-memory acquisition.
For journalists, activists, attorneys, executives, researchers, or people operating in high-risk environments, physical seizure and forensic acquisition may be realistic. Those users should evaluate the full device and workflow, not just whether the model runs locally.
Do not treat the delete button as verified secure erasure
Use deletion to reduce ordinary exposure, but do not infer more than the product documents and tests. Ask what the action removes:
- the visible chat entry;
- an app database row;
- cached files;
- model context;
- process memory;
- backups or synced copies; and
- diagnostic or security logs.
If a vendor cannot answer, “deleted” should be interpreted as a user-interface state rather than a proven media-sanitization claim.
Minimize secrets before they enter any AI workflow
The safest sensitive prompt is the one you did not create. Remove names, account numbers, credentials, health details, confidential deal terms, privileged material, and source identities when they are not needed for the task.
Use placeholders and synthetic examples. Split a task so the model receives only the minimum relevant fragment. Redaction is imperfect, but data minimization reduces the impact of cloud logs, browser storage, app databases, screenshots, and volatile-memory recovery alike.
Keep the phone and app environment hardened
Use a strong device passcode, current OS and app versions, device encryption, trusted software sources, and the shortest practical auto-lock interval. Avoid rooting a daily-use phone unless you understand the security tradeoffs. Review backup and sync settings separately; local inference does not mean every supporting artifact remains local.
These controls raise the cost of acquisition or compromise. They do not prove that deleted process memory has been cryptographically erased.
For developers, test deletion at every layer
An app should not stop its deletion test after confirming that a conversation disappears from the screen. Test the database, files, caches, logs, analytics payloads, crash reports, clipboard, notifications, backups, token buffers, KV caches, and other retained copies.
Where practical, explicitly zero sensitive buffers before release and minimize the lifetime and duplication of plaintext prompts. Document the limits honestly. “No cloud upload” is useful information; it is not a substitute for a deletion and memory-handling specification.
Where OpenVeil Fits—and Where It Does Not
OpenVeil is a hosted conversational AI workspace for adults. Its normal chat history is stored in the browser rather than as a normal server-side chat-history account record. OpenVeil's documented policy says user inputs and outputs are not used to train foundation models.
That architecture avoids operating a local mobile LLM process like the llama.cpp apps in ORISA's main evaluation. It can be a useful fit when you want a conversational workspace without maintaining local models and when browser-local normal history matches your needs.
The distinction should not be exaggerated. OpenVeil is not fully offline or anonymous. Active requests are still processed by OpenVeil and selected model providers. Browser-local history can still be exposed by someone with access to the browser profile, device backups, malicious extensions, malware, operating-system compromise, or physical acquisition. OpenVeil is not a secure-deletion utility, disk-encryption product, memory-sanitization tool, endpoint-security product, forensic shield, or guarantee against every privacy risk.
The honest comparison is this: ORISA documents a residual-memory risk in tested on-device local-LLM runtimes. OpenVeil uses a different architecture, with different privacy advantages and different exposure points.
FAQ
Can a normal person recover my deleted local AI chats?
The paper does not show that. ORISA starts from acquired process-memory and disk images. The lab evaluation used a rooted phone and specialist instrumentation, while the real-world threat model discusses law-enforcement acquisition tools or exploits.
Did ORISA recover every deleted message?
It recovered all tested tokens and KV-cache tensors within the active context window across the 60 configurations, plus a portion of logically evicted context. It did not recover every planted fact in the ChatterUI example. The reconstructed session returned 26 of 100 planted facts.
Why did the recovered session remember more than the original session?
The original model was operating with a small active context window, so older material had been logically evicted. Some of that material still physically remained in allocated memory. ORISA recovered and realigned it, then rehosted the session with a larger context window.
Does closing or rebooting the phone solve the problem?
The paper does not provide a universal answer. Its main scenario requires the LLM process to still be running. Process termination, rebooting, memory pressure, and later activity can change what remains in volatile memory, but other copies may exist elsewhere. Do not treat one action as verified secure erasure without product-specific testing.
Is this an Android vulnerability or CVE?
The publication presents a forensic framework and residual-data finding across tested local-LLM apps and runtimes. It does not describe a single Android platform CVE or announce active exploitation.
Does local AI still have privacy benefits?
Yes. Local inference can keep prompts and responses out of the routine cloud-processing path. The study shows that the device then becomes a critical privacy boundary and that local runtime memory deserves the same attention as disk storage and UI deletion.
Is browser-local chat history immune from forensics?
No. Browser-local storage is a different mechanism from the Android local-LLM process state studied by ORISA, but device and browser data can still be exposed through physical access, backups, extensions, malware, OS compromise, or forensic acquisition.
Does OpenVeil eliminate provider processing?
No. OpenVeil is hosted. Active requests require processing by OpenVeil and selected model providers. Its browser-local normal chat-history design narrows one category of stored account history; it does not eliminate every processing or device risk.
The Bottom Line
Georgia Tech's ORISA research supports a precise conclusion: in the tested Android local-LLM configurations, deleting a conversation from the app UI did not immediately erase all of its token and attention-state artifacts from the still-running process. With specialist memory acquisition, the researchers recovered and rehosted enough state to reveal both active and logically forgotten context.
That is not proof that deleted chats are universally or easily recoverable. It is proof that local, private, deleted, and securely erased are different claims.
Choose AI tools by threat model. Minimize sensitive inputs, harden the device, verify what deletion actually covers, and avoid granting or storing more than the task requires. If you prefer a hosted conversational workspace with browser-local normal chat history, OpenVeil offers that narrower design—but it does not replace endpoint security, secure deletion, or forensic safeguards.