Security posture
Financial-grade by architecture.
BEXAI was built so that a regulated financial-services or healthcare client can deploy it without a six-month security review. Every table is RLS-protected. Marketing email is sent only after a consent check. Every financial event is hash-chained. Every audit query against personal data uses SHA-256 hashes, never raw values.
Six pillars
Row level security on every table, and a gate on the path around it
Every public table has Row Level Security enabled and denies by default. Two things are worth saying plainly rather than leaving to a badge. FORCE ROW LEVEL SECURITY is deliberately not applied: it does nothing here, because every table is owned by the postgres role and that role holds BYPASSRLS, which overrides FORCE. That was proven on a scratch table, not assumed. And the server paths that use the service_role key do bypass RLS completely, by design, because some work has to. On those paths the application code is the isolation control rather than the database, so a build gate requires every one of them to authorise the caller before it reaches for that key, and lists by name the public surfaces that legitimately do not.
AAL2 multi-factor authentication
Every dashboard request is gated by MFA at AAL2, not just at login, but on every protected route. TOTP plus backup codes hashed with bcrypt; backup codes are single-use.
Append-only audit + consent ledgers
audit_log and consents tables have no UPDATE or DELETE paths. SHA-256 hashed user_id and IP (never the raw values) give us forensic visibility without storing PII in operational telemetry.
Hash-chained financial records
commissions and proposals tables are hash-chained: each row's row_hash includes the previous row's hash, written through a SECURITY DEFINER RPC under an advisory lock. Tamper a row and every subsequent row's chain breaks.
ca-central-1 data residency
Personal information is stored in our database in Montréal, Canada; the privacy policy says what is processed outside Canada, and a list of our service providers is available on request. Storage in Canada is a commercial and trust commitment rather than a legal duty: PIPEDA imposes no data localisation requirement, it is an accountability statute, and any firm telling you otherwise is selling you something. The choice earns its keep elsewhere, because Canada holds European and United Kingdom adequacy, so a client in either can transfer here with no standard contractual clauses and no international data transfer agreement.
Personal information is tokenised before the report models, and not before the chat
Every prompt in the diagnostic and report pipelines is run through anonymisePii() first: names, organisations, emails and phone numbers are replaced with neutral tokens, and the response is rehydrated inside the BEXAI perimeter. The live chat agent and inbound SMS are the exception, and it is a real one rather than an oversight: a conversational agent cannot answer a question whose subject has been replaced by a token. What you type into the chat reaches the model as you wrote it, so do not put anything there you would not put in an email.
Compliance + standards
PIPEDA
Personal Information Protection and Electronic Documents Act (Canada)
CASL
Canada's Anti-Spam Legislation: marketing email is sent only after a consent check, with one-click unsubscribe
RLS
Postgres Row Level Security on every table, deny by default
AAL2
NIST 800-63B Authenticator Assurance Level 2
OWASP Top 10
Reviewed at every release; CSP + rate-limit + signed webhooks
Vulnerability disclosure
Found something? Email security@bexai.ca. We acknowledge in 2 business days, fix HIGH or CRITICAL issues within 14 days, and credit you in the release notes if you wish. Safe-harbor clause for good-faith research applies.
Machine-readable contact in security.txt. Privacy details in /privacy.