Security Controls & Sensitive Data Isolation
This page documents the implemented controls for both the standard hosted offering and Enterprise private or on-prem deployment scenarios, covering network, host, application, data, and identity controls as well as isolation for private knowledge, mailbox authorization codes, and business-critical data.
Deployment Model
Basic and Pro are hosted by MailsRAG. Enterprise can opt for private or on-prem deployment by project.
Isolation Unit
Tenant is the primary isolation boundary. Knowledge bases, mailbox settings, processing records, usage, and billing objects are scoped by tenant ownership.
Disclosure Scope
This page only describes implemented controls and explicit deployment assumptions. External facilities such as WAF, bastion, KMS, or EDR are not claimed as built-in features.
Network Security
Implemented controls at the network layer focus on origin restriction, cross-origin boundary control, and stricter cookie transport behavior under HTTPS production deployments.
Ingress and origin paths are controlled
Standard plans are delivered through controlled HTTPS ingress and backend origin paths. Enterprise private deployment can further align network boundaries with the customer's environment.
Cross-origin access is allowlisted
The backend only enables CORS when api_cors_origins is explicitly configured, and allowed origins, methods, and headers are constrained by that configuration.
Session cookies tighten automatically under HTTPS
Cookie Secure is enabled when HTTPS is detected directly or through reverse-proxy headers, while SameSite is adapted to same-site or cross-site conditions for secure browser handling.
Host Security
At the host layer, controls focus on durable storage, path safety, and tenant partitioning. Standard plans run on MailsRAG-managed infrastructure, while Enterprise can deploy into customer-designated environments.
Knowledge files and indexes use durable storage
Tenant files, knowledge documents, and vector indexes are persisted on controlled storage. In Enterprise private deployment, storage can be mapped to customer-designated hosts and disks.
Directory access uses path safety checks
Knowledge-base path resolution uses safe_id and safe_join to prevent path traversal and invalid kb_id values from escaping the intended storage tree.
Public and tenant data are partitioned
Public knowledge and tenant-private knowledge are partitioned in storage layout and access control to reduce cross-tenant access risk.
Application Security
Application controls rely on input validation, throttling, idempotency, feature boundary enforcement, and a clean separation between public demo traffic and private business traffic.
Structured server-side validation
Mailbox settings, knowledge-base IDs, billing parameters, and management actions are constrained by Pydantic schemas and server-side validation before entering the business flow.
OTP flow is throttled and time-bound
Email OTP issuance uses TTL, minimum request interval, and per-hour limits to reduce brute-force or abuse-driven request patterns.
Public demo and private business flows are separated
The product demo uses only the public knowledge base, while authenticated tenant actions use tenant-scoped private knowledge paths and tenant-scoped query execution.
Billing operations use idempotent constraints
Order creation and payment state transitions use idempotency keys, uniqueness constraints, and status checks to reduce duplicate submission and duplicate accounting risks.
Data Security
Data controls focus on tenant ownership, minimization of sensitive values in storage, hashed credential material, and auditable business traces.
Core business tables are tenant-scoped
Users, knowledge bases, mailboxes, message threads, drafts, send records, usage, payments, and refunds all carry tenant ownership and related uniqueness constraints.
Sensitive authentication values are hashed
API keys are stored as salted hashes and email OTP codes are stored as code_hash values, so verification relies on digest comparison rather than raw credential persistence.
Only minimal payment fields are retained
Payment records store necessary references, status, amount, and reconciliation fields. Card channels retain only card brand and last4 for operations, not full PAN or CVV.
Business actions can be audited
The system can keep usage events, draft records, sending records, payment states, and refund traces for audit, incident review, and operational diagnostics.
Identity & Access Security
Identity and authorization controls are built around OTP login, tenant binding, separate admin authorization, signed session cookies, and subscription-based feature gates.
End-user access is based on email OTP
Users sign in with email OTP and only receive a tenant session after successful verification. Unauthenticated requests cannot reach tenant-scoped APIs.
Sessions are signed and API access is authenticated
Business APIs accept X-API-Key or a signed mailsrag_session cookie, and the signature is validated with session_secret on the server side.
Admin access has a separate trust boundary
The admin console uses a dedicated ADMIN_TOKEN and a separate mailsrag_admin session cookie, keeping elevated administrative access distinct from tenant sessions.
Subscription state affects access
Expired or invalid subscription states are redirected to billing-only flows, and higher-value private-knowledge capabilities remain subject to plan and status checks.
Special Isolation for High-Sensitivity Data
For private knowledge, mailbox authorization codes, and core business data, the current implementation combines tenant scoping, storage partitioning, authenticated context, and minimum-field exposure.
Private Knowledge Isolation
Basic and Pro run on MailsRAG-managed infrastructure, where private knowledge is isolated across metadata, indexing, and access control. Enterprise can opt for private or on-prem deployment by project. The public demo never loads tenant-private knowledge.
Mailbox Authorization Code Isolation
The system supports an environment-variable reference mode. The password_env field is resolved from process environment variables first, and only falls back to a literal value for compatibility. In production, the recommended pattern is to keep the real mailbox authorization code in host-side environment variables or secret management and store only the reference name in application configuration.
Business-Critical Data Isolation
Tenant names, subscription states, billing records, message threads, drafts, send traces, and usage records remain tenant-scoped and are accessible only through user or admin authorization boundaries. The admin view exposes only the minimum operational fields required for reconciliation and support.
Disclosure Boundary & Deployment Notes
This page reflects implemented controls only. Basic and Pro are hosted by MailsRAG. If a customer requires private or on-prem deployment, dedicated network boundaries, or higher-grade enterprise controls, those should be handled under an Enterprise delivery scope. This page does not claim that all plans are self-hosted by default.