Trust & Safety Overview
How Optserv approaches security — defense in depth, tenant isolation, encryption, and operational best practices.
Optserv is built around the principle of defense in depth: security is enforced at multiple layers, not just in the UI. This section documents Optserv's security model so you can make informed decisions about trust.
Security layers
| Layer | What it does |
|---|---|
| UI gating | Hides navigation items and features the user's role can't access |
| Route checks | Server-side validation on every page load |
| RLS (Row-Level Security) | Database queries are automatically scoped to what the authenticated user can see |
| Edge Functions / RPC | Write operations validate role and company scope at the API layer |
No single layer is the only control. A user who manipulates the UI won't bypass route checks. A user who crafts direct API calls won't bypass RLS. Defense in depth means a failure in one layer doesn't expose data.
Tenant isolation
Every piece of data in Optserv belongs to a company. RLS policies ensure that queries from one company can never return data from another — even if two companies share the same database infrastructure.
See Tenant Isolation & RLS for technical details.
Encryption
Data in Optserv is encrypted in transit (TLS) and at rest (database encryption). Account Sharing uses an additional layer of client-side encryption — Optserv's servers never see plaintext credentials.
See:
What you should do
Security is a shared responsibility. Optserv handles the infrastructure layer — you handle the operational layer:
- Assign the smallest role that lets someone do their job
- Review Admin and HR access quarterly
- Offboard people promptly when they leave
- Rotate shared credentials when someone loses access
- Don't share Admin credentials across people