Privacy Policy

Effective Date: [TO BE FILLED at v1.0 launch] Last Updated: 2026-05-21 (draft)

DRAFT for legal counsel review. This is the engineering team's first-pass draft, written in plain English to map onto the actual code paths in the Apna app. The architecture is intentionally simple: almost no user data leaves the device. This policy reflects that. Counsel: please flag where additional language is required for jurisdiction-specific compliance.

1. The short version#

Apna is a personal agent app. Your memory, contacts, calendar, voice, and conversations stay on your device. The Apna service exists only to route encrypted messages between agents — we never see the contents of those messages, and we never receive a copy of your memory or voice.

When you ask Mira (your agent) to do something, Mira runs on your phone using on-device AI models. When Mira talks to another person's agent, the messages are end-to-end encrypted and our servers only forward the encrypted bytes. We can't read them, even if we wanted to.

If you stop using Apna, you can take all your data with you in standard, open formats. If Apna is ever acquired or shut down, we have legally binding commitments to preserve your access for at least 90 days and to refuse to transfer your plaintext data to anyone.

The rest of this policy is the legally precise version of the above. We're keeping it as short as possible.

2. What data Apna touches, where it lives, and who can read it#

2.1 Data that stays on your device#

The following data never leaves your phone in plaintext:

Your contacts (read via system Contacts API; never copied to our servers)
Your calendar events (read via system Calendar API; never copied)
Your voice recordings during Personal Voice training (Phase 6 feature)
Your speaker embedding (a numerical representation of your voice, used by Mira to synthesize your voice if you opt in; stored in Secure Enclave on iOS / StrongBox on Android)
Your memory graph (people, episodes, facts, conversations, decisions) — stored locally in an encrypted LadybugDB database
The content of every message Mira sends or receives on your behalf (decrypted only on your device)
Mira's reasoning state mid-conversation (in-memory only; cleared on app close)

We use Apple's completeUnlessOpen file protection on iOS and Android's encrypted file system + StrongBox-backed master key to encrypt all of the above at rest.

2.2 Data that touches our servers (and what we can see)#

The following data passes through Apna's Cloudflare Workers backend:

Your decentralized identifier (DID) — a public ed25519 key derived from a private key your device generated. We use this to route messages to your agent. We can see this; it's the routing address.
Your published AgentCard — a small file describing your agent's capabilities (e.g., "can schedule meetings"). Public by design.
Encrypted message envelopes — when someone else's agent sends a message to yours, the encrypted bytes pass through our servers. We can see envelope routing metadata (sender DID, recipient DID, timestamp, envelope size) but NEVER the message contents.
Push notification routing metadata — when we wake your app to deliver a message, we send Apple Push Notification Service (iOS) or Firebase Cloud Messaging (Android) a notification containing only: envelope ID, sender DID, timestamp. NEVER message contents or session keys.

2.3 Data we explicitly never collect#

To make this concrete:

We do not collect your phone number, email address, or full name (we collect only your chosen handle, e.g., venkat from apna.me/venkat)
We do not collect IP addresses except as needed for transient request routing (Cloudflare logs at the edge for the standard 30-day operational retention; we do not query these logs)
We do not collect device identifiers beyond the per-install random ID required for push notification routing
We do not read, log, or process the content of any message Mira sends or receives
We do not train AI models on your data. The AI models on your device come pre-trained from the open-source community (Gemma 4 E4B, Qwen3-TTS, etc.) and are never updated based on your usage.
We do not receive your contacts, calendar, voice recordings, or memory graph

2.4 Why we believe this#

This is verifiable. Apna's code paths can be audited:

The Apna mobile clients are planned for open-source release post-product-market-fit (v1.5 or earlier). Wire-format contracts are documented today in docs/implementation/golden/ so any technically-able user can verify the bytes leaving their device.
The Apna backend's role is intentionally narrow: route encrypted envelopes + sign push notifications. We've designed it so we can't read message contents even if a court ordered us to — the session keys live exclusively on your device.

3. End-to-end encryption (E2E)#

Every message between Mira agents uses the Signal Double Ratchet protocol, with:

X3DH key agreement (Curve25519)
Per-message ephemeral keys (forward secrecy: a key compromise today can't decrypt yesterday's messages)
DH ratchet step on every message direction change (Signal §3.5)
Skipped-keys cache for out-of-order delivery
XChaCha20-Poly1305 authenticated encryption for the message bodies

Your device generates the session keys. They are never transmitted. We literally cannot decrypt your messages, even with full database access.

4. Personal Voice (Phase 6 — opt-in only)#

Personal Voice is a feature where you can train Mira to speak in your voice for specific situations (e.g., screening telemarketers, sending voice messages). It is:

Off by default. You must explicitly opt in via Settings.
Trained on-device. Training samples never leave your phone.
Stored encrypted in hardware. Your voice embedding lives in Secure Enclave (iOS) / StrongBox (Android). We have no copy.
Per-conversation opt-in. Mira cannot use your voice for any specific conversation without your explicit per-conversation authorization, OR a "standing rule" you have set in Settings for specific situations.
Watermarked. Every synthesized utterance carries an AudioSeal watermark, detectable by anyone using the open-source detector — required by the EU AI Act and our own foundational principles.
In-band disclosure. By default, every cloned-voice utterance begins with "Hi, this is Mira speaking for [your name]." You can disable this in Settings, but disabling requires a hard double-confirmation flow.

You can delete your voice embedding at any time from Settings → Personal Voice → Delete. This is irrevocable; we have no copy to restore from.

5. AI use disclosure (EU AI Act Article 50 + App Store 5.1.2(i))#

Mira is an AI agent. We disclose this in:

Onboarding (Phase 2): explicit acknowledgement of "Mira is your AI agent."
Settings → AI: plain-language explainer of every AI feature, including which model handles which task, whether the model runs on-device or in the cloud (answer: always on-device), and the data the model touches.
Settings → AI Disclosure Log: every cloned-voice synthesis is logged with timestamp, conversation ID, and duration. Visible only to you. Auto-purges after 90 days unless exported.
In-band per-utterance disclosure when Mira speaks in your voice (Phase 6).
AudioSeal watermark on every cloned-voice utterance.

The EU AI Act Article 50 (enforcement Aug 2, 2026) requires disclosure when generated content "could appreciably resemble" a real person. Apna's design satisfies this.

6. Your rights (and how to exercise them)#

You have the following rights regardless of where you live:

6.1 Export your data ("data portability")#

Settings → Privacy → Export Data produces a ZIP containing:

Your onboarding state (JSON)
Your memory graph (Cypher dump + JSON-LD + Markdown human-readable)
Your A2A session transcripts (encrypted blobs you can decrypt with your local keys)
Your Personal Voice embedding (encrypted blob; only your device's keys can decrypt; we cannot)

This runs entirely on-device. No server roundtrip. Format is documented at legal/data-export-format.md.

6.2 Delete your data#

Settings → Privacy → Delete Everything wipes:

Your local memory graph
Your Personal Voice embedding
Your Apna identity (DID + private keys)
Your subscription state (Pro tier; we also process the cancellation with Apple/Google/Stripe)

We also delete (from Apna's backend):

Your AgentCard registration
Your push notification token binding
Any encrypted envelopes addressed to you that we haven't yet delivered

We do not retain backups of the above. Once deleted, gone.

Processing timeline (GDPR Art. 12(3)): Erasure requests issued from the in-app Delete Everything flow are processed without undue delay — typically within seconds on-device, with the backend-side deletes (AgentCard, push token, undelivered envelopes) completing inside our normal job cadence and always within 30 calendar days of receipt. If a manual request is sent to privacy@apna.app instead, the same 30-day SLA applies and we will confirm completion in writing.

6.3 Rectify inaccurate data#

You can edit any item in your memory graph from within the app (Settings → Memory Inspector). We have no copy to rectify on our end; your device is the source of truth.

6.4 Restrict or object to processing#

Since our processing is limited to (a) routing encrypted messages we can't read and (b) sending push notifications you've opted into, the "object to processing" right effectively means "delete your account" (§6.2 above).

6.5 Right to complain to a regulator#

EU users can complain to their national Data Protection Authority. UK users: the Information Commissioner's Office. California users: the California Privacy Protection Agency.

7. Children#

Apna is not directed at children under 13 (US) or under the locally-defined age of digital consent (EU GDPR Art. 8: typically 16). We do not knowingly collect data from children. If you become aware of an under-age user, please contact us at [TO BE FILLED] and we will delete their account.

8. International users#

Apna's backend runs on Cloudflare Workers, with edge presence globally. Your encrypted envelopes are routed via the nearest Cloudflare edge. We do not transfer plaintext user data across borders because we never have plaintext user data to transfer.

For EU users: our processing is governed by the GDPR. We are the data controller for the limited backend-side metadata we hold (DIDs, AgentCards, push tokens, encrypted envelope routing). Standard data subject rights (above) apply.

9. Security and breach notification#

We commit to:

Encrypting all data at rest on the device with the platform's strongest available file protection (Phase 0+ architectural baseline).
Using audited cryptographic libraries (swift-crypto on iOS, java.security on Android, @noble crypto stack on the Workers backend, libsodium for XChaCha20-Poly1305).
A formal cryptographer engagement to audit our Signal Double Ratchet + X3DH implementation before v1.0 production launch.
72-hour breach notification to affected users + applicable regulators if we ever experience a security incident.

10. Acquisition / shutdown survival ("Day-1 commitment")#

This section is a legally binding commitment carried forward from our foundational design principles (spec §13.3). It exists because Apna users are extraordinarily sensitive to acquisition risk — our reference case is Rewind/Limitless, which was acquired by Meta in December 2025 and kill-switched 14 days later.

If Apna is acquired, sold, restructured, or wound down:

(a) We will maintain service for 90 days minimum to allow data export. No exceptions, including in the event of bankruptcy. The 90-day window will be funded from a dedicated escrow account established at launch.

(b) We will prohibit transfer of plaintext user data to the new owner. Since we cannot decrypt your messages or read your memory graph, this means our backend's database tables (DIDs, AgentCards, push tokens, encrypted envelope blobs) are the maximum possible transfer. No plaintext content. No session keys. Ever.

(d) We will honor your existing privacy commitments even if the new owner's defaults are different. If the new owner wants to change anything in this Privacy Policy, they must obtain affirmative consent from each existing user. Default consent is "no."

(e) We will publish the wind-down notice at apna.com/announcements, in-app, and via email/AirDrop if you have provided those.

(f) In the event of a hostile acquisition where the new owner refuses to honor commitments (a)-(d), the existing engineering team commits to publishing the iOS and Android client source code and the wire-format specifications immediately, enabling users to migrate to an independently-operated clone.

11. Children, contact, and changes#

Contact: [TO BE FILLED: support@apna.com] Postal: [TO BE FILLED entity address] Data Protection Officer: [TO BE FILLED — required if processing scale crosses GDPR threshold] EU representative: [TO BE FILLED — Art. 27 GDPR if applicable]

Changes to this policy: We will notify you in-app and via email/AirDrop at least 30 days before any material change. Continued use after the change date constitutes acceptance. For non-material changes (clarifications, typo fixes), we will note the "Last Updated" date but not provide individual notice.

Legal disclaimer (DRAFT): This document is a first-pass engineering-team draft. It does not constitute legal advice. Final language is subject to review by qualified counsel in each jurisdiction where Apna is offered.