Security and data at reph

§At a glance

• Encryption in transitYesTLS on every hostname, HSTS for one year.
• Stored secrets encryptedYesAES-256-GCM envelope encryption for the keys and passwords you give us.
• Role-based accessYesWorkspace and document roles. New personal documents are private.
• Workspace audit logYesAdmins can view their workspace's events and download them as CSV.
• Audit streaming to a SIEMPartialA hash-chained export exists per deployment, not per workspace.
• Export your account and documentsYesSelf-serve, from your profile.
• Self-serve account deletionYesYour audit entries are renamed, not deleted.
• BackupsYesHourly, with an off-server copy in a second Azure US region.
• reph trains models on your contentNoThe AI provider's own terms govern what it does with requests.
• SSO (SAML / OIDC)Not yetSign-in is email link or code, Google or GitHub.
• SCIM provisioningNot yetMembers are invited and removed by hand.
• Choice of data regionNot yetPrimary hosting and off-server backups are in Azure US regions.
• SOC 2 / ISO 27001Not yetNo audit has been done.
• Third-party penetration testNot yetReviews so far are internal.
• Uptime SLA / status pageNot yetreph is in pilot, provided as-is.
• Self-hostingYesThe product runs from one repository with Docker Compose.

§Hosting and data location

• Primary hosting: the hosted service runs on one Microsoft Azure virtual machine in an Azure US region (East US). The database and uploaded files live on that machine's disk. There is no CDN and no separate data warehouse.
• Off-server backups go to Azure Blob Storage in Central US, which Azure keeps geo-redundant with a second copy in East US 2. The storage account has no public access and requires TLS 1.2.
• Operator copy: the operator also keeps an access-controlled backup copy on an operator workstation.
• No region choice: there is no EU or other regional option today. Self-hosting puts the data wherever you run it.
• Disk encryption: Azure encrypts managed disks and Blob Storage at rest by default with Microsoft-managed keys. That is an Azure platform default, not something reph adds. reph adds its own encryption for secrets (below), not for document text.
• Running reph yourself? Then hosting, backups, subprocessors and the security contact are whatever you set up. The rest of this page describes the code, which is the same. The bundled /.well-known/security.txt names the hosted service; replace it with your own.

§Encryption

• In transit: every hostname (app, API, realtime, published sites on custom domains) is served over HTTPS by Caddy with automatically issued certificates. HTTP redirects to HTTPS. The app, API and realtime hostnames send Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Sealed secrets: each is encrypted with its own random 256-bit key (AES-256-GCM), and that key is wrapped by a master key kept in server configuration, outside the database. The ciphertext is bound to its workspace (a Google Drive token to its person), so a value copied into another row fails to decrypt. Sealed: workspace AI keys, git credentials, data-source keys, Google Drive tokens, webhook signing secrets, WordPress application passwords, external agent keys, and newsletter subscriber and report recipient addresses.
• Hashed: sign-in links and codes, session refresh tokens, API tokens (including MCP connector tokens) and export download tickets are stored only as SHA-256 hashes.
• Stored as-is: some capability links must be shown or used, so they are kept in plain form: workspace feed keys, newsletter reader links, and webhook and Google Sheets URLs as entered. An admin can rotate a feed key or change a URL.
• Shown once: a webhook signing secret is shown in full when created or rolled, then only its last few characters. Stored keys are never written to logs.
• Not yet: the master key is not held in a hardware security module (Azure Key Vault), and customer-managed keys are not offered.

§Sign-in and sessions

• No passwords. You sign in with an emailed link or 6-digit code, or with Google or GitHub.
• Email sign-in is valid for 15 minutes and works once. A code allows 5 attempts per request and 30 wrong codes per mailbox in 24 hours.
• Sessions: access tokens last 15 minutes. Refresh tokens last 30 days and are replaced on every use; presenting a replaced one again after a short grace window revokes the whole session family.
• Not yet: SAML or OIDC single sign-on, enforced MFA, idle-session timeouts and IP allowlists. Google and GitHub sign-in carry whatever MFA those accounts enforce.

§Access control

• Workspace roles: admin, member, viewer. Document roles: owner, editor, commenter, viewer. The strongest role that applies wins.
• Private by default: a new personal document opens only for its owner and people explicitly invited. Link sharing is opt-in. A workspace document is open to its workspace at the role set on that document (editor unless changed), or can be restricted.
• Revocation is live: removing someone's access closes their open editing session at once.
• Publishing is limited to the document owner and workspace admins unless an admin opens it to editors.
• Deleting moves a document to Trash, where it stays restorable for 30 days unless its owner deletes it forever sooner. Deleting a workspace (owner-only, with the workspace name typed to confirm) permanently deletes all its documents at once.
• Not yet: workspace policies that switch off public links or publishing, domain claiming, and guest expiry.

§API tokens and AI agents

• Scoped tokens: API tokens carry one scope, read, suggest or edit, which is a hard ceiling on the API and on the realtime connection. A token can be pinned to one workspace and is revoked when that membership ends.
• Suggest means suggest: an agent with a suggest token cannot change a document. Its edits arrive as suggestions a person accepts or rejects, and each decision is audited.
• Containment is logged: agents reach only an allowlist of routes. A refused attempt is recorded as agent.denied. Sending, inviting, billing and other person-only actions are never open to agents.
• MCP connector (claude.ai and other MCP clients): sign-in is OAuth 2.1 with PKCE (S256), and the token it issues is an ordinary API token. Revoking it in Profile → API tokens disconnects the client.

§AI

• reph does not train models on your content. reph has no model of its own and no training pipeline, and does not sell your content or share it beyond the subprocessors below.
• Where AI requests go: what the AI provider does with requests is governed by its own terms. The operator chooses a provider (an OpenAI-compatible API), and you can bring your own key. Requests are sent only when someone runs an AI feature, carrying the text that feature needs.
• Whose key: each workspace picks a policy. An admin stores one workspace key (sealed as above), or members bring their own key, which is kept in their browser and sent with their own requests, never stored on reph's servers, or the workspace uses reph's metered key.
• Suggestions, not overwrites: drafts from data, rewrites for an audience and data refreshes land as suggestions someone accepts, or as new documents. A translation creates a copy and never changes the original. Text you ask for in the editor is inserted where you asked, as your own edit.
• Not yet: a choice of provider per workspace, zero-retention provider guarantees, and a separate AI usage log.

§Audit log

• What workspace admins see: their workspace's document, sharing, publishing, membership and role, workspace token, suggestion, ownership transfer and refused-agent events, in the app and as a CSV download. Each row names the actor (person, agent or system) and the time.
• Sign-ins: sign-ins and failed sign-ins are recorded for the whole service and visible to the service operator, not to workspace admins.
• Per document: a document's owner can see that document's audit history.
• Off-site copy: a deployment can ship every audit row, append-only and hash-chained, to a file or Azure Blob Storage, with email addresses replaced by keyed hashes. A script verifies the chain. It is off by default and runs per deployment.
• Account deletion renames the actor to "deleted user" on the entries you made; the entries stay. Some entries, such as failed sign-ins or invites, may still contain an email address.
• Not yet: member sign-in history for workspace admins, an audit API or streaming for a workspace's own SIEM, and a configurable audit retention period.

§Your data

• Your content is yours. Documents are plain Markdown.
• Export: from your profile, download your profile, memberships and audit entries as JSON, and every document you own (optionally the ones shared with you) as a .zip with comments, recent versions and files.
• Deletion: deleting your account purges your personal documents and sessions and renames you on your audit entries. Documents in a workspace stay with the workspace.
• Backups: the database is snapshotted every hour. The server keeps 24 hourly and 7 daily snapshots. The off-server copy keeps hourly copies for 7 days and daily copies for 90 days, plus 14 days of soft delete, so deleted data leaves the Azure backups within 105 days. The operator copy keeps 30 days. Restoring from the on-server snapshots is scripted and has been drilled.
• Downgrades never delete data.

§Published pages and the app

• Published pages run no script. /p/ pages and docs sites send a Content-Security-Policy with default-src 'none' and script-src 'none'. The only exception is the embed version of a page, which allows one fixed script by its hash to size its frame.
• Author HTML is filtered to an allowlist of tags, with no style, class, id or event attributes.
• The app sends a CSP with frame-ancestors 'none', X-Frame-Options: DENY and nosniff.
• Custom domains serve only the published site. The API and sign-in are unreachable on them.

§Analytics and tracking

• No third-party analytics, ad trackers or session replay. The app loads no third-party scripts or fonts. The one exception is Google's file picker, loaded only when someone links a Google Drive file. The app's CSP still lists Google Fonts and esm.sh, though nothing loads from them.
• Images a document embeds from another website load from that website.
• First-party events (page views, sign-ups, feature use) are stored in reph's own database. Funnel events carry where the visitor first arrived from (a link's ref or utm tag, or the referring site), remembered in the browser's local storage for 30 days. No cookie is set for it.
• Reader counts on published pages store no IP address, cookie or raw user agent. A visitor is a hash under a salt that is deleted each day.

§Rate limits and outbound requests

• Rate limits apply per route class on the API (sign-in, email, AI, writes, exports and more), plus a per-IP limit of 600 requests a minute on the API at the edge. The MCP endpoint is limited per token instead.
• Outbound requests to addresses customers enter go through checks that refuse private and internal addresses. Webhooks, JSON data sources, external agents and WordPress share one guard that follows no redirects and has a hard deadline. Google Sheets sources only reach Google's hosts.
• Logs are structured and redact tokens and sign-in links.

§Subprocessors

Services that handle customer data for the hosted service. Several are used only when a feature is switched on or you choose them.

• Microsoft Azurealways

  Hosting (virtual machine) and off-server backups (Blob Storage), in Azure US regions. All customer data.

• The operator's SMTP email provideralways

  Sends sign-in links and codes, invites, notifications and messages from the operator. Recipient address and message.

• The OpenAI-compatible provider the operator configureswhen AI is used

  Runs AI features. The text the feature works on.

• Stripewhen paid plans are on

  Payments. Card details are entered on Stripe's pages and never reach reph.

• Googlewhen you choose it

  Sign-in with Google. Google Drive sync only when an operator enables it and you link a file.

• GitHubwhen you choose it

  Sign-in with GitHub. Git import and proposing changes only when you connect a repository.

• Newsletter delivery (SMTP or Resend)when newsletters are on

  Sends a workspace's newsletters. Subscriber address and message.

§Not yet

None of these exist today and none is scheduled. If one blocks your review, tell us; that is how they get prioritized.

• SAML / OIDC single sign-on with enforcement, and domain claiming
• SCIM provisioning and deprovisioning
• SOC 2 Type II or ISO 27001
• A third-party penetration test
• An uptime SLA and a public status page
• A choice of data region (EU, India)
• Customer-managed keys, or a master key held in an HSM
• Workspace policies that switch off public links or publishing
• Member sign-in history for workspace admins
• A tested restore from the off-server backup copy
• A signed data processing agreement (DPA)

§Report a vulnerability

Found a security issue? Contact us with the details. We'll reply, fix it promptly and credit you if you'd like. We won't pursue anyone who reports in good faith, tests only against their own account and data, and gives us time to fix before telling others. There is no paid bug bounty. Machine-readable contact details are in /.well-known/security.txt.

Terms, privacy and payments are on the legal page.