Tenant isolation
Every customer is an Organization. Every tenant-scoped table carries an organisation identifier, and isolation is enforced at the application layer.
- Row-level scope enforcement
- Cross-tenant queries blocked
- Automated isolation tests
Security & Architecture
Tenant data is isolated at the application layer.
An AI governance platform holds an organisation's most sensitive inventory: which team does what, with which data. That is why isolation, identity and auditability are designed in from the start.
Foundations
Three foundational architecture decisions
Tenant isolation, strong identity and tamper-evident records.
Identity and access
Connect to your corporate identity provider with per-tenant OIDC configuration; where local login is used, TOTP-based multi-factor authentication is mandatory.
- Per-organisation OIDC/SSO
- Mandatory TOTP MFA
- Short-lived access + refresh tokens
Audit and accountability
Every critical action, including permission changes, is written to the audit trail with its actor and rationale, and can be exported.
- Actor, action, entity and metadata
- Role assignment records
- Export for audit
Multi-tenancy
One tenant's data is never visible to another.
On a multi-tenant platform the biggest risk is a single query that accidentally escapes its scope. That is why isolation is a tested behaviour, not a hoped-for assumption.
- An organisation identifier is mandatory on every tenant-scoped table.
- Access scope is constrained at the application layer by the session's organisation.
- Cross-tenant super-admin authority is separated behind a distinct flag (
is_platform_owner). - Tenant isolation is continuously verified by the automated test suite.
Role-based access at the data level, not the menu level
A spoke representative sees only their own business unit's inventory, and that constraint is applied through query scope rather than by hiding parts of the interface. A request that bypasses the UI and calls the API directly hits the same boundary.
Controls
Application security controls
The following controls are part of the platform's standard configuration.
| Area | Control | Note |
|---|---|---|
| Authentication | OIDC/SSO or local password with bcrypt | Configured per tenant |
| Multi-factor authentication | Mandatory TOTP MFA | Required for local password login |
| Session | Short-lived access token + refresh | Role claims mapped at token issuance |
| Authorisation | Role-based access control (RBAC) | Scope enforced at the data layer |
| Transport security | HTTPS/TLS | Terminated at the reverse proxy |
| Application headers | Security headers and CORS policy | helmet-based configuration |
| Abuse prevention | Rate limiting | Tightened on authentication endpoints |
| Input validation | Schema-based request validation | On all write endpoints |
| Auditability | Central audit trail and structured logging | Exportable |
Responsible disclosure
If you found a vulnerability, we want to hear about it.
We take reports from security researchers seriously. Please send your finding to our security team together with reproduction steps. We will confirm receipt and keep you informed as the process progresses.
- Give us a reasonable remediation window before disclosing publicly.
- Do not access customer data, modify data or disrupt the service.
- Test only against your own tenant and your own account.
- State reproduction steps and impact clearly in your report.
Let us run a technical session with your security team.
Discuss architecture, data residency and deployment model questions directly with our engineering team.