ORION Biotech Catalyst Calendar
Menu
Security & Trust

What's actually true about how your data is handled — and what isn't built yet.

Last updated (page presentation): . Page presentation only; original policy, publication and source-review dates remain unchanged. Data checks and service status retain their own verification times.

This page follows the same rule as everything else ORION discloses: a stated fact is checked against the running code, not aspirational. If something below isn't true yet, it says so, rather than staying silent about it.

Data access

Row-level security on every table

Database tables have row-level security enabled. Browser sessions do not read or write database tables directly. One exception: a signed-in browser calls a single read-only database function that returns only that user's own report list. Every other read and write goes through ORION's servers, and the service-role credential is used only in server-side code, never in the browser.

Your session, verified every time

Authentication tokens are re-verified against Supabase on every request. Account access is never trusted from anything the browser sends; it is re-checked on the server.

Secrets stay server-side

API keys and service credentials are environment variables on the backend only — never shipped to the browser, never logged in plaintext, never returned in any API response.

Reliability

Structured, reviewable logs

Failures are logged in a consistent, searchable format with masked identifiers — not left as unlabeled text an operator would need to happen upon by accident.

A written incident runbook exists

Investigation steps for incidents are documented in an internal operations runbook, not improvised during an incident.

What's honestly not true yet