The defaults are the product.

Our threat model

Every privacy posture should answer the same question first: what attacker is it for? bimi is designed for four:

1. Hyperscaler ingestion. Big providers retaining everything you ever asked a model. We defend by running locally by default and naming every cloud call.
2. Third-party analytics drift. An SDK silently sending behavioural metrics to a vendor whose privacy posture nobody on your team has read. We defend by shipping zero third-party telemetry.
3. Device-loss disclosure. A stolen laptop with the agent's memory on it. We defend with at-rest encryption tied to your device key.
4. Insider curiosity at Appalogue. Us — looking at your data without you asking. We defend by encrypting feedback end-to-end and refusing to centralize anything we don't need.

Things we are not defending against, and we say so:

• State-level adversaries with root on your Mac.
• An attacker with your iCloud password and your device.
• Anything you paste into a third-party tool we're calling on your behalf, once it leaves the boundary.

The six promises

The home page lists these. Here's the unabridged version.

① On-device whenever your Mac can run a capable model.

When a capable local model is installed, bimi runs it on your Mac for classification, extraction, and memory work. Cloud providers are opt-in, listed by name, and every routing decision is visible in the sidebar — the provider name, the model, and the reason are shown for each request.

② What a hosted chat model sees.

bimi stores your memories on your device. When you use a hosted chat provider (Claude, GPT), the memories relevant to your question are included in the request so it can answer accurately. Before sending, bimi redacts credentials, API keys, tokens, credit-card and SSN numbers, and password/key material. It does not redact names, locations, employers, or general personal facts — those are included so the answer is correct. To keep memory fully on-device, run an on-device chat model (requires a capable local model on your Mac).

③ Your voice is yours.

Wake-word detection happens locally. Push-to-talk audio lives in RAM during the utterance and is discarded once it becomes text. Meeting Mode writes the m4a to a sandboxed cache so bimi can transcribe a multi-hour session — today the default retention applies to that file (a user-facing retention picker is landing in a near-term wave). No audio of any kind is ever transmitted off-device by bimi. Voiceprints — only if you opt in — will be stored as sensitive memories alongside the rest of your constellation, encrypted with your device key.

④ Memory is auditable.

Every fact bimi remembers has provenance (where it came from, when), confidence (how sure we are), sensitivity (public / personal / sensitive — with finer-grained categories for PHI, credentials, and financial data), and links (graph edges to related memories). The Memory Inspector — currently in beta — lets you browse, edit, and delete every record. Contradicting facts get marked "in review" in the Inspector today; an in-conversation surfacing pass is on the roadmap.

⑤ No telemetry SDKs. Ever.

We don't ship Mixpanel, Amplitude, Sentry, Crashlytics, or any third-party analytics. Crash diagnostics use MetricKit, attached to your bug reports only when you submit one, end-to-end encrypted to us.

⑥ Beta reports are encrypted to us, not Anthropic.

When you send feedback from the in-app sidebar, the payload is encrypted with X25519 + ChaCha20-Poly1305 on your Mac and decrypted only on our server. We don't read it through any third party. There is no proxy provider in the chain.

⑦ Open about what we can't do.

Where we use the cloud — long-form reasoning, embeddings on big corpora — we say so. Where we don't yet meet our own bar, the in-app trust badge shows yellow and we tell you why. We'd rather be visibly imperfect than quietly compromised.

What does and doesn't leave the device

Crypto specifics

For the technically inclined. None of this is exotic — we use well-vetted primitives from CryptoKit.

At rest

• Memory store — file-level encryption tied to your macOS user account.
• Voiceprints — same path as memories, with a dedicated key derived from your account.
• iCloud sync — uses your CloudKit container; encryption posture is the platform default for CloudKit.

In flight (bug reports + feedback)

The feedback channel uses hybrid public-key encryption. Mechanism:

• Key agreement — X25519. Your bimi generates an ephemeral key pair per report.
• Symmetric encryption — ChaCha20-Poly1305. AEAD, ad authenticates report metadata.
• KDF — HKDF-SHA256 over the X25519 shared secret.
• Public key — our long-term encryption key ships in the bimi binary; we publish its fingerprint in the in-app About panel.

No telemetry SDKs

This one we list explicitly because it's the most common slip-up in privacy-marketed apps.

• No Mixpanel.
• No Amplitude.
• No Sentry, no Crashlytics, no Bugsnag.
• No PostHog.
• No Datadog RUM, no Firebase Analytics.
• No Segment proxy.
• No advertising or attribution SDKs of any kind.

Crash diagnostics use MetricKit. They are attached to your bug report when you send one — never auto-uploaded. You can inspect the diagnostic payload before it leaves the device.

Feedback & bug reports

In-app: open the sidebar → Share feedback. The composer shows you exactly what will be attached (message, optional diagnostic, optional screenshot), encrypts the payload locally, and ships it to us. We see the report; no third party sees it.

Out of band: hello@appalogue.com for anything else. Please don't email us secrets — we don't have a receipt mechanism for them, by design.

Security disclosure

Found a vulnerability? We'd love to hear about it. Email hello@appalogue.com with the word "security" in the subject line. We aim to acknowledge within 72 hours and coordinate disclosure timing with you. We don't have a paid bounty program yet — we'll credit you in release notes and a public security page.