Security

API keys, HRIS integration tokens, and other secret-kind configuration values are encrypted at rest using AES-256-GCM before being written to the database. Each secret is stored with its own random IV and authentication tag; the encryption key is a dedicated environment variable, kept separate from the key used to sign user sessions, so the two can be rotated independently.

Values written before encryption was enabled, or saved while the encryption key was temporarily unset, are transparently decrypted-as-plaintext on read rather than treated as corrupted — the system is designed to fail open to "still works," not silently lose data, while every value gets encrypted the next time it's saved.

Company and organization data (rosters, skill inventories, retraining targets) is scoped server-side: every route resolves which company or organization the authenticated caller belongs to from the database itself — never from a client-supplied id in a query string or request body — before running any query. Public API keys are hashed at rest and are bound to exactly one company or organization; a key can only ever read data that belongs to the tenant it was issued to.

We do not currently rely on database-level row-level security (RLS) as the tenant boundary — that enforcement lives in this application-layer resolution step. This is a deliberate, audited design choice today, not an oversight, but it does mean tenant isolation depends on every new route calling the shared resolver correctly rather than on a database policy that fails closed by default.

All traffic to SkillOS is served over TLS. Passwords are hashed (never stored in plaintext or reversibly encrypted). Authentication uses a single signed session cookie re-validated against the live database record on every privileged request — a revoked or demoted account loses access immediately rather than waiting for a cached token to expire.