Security
Last updated: 14 October 2026
Rivyt turns a company’s own documents (manuals, procedures, work orders, drawings, specifications, spreadsheets) into a cited knowledge base and answers questions about them by typing or, optionally, voice. Access is by invitation only. This page summarises how we protect that data. Customers can ask for our full security review answers at security@getrivyt.com.
How data flows
- The browser loads the app from Vercel at app.getrivyt.com. Vercel serves files and sees request logs, never customer content.
- The API runs on Railway and receives every request over TLS. Every route calls an authorization gate, and a test asserts that for every route.
- Sign in is Supabase Auth: a password (hashed by Supabase) plus an authenticator app. Sign in, invite and security emails go out through Resend.
- Documents are uploaded, or read from the customer’s own Google Drive under the permission the customer grants. They are stored in Supabase, converted to text, split into passages, embedded by Voyage AI and indexed in Pinecone, in one namespace per workspace. Anthropic reads document text to build the knowledge graph, which is stored in Supabase.
- A question retrieves matching passages, and the question, the passages and earlier turns go to Anthropic to write a cited answer, which is stored in Supabase.
- Voice, if a person turns it on after a consent screen, sends their speech to OpenAI to be transcribed, and answer text to OpenAI to be spoken. Rivyt stores no audio.
Every company that processes customer data, what it receives and where, is on our subprocessors page.
Encryption
- In transit: TLS on every connection, with HSTS on the app and API.
- At rest: provided by our storage providers. Supabase (database and file storage) and Pinecone (search index) encrypt stored data with AES-256.
- Google Drive tokens are encrypted again by Rivyt, with the key held in Supabase Vault and readable only by our servers.
- Passwords are hashed by Supabase Auth; Rivyt never sees them.
Access control and sign in
- Multi-factor authentication is required for every user, with an authenticator app, and enforced on the server. Sensitive actions ask for it again, and code attempts are rate limited.
- Passwords found in known data breaches are refused, and changing a password needs the current one.
- Workspaces are private by default. New people get no workspace until an admin adds them. Company admins manage every workspace but read only the ones they belong to; joining a private workspace requires a reason that its members can see.
- Rivyt staff read customer content only with a stated reason. Direct database access needs a second factor.
Tenant isolation
Every read follows workspace membership in the application, and Postgres row-level security checks it again. Every database function is callable only by our servers. Search uses one Pinecone namespace per workspace with the same permission rule, and an empty scope matches nothing. The answer cache never replays an answer across workspaces. Automated tests assert that one customer cannot reach another’s data, and that every API route has an access gate.
AI controls
- Customer documents placed in AI prompts are marked as data, not instructions, to resist prompt injection.
- Every AI agent tool is read-only and scoped to one workspace, and no tool accepts a workspace id, so a model cannot be steered into another workspace. Nothing is written into another system until a person approves it.
- Answers cite their sources. Decision briefs do their arithmetic in code, cite every figure, and never recommend or choose.
- Customer content is never used to train AI models. We use AI providers only under terms that do not allow training on our data, and have opted out wherever a provider offers the setting.
Logging and monitoring
An audit log records access changes, workspace joins and their reasons, staff reads and relationship decisions, and the database refuses updates and direct deletes of it. Refused requests and new sign in sessions are recorded in the same log, and security events raise alerts: repeated refusals from one address, a spike in refusals, a suspended account still trying, and staff reads of customer content. Application logs and error reports carry ids, not customer content.
Secure development
- Changes go through pull requests gated by automated tests. Dependencies are pinned, and dependency vulnerability scans and secret scanning block the build.
- Uploads are checked by their content, not their name; SVG, HTML and XML files are downloaded rather than opened in the browser.
- A strict Content-Security-Policy with no inline scripts or styles, a Cross-Origin-Opener-Policy, framing denied, and a CORS allow-list.
Backups
Supabase manages backups of our database. The search index can be rebuilt from stored documents.
Incident response
If a security incident affects customer data, we notify the customer without undue delay, and within 72 hours of confirming it, with what happened, what data was affected, what we are doing about it, and what the customer may need to do. Our Data Processing Addendum sets out the full commitment.
Certifications
Rivyt does not yet hold a SOC 2 report or ISO 27001 certification, and has not yet had an external penetration test. Our hosting and storage providers publish their own SOC 2 reports, and physical security of the infrastructure rests on theirs.
Reporting a vulnerability
If you find a security vulnerability, email security@getrivyt.com. Please report in good faith, do not access other people’s data, and give us a chance to fix the problem before you share it.