Security
Private by proof, not promise. If you find a hole in that, we want to hear about it.
Email us directly. Please do not open a public issue, post the details on social media, or file it in an app store review before we have had a chance to fix it.
If that address bounces, use support@privateer.pro with "security" in the subject line.
What to include
- What the issue is, and what an attacker gets out of it.
- Steps to reproduce it. A short proof of concept is worth more than a long description.
- Which surface it affects (web, Android, desktop, the CLI agent, the browser extension, the API) and the version or build you tested.
- Whether you have shared it with anyone else, or intend to.
Automated scanner output pasted without analysis is not a report, and we will not respond to it.
What we commit to
We will acknowledge you within 3 business days.
Privateer is a small team, so we would rather promise something we can keep than something that sounds better. If you have not heard back in 3 business days, send a follow-up.
We will tell you what we decided, and why.
Including when we decide something is not a vulnerability. You will get a reason rather than silence.
We will credit you if you want credit.
Named on this page, or anonymous, or not mentioned at all. Your call, and we will ask before publishing anything.
We do not currently pay bounties.
We are an independent project and would rather say so plainly than run a programme we cannot fund. That may change. It has no effect on how seriously a report is treated.
Safe harbour
If you make a good-faith effort to follow this policy, we will treat your research as authorised, we will not pursue or support legal action against you, and we will help make that position clear to anyone who asks.
Good faith means: use only accounts you own or have permission to test, stop as soon as you have confirmed a finding, do not access, modify, download or retain anyone else's data, do not degrade the service for other people, and give us reasonable time to fix the issue before telling anyone else.
Scope
In scope
privateer.pro and its subdomains, the Privateer API, the web app, the Android app, the desktop app (macOS and Windows), the browser side panel, the privateer-agent CLI and the packages we publish to npm, and Harbor.
Out of scope
Vulnerabilities in third-party services we depend on (report those to their owners, and tell us so we can track it). Volumetric denial of service. Social engineering of our team, our users, or our vendors. Physical attacks. Findings that require a rooted, jailbroken or already-compromised device. Missing hardening headers or weak TLS configuration with no demonstrated impact. Self-XSS. Reports based only on software version numbers.
Especially interesting to us
Anything that lets one account reach another account's data. Anything that causes content to be stored unencrypted, or a key to leave the device that derives it. Anything that makes an agent take an action outside its approval gate, or that gets a prompt or a page to arm a permission the user did not grant. Anything that lets a request bypass zero-data-retention routing.
Disclosure
We work to a 90 day coordinated disclosure window. Publish after 90 days from your report, or earlier once we confirm a fix has shipped, whichever comes first. If a fix is genuinely going to take longer, we will come and ask you rather than let the clock run out quietly.
If a vulnerability is being actively exploited, we will say so publicly and quickly rather than wait for a tidy timeline.
How Privateer is built
The detail lives in the Privacy Policy. The short version, so you know what is worth attacking:
- Content is encrypted on your device or in our cloud, with inference on hardware-attested enclaves. Encrypted content is stored as ciphertext under a key we do not hold.
- Chat inference runs with zero data retention, and ZDR routing fails loudly rather than quietly falling back.
- Confidential models run inside hardware enclaves (Intel TDX, NVIDIA Confidential Computing, AMD SEV-SNP). The app marks a model verified only where the client itself checks the attestation, never on our say-so.
- There is no password recovery, by design. The encryption key derives from your password or wallet, so losing it means losing access to the encrypted data.
- Operational metadata (timestamps, model IDs, token counts, cost) is stored in plaintext because billing and abuse prevention need it. Message content is not.
Our sub-processors and retention periods are listed in the Privacy Policy, sections 9 and 10.
Credits
No reports yet. Researchers who report an issue and want to be named will be listed here.