Security & trust
Compliance data is sensitive, and Oblifee is built so that your workspace's data stays yours. This section explains, in plain terms, how the platform is architected and hardened. It is written to be useful both to a buyer doing due diligence and to an administrator running a workspace.
Principles
- Isolation by default. Every workspace's data is separated at the database level, not just in application code. See Tenant isolation.
- No standing secrets in the app. The application authenticates to its database with short-lived managed-identity tokens, and pulls other secrets from a vault at runtime - there is no database password stored anywhere. See Secrets & managed identity.
- Identity you already trust. Sign-in is handled by managed identity providers, not a password table Oblifee maintains. See Authentication.
- Least data. Integrations pull only the product and volume data compliance needs. See Data handling.
- Defence in depth in the browser. A strict Content Security Policy and related headers limit what a page can do. See Application hardening.
Architecture at a glance
The app runs on Azure. It reaches the workspace database only through an identity that is granted the minimum it needs, and every query runs under row-level security keyed to the current workspace. The regulatory brain is a separate, read-only dataset.
In this section
- Tenant isolation - row-level security and how one workspace can never see another's data.
- Authentication - how users sign in and how sessions work.
- Secrets & managed identity - why no database password exists, and how secrets are pulled at runtime.
- Data handling - what is stored, where, and for how long.
- Application hardening - Content Security Policy, headers and safe rendering.
- Regulatory brain integrity - how the cited dataset is protected and kept read-only.
:::note Responsible disclosure Found something? Contact us via the help centre. We take security reports seriously and will work with you. :::