How Can a Phone Run AI Without Leaking Your Messages?

September 2, 2026

On-device AI can protect encrypted messages, but only under conditions most products never spell out. The model has to run where the plaintext already exists, and the app has to prove that it leaves no record behind.

Your phone can now run a small, quantised language model locally, but that alone is not the security claim. The security concern is more confined: the messages are decrypted only where they are in readable form, and the model runs within that boundary, with no new endpoint joining the conversation.

The dilemma isn't whether the model file sits on the handset or not. It's whether the decrypted message, the summary it produces, the audio buffer, or its own working state ends up somewhere the encrypted conversation never reached.

For secure messaging, local is a necessary condition. It is not the complete one.

Where this picks up

Our previous pieces set out the argument. E2EE vs AI explained the three architectures now in production, and On-Device AI vs Cloud AI stress-tested them against the trust surface of cloud inference.

This article assumes that framing. If AI is going to touch end-to-end encrypted messages, inference belongs on the endpoint wherever the workload allows it. What that does not answer is the engineering question underneath the slogan: what has to be true before 'on-device' is a confidentiality claim rather than a placement diagram?

The model is not the guarantee

Three things sit on the phone. None of them is the guarantee by itself.

- A base text model. Modern phone-grade language models tend to sit in the one-to-four-billion-parameter range, then shrink through quantisation from many gigabytes to hundreds of megabytes or a few gigabytes. Apple's published on-device foundation model is in this class; Google's Gemini Nano runs through Android's AICore system service on supported devices. The point is not the exact parameter count. The point is that a secure messenger has to fit the user's phone, not a server it controls.

- Task adapters for text features. Reply, rewrite and summarisation can share one text model and specialise it with small adapters or task prompts. That is why one base model can serve several messaging features. Transcription is the exception worth naming early: speech-to-text is a separate speech model or a forced on-device speech API, not the same language model with audio bolted on.

- A runtime. The runtime is the software that maps weights, manages the KV cache, chooses the CPU/GPU/NPU path and decides what happens under memory pressure. For a secure messenger, runtime policy is not plumbing. It is part of the boundary: one heavyweight model at a time, verified model files, no prompt telemetry and no plaintext persistence.

A request, not a record

A summarisation request in a secure messaging app is not 'send text to a model'. It is a short-lived custody chain for plaintext.

Availability comes first.

‍Model availability, device class, free memory, battery and thermal state all matter. On a low-memory handset the honest answer is sometimes no, or not right now.

Plaintext enters RAM, not storage.

‍The database remains encrypted at rest. The app reads only the rows it needs, builds a working prompt in RAM, and avoids temporary files or plaintext caches.

The prompt becomes tokens.

‍The model does not see words; it sees tokens. The entire prompt is processed in prefill to build the KV cache, then decode streams the summary token by token.

The derived state is destroyed.

‍Plaintext buffers should be short-lived and zeroed where the platform permits. The KV cache is treated as sensitive derived state and discarded rather than persisted.

Figure 1. A secure summarisation request stays inside the handset: encrypted messages are read, decrypted into RAM, tokenised, processed through prefill and decode, then cleaned up. The red box marks the places plaintext is not allowed to go: cloud endpoints, temporary files, plaintext caches or persisted KV cache.

‍

Why the first word costs more

The user sees one stream of text. The phone pays for two different workloads.

Prefill is the reading phase.

‍The model processes the whole prompt to build its working state. Long conversations therefore increase time-to-first-token before the first word of the summary appears. Apple's Foundation Models documentation is blunt about the limit: the on-device model has a 4,096-token context window per session, so budget is not an implementation detail.

Decode is the writing phase.

‍The model generates one token, appends it to the sequence, then repeats. For small batch interactive use, this phase is often limited less by arithmetic than by moving weights and cache data through memory.

The counter-intuitive part is this: every generated token has a memory bill. Every token.

This is why quantisation is a speed feature, not just a download-size feature. Moving four-bit weights can cut weight traffic dramatically compared with sixteen-bit weights. The observed gain is not automatically four times, because backends, cache format, dequantisation and memory bandwidth all interfere, but the direction is the same: smaller data moves faster.

Figure 2. Prefill and decode fail differently: prefill processes the whole prompt in a parallel pass and mostly benefits from compute, while decode produces tokens sequentially and is often bounded by memory bandwidth. Quantisation helps decode because the phone moves less model data per token.

‍

The NPU is not the boundary

Phone launches like to quote TOPS. TOPS can correlate with prefill, encoders and other parallel workloads. It is much less predictive for single-user autoregressive decode, where memory bandwidth and usable per-app headroom often decide whether the experience feels instant, slow or impossible.

The conclusion is not that NPUs are useless. It is narrower. They matter for energy, supported operators and vendor runtimes. They do not remove the memory budget, and they do not make a cloud fallback acceptable. Flagship demos do not define the product boundary. Mid-range memory does.

One runtime technique does a lot of work here: memory mapping. If model weights are mapped from the model file rather than copied onto the heap, the operating system can often reclaim those clean pages under pressure. That can reduce heap pressure and turn some memory events into latency spikes. It does not abolish jetsam, low-memory kills or a KV cache that simply grows too large.

The local leaks that remain

This is where a secure messaging app diverges from almost every other local-AI app. The threat is no longer that a vendor reads the messages at an inference endpoint. The threat is that plaintext, or something derived from it, is left behind on the device after the request.

Local inference can still leak through ordinary platform machinery:

- App backgrounding snapshots. When an app moves to the background, iOS captures a UI snapshot for the app switcher. OWASP tests for exactly this class of exposure because sensitive content on screen can become a cached image unless the app hides it.

- Swap and compressed memory. iOS generally kills apps rather than swapping app memory to disk, while Android devices can use compressed memory and swap-like mechanisms. Sensitive buffers should be short-lived and, where platform limits permit, locked from paging.

- Crash logs and diagnostic captures. A crash during inference should not upload prompt text, transcripts, generated summaries or model working state. Telemetry can record latency, token counts, device tier and failure category. It must not record content.

- Persisted caches. The KV cache is not the original text. That is not the same as harmless. It is a derived representation of the conversation, and a secure app should discard it at the end of the request.

Hardware-backed keys help, but they do not solve memory hygiene. Apple's Data Protection model keeps file keys wrapped and uses the Secure Enclave and hardware AES path for protected storage. Android Keystore can keep key material outside the app process, and on supported devices bind keys to secure hardware such as TEE or StrongBox. Those mechanisms protect keys. Once message bytes are decrypted for inference, the app still has to handle plaintext correctly.

Figure 3. Local inference is confidential only if decrypted text, generated summaries and derived model state never survive the request outside protected memory. The leak paths are mundane: swap or compressed pages, background snapshots, crash logs and persisted KV cache. The control is equally mundane: do not write plaintext down.

‍

The API call that breaks speech

Transcription is not text generation with a microphone attached. A speech model captures audio, detects speech, chunks the stream or file, runs an encoder-heavy workload, then emits a transcript. Text generation starts after that.

This distinction matters because the easiest privacy failure in speech is not the model. It is the API call.

Android's own SpeechRecognizer documentation says the default implementation is likely to stream audio to remote servers. Android 12 added createOnDeviceSpeechRecognizer(), which creates an on-device recognizer and fails if one is unavailable. On iOS, the legacy SFSpeechRecognizer path has to be checked for supportsOnDeviceRecognition, and requests must set requiresOnDeviceRecognition to keep audio off the network when supported. Apple's newer SpeechAnalyzer/SpeechTranscriber path is presented by Apple as on-device, but availability still depends on platform support and downloaded models.

Use the wrong speech API, and the privacy model changes before the local LLM even starts.

Figure 4. Text generation and speech transcription are different local workloads. For voice, the secure path is explicit: use an on-device recognizer or a bundled speech model, and reject cloud fallback when local recognition is unavailable.

‍

The honest costs

The constraints are not exotic. They are just inconvenient enough that product claims should be specific.

- Context windows are small. A long conversation can overflow a phone-grade context window. The product then has to truncate, summarise in chunks, or summarise segments and then summarise the summaries. Each option changes quality.

- Model delivery is a product flow. A model that is hundreds of megabytes or several gigabytes does not belong silently inside the base app install. Delivery can use OS asset systems or an app-owned verified model cache; either way, downloads need consent, resume, integrity checks and private storage.

- Two models at once is a real limit. Transcribing a voice note and then summarising the thread can require a speech model and a text model. On constrained devices those jobs should be serialized. The user waits, but the app survives.

- Languages do not cost the same. Arabic and other non-English text can consume materially more tokens on a given tokenizer. In RealTyme's LFM2 tokenizer measurements, Arabic was about 1.8 times the baseline token density, while poorly covered scripts were much worse. That means less conversation fits in the same context window.

- Quantisation quality is uneven. Research on multilingual quantisation finds that non-Latin and lower-resource languages can degrade more than English, and that automatic metrics can understate the damage. If a secure messenger serves Arabic, human evaluation is not optional garnish. It is the test.

The test that matters

The useful question for any vendor is not 'is the model on-device?' That is only the first line of the answer.

The useful question is: after a summarisation, what plaintext artefacts should exist outside the encrypted message database under the stated threat model?

1. Not in a cloud fallback. Hard requests, long conversations and low-memory devices do not quietly route to a server.

2. Not in plaintext telemetry. Analytics and crash reporting never carry message text, audio, transcripts, embeddings or generated private content.

3. Not in snapshots. The UI hides sensitive summaries before the platform captures an app-switcher image.

4. Not in caches. The KV cache, prompt buffers and generated outputs are not persisted unless the user explicitly saves them into encrypted app storage.

5. Not through speech. Voice recognition is explicitly on-device, or the feature fails closed.

If the answer is a promise, it is weak. If the answer is a test plan, it is stronger. Inspect storage before and after, exercise the feature, pull snapshots and logs, and verify that the only durable copy of the conversation is the encrypted one the app already had.

Where we stand

RealTyme's position is not that local AI is automatically private. It is that AI should run where your messages already live, and that the app must be built so the plaintext has nowhere else to go.

That means accepting the limits rather than hiding them. The model is small and quantised because phones have a memory budget. The first word is slow because the whole conversation has to be processed before the answer begins. Speech is separate from text. Long conversations have to be budgeted by tokens, not by character counts or hopeful averages.

And the whole thing is confidential only if decrypted text, generated summaries, audio buffers and model state stay out of cloud fallbacks, out of telemetry, out of crash logs, out of background snapshots and out of disk-backed caches.

None of that is magic. It is a memory budget and a refusal to write anything down.

Our technical brief covers model selection, adapter architecture, verified model delivery and measured memory footprint on mid-range hardware. Available on request.

‍