Documentation

Security Whitepaper

The technical companion to our compliance commitments. Architecture, controls, and the design choices behind the Fortress Standard.

Effective·February 1, 2026
01

Design Thesis

Public-company customers entrust us with material non-public information. Our security architecture is designed for this responsibility from the database to the AI inference layer, with four independently auditable defense layers.

The thesis is that breach prevention through layered defenses, combined with rapid detection and immutable audit, produces a defensible posture that meets institutional procurement requirements while remaining operable by small teams.

02

Layer 1. Multi-Tenant Isolation via RLS

Every Postgres table in the platform enables row-level security with policies scoped on issuer_id. The application server connects with a service role that respects these policies; there is no escape hatch in product code.

RLS policies are enforced at the database, not at the application. A SQL injection or application-layer bug cannot result in cross-tenant data access. Audit tests verify policy coverage on every CI build.

03

Layer 2. Encryption Architecture

At-rest encryption uses AES-256-GCM. Each issuer has its own Data Encryption Key (DEK), wrapped under a Key Encryption Key (KEK) that is held in a hardware security module attested to FIPS 140-3 Level 3.

In-transit encryption requires TLS 1.3 for all client and inter-service traffic. HSTS, certificate pinning for high-sensitivity flows, and mutual TLS for internal RPCs.

End-to-end encryption is available as an opt-in for board portal communications using browser crypto.subtle keypairs with server-side public-key registry.

04

Identity and Authentication

Authentication is managed via Supabase Auth with JWT-based session tokens, refresh-token rotation, and short-lived access tokens. WebAuthn / FIDO2 is supported for passwordless authentication using platform authenticators or hardware security keys.

Administrative functions require multi-factor authentication. Step-up authentication is enforced for sensitive operations such as Vault publish, certification, and team-role changes.

05

Layer 3. AI Data Isolation

The AI router classifies every document by sensitivity before any inference call. Public-record documents (SEC filings, OTC disclosures, press releases) route through the Gemini API for maximum extraction accuracy. Documents classified as material non-public information route through Vertex AI in a customer-isolated GCP VPC.

The Vertex AI environment is contractually configured against training, log retention, and human review. Inputs are encrypted in transit, processed in memory, and not persisted beyond the inference call. The classification decision and routing log are written to the immutable audit trail.

06

Layer 4. Audit and Immutability

Every mutation to Vault records, Cap Table entries, filings, board actions, and material events is captured in the audit_logs table with actor identity, IP, timestamp, action category, target identifier, and full before/after snapshots.

The audit table is append-only at the database level. There are no soft deletes of mutation history. SOC 2-aligned retention applies. Customers can export the audit log on demand.

07

Monitoring and Detection

We monitor for authentication anomalies (impossible-travel, brute-force, credential-stuffing), API rate-limit violations, structural-integrity drift, and audit-log tampering attempts. Alerts route through PagerDuty with defined severity levels and on-call rotation.

08

Post-Quantum Hybrid Mode

Optional ML-KEM hybrid key exchange is available for forward-secrecy in anticipation of post-quantum cryptography migration. Hybrid mode runs the classical exchange in parallel for backward compatibility while introducing quantum-resistant material to the session key derivation.

09

Incident Response

Documented incident response plan with defined roles, communication templates, customer-notification triggers (72-hour breach commitment), and post-incident review process. Tabletop exercises run quarterly.

10

Subprocessor Architecture

The full subprocessor list, including their security postures and processing scope, is maintained in our Data Processing Addendum. Customers receive 30 days' notice before any new subprocessor is engaged for personal data processing.

11

Audit and Evidence Requests

For SOC 2 evidence packages, vendor risk questionnaires, or architecture deep-dives under NDA, contact security@marketfortress.app.

Effective February 1, 2026. © 2026 Market Fortress.
Questions? legal@marketfortress.app