---
title: "Local AI Privacy Threat Model and Checklist"
description: "Audit local AI privacy beyond offline inference, including downloads, telemetry, logs, voice data, caches, tools, updates and deletion."
canonical: "https://www.murmurtts.com/blog/local-ai-privacy-threat-model"
---
Guide

# Local AI Privacy Is More Than Offline Inference: A Threat Model

A practical threat model for local AI apps covering model downloads, telemetry, logs, voice embeddings, caches, tools, updates, licenses, and deletion.

![](https://www.murmurtts.com/murmur-icon.webp)Murmur·August 13, 2026·5 min read

**Direct answer:** local inference means the core model can process an input on the device. It does not prove the app is network-silent, encrypted at rest, free of telemetry, or safe from local tools with excessive permissions. A useful threat model follows each asset: source text, microphone recording, transcript, voice embedding, prompt, model output, cache, export, and diagnostic log. For each one, record where it is created, stored, transmitted, backed up, and deleted. Then test the claims with the network disabled and inspect documented license, update, analytics, and crash-report paths.

**What changed in 2026**

On-device frameworks and compact local models make privacy-preserving features easier to build in 2026. They also create more local assets and provider choices. Apple's unified LanguageModel API can represent both local and remote providers, so a product must state which path a request actually used.

## Quick decision table

| Asset | Common hidden path | Control |
| --- | --- | --- |
| Model weights | Downloaded from a third-party host | Checksum, source, and update policy |
| Voice reference | Cached or backed up after cloning | Consent, encryption, retention, deletion |
| Prompt or transcript | Crash log or analytics property | Redaction and payload allowlist |
| Generated audio | Cloud backup or shared temp folder | User-visible location and cleanup |
| Tool access | Reads broader local files than needed | Scoped permissions and confirmation |
| License check | Network identifier and entitlement state | Document minimal data and failure behavior |

## Map data before making a privacy claim

Draw the flow from input to deletion. Include temporary files, operating-system caches, app backups, thumbnails, waveform data, saved project metadata, and exported voices. A reference recording may be converted into an embedding, but deleting the original is not enough if the reusable representation remains. A local transcript can still appear in a crash report if an exception includes the request body.

Use precise language. Say core generation runs on the Mac, models download once from named hosts, license validation sends a key hash, and optional crash reporting excludes content. Avoid absolute phrases such as nothing ever leaves the device if update, checkout, support, or diagnostics make network requests.

## Voice data deserves its own lifecycle

A voice is both personal data and a capability that can be misused. Store the speaker's permission, allowed purposes, expiration, and withdrawal method beside the profile. Keep the raw reference and derived state in an app-owned folder with restrictive permissions. Avoid exporting reusable embeddings by default. When a user deletes a profile, explain which files are removed and whether backups remain outside the app's control.

The [private voice-cloning guide](https://www.murmurtts.com/blog/private-voice-cloning-guide) covers recording and consent. A commercial-use license for model weights does not grant the right to imitate a person. Privacy and authorization remain separate checks.

## Test the offline boundary

Install required assets, disconnect the network, relaunch the app, and complete the real workflow. Test generation, voice loading, project recovery, export, and license grace behavior. Record which features stop. Then reconnect through a monitored environment and inspect destinations during idle, launch, generation, and crash reporting. Compare observed traffic with the privacy policy.

Do not publish raw packet captures containing keys or identifiers. The goal is to verify categories and domains. Automate a regression check so a new analytics event cannot accidentally attach script text. Murmur's product boundary is local voice production after setup; its public pages should continue to distinguish core generation from model downloads and license checks.

## Local tools can be the largest risk

An agent with broad file access can disclose more than a remote model with a narrow prompt. Scope tools to a project directory, validate paths, reject traversal, limit output size, and require confirmation for sending, publishing, or deletion. Store tool results in the transcript only when needed. A local model does not make an unsafe tool safe.

Murmur's [automation interface](https://www.murmurtts.com/automation) is intentionally bounded around voice discovery, generation, jobs, and workspace-scoped artifacts. The same design applies to any local AI app: expose the smallest useful capability, log the action without content, and make destructive side effects explicit.

## Evidence to collect before publication

Run the installed Murmur workflow offline after all selected models are present, then repeat through a monitored connection during launch, model download, license validation, generation, update check, and a controlled crash. Record destinations and data categories, not secret values. Compare the result with the public privacy policy and correct any mismatch before publishing. Add a downloadable asset inventory that readers can apply to [their own voice-cloning workflow](https://www.murmurtts.com/blog/private-voice-cloning-guide).

- Offline relaunch, generation, project recovery, and export
- Documented network destinations by feature
- No script, prompt, or voice data in diagnostics
- Voice-profile deletion test
- Scoped-tool path and confirmation tests

## Reader worksheet

Create a one-page worksheet before acting on this local AI privacy checklist guide. Write the job, current baseline, minimum supported Mac, privacy requirement, model and runtime revision, acceptable failure rate, and the one result that would change your decision. Add measured values only after the test, and keep upstream claims in a separate column. Save links to raw output and licenses beside the row they support. Review the worksheet after seven days of real use, not only after a successful demo. Browse the [Murmur research library](https://www.murmurtts.com/blog) for the related memory, privacy, model, and production checks that belong in the same decision.

## Practical checklist

1. Inventory every input, derivative, cache, log, export, and backup path.
2. Document each network destination and the fields it receives.
3. Test the full installed workflow with the network disconnected.
4. Keep voice consent and deletion state beside reusable profiles.
5. Redact content from analytics, crash reports, and support bundles.
6. Scope local tools and confirm external or destructive actions.

## Frequently asked questions

## Sources

- [Apple Foundation Models framework](https://developer.apple.com/documentation/FoundationModels)Accessed 2026-08-08
- [Apple Platform Security](https://support.apple.com/guide/security/welcome/web)Accessed 2026-08-08
- [Qwen3-TTS official repository](https://github.com/QwenLM/Qwen3-TTS)Accessed 2026-08-08
- [Kyutai Pocket TTS prohibited use](https://github.com/kyutai-labs/pocket-tts#prohibited-use)Accessed 2026-08-08

## Turn the research into finished local audio

Murmur brings local models, reusable voices, projects, queueing, and export into one Mac production workspace. Hear the current models before choosing a workflow.

[Buy Murmur · $49](https://murmur-licenses.tarunyadav9761.workers.dev/checkout)

macOS 15+ · Apple Silicon required · 7-day refund policy