Security
Straight answers, before you connect a thing.
Every claim here was checked against the code that runs the platform, not written from memory. Where something is still on the way, it says so.
- AES-256-GCM at rest
- Isolated per workspace
- Least-privilege access
- We train no models on your data
- Enforced CSP + HSTS
- Card data never touches us
Verified against the running platform on 16 September 2026.
How it is built
Six things that protect your data.
Envelope encryption at rest
Every sensitive value — access tokens, the mail and calendar content you connect, documents, retrieval chunks, attachments — is sealed with authenticated AES-256-GCM before it reaches the database. A master key wraps a separate data key for each workspace, and the plaintext keys are wiped from memory once used. One tradeoff we would rather name than hide: so that keyword search works at all, a search index of the words in your content is stored alongside the encrypted text, and that index is not itself encrypted.
Tamper and wrong-key paths are covered by tests.
Isolated per workspace, and per person
Who you are and which workspace you are in is re-derived from your signed server session on every single request — never taken from the browser — and enforced in the database query itself. CEO Brain goes further: it is a private brain, scoped to both the workspace and the individual, so no colleague and no other customer can reach it.
Enforced at over 200 call sites, with isolation regression tests.
Least privilege, grant by grant
Each agent connects on its own separate grant and asks only for what its job actually needs, so no agent inherits another's access. Agents that only read are only ever given read access. The two whose job is to send email on your behalf — Procurement sending RFQs, Sales sending follow-ups — carry that Google send permission on their own grant alone. What they send was either approved by a person, message by message, or went out under an auto-send policy that is off until you switch it on and reaches only the suppliers or contacts on your list at the moment a message is queued. Switching it off stops any further automatic sends; a message already in its short sending window may still go out. The one exception is a pair of fixed, templated replies Procurement can send to a supplier already on file who emails you — asking for the details a quote is missing when a message does not read as a usable quote, or noting that a quote from them is already on record for that request, so the new email was not taken as another quote.
Five separate connection purposes, each with its own scope set.
Built for a world with prompt injection
On the paths that take in third-party content — product feedback, brand notes, briefs — that content is fenced and explicitly marked as data, not instructions, before a model sees it, so nobody can smuggle a command to your agents inside something they send you. That fencing is not yet on every agent: extending it across all of them is active work, and we would rather say so than imply it is finished. Inbound webhooks are verified with constant-time signature checks.
Only operator-authored blocks carry instruction authority.
Hardened in the browser and on the wire
HTTPS only, with HSTS. A Content-Security-Policy is enforced on every page and minted fresh per request with its own nonce, which is what stops an injected script from running at all. Framing is denied, MIME sniffing is off, and referrer and permissions policies are locked down.
Policy violations are reported back to us, not silently dropped.
Your card never touches us
Billing runs entirely through Stripe's own hosted checkout and billing portal. A card number never reaches our servers, which keeps the sensitive part of payments out of our scope completely. The billing events Stripe sends back are signature-verified and de-duplicated.
No card data is handled anywhere in our codebase.
The lifecycle
What happens to your data, start to finish.
Connect
You grant one agent one purpose-scoped permission. An admin has to approve it, and the handshake is protected against forgery.
Ingest
Only the data inside that permission is read, on your behalf, and only when an agent needs it.
Encrypt
It is sealed with your workspace's own key before it is stored. Tokens are encrypted the same way.
Isolate
Every later read is scoped to your workspace, and for the private brain to you personally, from your signed session.
Process
An agent sends only the content a task needs to the model providers listed below. Nothing is used to train them.
Erase
You can delete the workspace yourself. We destroy the key, revoke the connections, and the encrypted data becomes unreadable.
The questions you should ask
Answered plainly, including where the answer is no.
- Where does my data physically live?
- Your workspace data sits in managed Postgres, and the AI processing happens with the providers in the table below. The authoritative statement of where each of those sits, and the safeguards for any transfer between them, is in our privacy policy — we keep residency in one place rather than restating it here and letting the two drift apart.
- Is my data encrypted in transit and at rest?
- Yes, both. In transit it is HTTPS only, with HSTS telling your browser never to try plain HTTP. At rest, sensitive values are sealed with authenticated AES-256-GCM under a key belonging to your workspace alone, and database connections themselves require TLS.
- How is my workspace isolated from other customers?
- The boundary is re-derived from your signed server session on every request and enforced in the SQL, not applied as a filter after the fact and not trusted from the client. Each workspace also has its own encryption key, so even at the storage layer one customer's data is not readable with another's key. Today that isolation is enforced in the application layer; a database-level backstop is on our roadmap as defence in depth.
- What permissions do you actually ask for?
- Only what a given agent needs, on its own grant. On Google, agents that only read are only ever given read access. Two — Procurement and Sales — carry a send permission, because sending RFQs and follow-ups is their job, and they ask for it separately and explicitly. What goes out on it was either approved by a person, message by message, or sent under an auto-send policy that is off until you switch it on and reaches only the suppliers or contacts on your list at the moment a message is queued; switching it off stops any further automatic sends, though a message already in its short sending window may still go out. The one exception is a pair of fixed, templated replies Procurement can send to a supplier already on file who emails you — asking for the details a quote is missing when a message does not read as a usable quote, or noting that a quote from them is already on record for that request, so the new email was not taken as another quote. You can see the exact permission on the consent screen before you grant it, and revoke it from your Google account at any time.
- Is my data used to train AI models?
- We train no model of our own on your data, and one customer's data never informs another's results. For the providers we send content to, we will only claim what their terms actually say: Anthropic, who provide the reasoning, are contractually prohibited from training on the data they process for us and delete it within 30 days by default; Voyage, who generate the embeddings behind search, are configured so your content is not used for training and is not retained after processing. Our speech-to-text and Arabic-language providers are covered by their standard commercial terms, which we are in the middle of confirming in writing — until that is done we are not going to make the same promise on their behalf.
- What happens when I disconnect — can I really delete everything?
- Yes, and you can do it yourself from your workspace settings without asking us. Deleting a workspace destroys that workspace's encryption key — so the stored data becomes cryptographically unrecoverable — and removes the records. We also call Google's revoke endpoint for your tokens, though that call is made after the deletion and is not retried if Google is unreachable, so the certain way to end access is to remove it from your own Google account too. Encrypted backups age out on their retention schedule afterwards, which we would rather state plainly than imply is instant.
- How do you defend against prompt injection and ordinary app-sec risk?
- Untrusted content is fenced and labelled as data before a model sees it, so a message someone sends you cannot issue commands to your agents. On the web side, an enforced per-request Content-Security-Policy is the main control. Every pull request is scanned for vulnerable dependencies and for leaked secrets, with a full-history sweep every week, and the scanner binaries are pinned and checksum-verified so a compromised release cannot be swapped in.
- Are you SOC 2 or ISO 27001 certified?
- Not yet, and we would rather say so than imply otherwise. We are a security-by-design build that is pre-certification: the controls above are real and in the code today, but they have not been audited by an independent third party. Google app verification and the associated security assessment are in progress. If certification is a hard requirement for you, tell us — it helps us sequence it.
Sub-processors
Everyone who touches your data.
The complete list, including the optional integrations that only apply if you connect them. If a service is not here, it does not receive your data.
| Service | Why | What it receives |
|---|---|---|
| Anthropic (Claude) | The reasoning behind your agents | The specific content a task needs. Contractually never used for training, deleted within 30 days. |
| Voyage AI | Embeddings that make your content searchable | Text passages, to turn into search vectors. Not used for training, not retained. |
| Groq | Speech-to-text | Audio you submit for transcription. |
| Cohere · Hugging Face | Arabic-language reasoning | The prompt content for an Arabic task, routed to a hosted Arabic model. |
| Google APIs | The source of the data you connect | Scope-limited access to what you grant. Tokens and content are stored encrypted. |
| Google Analytics | Measuring visits to our public website | Page views, browser and device details, and approximate location from visitors to our public pages. Switched off inside the product, so no workspace data reaches it. |
| Neon (Postgres) | The managed database | All application data. Sensitive fields are stored as ciphertext. |
| Stripe | Billing | Your card details, handled entirely by Stripe, plus subscription metadata. |
| Resend | Sending transactional email | The recipient address and the contents of that email. |
| Cloudflare R2 | Storing media you publish or upload | The image and media files themselves. |
| Sentry | Error monitoring | Server-side error context. Personal-data capture is switched off, and there is no browser tracking or session recording. |
| GitHub | Turning your feedback into fixes | Feedback you submit in the product, written into our private issue tracker so an engineer can act on it. |
| DigitalOcean | Running the application | Technical connection data such as IP addresses, not your business content. |
| Slack · Microsoft Teams(optional) | Chat, if you connect it | Messages with the bot and the channels it is in. Tokens stored encrypted. |
| Fireflies(optional) | Meeting notes, if you connect it | The transcripts you choose to bring in. Your API key is stored encrypted and never shown again. |
| Google Ads(optional) | Ad accounts, if you connect them | Access to the ad account you connect. Nothing is spent without your approval. |
| LinkedIn(optional) | Publishing to LinkedIn, if you connect it | The posts and media you approve for publication. |
| Meta (Facebook · Instagram)(optional) | Publishing to Facebook and Instagram, if you connect them | The posts and media you approve for publication. |
| X(optional) | Publishing to X, if you connect it | The posts and media you approve for publication. |
| WhatsApp(optional) | WhatsApp messaging, if you connect it | The messages sent and received on the number you connect. |
Where we are
What is done, and what we are still building.
In the code today
- Envelope encryption with a key per workspace
- Workspace and per-person isolation from the signed session
- Purpose-separated, least-privilege connections
- Enforced per-request Content-Security-Policy, HSTS and hardened headers
- Self-serve deletion with cryptographic erasure and token revocation
- Dependency and secret scanning on every change, plus a weekly sweep
- Signature-verified webhooks and Stripe-hosted payments
- Server-side-only error monitoring with personal-data capture off
What we are building next
- Independent certification. We do not hold SOC 2 or ISO 27001 today. The controls are real and in the code; they have not been third-party audited, and we will not imply otherwise.
- Google app verification and the associated security assessment, in progress.
- Continued hardening — key management, database-level defence in depth, and automated retention tooling.
The brief is this page on paper — made to forward, or to attach to a security review. If you are evaluating us seriously and want more, we also keep a detailed engineering ledger of exactly what is shipped, what is configuration and what is still open, with the evidence behind each line; ask and we will share that one under NDA.
Download the security brief (PDF)Found something, or need something?
Security questions, a review request, or a vulnerability report — write to us and a person will answer.
security@revent.store