Security
An overview of Sevrel's repository-verifiable controls and the live evidence that IT, security, and compliance teams should request. Cloud configuration, vendor assurances, certifications, and contractual commitments require current supporting evidence. For deeper due diligence, contact [email protected].
Last updated: August 11, 2026. Read alongside the Privacy Policy, Data Processing Addendum, and the sub-processor register.
1. Security Overview
Sevrel combines identity, application authorization, tenant scoping, database row-level security, application-level encryption for designated fields, and human confirmation for high-impact actions. These are layered defenses, not a claim that repository code alone proves every live setting or future request safe.
- Microsoft Entra ID, Google OAuth, and password/TOTP authentication paths
- Signed HttpOnly sessions with server-side revocation
- Application encryption for credentials, MFA secrets, and indexed chunks
- Selected security and product events in an append-only database audit trail
- SOC 2-oriented controls; no completed SOC 2 report is currently asserted
2. Identity & Access
Single Sign-On
Sevrel supports Microsoft Entra ID and Google OAuth. The code validates provider identity assertions server-side and can restrict configured tenant or domain membership. Customer-controlled MFA, conditional-access, device, and offboarding policy must be verified in the relevant identity-provider tenant. Password/TOTP accounts are also implemented; passwords are bcrypt-hashed rather than reversibly stored.
Role-Based Access Control
Sevrel has three base roles, organization-defined custom roles, and named permissions. Server-side checks protect privileged routes and actions; UI visibility is not treated as an authorization boundary.
| Viewer | Base read-oriented role; effective access also depends on named permissions and enabled features. |
| Member | Base collaboration role; high-impact email and calendar writes still require confirmation. |
| Admin | Base administration role for organization-scoped settings and access management. |
Session Security
- Sessions are carried in signed, HttpOnly cookies; production configuration requires the Secure attribute and SameSite=Lax.
- Every session is tracked server-side and can be revoked instantly — users and admins can sign out all devices at once.
- Sessions have idle and absolute expiry controls; their effective live configuration requires deployment evidence.
3. Encryption
| In transit | Repository production configuration requires HTTPS-oriented operation. Current edge, origin, protocol, and cipher posture requires live Cloudflare and Railway evidence. |
| At rest | Credentials, MFA secrets, indexed chunks, and confirmation payloads receive designated application protection. Provider storage encryption requires current vendor and project evidence. |
| Key management | Application keys are supplied server-side and support controlled rotation. Custody, backup escrow, and completed rotation require operational proof. |
| Internal traffic | Database and provider clients support authenticated TLS policies; the actual scheme, certificate mode, and network path must be verified live. |
4. Data Handling & Privacy
Your documents stay yours
Sevrel is not a pass-through-only service. Depending on enabled features and user actions, it can persist raw uploads, extracted or indexed document chunks, synchronized email and calendar content, conversations, memories, generated artifacts, portfolio records, and audit events. Sources can include Egnyte, Google Drive, and direct uploads.
Identifier redaction before AI processing
Document text passes through a deterministic redaction engine before it is chunked, embedded, or sent to any AI model. Detected identifiers are replaced with typed [REDACTED_*] tokens. Embeddings are computed over the redacted text, so the vector index is built from redacted content, and passages sent for reranking have the policy re-applied immediately before transmission. There is no feature flag or administrative override, and the engine fails closed: if it errors or cannot resolve an organization's policy, the content is suppressed rather than sent.
Because the boundary matters more than the headline, it is stated exactly:
- Always redacted, every organization: Social Security, ITIN and taxpayer numbers; bank account and ACH routing numbers; IBANs; payment card numbers; dates of birth; driver's licence and passport numbers; and payroll and personal financial amounts.
- Redacted in personal or guarantor context: personal email addresses, personal phone numbers, and home addresses.
- Available as a per-organization strict mode: business tax identifiers (EIN), which are not redacted under the default policy.
- Not redacted: person, tenant and landlord names, and business contact details. These are the substance of a lease, and removing them would make the answers useless — so Sevrel does not claim to remove them.
Two related gates: raw file bytes are never returned from the document endpoints — every raw-byte surface refuses with an audited denial — and images and scanned PDFs are redacted before any vision call, or blocked outright if they cannot be, so raw image bytes are never sent to the model.
Use of customer content
- Sevrel does not use customer content to train its own models.
- AI requests can include questions, conversation context, and retrieved content needed for the task.
- External-provider training, retention, and regional processing depend on current provider terms, account settings, and executed agreements.
- Anthropic does not use API data to train its models. Under Anthropic's standard commercial API terms, request inputs and outputs are retained for up to 30 days for abuse monitoring — longer only if flagged for Trust & Safety review.
- Anthropic Zero Data Retention is not yet in place. Sevrel does not assert it without written account-level confirmation from Anthropic.
Deletion
Self-service conversation deletion, data export, and user-erasure workflows exist. Disconnecting a provider does not by itself prove deletion of previously synchronized or derived data, backup aging, or a contractual deletion deadline.
5. Tenant Isolation
Customer-data models carry organization and/or user identifiers. Routers and services apply explicit tenant filters, while PostgreSQL row-level security and a fail-closed tenant context provide database defense in depth. CI includes route, IDOR, RLS inventory, and real-Postgres cross-tenant tests. The current production role, grants, and enabled/FORCE policy state still require direct live-database evidence.
6. AI Safety Controls
AI systems introduce risks that traditional software doesn't. Sevrel treats them as first-class security concerns:
- Grounded answers: responses are generated from your documents and can cite retrieved sources. Citations help users inspect evidence but do not eliminate hallucinations or guarantee that every claim is supported.
- Prompt injection defense: defined ingestion and tool boundaries screen for recognized embedded instructions and encoded payloads. Detection is defense in depth, not a universal guarantee.
- Output screening: high-risk output paths inspect recognized encoded content and sensitive patterns before delivery.
- Human-in-the-loop actions: high-impact email and calendar writes require short-lived confirmation bound to the user and action. Background workflows are separately feature-gated and budgeted.
7. Platform Hardening
- Input validation: typed request schemas, request-size limits, upload checks, and parser-specific defenses protect defined application boundaries.
- Abuse and DoS protection: layered rate limiting per user and per address, request size caps, and concurrency limits keep a single actor from degrading the service.
- Injection defense in depth: parameterized value queries, allow-listed identifiers where interpolation is required, timing-safe credential comparisons, and boundary-specific sanitization.
- Modern browser protections: strict Content Security Policy, clickjacking denial, MIME sniffing protection, and restrictive referrer and permissions policies in repository-controlled frontend and API responses.
- Fail-fast configuration: production validation rejects defined weak or missing settings. This does not replace inspection of the deployed environment.
- Dependency controls: CI audits exact production dependencies, scans the backend image for fixable high/critical vulnerabilities, and pins third-party workflow actions. Current cloud patching and network controls require vendor evidence.
8. Audit & Monitoring
Selected security and product events are stored with user, organization, action, timestamp, and correlation context. A database trigger rejects audit-row updates and deletion except for a narrow erasure-pseudonymization path. This is append-only database enforcement, not cryptographic immutability or a claim that every read is logged.
Recorded events include
- Sign-ins, failed sign-ins, sign-outs, and session revocations
- Role changes and administrative account access
- Permission denials, with the user and permission requested
- Questions asked and the documents accessed to answer them
- Document ingestion and access
- Security events such as redactions and token anomalies
Admins can review organization-scoped audit records in-product. The web, worker, and scheduler share a fail-closed Sentry scrubber. Sentry error monitoring is live for backend services, with the DSN, privacy-safe smoke events, and a production-scoped alert rule operator-verified on July 26, 2026. Alerting proves detection, not staffed response: 24/7 human receipt and escalation coverage is not yet established.
9. Responsible Disclosure
If you discover a security vulnerability, please report it responsibly by emailing [email protected]. Please include reproduction steps, affected functionality, and a potential impact assessment where possible.
Scope. Sevrel-operated systems: sevrel.com, www.sevrel.com, and api.sevrel.com. Out of scope: our vendors' own infrastructure, customer-controlled document storage and mail tenants, and any testing that would access, modify, or exfiltrate another organization's data. Please do not run automated scanners or load generators against production.
What to expect. Reports are read by a human and acknowledged on a best-effort basis. Sevrel does not yet publish a formal response-time commitment or a legal safe-harbour statement, and this page does not create one; where a customer agreement sets security-contact obligations, that agreement governs. If a report needs one, say so and we will handle it directly.