Security posture

Documents are uploaded directly to Cloudflare R2 object storage over an encrypted connection. The application server is not in the data path for the file itself. Before issuing an upload URL, the server validates the file size (500 MB maximum), confirms that the content type is PDF, DOCX, XLSX, or PPTX, and verifies that the requesting user is a member of the target audit.

Upload and download URLs are presigned with a 15-minute expiry. The storage bucket is not public. No one retrieves a document by guessing a URL.

Storage keys are structured to mirror the authorization boundary: each object is prefixed with the matter identifier so that a misconfigured access policy would still constrain cross-tenant access. Files are content-addressed with a SHA-256 hash stored in the database as a tamper-evidence anchor.

Uploaded filenames are sanitized before use as storage keys: path traversal characters are stripped and unsafe characters are replaced. Extracted text and LLM classification responses are stored separately in R2 and are never written to local disk during request handling.

Documents in transit are protected by TLS. Documents at rest are encrypted by the storage provider: Cloudflare R2 uses AES-256 with provider-managed keys, and the Supabase Postgres database uses provider-managed encryption at rest.

The application does not perform client-side or column-level encryption. Customer-managed encryption keys are not available at this stage.

RED LINE is built on the following providers. Each processes data only as needed to operate, secure, monitor, support, or improve the service.

• Clerk — authentication provider. Manages user accounts, session tokens, multi-factor authentication enrollment, password resets, and brute-force protection. Clerk is the only path to a protected session; the application does not implement credential handling.
• Cloudflare R2 — object storage for uploaded documents, extracted text, and LLM classification records. Encryption at rest is AES-256, provider-managed.
• Supabase — managed Postgres database hosting audit configuration, document metadata, findings, reports, event logs, and user records. Encryption at rest is provider-managed.
• Resend — transactional email delivery for account notifications, counsel invitations, and audit-complete notices.
• Google Gemini — large-language-model provider used to classify documents and analyze audit materials. See the AI and LLM data section below.
• Stripe — payment processing for subscriptions. Card details are entered on Stripe-hosted surfaces and are not stored by RED LINE.
• Sentry — error monitoring and observability. Application-level error logging does not include request bodies or credentials. Sentry SDK configuration and what Sentry retains server-side is governed by Sentry's privacy and data-handling terms.
• Vercel — application hosting and edge network. Hosts the Next.js application layer, including all server-side API routes and server functions.
• Temporal Cloud — workflow orchestration for audit runs. Workflow state and activity payloads pass through Temporal Cloud as part of audit execution.
• Hostinger — virtual private servers operated by RED LINE that run the audit workflow workers (document processing, LLM analysis, report generation).

Authentication is delegated to Clerk. Every route under the application and API is protected by a session guard. The only public inbound path is the Clerk webhook, which is authenticated by Svix signature verification.

Authorization is enforced at the matter level. Each audit has a membership table keyed on user ID and role (owner, counsel, or viewer). Document reads, document writes, upload URL issuance, and finding access all require the requesting user to be a member of the specific audit being accessed. Non-members receive a 404 response whether the resource exists or not, to avoid disclosing the existence of other audits.

There is no organization or workspace layer above the matter. One user account can hold memberships in multiple audits with independent roles.

Document state transitions are recorded in an append-only event log. The log covers uploads, text extraction, classification, version supersession, module assignment, archival, restoration, and download requests. Each event captures the actor identity, the actor kind (user, system, or LLM), and a structured payload. Rows are never updated or deleted.

Authentication events (sign-in, MFA challenge, sign-out) are recorded in Clerk's audit log and are not currently mirrored into the application database. Generic API access logs and per-read access records are not yet implemented. Those are named gaps, not omitted controls.

The current product supports document archival. Archiving a document marks its row with an archived-at timestamp and removes it from active views; the R2 object and database row are retained for chain-of-custody.

A hard-delete workflow that removes both the database row and the R2 object is not yet implemented. An automated retention schedule that ages documents or events after a fixed period is not yet implemented. Deletion and export requests are handled through an operator process until those workflows ship — send requests to compliance@redline.audit.

This is consistent with what the Privacy Policy states: the current product supports archive states, and a fully automated hard-delete and retention workflow is not yet present.

Uploaded documents are sent to Google Gemini for classification and audit analysis. This is the core function of the service: the LLM reads the document to identify potential compliance issues.

RED LINE does not use audit documents, findings, or reports for third-party behavioral advertising. Customers with questions about Google's data handling for the Gemini API should review Google's applicable terms and policies directly.

LLM classification responses are persisted to R2 under the matter prefix for audit traceability. Short-TTL operational diagnostics that may reference document content are subject to a rolling deletion window and are never exposed to users or counsel.

Notable controls not currently present in the product are listed below. Each is on the roadmap; none are described as shipped. The internal security documentation tracks the full set.

• Virus and malware scanning. Uploaded documents are not scanned before text extraction.
• Per-document-access audit rows. Reading document content does not generate a log entry. Only state-change events are recorded.
• Automated retention schedule. No scheduler ages documents, events, or extracted text.
• API rate limiting in application code. Rate limiting relies on edge-platform defaults.
• Customer-managed encryption keys. All encryption keys are provider-managed.
• Formal penetration test. No external penetration test has been completed against the current build.
• Bug bounty program. Not yet launched.
• SOC 2 report. SOC 2 Type I is on the roadmap. No audit engagement is active and no SOC 2 report exists today.

The following are deliberately not in scope for the current build and are not represented in marketing or product copy: SOC 2 Type II, ISO 27001, HIPAA (RED LINE does not process protected health information), FedRAMP or government compliance regimes, customer-managed or bring-your-own keys, on-premises or VPC-isolated deployment, and a formal data processing addendum or subprocessor registry.

RED LINE is designed for U.S. private capital compliance workflows. Customers who may subject RED LINE to GDPR, UK GDPR, or equivalent data-protection regimes should contact compliance@redline.audit before use. An institutional data processing addendum is not yet available.

These will become in-scope as the customer set requires them.

If you discover a security vulnerability in RED LINE, report it to compliance@redline.audit with "Security" in the subject line. Include a description of the issue, the steps to reproduce it, and any supporting materials. RED LINE reviews security reports and aims to acknowledge confirmed vulnerabilities.

A formal bug bounty program and a defined response SLA are not yet in place.