Designed so we couldn't sell your data even if we wanted to.

Our principles

Three rules that nothing in the product is allowed to violate. If a feature would require breaking one, we don't ship the feature.

1. Your data is yours. We hold it on your behalf. We do not own it, sell it, or use it for our benefit.
2. Read-only by default. Connectors request the minimum scope to read what you want remembered, never to write or delete.
3. Architectural privacy beats policy privacy. Where we can encrypt instead of promise, we encrypt. Promises drift; math doesn't.

Data we store

Three classes — each handled differently:

• Account metadata. Email, billing, auth tokens. Standard SaaS stuff. Encrypted at rest.
• Source data projections. Structured records derived from your connectors (a parsed Tesla service event, an inbox thread, a statement line item). Encrypted at rest with KMS-managed keys; isolated per workspace.
• Original attachments. The actual PDFs, images, voice notes you let us ingest. Stored in object storage, encrypted at rest, and access-gated to your account.

Encryption

AES-256 at rest, TLS 1.3 in transit. Each user has a per-account encryption key, derived from a server-side master and a per-user salt. Keys are rotated quarterly and on any access-control event.

We're rolling out client-side encryption for sensitive record classes (financial statements first) so the server never sees plaintext for those classes. That's a 2026 H2 item — current status is on the changelog.

Per-user isolation

Your data lives in storage primitives that are physically and logically separated from every other Lossless user's. There is no shared table, bucket, or namespace where a software bug, a misrouted query, or a stolen credential could cause data to leak across accounts. The blast radius of any incident is bounded to a single account.

• Vector database — unique, isolated namespace per user. Each user gets a dedicated namespace in the vector store (Pinecone). Embeddings, RAG retrieval, and similarity search are hard-scoped to your namespace; cross-namespace queries are rejected at the API boundary, not just filtered in application code.
• Object storage — unique, isolated GCS bucket per user. Original files (PDFs, images, voice notes, statement attachments, screenshots) live in your own Google Cloud Storage bucket. Bucket names are randomized, access is scoped to a per-user service account, and cross-bucket access is forbidden at the IAM layer — not just by application logic.
• SQL + entity graph — row isolation tied to your identity. Your typed records, account metadata, and entity graph live in the same Postgres database, with row isolation enforced through a hard user_id predicate carried on every query. The entity graph is stored alongside the records (not in a separate engine) so every relationship inherits the same row-level enforcement. We are currently rolling out Postgres Row-Level Security so the database itself — not just the application — refuses a row tagged for anyone else; until that ships, the parameterized-query discipline and per-blueprint code review are the load-bearing controls.

This pattern is enforced at three layers — IAM (the cloud provider rejects cross-tenant access for Pinecone and GCS), the application (every Postgres query parameterized by user_id), and engine-level Row-Level Security (rolling out across the SQL surface) — so a failure at any single layer doesn't expose another user's data.

Who can access it

Inside the company, almost no one. Engineering access to production data requires a signed access ticket tied to a specific support case, expires in 24 hours, and is logged in an append-only audit log that you can request a copy of at any time. We had 0 such tickets in Q1 2026.

Model training

Lossless does not train shared models on your data. The reasoning models we use (Anthropic, OpenAI, and a handful of self-hosted open-weight models) are called via APIs that contractually exclude the request from their training set. We re-verify the contracts annually.

We will never offer a "share your data to improve the AI" option. Your data only serves you. If a future feature needs aggregated patterns, it will be built on synthetic data we generate ourselves.

Permissions, per source

Every connection has a per-source permission sheet. You see the exact OAuth scopes we request before authorizing, and a runtime permissions panel that lets you toggle data classes off — retroactively. Toggling a class off purges what was ingested under that grant.

Retention & deletion

• Pro / Household: data is kept for as long as your account is active.
• Free: memory history capped at 90 days, on a rolling window.
• Account deletion: a single click. Data is purged from primary storage within 24 hours and from backups within 30 days. We send you a written confirmation when both stages complete.

Subprocessors

Full list at /legal/subprocessors, kept current. The short version:

• Cloud: Google Cloud (US-WEST1, EU-WEST3) and AWS for object storage.
• Auth: WorkOS for SSO, Stytch for passkeys.
• Payments: Stripe.
• AI inference: Anthropic, OpenAI (zero-retention API tier on both).
• Email: Postmark for transactional, no marketing tracker pixels.

Adding a subprocessor requires a privacy review and 30 days' notice to active customers.

If we shut down

If Lossless is acquired, the acquirer must honor all existing privacy terms or you get a 90-day window to export and delete. If Lossless wound down, we publish a frozen self-hosted version of the export tool, signed and verifiable, so you can pull your data with a static script even after our servers go away.

DPA & legal documents

Available without sales contact:

• Data Processing Addendum (PDF)
• Subprocessors list
• SOC 2 Type I report (NDA); Type II in progress
• Privacy policy

If your security team needs something we haven't published, email security@lossless-ai.com. Most requests get a real human reply within one business day.