Security
How we think about security
This page describes Chassis practices at a high level. It is not a compliance certificate, penetration-test report, or guarantee. Security is ongoing work — if you find an issue, tell us.
Row-level security
Application data in Postgres is designed with RLS enabled on public tables. Trusted server paths use a service client; client sessions should not bypass org boundaries.
OTP sign-in
Human authentication uses email one-time codes through our auth flow — no password database of our own for the default path.
Hashed API keys
Public API access uses Bearer keys (chs_…). Plaintext is shown once at creation; we store a hash and authenticate by lookup against that hash.
Chassis identifiers
The console, public API, and SDKs speak Chassis resource IDs end to end — the same IDs you create and manage in your org.
Clear errors
API and SDK failures return short, actionable messages meant for operators and automation — not stack traces or internal exception dumps.
Roles and authorization
Authorization is based on Chassis profiles and organization membership — not on editable client user metadata. Treat roles as server-enforced. Admin capabilities are restricted to designated accounts and guarded routes; there is no separate “magic” admin login page.
Secrets
Platform secrets (database service keys, payments, mail, and other server integrations) live in server environment configuration. They are not shipped in Vite client bundles or VITE_* variables.
Your responsibilities
- Protect API keys and rotate them when people leave the org.
- Secure secrets inside your workloads (tokens in images, env files on disk, notebook cells).
- Follow the Acceptable Use Policy.
Report a vulnerability
Email security@okeymeta.com.ng with enough detail to reproduce. Please do not disclose publicly until we have had a reasonable window to investigate and fix.
General support remains at support@okeymeta.com.ng. Privacy questions are covered in our Privacy Policy.