Isolation you can point at.
OmniIntel is multi-tenant by design, which makes tenant isolation the control that matters most. This page describes how it is enforced, what is logged, and what we have not yet certified.
Where isolation is enforced
Tenant isolation
Row-level security, enforced by the database
Every tenant-scoped table has FORCE ROW LEVEL SECURITY enabled and is filtered on a per-request tenant identifier set as a Postgres session variable. Isolation is enforced by the database itself, not by remembering to add a WHERE clause in application code.
No cross-tenant reads, including for staff
Platform administrators can act on a tenant, but that action is scoped and written to the audit trail. There is no code path that lets an ordinary org role widen its own tenant scope.
Sub-tenants inherit, they don't share
MSSP parents can create nested organisations. A sub-tenant's indicators, documents and keys stay in that sub-tenant; the parent sees management surfaces, not the child's private intel.
Authentication & access
Passwords hashed with bcrypt at cost 12
Credentials are never stored or logged in plaintext. Sessions are server-side records referenced by an httpOnly, SameSite cookie, and are invalidated on password change, suspension and sign-out.
Capability-based authorisation
Six organisation roles map to a fine-grained capability catalogue, and each capability is checked server-side at the point of use. Per-user grants can only add capabilities on top of a role — never silently remove the checks.
Scoped API keys
Keys are tenant-scoped, minted per profile, and revocable individually. Requests are rate-limited per key with a per-plan burst ceiling.
SSO and MFA
SAML single sign-on is available on workplace plans. Time-based MFA is available to every account from the account settings page.
Data handling
Region pinning and KSA residency
Tenants can be pinned to a region so their data is stored and processed in it. KSA-region tenants are never routed through non-KSA infrastructure — a hard constraint, not a configuration default.
Provenance retained with the data
Retained documents keep their source, fetch time, confidence and an Admiralty reliability code. Answers cite the specific document behind each claim, so you can audit what a conclusion was based on.
Encryption in transit
All traffic is TLS-only. Third-party credentials stored on your behalf are held in a separate credential vault, not alongside tenant content.
Auditability
Privileged actions are logged
Role changes, plan changes, suspensions, key lifecycle, capability grants and advisory publishing all write an audit_log row recording the actor, target and time. Audit retention runs to 36 months on enterprise agreements.
Retriever traces on every answer
API responses include which retrievers ran, how many hits each returned and how long each took — so an unexpected answer is diagnosable rather than opaque.
What we don't claim yet
Security pages tend to imply certifications by leaving them out. Ours are listed explicitly.
- SOC 2 Type II — not yet certified. Happy to share our control descriptions and answer a security questionnaire in the meantime.
- ISO 27001 — not yet certified.
- Third-party penetration test report — in progress; contact us for current status.
Disclosure
Email [email protected] with steps to reproduce. We acknowledge within two business days and will keep you updated until the issue is closed. Please don't run automated scans against production tenants or access data that isn't yours — tell us what you found and we'll reproduce it in a controlled environment.