Privacy and security
What Remly stores, how it is protected, who can reach it, and what is not settled yet.
Last verified: 31 July 2026
This page describes what the product does today. Where a control is deployment-dependent or not finalized, it says so rather than rounding up to a stronger claim.
Where your data lives
| Data | Where |
|---|---|
| Original local file binaries | On your Mac. Not stored in Remly's tenant index. |
| Local derived data – text chunks, embeddings, metadata | Your choice per folder: local-only on your Mac, or synced to Remly's cloud. |
| Cloud-indexed content | Remly's cloud database, as derived chunks, embeddings, and metadata. |
| Provider credentials | Remly's cloud database, encrypted server-side. |
| Your activity – searches, Ask conversations | Stored against your account. |
Isolation between accounts
Tenant isolation is enforced by row-level security policies for the restricted application role, verified by adversarial cross-tenant testing.
That testing attempted cross-tenant reads through search, Ask, MCP, and raw SQL against a schema-identical environment, and found none, with a passing positive control confirming the test itself would have caught a leak. The database role used was confirmed to be neither a superuser nor able to bypass row-level security.
Every query also resolves your identity server-side and filters results to what your account is entitled to.
It has not yet been confirmed that the production connection uses that restricted role. This page therefore claims what was verified – the policies and the testing – and does not claim that row-level security is active in production.
Sharing and ACLs
Retrieval supports user-level and workspace-level access paths. Group sharing is not a current feature – Remly is single-user today, and team support is planned.
Access snapshots are taken from the source at index time and applied at query time. Between a permission change at the provider and that source's next sync, results can reflect the older snapshot. The same filter applies to Search, Ask, and MCP.
Credentials and encryption
Provider credentials are encrypted at the application level before storage. Plaintext is held only in memory inside a request handler or sync job, sent to the provider in an Authorization header, and never returned in a response body. OAuth state and PKCE verifiers stay server-side.
Not every connector uses OAuth: Granola uses a provider token, and the Mac app uses device pairing with its own device token. Both are stored the same encrypted way.
The application-level encryption claim above covers provider credentials and tokens. Database and disk encryption are provided by the underlying infrastructure; those are not described in detail here because they have not been separately verified for this documentation.
Traffic is encrypted in transit over TLS: browser to API, API to provider APIs, Mac app to API, and API to database. The Mac app talks only to the Remly API and never connects directly to the database.
Local files and OCR
Original local file binaries are not stored in Remly's tenant index. If you opt a folder into cloud sync, derived text, embeddings, and metadata are uploaded. Image pixels may transit /api/image-extract and may be sent to OpenAI for OCR.
If you do not want image content processed off-device, keep image-heavy folders Local only. Nothing from a local-only folder is uploaded.
The text OCR returns is treated like any other indexed content. It is deleted when you disconnect the connector it came from, and at the 30-day purge when you delete your account.
AI training
Remly does not send your content to be used as training data for model providers. What that guarantee rests on is the provider contracts and configuration in place at any given time.
A precise, contract-backed statement of each provider's data-handling terms – including OpenAI's, for OCR and for answer generation – has not been finalized for publication. Until it is, this page states the intent and the mechanism rather than a legal commitment. Ask team@remly.it if you need something you can rely on contractually.
Your activity and who can see it
Your searches and Ask conversations are not exposed through normal product views to anyone else, including an organization admin. There is no admin screen for reading another person's search history or conversations.
That is a statement about the product surface, not a claim that no operator can ever reach a database row. Staff access to production is restricted to incident debugging, Remly does not bulk-export user content, and nobody browses your indexed files as a matter of course.
Access logging for production data access is a control we are putting in place, not one this page can date as fully deployed. It is listed here as planned so you are not led to assume otherwise.
MCP exposure
MCP access is scoped to your organisation and to your own document permissions – a client sees exactly what you can already see, and nothing beyond it. Within that boundary, a connected client can search and open any document in your own indexed knowledge base. There is no per-source or read-only limit yet, so only connect clients you trust. See the MCP overview.
Deletion and retention
Deleting your account freezes it immediately, cancels billing, and schedules permanent deletion 30 days later. Your content still exists during those 30 days and the deletion can be undone by resubscribing. At day 30 the purge permanently removes documents, text chunks, embeddings, permissions, conversations, messages, search history, and text extracted from your images. That list is exhaustive: nothing derived from your content survives it.
Disconnecting a single connector is a different path: it deletes that connector's content immediately, with no recovery window.
The only thing retained is a content-free record that an account existed and was deleted. Its email address is erased after 90 days.
Full detail is in account lifecycle.
Data export
Self-service export is not implemented. See account lifecycle.
Not yet documented
These are open, and we would rather say so than publish something you might rely on:
- Data residency – the hosting region for production data is not published here.
- Subprocessors – a published subprocessor list does not exist yet.
- Provider data-handling terms – see the AI training note above.
- Incident contact and response commitments – not published.
- Production database role – whether the production connection uses the restricted, row-level-security-bound role is not yet confirmed.
Email team@remly.it if you need any of these before they are published.
Compliance
Remly holds no formal certification. SOC 2 is on the roadmap; there is no ISO 27001 certification. Account deletion works today; GDPR-style self-service export does not.
Remly is not HIPAA compliant and must not be used for protected health information.