Everything on this page is shipped, documented, and open to review — the Windows client on GitHub, the server source available to customers on request. Where a protection has limits, we state them — that’s what makes the rest believable.
Guardrails and single sign-on need the licensed Enterprise Edition — guardrails because they are a group setting, and the Community Edition cannot reconfigure its one group. Everything else here — the audit trail, encryption at rest, end-to-end encryption, recovery and device revocation — runs on the free Community Edition too. See the comparison
A catalog of check rules you configure per group — and three decisions that stay with you: which rules are active, which model classifies every assistant request, and which protected model answers when a rule hits. Verdicts are cached so the check stays fast — and every decision lands in a log you can review.
Microsoft Entra ID single sign-on with a fully documented OAuth registration and login flow. SSO comes with the Enterprise Edition; the free Community Edition signs people in locally, with MFA and passkeys.
Structured events with filtering and retention — including login-anomaly detection that flags unusual sign-in patterns. Guardrail decisions sit alongside, with verdict, model and a hash of the judged content instead of the text: one place answers what happened and what the AI layer did about it — without reading along.
A master key, an AES-GCM wire format — and documentation that states the threat model, including what it does not protect against. We’d rather you know.
We select the providers behind Pia Cloud to be European companies processing in Europe (EEA and Switzerland), with a data-processing agreement in place for each. No US companies among our providers; the service providers they use in turn are listed on our sub-processor page. That is our procurement policy for Pia Cloud — self-hosting or your own provider key keeps the question in your hands entirely.
With end-to-end encryption on, the admin console shows what exists — devices, item counts, sync state — while synced content reaches the server, and its operator, only encrypted. Our server processes prompts to a Pia Cloud model the moment they arrive and does not store them; one of our model providers keeps them for 30 days to detect abuse. If you run the server yourself or use your own AI provider, those prompts never reach our server at all. That separation is documented and demonstrable: exactly what a works council or data-protection officer asks for. Data that arises on the server or runs it — accounts and sign-ins, logs, reports on AI answers, managed personas, policies, extensions, device details, trusted certificates — is not end-to-end encrypted, and neither is what sync itself needs, such as IDs, timestamps and order.
A recovery code lets encrypted data survive a lost or reset device. And the honest flip side: if the code is gone too, the data is unrecoverable — by design, because a backdoor for you would be a backdoor for everyone.
An enterprise policy file enforces defaults across managed installations — including how the assistant itself behaves — with rollout guidance for IT.
Every registered device is visible with its pairing status and sync cursors. A lost machine gets revoked — cut off from sync — without touching the account or the other devices. Delete it entirely when it’s truly gone.
Pods connect over a single inbound route with a narrow contract: what a pod can and cannot see is documented, and the operator plane is unreachable from chat.
Security questionnaires, DPO questions, threat-model deep dives — we answer them ourselves.