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 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 the inference provider 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.

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.

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 several third-party providers, depending on the model you choose: OpenRouter, a model gateway; three confidential-compute providers — NEAR AI Cloud, Tinfoil, and Phala — that run models inside hardware secure enclaves (Trusted Execution Environments, TEEs); and fal.ai, which we use only for media generation — voices, music, sound effects, and 3D meshes — in the cases where no gateway or enclave provider hosts a suitable model at all. fal.ai is not a confidential-compute provider and offers no zero-retention contract. The models we route to it are labelled accordingly, and apart from music (see below) a request reaches it only if you have turned on non-zero-retention media generation. Generating text, images, or any other media 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.

"Finish replies in the cloud" (optional, off by default). Normally, if you close or background the app before a reply finishes streaming to your device, that reply is lost — only your device can encrypt and save it. You can turn on Finish replies in the cloud in Security settings to change that. When it is on and you close the app mid-reply, we keep the finished reply text on our servers briefly, in plaintext — held in short-lived memory (Redis), never written to our main database, automatically deleted within about an hour, and deleted immediately once your device retrieves it, encrypts it, and saves it. We say so plainly in the setting itself, and we do not describe it as encrypted. Leave it off (the default) and this never happens.

"Keep finished videos briefly in the cloud" (optional, off by default). The same trade-off applies to generated video, for a different reason. A finished video is sent to your device once; if the app closes or loses its connection at that moment, the video is lost — and because generating it has already been charged, you would be paying for something you never receive. You can turn on Keep finished videos briefly in the cloud in Security settings. When it is on, we keep the finished video on our servers briefly, in plaintext — held in short-lived memory (Redis), never written to our main database or file storage, automatically deleted within about an hour, and deleted as soon as any of your devices has retrieved it, encrypted it, and saved it. We do not describe it as encrypted. Leave it off (the default) and this never happens.

Those two settings — "Finish replies in the cloud" and "Keep finished videos briefly in the cloud" — are the only settings under which a piece of your content rests on our servers in a readable form, and in each case only for that short recovery window. Both are off unless you turn them on.

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 built on Intel TDX with confidential GPU compute; models we route through Tinfoil run inside secure enclaves built on AMD SEV-SNP with confidential GPU compute; models we route through Phala run inside its own Intel TDX enclaves with confidential GPU compute, and your client encrypts the request to the attested enclave so that our relay cannot read it either. In every case 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.

Music generation — the one exception to the two guarantees above. The Audio studio's Music mode is the single feature where neither protection is available, and we would rather say so here than let the paragraph above imply otherwise. Music generation is served by Google's Lyria models through OpenRouter, and by a number of music models hosted on fal.ai. No music model on any provider we can reach offers a zero-retention endpoint or a confidential-compute option — so a music prompt reaches whichever provider serves the model you chose under that provider's ordinary terms, and that provider may retain it. Because there is no compliant model to fall back to, turning on Require Zero Data Retention does not restrict Music mode the way it restricts every other kind of model selection; if it did, the feature would simply be unavailable to you rather than more private. Two things apply instead. First, we send music prompts unattributed: the request carries no account identifier, no chat, and no conversation history — only the description you typed — so a prompt the provider retains is not linked by us to your account. That holds for every music model we offer, on either provider. Second, the Music composer states this plainly on screen every time you use it, above the button that generates. Everything downstream is unchanged: a track you save is encrypted on your device like any other file, and the prompt is stored only inside that encrypted envelope. If a zero-retention or confidential music model becomes available, we will move Music mode onto it and this exception will end.

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 the speech-to-text service of the voice model you selected — OpenRouter's, or Tinfoil's for confidential voice models — 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 the corresponding 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 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 and confidential-compute protections described above: ZDR routing applies wherever the chosen voice models support it, and voice models served by Tinfoil are transcribed and synthesized entirely inside its secure enclaves. Voice chat is a paid feature (see our Terms of Service).

Web search. Web search is off unless you turn it on. When it is on, answering a prompt may require looking something up on the live web, which means sending a search query — text derived from your prompt — to a third-party search service. Depending on the model and configuration, that search is performed in one of two ways: by Brave Search (operated by Brave Software, Inc.), to which we send only the short search query string and never your full conversation or attachments; or by OpenRouter's built-in web plugin, in which case OpenRouter performs the search as part of serving the model you selected. As with any inference, a web-search query reaches the search provider in the clear so it can be processed, and it is part of the transient inference window — we do not write it to our database.

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

For more, see OpenRouter's Privacy Policy at https://openrouter.ai/privacy, NEAR AI's published terms at https://near.ai, Tinfoil's Privacy Policy at https://tinfoil.sh/privacy, Phala's Privacy Policy at https://phala.network/privacy, fal.ai's Privacy Policy at https://fal.ai/privacy, and Brave Search's Privacy Policy at https://brave.com/privacy/browser/.

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. The Browser Extension

Privateer also ships as a browser extension: a side panel that signs into the same account, answers questions about the page you are looking at, and — only if you turn it on — acts on that page for you. It is the same account and the same encryption as the app, but it can see something the app cannot, so this section says exactly what and when.

Nothing is read until you attach a page. The extension installs with no access to the pages you visit. When you attach a tab, your browser asks you to grant that one website, and only then can the extension read it. Every site you have granted is listed in the extension's Account screen and can be revoked there, or in your browser's own extension settings. We never receive a list of the sites you visit, your browsing history, your bookmarks, or the content of any page you have not attached.

What leaves your device when you ask a question about a page. The page's visible text, and a structural description of it — element types, positions, colours, link and image URLs — are sent with your message through our server to the inference provider serving the model you chose. This is the same inference window described in Section 4, with the same protections and the same honest limit: it is plaintext at that moment, routed to a zero-data-retention or confidential-compute model where one is available, not written to our database, and not retained by us. Two things are deliberately excluded before anything is sent: the contents of password fields, which are never read even when the extension is describing a page it has been granted, and any page you have not attached.

Acting on a page. Reading a page you have attached happens on its own — attaching it is the permission. Anything that changes a page — clicking, typing, scrolling, navigating — asks you to approve it, every time, and shows you what it is about to do. There is no per-site "always allow". You can lower that gate for a single browser session if you want a long task to run unattended; while it is lowered a warning stays on screen, every action is still listed, and closing your browser raises it again. Turning page control off entirely blocks every change regardless.

Rebuilding a page. You can ask the extension to rebuild a page you have attached as a saved artifact. What is sent to the model is the description above, never the original page's code, and what comes back is a new document written by the model — a reconstruction, not a copy. It is encrypted on your device before it is stored, like anything else in your account. The extension refuses to save a rebuilt page that asks for a password or card details.

Signing in with a wallet. Wallet extensions can only present themselves to ordinary web pages, not to another extension's panel, so wallet sign-in opens a Privateer page to collect your signature. That page is always ours (privateer.pro) and never the site you happen to be on. The signature derives your key locally, exactly as described in Section 3.

What is stored. Conversations you have in the extension are ordinary account chats: encrypted on your device under your master key before they reach us, and readable in the app afterwards. The list of sites you have granted is held by your browser, not by us.

7. 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).

8. Warrant Canary

As of August 6, 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.

9. Data Sharing

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

Transmitting inference requests to our inference providers — OpenRouter, NEAR AI Cloud, Tinfoil, Phala, and fal.ai (Section 4).
Transmitting a web-search query to Brave Search when you enable the optional web-search feature — only the search query string, never your full conversation (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).

10. 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 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 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.

11. 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.

12. Children's Privacy

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

13. 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.

14. Contact

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

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