Security, stated plainly.
What we protect, how we protect it, and what is still in progress — written to survive a procurement review, not to win one.
Last updated 2026-07-06
The controls that are live today
Each claim opens its receipt — the same way answers work inside the product.
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.
TLS with HSTS for everything in transit; storage encrypted at rest; connector and API credentials carry an extra layer of AES-256-GCM encryption bound to their owner.
Credential encryption — owner-bound
OAuth tokens and API 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.
Any folder can become a vault: notes are encrypted in your browser before they reach us, and we store ciphertext we cannot read.
Client-side vault — including what it costs you
The vault key is derived from your passphrase in the browser (Argon2id); the server stores only ciphertext and a verification value, never the passphrase or the key. Vaulted notes are excluded from AI answers, digests, analytics, and sharing. The trade is real: there is no recovery path today — if you lose the passphrase, we cannot decrypt those folders for you.
Workspaces enforce five roles and seventeen capabilities in code, and every administrative change lands in a hash-chained audit log you can export.
Audit log — tamper-evident by construction
Each audit event embeds the hash of the event before it, so the exported log can be verified independently: editing or deleting an entry breaks the chain. Role checks run on every workspace mutation before it executes, and denials are logged too.
Tenant isolation is enforced by explicit user-scoped predicates on every query at the application layer, backed by regression tests in CI.
Isolation posture — what is live and what is in progress
Every query that touches user data carries an explicit owner predicate, and CI fails if a new data path ships without one. Postgres row-level security exists in our schema but is not yet enforcing on the core user tables in production — database-level enforcement is a tracked hardening program, and we will not advertise it until it is live and proven. Workspace content isolation (personal libraries staying personal) is covered by integration tests against a real database.
One model provider, on purpose — and what happens if it goes down
- We don't train models on your content. 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.
- No automatic failover between AI providers — deliberately. 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.
Where we are, without the badge inflation
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. |
| 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. |
Every vendor that can touch customer data, listed
The list — 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, audit 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.aiand 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 procurement asks for, one click each
Questions for procurement or security review? Email security@xeso.ai — a human answers, usually within one business day.