Security — SELAHAI

Isolation

Your records cannot be reached from another account

In one line: the evidence record is append-only at the database level, so nobody can rewrite history — including us. The gaps are named on this page rather than left for your review to find.

Tenancy is a WHERE clause, not a filter. Every query that reads your data is keyed on your operator id in the query itself. There is no code path that accepts an operator id from a request — it comes from the verified session and nowhere else.
A record belonging to someone else is a 404, not an empty list. An empty result confirms the id exists. The tenant predicate sits on the join, so the row is simply not found.
Demo data is scoped and cannot cross. Illustrative rows carry the operator they belong to and are excluded from every shared surface by construction.

The record

What is written cannot be quietly rewritten

Append-only, enforced by trigger. Attestations, closures, outcomes, artifacts and the decision history refuse UPDATE and DELETE at the database level. A correction creates a new record referencing the old one; it does not edit history.
Evidence is hashed. A closure references a document by content hash, so a later edit to the file cannot silently change what was attested against.
Coverage dates are immutable. The day a state's watch began cannot be moved — not forward, not back, not by us. A movable coverage date would let every other guarantee here be rewritten after the fact.

Access

Sessions, passwords and what happens when something goes wrong

Passwords are bcrypt at cost 12, with a policy that refuses common and structural weak choices and anything containing the account name.
Lockout is per account and evaluated in SQL, so parallel requests cannot race past it. Sign-in failures are indistinguishable from one another — a wrong password and an unknown address return the same thing, and the unknown-address path still hashes so the timing matches.
Every session can be revoked. Tokens carry a version checked against the database on each request; a password change, a reset or a sign-out-everywhere invalidates every live session immediately.
Reset and verification links are single-use, hashed at rest and expiring. A minted link supersedes the previous one.
Sign-ins and administrative actions are recorded in a ledger that outlives the account it describes, and that recording can never take down a login.

Recent, and verifiable

Shipped this quarter, checkable today

Two-factor authentication. TOTP (RFC 6238) for every account, verified against the RFC’s own test vectors; recovery codes stored hashed, single-use. A password alone buys a five-minute exchange token, never a session.
Team seats, checked live. Owner, admin and member roles resolved on every request rather than minted into tokens — a removed seat means removed now, not at token expiry.
Signed webhooks. Every delivery HMAC-signed over the raw body; receiver URLs are https-only and refused into private address space; every attempt — success or failure — is a ledger row.
The status page. Every lane alarms on itself and the needle is public: selahai.ai/status. A lane reads healthy only because its job completed and proved it.
SOC 2 readiness, started 2026-08. A controls matrix mapped to what actually exists, a gap register, and monthly evidence snapshots generated from the live system — dated, in the repository, before any auditor asked.

Reviews and questionnaires

Ask us anything your review needs

We answer security questionnaires directly. Send yours and you will get a complete, specific response — including where a control is structural, where it is procedural, and where it is neither yet. We would rather have that conversation with your reviewer than pre-answer it for the whole internet.

Architecture detail on request. How tenancy is enforced, how the append-only guarantees are implemented, how sessions are revoked and what the retention boundaries are — available under NDA to anyone evaluating seriously.

Responsible disclosure

Found something? Tell us.

Security reports are read before anything else in the inbox and answered by someone who can fix it, not by a triage queue. Tell us what you found and how to reproduce it. We will confirm we have it, tell you what we are doing, and say when it is fixed.

We will not threaten you, and we will not argue about scope with somebody who took the trouble to tell us.

Report a vulnerability → or write to hello@selahai.ai