Built like the evidence depends on it — because it does.
Sluice handles regulated client data for broker-dealers and RIAs. Everything below is a design fact about the running system, not an aspiration. Where something is on the roadmap, it says roadmap.
Tenant isolation, enforced by the database
Every firm's records live behind row-level security enforced inside the database engine — forced on every table that carries firm data, with a fail-closed policy: a query without an authenticated firm context matches zero rows. The application cannot opt out; queries run under a restricted role that has no bypass. Isolation is also linted: a build fails if any code path tries to query firm data outside the scoped transaction layer.
Append-only evidence ledgers
The audit trail, signed-document baselines, post-signing verdicts, and lifecycle events are write-once ledgers: database permissions to update or delete those rows are revoked from the application role and re-asserted (and verified) automatically every day. Snapshots are content-hashed and chained, so a missing or altered capture is detectable. When paperwork is signed, the signed baseline is sealed first and every later change is compared against it — the record of what the client signed can't quietly drift.
PII handling
Tax identifiers are envelope-encrypted (AES-256-GCM, versioned keys) in a dedicated vault table; raw values never appear in screens, logs, exports, or the audit ledger — those carry last-four only. Self-profiling links clients use to submit their own information tokenize identifiers before anything is stored. Sensitive values in the audit trail are masked at write time, so even the evidence ledger never holds a raw identifier.
AI boundaries
AI in Sluice proposes; it never decides. Anything a model suggests re-validates through the same field-level rules a human keystroke goes through, and nothing posts without the deterministic engine's verdict. Identifier-shaped values (SSNs, EINs, account numbers) are redacted to last-four before any text reaches a model. Model inputs are not used for training, and the gate, signer, ownership, and drift logic contain no AI by construction — a lint rule fails the build if AI code is ever imported into the rules engine.
Access and authentication
Production sign-in is enterprise SSO via WorkOS (SAML/OIDC-capable). Inside the app, actions are role-gated (advisor, principal, admin) at a single server-side chokepoint, team visibility is enforced on reads and writes, and sensitive reveals and approvals are attributed, reasoned, and audited.
Infrastructure and subprocessors
Sluice runs on Vercel (application), Neon (Postgres, encrypted at rest, TLS in transit), WorkOS (authentication), DocuSign (e-signature), and Anthropic (AI proposals, redacted input only). Webhooks are HMAC-verified; scheduled jobs are secret-authenticated; security invariants (isolation coverage, ledger immutability, role safety) are re-checked by an automated sweep every hour and fail loudly.
On the roadmap — labeled honestly
SOC 2 examination (controls are being built evidence-first ahead of the audit), SEC 17a-4-compliant document storage with a designated third party for firms that want Sluice as the official record-keeper, per-firm dedicated encryption keys, and custodian-side mTLS connectivity as part of clearing-firm certification.
Evaluating Sluice for your firm? We'll walk your compliance team through any of this against the running system.
Request a demo