Privacy & Data Isolation

AI Inference & Provider Handling

Anthropic Claude is Sevrel's default AI implementation. Requests can include the user's question, conversation context, and retrieved content needed for the task. Optional provider gateways, embeddings, transcription, and document extraction services are configuration-dependent.

Sevrel does not use customer content to train its own models. External-provider training, retention, and regional handling are governed by current provider terms and executed agreements.

Anthropic does not use API data to train its models. Anthropic retains API request inputs and outputs for up to 30 days for abuse monitoring (longer only if flagged for Trust & Safety review). Sevrel does not currently have a Zero Data Retention agreement with Anthropic in place; ZDR is not asserted without written account-level confirmation.

What Sevrel Stores

Some source files remain in customer-controlled systems, but Sevrel is not a pass-through-only service. Depending on enabled features and user actions, persisted data can include:

• account, organization, role, and session metadata;
• conversations, messages, memories, and generated artifacts;
• uploaded files and extracted/indexed document chunks;
• synchronized email, attachment, and calendar content;
• portfolio, tenant, lease, work-order, and audit records;
• encrypted integration credentials and MFA secrets.

Document sources can include Egnyte, Google Drive, and direct uploads. Which sources are active is organization-specific.

Tenant Data Isolation

Sevrel combines application and database defenses:

• customer-data records carry organization and/or user identifiers;
• routers and services apply explicit tenant filters;
• PostgreSQL row-level security provides defense in depth;
• missing tenant context is designed to fail closed;
• CI inventories routes and RLS coverage and runs IDOR, cross-tenant, and real-Postgres tests;
• integration credentials and provider scopes are associated with the relevant organization or user.

These overlapping controls are stronger than a single filter, but they are not a claim that every future query is automatically safe. The live database role, grants, and enabled/FORCE RLS flags require direct evidence.

Document Access & Changes

Access depends on the connected provider and the feature being used. Search, retrieval, upload, filing, move, rename, delete, and share operations exist in different product paths and are subject to server-side authorization and feature controls.

Sevrel should not be described as universally read-only or as never maintaining derived content. Customer administrators should review the scopes granted to each enabled provider and the actions exposed to each role.

Encryption & Secrets

• In transit: Production repository configuration requires HTTPS-oriented operation. Current edge, origin, protocol, and cipher settings require live Cloudflare and Railway evidence.
• Application-encrypted: Integration credentials, MFA TOTP secrets, the body text of indexed document chunks, and short-lived action-confirmation payloads. The vector embeddings derived from that chunk text, and each chunk's file name, section heading, and source path, are not application-encrypted; they rely on tenant scoping and provider-level storage controls.
• Application-plaintext: Bulk conversations, memories, synchronized email/calendar content, and audit-event content. Tenant scoping and access controls remain separate defenses.
• Provider storage: Storage encryption is not inferred from the host name. It must be verified from the current vendor and project configuration.
• Sessions: Signed HttpOnly cookies are paired with revocable server-side session records; production configuration requires Secure cookies.

Authentication & Access Control

The codebase supports Microsoft Entra ID, Google OAuth, password/TOTP accounts, and API keys. Passwords are bcrypt-hashed; OAuth credentials and TOTP secrets are encrypted.

• Three base roles plus organization-defined custom roles and named permissions
• Server-side authorization for privileged operations
• Per-IP and per-user abuse controls
• Individual and account-wide session revocation
• Explicit confirmation for high-impact email and calendar writes

Customer identity-provider MFA and conditional-access rules remain customer-controlled and should be verified in that tenant.

Audit, Retention & Deletion

Selected security and product events are recorded with correlation context. Database controls reject audit-row mutation except for a narrow erasure-pseudonymization path. Audit coverage is event-specific, not a promise that every read is logged.

Conversation and audit retention is not universally configurable per tenant in the current implementation. Audit rows are retained indefinitely unless an approved operational policy changes that posture. Sentry error monitoring was activated and operator-verified on July 26, 2026; its event retention follows the selected Sentry plan and should be confirmed against that plan rather than assumed from this page.

Self-service data export and user-erasure workflows exist. They do not by themselves prove customer-level deletion timing, backup aging, or legal compliance; those depend on executed procedures and agreements.

Subprocessors

Depending on enabled features, customer data may be processed by hosting, edge, identity, document, AI, observability, billing, transactional-email, and embeddings providers. Vendor location, retention, assurance reports, and contractual terms can change outside this repository.

Review the current public subprocessor register together with the customer's executed agreement and enabled integration list.