Here is how we protect your library.
What we protect, how we do it, and what is not finished yet.
Last updated 2026-08-23
Four stops, with explicit boundaries
Your device
You choose what to add and what context to send in a request.
In transit
TLS with HSTS on everything, in both directions.
XESO
Encrypted at rest; personal-data routes apply application-layer owner checks.
Model provider
Receives the context needed for a request. XESO does not use that content to train or evaluate models; provider handling follows the active account terms.
Sensitive-folder setup is unavailable while its ciphertext-only storage path is rebuilt and independently verified.
Current individual-account security scope
These statements describe the current individual release. Shared-workspace controls are not claimed here while their Trust Gate remains open.
Passwordless sign-in, passkey (WebAuthn) step-up before sensitive actions, and session revocation that takes effect within 60 seconds.
Session security: revocation mechanics
Every session carries a unique ID and a version. Revoking access adds the ID to a deny-list and bumps the session version; live sessions re-check on a short interval and are cut within 60 seconds. Minting or revoking API tokens, changing security settings, and deleting data additionally require a fresh passkey step-up.
The public app uses TLS with HSTS; storage is encrypted at rest; stored connector credentials carry an extra owner-bound encryption layer.
Credential encryption: owner-bound
OAuth tokens and stored connector credentials are encrypted with AES-256-GCM using authenticated data bound to the owning account, with key material held in a managed secret store, so a ciphertext copied between rows fails to decrypt. Database storage is encrypted at rest by the cloud provider.
New sensitive-folder setup is unavailable while the ciphertext-only storage path is rebuilt and independently verified.
Sensitive-folder encryption: release status
We do not present the current protected-folder label as end-to-end encryption. New setup is disabled until existing-note migration, ciphertext-only writes, recovery, key rotation, and the unlock-token threat model all pass independent verification. Existing protected folders remain excluded from derived surfaces while remediation is completed.
We use one model provider. Here is why, and what happens if it goes down
- XESO does not use customer content to train, fine-tune, distill, or evaluate AI models. AI requests are processed by our model provider under the data-protection terms in our DPA and subprocessor commitments.
- Provider-agnostic architecture with a single swap seam, gated by our grounding evals: any model change must re-pass the same citation and grounding thresholds before it ships.
- Search and your library remain available during any AI-provider outage. Reading, browsing, and search never touch the generation path.
- During an outage, AI answers fail loudly, not silently. Chat and research return a clear error state; new captures are saved so note generation can be retried; background enrichment retries on its own, and search falls back to keyword matching until embeddings resume.
- There is deliberately no automatic failover between AI providers. Our citation-coverage floor and grounding evals are calibrated per model. Silently swapping models mid-conversation would degrade exactly the thing we sell, so a provider change is a considered, eval-gated event rather than an invisible one.
What is done, and what is still in progress
No row below claims an audit we haven't completed. When a status changes, this page and its date change with it.
| Item | Status | What is true today |
|---|---|---|
| SOC 2 Type II | In preparation | Control mapping is complete and evidence collection is under way. No audit report exists yet, and we won't imply one does. |
| External penetration test | Scheduled | Scope and vendor brief are prepared. We don't publish target dates; a results summary will be available to customers under NDA once complete. |
| GDPR posture | Live | GDPR-aligned DPA, self-serve export and deletion from Settings, and the rights described in our privacy policy. What you can always take with you is written down in the portability covenant. |
| Data hosting | US-hosted | Production runs in US Google Cloud regions today. EU data residency is on the roadmap; it is not offered yet. |
| Reliability | Live status | We target 99.9% availability, run automated backups with point-in-time recovery, and publish incidents on our status page. During an AI-provider outage your library and search stay available; only generated answers pause. |
Which vendors can touch your data?
The list of what each vendor processes and why is public and maintained on its own page, so it has one source of truth instead of a copy here that could drift.
Start your review from our answers
We maintain a two-page vendor security overview: architecture, authentication and authorization, encryption, isolation posture, current logging, data lifecycle, and AI-provider posture, assembled from the same verified facts as this page, plus a longer pre-answered questionnaire in SIG-Lite/CAIQ style for teams that need the full spreadsheet.
- The overview is delivered by email today; its source of truth lives in our repository at
docs/security/questionnaire/SECURITY_OVERVIEW.md, so the document and the code are reviewed together. - Custom questionnaires: send yours and we'll return it completed; honestly, including the rows where the answer is "in progress."
Found something? Tell us safely.
Scope: the production services at xeso.ai and its subdomains. Please stay out of other people's data; use test accounts you control, and stop at the minimum proof a vulnerability exists.
- How to report: email security@xeso.ai with steps to reproduce. We aim to acknowledge within two business days and keep you informed through the fix.
- Safe harbor, in plain terms: if you research in good faith within this scope; no accessing or modifying data that isn't yours beyond a minimal proof, no degrading the service, no social engineering of our users or staff, and reasonable time for us to fix before you publish. We will not pursue legal action against you for that research.
- Rewards: we don't run a paid bounty program today. We do fix what you find, and we credit reporters who want credit.
- Machine-readable: this policy is referenced from
/.well-known/security.txt(RFC 9116).
Everything we publish
Questions for procurement or security review? Email security@xeso.ai. A human answers, usually within one business day.