Setting things up…
Setting things up…
Loading security…
No badges, no certification claims we can't back up. Every control below traces to a specific piece of code, including the one place a control has a real limit — we'd rather say so than let you assume it doesn't.
Every stored credential — a mailbox token, a CRM token, LinkedIn session data — goes through the same chain before it's written to disk.
Held outside application code, never logged, never stored next to the data it protects.
Computed from the master key and your organization's ID — unique to your workspace, not shared across tenants.
Every stored credential gets its own key, generated fresh and wrapped by your organization's derived key.
The credential itself is never written to the database in the clear — reading it back requires your organization's key.
Each one maps to a specific route, table, or handler in the running product — not a policy document.
Mailbox tokens, CRM tokens, and LinkedIn session data are encrypted with a key derived specifically for your organization from one master key. Your organization's key exists only in relation to your organization — it isn't a shared secret sitting next to the data.
Account passwords go through bcrypt before they touch storage. There is no code path anywhere in the product that reads a plaintext password back out.
Reset a password and every other active login for that account is invalidated immediately — not on next refresh, not the next time someone tries to use it.
A login session, a paired Chrome extension, and a staff support session are signed with different secrets and expire on different schedules, so a compromise of one token type doesn't unlock the others.
When our staff open a workspace to help with support, they use a separate, time-limited session that is explicitly marked read-only — a write attempt under it is rejected at the server, not just hidden in the interface. Every administrative action any staff member takes is written to an audit trail.
Disconnect a paired Chrome extension, a connected mailbox, or any other linked account from your workspace settings whenever you want — no ticket required.
Files uploaded to WorkDrive are queued for a virus scan, and a file stays blocked from download until that scan clears it — if the scanner can't be reached, the file stays blocked rather than opening up. Ask your account contact to confirm scanning is actively configured for your workspace before relying on it for a compliance requirement.
A webhook destination you configure — a Slack alert, an outbound integration — is checked against an allow-list before LexisOS will call it, and every outbound webhook is signed so the receiving system can verify it came from us.
A file share link can carry its own password and an expiry you set, and every view or download against it is rate-limited and logged back to your workspace's activity feed.
Support and platform staff never use your normal login to view a workspace. They use a separate session, capped at 30 minutes, that is explicitly marked read-only — any write attempt under it is rejected by the server itself, not filtered out by the interface. Every action a staff member takes while assisting your account — opening a workspace, changing a setting — is recorded to an audit trail you can ask us to show you.
We'll answer in plain terms, point to the exact control above for each question, and tell you outright where something isn't built yet rather than let a form answer imply it is.
Talk to our team about how LexisOS handles your data, or start the free trial and see it yourself.