Privateer — Privacy Policy

1. Introduction

Privateer is designed from the ground up with privacy as a core property, not an afterthought. This Privacy Policy explains what data we collect, what we do not collect, and how your information is protected.

2. What We Collect and Why

We try to be specific rather than abstract here. The rule is: if the server has to read it to operate (route a request, bill you, keep you signed in, prevent abuse), we store it in plaintext. Everything else is end-to-end encrypted under a key only your device holds.

2.1 Account Data

Email/Password accounts: Your email address, a bcrypt-hashed password (we never store the plaintext password), and your encrypted master-key blob plus the salt and Argon2id parameters needed for your client to re-derive your key (see Section 3).

Solana wallet accounts: Your Solana public key, the encrypted master-key blob, and the version of the vault-key message your client signed to derive its KEK (see Section 3). We never receive or store your wallet private key, seed phrase, or the unwrapped master key. Anyone with a Solana wallet can create an account by signing the wallet-bound sign-in message; we do not require email for wallet accounts.

Guest sessions: Guests have no server account at all. See Section 5.

2.2 Operational Metadata

To bill, route, and protect the service, we necessarily see in plaintext:

Timestamps of API calls and the model identifier used for each request (for billing and routing — without this, we can't tell OpenRouter which model to call).
Token counts and approximate per-request cost.
Your chosen storage backend (cloud or local) and, for cloud users, a running total of bytes stored on your behalf so we can enforce per-tier storage caps.
Subscription and credit state (active plan, renewal date, Stripe customer and subscription IDs, credit balances).
Session and refresh-token identifiers so you stay signed in.

This data does not include the content of your messages, files, titles, image-generation prompts, AI personalization, memories, or attachments' file names or MIME types — those are encrypted on your device before they reach us (Section 3).

If you purchase credits or a subscription, we also store the metadata required to fulfill that purchase: timestamp, plan or credit pack, and the Stripe customer/subscription identifiers needed to bill, refund, or cancel. Payment card details themselves never touch our servers — they are handled by Stripe.

2.3 Technical Data

We may log your IP address, device type, and operating system version, and we apply per-IP rate limits to sign-in and sign-up endpoints. This data is used for security and abuse-prevention purposes only; it is not sold or shared with advertising networks.

2.4 Product Analytics (self-hosted, aggregate-only)

We run our own analytics on our own servers. There is no third-party analytics, advertising, or tracking SDK in the app or on this site. What we count is stored as daily totals across all users — never as per-user event logs. Here is the complete list of what we count:

Sign-ups per day, by method (email, wallet, or guest-to-account conversion).
How many users sent their first message, generated their first image or video, or saved their first file each day.
How many users returned the day after signing up, and seven days after signing up.
How many users reached three messages in a week (our measure of an active user).
How many times the subscription or top-up screen was opened, by which screen led there. This counter is anonymous — the request carries no account identifier.
Subscriptions started and cancelled per day, by plan tier, billing interval, and store (web, Google Play, or App Store).
Top-ups per day, and how many times users ran out of credit.
Daily totals of subscription revenue, top-up revenue, and our inference costs.
Guest usage: how many guest messages and guest image generations we served each day, and the daily total cost to us of serving them. Guest requests carry no account, and we store no per-guest identifiers — these are plain daily totals across all guests.

To make a handful of those totals countable, we keep exactly these analytics fields on your account: the timestamp of your first message, first media generation, and first saved file; your most recent activity timestamp; two one-time yes/no flags recording whether you returned on day 1 and day 7; and a current-week message counter that stops counting at three. These are single values that are overwritten in place — they are not logs, and we cannot reconstruct your activity history from them. We never know whether you sent three messages this week or three hundred.

3. What We Do Not Collect

Your message content. Messages, AI responses, chat and graph titles, AI personalization, memories, project instructions, project files, and image-generation prompts are encrypted on your device with AES-256-GCM (random IV per operation, 128-bit authentication tag) before being sent to our servers. Image and video attachment metadata — file name, MIME type, the prompt used to generate an image — is included inside that encrypted envelope. Our databases contain only ciphertext for all of these fields. We are structurally unable to read them.

Your password or master key. Every account has a randomly generated 32-byte master key that wraps all of your content. The master key is itself wrapped (encrypted) by a key-encryption key (KEK) that is derived locally and never transmitted:

For password accounts, the KEK is derived from your password using Argon2id with parameters at or above the modern OWASP minimum (64 MiB of memory, three iterations, parallelism of one). The server stores only the wrapped blob, the salt, and the Argon2id parameters — never the password, never the KEK, never the unwrapped master key.
For wallet accounts, the KEK is derived via HKDF-SHA256 from a signature your wallet produces over a message bound to your wallet's public key: "Privateer vault key v2 for <your-pubkey-hex>". The server stores only the wrapped blob — never the signature, never the KEK, never the unwrapped master key.

If you forget your password (or permanently lose access to your wallet), your data is irrecoverable. Privateer cannot reset your password and cannot recover your data. This is a deliberate architectural property, not a limitation we plan to remove.

Plaintext user content at rest. Our databases contain only encrypted blobs for the content fields listed above. We are structurally unable to read your stored data.

Behavioral profiles. We do not build per-user behavioral profiles, per-user event trails, session recordings, or device fingerprints, and we embed no third-party analytics or advertising SDK. Product analytics are aggregate daily counts only, enumerated exhaustively in Section 2.4.

Master key in device backups. On Android, our app opts out of system backups (cloud and device-to-device transfer) so the locally cached unwrapped master key cannot leave the device through Google Auto Backup. On iOS, the master key cache is held in the Keychain and is not synced to iCloud Keychain (we do not set the synchronizable flag). It may be included in an encrypted iTunes/Finder device backup; recovering the key from such a backup would require the user's iOS backup password and physical access to the backup file. Users who want the strongest guarantee against this narrow attack should disable encrypted backups on the device or use a wallet account — wallet accounts re-derive the key from a fresh wallet signature on each cold start and do not rely on the local cache.

4. AI Inference and the Inference Window

Privateer routes AI inference requests through one of two third-party providers, depending on the model you choose: OpenRouter, a model gateway, and NEAR AI Cloud, a confidential-compute provider that runs models inside hardware Trusted Execution Environments (TEEs). Generating text or images requires sending plaintext to a model provider — there is no way around that. We minimize what passes through, and we don't pretend it's encrypted when it isn't.

The inference window. When you send a prompt for AI processing, your client decrypts the conversation history locally and forwards the request — your message, any prior turns you've chosen to include as context, the relevant attachments, and any AI personalization or memory entries you've authored — through our server to the inference provider that serves the model you selected. This plaintext exists transiently along the request path. We do not write the request body or the model's response to our database in plaintext; the response is encrypted by your client before being persisted.

What our server logs about an inference call. Operationally useful metadata: timestamps, model ID, token counts, request shape (e.g. whether images were attached), and cost. We deliberately do not log request or response bodies.

Two privacy guarantees for inference. Because inference inevitably exposes plaintext to a model provider, every request is covered by one of two protections, and we label each model so you can see which one applies:

Zero Data Retention (ZDR). For every model we label ZDR, we enforce zero data retention on each request — the request is pinned at the endpoint level to providers that are contractually prohibited from retaining your prompts for model training or any other purpose. You can also turn on Require Zero Data Retention in Security settings: while it is on, model selection is restricted to ZDR (and confidential-compute) models and every request additionally excludes any provider that stores data at all. If you choose a non-ZDR model with that setting off, we tell you plainly before you do that the provider may store and use that request.
Confidential compute (TEE). Models we route through NEAR AI Cloud run inside a hardware Trusted Execution Environment (Intel TDX with confidential GPU compute). Your prompt is decrypted and processed only inside that enclave; the provider's own operators and infrastructure cannot read it, and it is not retained after the request completes. We label these models as confidential, and where the provider publishes a cryptographic attestation that the model is genuinely running inside the enclave, you can view it in the app before you send. Confidential-compute models carry a zero-retention guarantee enforced by the hardware rather than only by contract, so for the purpose of the Require Zero Data Retention setting they are treated the same as ZDR models.

Voice chat mode. Voice chat extends the inference window to spoken conversations, and it works the same way: by sending data to a provider in the clear so it can be processed. When you turn voice mode on and speak, the app accesses your microphone and records your spoken turn. That audio is sent through our server to OpenRouter's speech-to-text service to be transcribed; the resulting transcript is then handled exactly like a typed message. To speak the reply back to you, the AI's response text is sent to OpenRouter's text-to-speech service, which returns spoken audio your device plays. Because audio and text must reach the provider unencrypted to be processed, the recorded speech and the reply audio in a voice turn are part of the transient inference window and are not end-to-end encrypted in transit — the same honest caveat that applies to any inference. We access your microphone only while voice mode is active, and only to capture your current turn. The recorded audio and the synthesized speech are used to fulfill the request and are not written to our database; only the resulting transcript and AI text are persisted, encrypted on your device like any other message. Voice transcription and synthesis follow the ZDR routing described above wherever the chosen voice models support it. Voice chat is a paid feature (see our Terms of Service).

What the inference provider does not receive. Your stored chat history, project files, and library images stay encrypted and are not sent to OpenRouter or NEAR AI Cloud unless you explicitly include them in an active request.

For more, see OpenRouter's Privacy Policy at https://openrouter.ai/privacy and NEAR AI's published terms at https://near.ai.

Model preferences. The model identifier is sent with each request so we can route it to the correct provider and model. Your model preference (the default model you've selected) is stored according to your storage backend: in our database for cloud users, on-device only for local-storage and guest users.

5. Storage Backends

You choose where your data lives, and the server enforces that choice.

Cloud Storage (default): Your encrypted content is stored in MongoDB (text fields, encrypted titles, encrypted attachment metadata) and AWS S3 (encrypted image and file blobs). Everything that touches our servers in the cloud-storage path is ciphertext for the content categories listed in Section 3. We can see the operational metadata in Section 2.2; we cannot see the content.

Local Storage: Your content is stored entirely on your device using encrypted on-device storage. No content, attachments, model preferences, AI personalization, or memories are transmitted to our servers. To enforce this on the server side as well (so a bug in the app can't accidentally leak), our content-write endpoints — image uploads, file uploads, image generation, video generation — reject requests from local-storage accounts with a clear error. Sign-in, billing, and inference proxy still operate (they have to, to keep the account working); everything else stays on your device. This is the strongest privacy guarantee Privateer offers for an authenticated account.

Guest Mode: You can use Privateer without creating an account. Guest chats live only on your device in encrypted local storage and never reach our servers. Signing up later converts a guest session into a regular account; with your consent, your existing guest chats can be imported into the new account. Exiting guest mode clears guest data from the device.

6. Technical Safeguards

These are the concrete controls behind the guarantees above. Crypto-level details live in our open architecture document and in our public, independently auditable source code at https://github.com/privateer-agent/privateer-transparency — you can read the exact encryption code behind these guarantees and verify them yourself rather than taking them on trust. This is the user-facing summary.

Symmetric encryption: AES-256-GCM with a fresh random 12-byte IV per operation and a 128-bit authentication tag, for both text fields and binary blobs.
Password KEK: Argon2id with m ≥ 64 MiB, t ≥ 3, p ≥ 1. The server rejects accounts that try to enroll with weaker parameters.
Wallet KEK: HKDF-SHA256 over a wallet signature of a domain-separated, pubkey-bound message (Section 3). The server validates the canonical sign-in message format and binds it to the wallet public key, so a signature produced in another context cannot be reused to authenticate to Privateer.
Sign-in nonces: Single-use, short-lived, server-issued, and bound to the canonical sign-in message; rate-limited per IP.
Network: All traffic between the app and our servers is TLS-encrypted in transit. Wrapped master keys are transmitted only over TLS.
Logging: Our server-side logs intentionally exclude request and response bodies for chat and inference endpoints. Authentication-related logs do not include passwords, master keys, or wrapped master keys.
Backups: Android system backups (Auto Backup and device-to-device transfer) are disabled for our app to prevent the locally cached master key from leaving the device. On iOS, the master key cache lives in the Keychain and is not synced to iCloud Keychain; it may be included in encrypted iTunes/Finder backups, in which case recovery requires the user's backup password (see Section 3 for the threat model and how wallet accounts avoid the cache entirely).

7. Warrant Canary

As of June 16, 2026:

Hayden Bulk Tech Labs has never received a National Security Letter, a FISA Court Order, or any other classified demand for user data.

We have never been compelled to install a backdoor in any Privateer software or modify our systems to allow surveillance.

We will re-evaluate this statement with each revision of this Privacy Policy. If this canary is removed or not updated, treat it as a signal that we may have received such a demand. This approach is modeled on Signal and Cloudflare.

8. Data Sharing

We do not sell your personal data. We share data only when:

Transmitting inference requests to our inference providers — OpenRouter and NEAR AI Cloud (Section 4).
Required by valid legal process. For content fields, we store only ciphertext — we can produce that ciphertext but cannot decrypt it. For operational metadata (Section 2.2), we can produce what we have.
Infrastructure sub-processors require it (AWS for S3 storage and compute, MongoDB Atlas for the operational database, Render for application hosting, an upstream Redis provider for short-lived nonce and rate-limit state). None of these sub-processors receive plaintext user content.
Payment processing requires it (Stripe Inc. — receives billing metadata and card details directly, never user content).
A merger or acquisition requires transfer (we will provide prior notice).

9. Data Retention

Account data: until you delete your account.
Encrypted content: until you delete it or your account.
Operational metadata and usage logs (the items listed in Section 2.2 — timestamps, model IDs, token counts, per-request cost; no message content): retained for as long as we need it to operate the service. We use this metadata for billing reconciliation, fraud and abuse prevention, capacity planning, and product analytics. None of it contains the substance of your conversations, files, or attachments — those remain end-to-end encrypted (Section 3). On account deletion, this metadata is unlinked from any direct identifier where doing so does not break the financial-record commitments below.
Voice-mode audio (your recorded speech and the AI's synthesized reply): transient — sent to the speech provider to fulfill the turn, played on your device, and not written to our database. Only the resulting transcript and AI text are persisted, and those are end-to-end encrypted (Section 3).
Sign-in nonces and per-IP rate-limit counters: minutes (TTL-expired automatically by our Redis store).
Session tokens: expire automatically, purged on logout.
Billing records (Stripe and our own audit rows for credit top-ups, subscription grants, and reservation refunds): retained per applicable tax law (currently 6 years under Canadian law).

Deleting your account triggers a grace period during which you can recover it. After the grace period, account data and encrypted content are removed by a scheduled deletion job.

10. Your Rights

You may have the right to access, correct, delete, or port your personal data depending on your jurisdiction. Contact us at support@privateer.pro. We respond within 30 days.

A note on the practical limit. Because the content fields in Section 3 are encrypted under a key we do not hold, an access or portability request to us can return only ciphertext for those fields. To recover plaintext, decrypt the export in the Privateer app using your password or wallet.

GDPR / EEA Users: You may lodge a complaint with your local data protection authority.

PIPEDA (Canada): As a Canadian company, we comply with the Personal Information Protection and Electronic Documents Act.

California Residents (CCPA): We do not sell personal information.

11. Children's Privacy

Privateer is not directed at children under 13. Contact support@privateer.pro if you believe a child has created an account.

12. Changes to This Policy

We will notify users of material changes via in-app notification or email at least 7 days before changes take effect. The warrant canary is re-evaluated with each update.

13. Contact

Hayden Bulk Tech Labs support@privateer.pro https://privateer.pro

Effective Date: June 16, 2026 Operator: Hayden Bulk Tech Labs Contact: support@privateer.pro