security
Repos, socials, documents, recordings — the product only works if it sees the genuine thing. These are the guarantees that make that reasonable, stated plainly.
Every query is scoped to your workspace in the application, and the database enforces the same boundary again with row-level security policies. Two independent layers have to fail before anyone else’s query touches your rows.
All traffic runs over TLS. Data lives in managed Postgres with encryption at rest, and media in managed object storage with the same.
Drafts are generated with foundation models accessed through AWS Bedrock, which does not use your content to train models. Neither do we. What ReadyToEdit learns from your edits is stored inside your workspace and applied only to your drafts.
Social and repository connections are read-only. ReadyToEdit ingests what you shipped and posted; it never posts, pushes, or publishes on your behalf. Nothing ships without your approval — that is the product’s whole design.
Sign-in and sessions are handled by Clerk. You can invite someone to a whole workspace or to a single project — an editor invited to one project sees that project.
Everything ingested is browsable and deletable from inside the app. If you leave, ask and we delete the workspace — there is no dark copy the delete button doesn’t reach.
ReadyToEdit is an early-stage product. We have not completed a SOC 2 audit yet, and we will not pretend otherwise with a borrowed badge. What you get today is the architecture above — isolation enforced in two layers, encryption by default, read-only connections, and no training on your content. As the company matures, formal certification follows, and this page will say so the day it is true.
Security questions, or something you need before connecting a private repo? Ask — you will get an answer from the person who wrote the isolation layer.