Per-action RBAC, re-checked every request
Every server action and API handler opens with a fresh authorization check against the database — never a cached token claim. The UI hides what a role can't do; the server always re-checks.
Security architecture
Security built to survive its own audit
We sell assurance. A platform that holds your risks, policies and audit evidence has to withstand the same scrutiny it helps you apply — so authorization is re-checked on every request, the audit trail is protected by the database itself, and stored credentials are encrypted at rest and never returned by any API.
Per-request authorization checksAppend-only audit trailAES-256-GCM encrypted secretsTLS · HSTS · CSP
Defense in depth
Six layers, none of them optional
The controls your own ISO 27001 or SOC 2 program expects of any vendor — built into the architecture, not bolted on afterwards.
An audit trail that can't be rewritten
The audit log is append-only and protected at the database level: a database trigger blocks updates and deletes, and the application connects as a restricted database role that holds no such grants in the first place.
Secrets encrypted, never echoed back
Connector, SMTP and SSO credentials are encrypted at rest with AES-256-GCM under an instance master key — and no API ever returns them.
Hardened authentication
TOTP-based 2FA, SSO via OIDC with claim mapping and just-in-time provisioning, configurable password policy and account lockout, plus session listing and revocation for administrators.
Hardened in transit and at the edge
TLS everywhere — through the bundled proxy option or your own — with HSTS and secure cookies, a strict CSP, and rate limiting on login and API endpoints.
Workspace isolation, tested per module
Every row is scoped to its workspace and that scoping is enforced at the action layer — and each module ships an isolation test proving two workspaces can never see each other.
On-prem posture
On-prem means on-prem: nothing leaves your network
The same code runs in the cloud and on your own servers — but on-prem, it runs entirely on its own.
- No outbound calls required: the product operates fully offline.
- Licenses are Ed25519-signed files verified offline against a public key baked into the build — no license server, no phoning home.
- No telemetry by default; error reporting is strictly opt-in and stays your decision.
- Documented network ports and least-privilege service accounts on Windows Server.
Outbound network callsNone required
License verificationEd25519Offline
TelemetryOff by default
Audit log update / deleteBlocked
Windows service accountsLeast privilege
The model
From least privilege to proof on demand
- 01
Least privilege by default
A user gets the union of their assigned roles and nothing more — and the application itself connects to the database as a restricted role with no destructive grants.
- 02
Verify continuously
Authorization is re-checked against the database on every single request, and sensitive transitions — like risk acceptance — go through a recorded approval chain.
- 03
Record immutably
Every mutation, login and security event — an SSO configuration change, a role change, a license upload — lands in the append-only audit trail with an actor snapshot and a diff.
- 04
Prove on demand
When your auditor asks who changed what and when, the answer is filterable, paginated, and impossible to have quietly edited after the fact.
Frequently asked questions
Where does our data live?
Wherever you decide. In the cloud, your workspace lives in our managed environment, with every row scoped to your workspace and isolation tests shipped per module. On-prem, everything lives on your own infrastructure — Docker on Linux or natively on Windows Server — and the code path is identical in every deployment.
Can UniSentinel see our on-prem data?
No — nothing leaves your network. An on-prem instance requires no outbound calls: the license is verified offline, telemetry is off by default, and error reporting only happens if you explicitly opt in.
How is the audit trail tamper-resistant?
Three layers: the log is append-only, a database-level trigger blocks updates and deletes, and the application connects as a restricted database role that has no update or delete grants on the audit log at all — so even a platform administrator working through the app cannot rewrite history.
Which SSO providers work?
Any OIDC-compatible provider — Microsoft Entra ID, Okta, Google and others. You configure the issuer and client credentials, map claims to user attributes, provision users just-in-time with a default role, and can disable local login entirely.
Get started
See UniSentinel running on your terms
Book a 30-minute walkthrough. We'll map your program to the modules you need — cloud, on-prem Linux or Windows Server.
Every module works standalone. License only what you need — grow when you're ready.