Privacy Policy
Policy revision dated July 11, 2026 · Technical clarifications added July 22, 2026 · ONE REMAINS service notice added August 12, 2026 · Effective only after required account-holder notice and no earlier than July 25, 2026 at 12:00 a.m. Pacific Time (07:00 UTC) · Previous version (July 10, 2026)
The short version: Zimac is local-first: your durable content — chats, memory, notes, emails, documents — lives on your own device. Sensitive stores are encrypted when at-rest sealing is active; the fallback boundary is stated below. A model request still sends its prompt and selected context to the model route you choose. Our hosted servers process what is needed to run your account, license devices, bill you, meter and forward hosted-proxy calls, and relay end-to-end-encrypted team messages we cannot read. The optional ONE REMAINS browser game is a disclosed exception: its shared room state and in-game chats are server-visible as described below. We don't sell data or run ad trackers; self-hosted Enterprise runtime services stay inside the customer's cloud.
1. What stays on your device (almost everything)
The desktop App stores your working life locally, under a folder you control: ~/Documents/Zimac on Mac or Documents\Zimac on Windows. That includes conversations, the memory graph, notes, imported emails and documents, people profiles, backups, pairing state, and what the assistants learn about how you write and think. When at-rest sealing is active, sensitive stores are encrypted on disk. The data key uses macOS Keychain or Windows Credential Manager when available; otherwise Zimac falls back to an owner-only, non-synced local key file. If neither location is writable, at-rest sealing is unavailable and new storage-boundary writes are not app-level encrypted. Zimac has no default server-side copy of this local store; optional hosted features below may process or retain their own scoped data. When sealing is active, you can create a passphrase-wrapped recovery code under Settings → Recovery key and import it on another computer; the code and passphrase are never sent to us, and without both of them we cannot recreate a lost device key or recover sealed data.
The in-app Erase memory action is deliberately recoverable: it removes live personal content but creates and retains a backup, and it keeps connections, API keys, and pairing. For full local deletion, use Settings → Privacy → Erase all local data. After an exact typed confirmation, the App quits and removes live data, backups, plugins, setup and pairing files, cached activation, and its legacy-named Stitcher items from the operating-system credential store. The erase works without the license server; if a device slot could not be deactivated first, you can remove it later from Hub or the verified-email recovery link. See the complete removal guide first.
When you choose direct Anthropic, the request goes from your device to Anthropic and never touches Zimac's hosted proxy. When you choose a local model, it can remain on your device. Other remote OpenAI-compatible services receive requests under their own terms.
Optional screen observation: Sight is currently a macOS-only part of the Frame and is off by default. It starts only after you enable it, click Observe for that session, and grant macOS Screen Recording permission. The current version observes the primary display, excludes Zimac's own windows and the cursor, and uses Apple Vision to recognize text on device. Raw screen pixels exist only briefly in memory for change detection and OCR; they are never saved or sent off the Mac. The recognized text is secret-redacted and may then be sent through the model route you selected so Zimac can distill it into local memory. Accepted facts carry local absorption receipts and can be undone. Pausing, unsticking the Frame, quitting the App, or a capture failure ends the observation session.
2. What we process, and why
If you use our hosted Platform, we process the minimum each service needs:
- Account & sign-in: your email address, org memberships, and seat tokens — so you can sign in and manage org access. Authentication runs on AWS Cognito.
- Retail app licensing: activation sends a license or activation key plus a device-binding identifier and computer name. The license service retains device identifiers, names, and activation times to enforce the three-computer limit and support device removal. After a successful check, annual subscription activations are normally revalidated every 24 hours; failed checks may retry sooner. One-time and grandfathered lifetime keys do not periodically revalidate.
- Billing: handled by Stripe. We keep transaction and subscription records (what was bought, when, for which account); your card details go to Stripe and never touch our servers.
- Promotional starter credit: when the App claims the one-time hosted-inference promotion, the payments service validates the presented Zimac token through the auth service. Payments receives the token’s tenant and principal label (which may be an email), a derived eligibility result, and a random campaign pseudonym. It does not receive the raw Cognito subject, the token-provenance fields auth used to derive eligibility, or Auth’s private lookup key. Auth derives that versioned lookup key with a dedicated keyed HMAC of the canonical provider-verified email, so the retained mapping stores no raw email. Auth retains the pseudonymous lookup-key-to-campaign mapping for abuse and cost control, and Payments stores a global redemption marker plus the tenant’s promotional-credit ledger receipt. These markers prevent deletion, re-registration, or another token from resetting the one-time grant.
- Proxy metering and optional Gateway Memory: for each proxied model call we record metadata — timestamps, model, token counts, and the org/seat it bills to — to enforce budgets and show you usage. By default, request and response content transits the proxy to the model provider and back without being stored by the proxy. If Gateway Memory is enabled for the key or tenant, the separate memory service processes the latest user cue, may return selected context for injection, and stages the completed user/assistant exchange in a tenant-scoped quarantine under its retention controls. It is off for other keys and can be disabled for an individual request.
- Team relay & discovery: device presence records (which expire automatically) and message envelopes that are end-to-end encrypted on your devices — the relay carries ciphertext it cannot decrypt, and undelivered envelopes expire and are deleted. One honest detail: “anonymous” team asks are anonymous to your teammates, but the relay authenticates every request, so they are attributable within your org's tenant for abuse control.
- ONE REMAINS game: when you opt into the hosted game, we process your account identifier and chosen display name; room membership, character, presence and location; challenge submissions and times; powers and ballots; and the public, group, and direct messages you send inside a room. This shared state is needed to operate and secure an asynchronous multiplayer game. Unlike the Team Relay, ONE REMAINS game messages are not end-to-end encrypted: Zimac's game service can read them, and intended room, group, or direct-message participants can see them. They use TLS in transit and encryption in the hosted data store at rest. Do not put secrets or information you need to keep permanently in game comms.
- Connected services: when you connect Slack or another integration, the App sends the credentials, queries, and content needed for the operation you authorize directly to that service. Credentials stay out of model context; the connected service processes that data under its own terms.
- iPhone pairing: account sign-in does not copy your Mac memory. Pairing requires both devices on the same local network, Local Network permission on iPhone, and explicit approval on the Mac; setup and memory then sync over the encrypted device channel.
- Websites: our sites are static pages with no advertising trackers, no third-party analytics, and no analytics cookies. We measure traffic ourselves, first-party and visit-scoped: while you browse, a random marker held only in your tab's session storage strings the pages of that single visit together — it disappears when the tab closes, so two visits are indistinguishable from two visitors. For a visit we record the pages viewed and in what order, engaged-time and scroll milestones, sections kept on screen, clicks, form and media outcomes, coarse page-load performance buckets, viewport size family, the referring site's hostname and any utm tags, your country, a masked network prefix (for example, 203.0.113.x rather than an exact address), and your browser and operating-system family. Valid campaign tags are retained only for the open tab and copied only onto links among Zimac-owned web properties so a visit can remain attributable when it moves between them; they are never added to third-party destinations. Never a cookie or fingerprint — your exact IP address and full browser signature are used only to derive those coarse values, then discarded. Browsers with Do Not Track or Global Privacy Control enabled are not measured at all. Raw visit records, including the masked network prefix, are deleted after 90 days; only per-day aggregate counts are kept. Fonts are served by Google Fonts, which sees standard request data (like your IP address) when loading them.
- Launch-note list: if you sign up for the launch note we store your email address, which site you signed up on, and your confirmation status — double opt-in, so nothing is ever sent to an unconfirmed address. Every email includes a one-click unsubscribe link, and the address is used for the launch note only.
- Support: if you email us, we keep the correspondence.
3. Model providers
Model calls have to be processed by a model. Requests routed through our proxy go to the provider configured for your org (by default Anthropic) and are handled under that provider's terms and data policies; we choose API terms under which providers do not train on your data. If you connect directly to Anthropic or another remote provider, your relationship is directly with that provider. A local model can keep the call entirely on your machine.
4. Who we share with
Only processors that make the service work, and services you choose to connect: AWS (hosting and authentication), Stripe (payments), your model provider (model calls), and the connected services you authorize. We don't sell or rent personal data, and we don't share it for advertising. We may disclose information if the law genuinely compels it — though note the design: the most sensitive data never reaches us to be disclosed.
5. Retention
- Account, license activation, billing, and promotional-credit ledger records: while the related account, license, or transaction requires them, plus what accounting, tax, security, and abuse-prevention obligations require. The keyed, pseudonymous starter-promotion mapping and redemption markers remain after account deletion so deletion and re-registration cannot reset the one-time offer.
- Proxy usage metadata: kept for metering, billing disputes, and abuse prevention, then aged out.
- Gateway Memory captures, when enabled: deduplicated in a capped tenant-and-space quarantine; the oldest staged entries are dropped when its configured cap is reached. Promoted entries become tenant memory and follow that tenant's memory controls.
- Relay envelopes and presence: delivered or expired, then gone — they are transient by design.
- ONE REMAINS room state and game messages: an active room expires no later than 30 days after it is created; after a room completes, its final record expires no later than 30 days after completion. Deleting your personal account immediately blocks that account from reading or changing the game and permanently replaces its identity in retained shared rooms with a room-scoped “Deleted player” identity. The rooms are not deleted. Messages and game events in shared room history remain visible to their intended participants under that de-identified attribution until the room record expires. Direct account-index rows are removed. Point-in-time recovery remains enabled for operational recoverability; a restore is isolated from the live service and deletion jobs are replayed and verified before restored data can serve traffic.
- Everything on your device: yours; we hold nothing to retain.
6. Your rights
Use Hub → Account & privacy for self-service personal-account deletion, or email [email protected] to access, correct, export, or delete data we hold when you cannot sign in. We honor these requests regardless of where you live, including under GDPR and CCPA/CPRA. Leaving or deleting an organization is not the same as deleting your personal account. Before deleting an org, settle its credits and subscriptions. Personal-account deletion requires a fresh interactive sign-in, revokes hosted tokens, forfeits any remaining promotional credit, removes direct account data subject to records we must keep by law, and permanently de-identifies the player in bounded shared ONE REMAINS room history without deleting the room; it does not erase devices or cancel unrelated Stripe commitments unless the confirmation says so. Resolve any billing error or legally required refund before deleting.
7. Security
In transit, hosted services use TLS. At rest on your device, Zimac seals sensitive stores when it can persist a recoverable data key. It normally uses macOS Keychain or Windows Credential Manager, then an owner-only non-synced key file; if neither is writable, sealing is unavailable. On the hosted-proxy path, the upstream provider credential lives server-side while your revocable org token is stored on the device. Direct-provider credentials use the platform credential store when available or the owner-only local fallback and are sent to that provider. Hosted Platform stores are encrypted. Team Relay messages are end-to-end encrypted with keys we never hold; ONE REMAINS game messages are the server-readable exception described above. No system is unbreakable — but this one minimizes what each component receives.
8. Zimac Enterprise (self-hosted)
If your company runs a self-hosted Zimac Enterprise install, its runtime platform operates inside your company's own cloud account; we receive no accounts, runtime usage, prompts, or memory from those services. Administrator-started installer builds contact Zimac for release authorization. Unless your IT team bakes in a private update feed or you disable automatic update checks, a branded desktop app also requests Zimac's public update feed after launch and about daily, which exposes normal HTTP connection metadata but not app content. Your employer operates the install and is the controller of its data; their policies apply.
9. Children
Zimac is a professional tool, not directed at children, and not intended for anyone under 16.
10. Changes & contact
If we change this policy in any material way, we'll announce it on this site (and by email for account holders) before it takes effect. Questions: [email protected].