Security
Your traffic, your data, kept apart.
Compass sits on the path of every AI request your organisation makes, so it is built to hold as little as it needs, protect what it holds, and show you what it did.
Tenant isolation
One cell per tenant.
In shared deployments, each organisation gets a complete, separate gateway rather than a row in a shared table.
- Its own database, settings, keys, connections, limits, caches and live feed. There is no shared table with a tenant column to forget to filter.
- Requests are routed to a tenant before any tenant code runs, by sign-in, session, key or token. A key or session from one tenant presented to another is simply not found.
- Each tenant's encryption key is derived for it alone. A stored provider key or backup copied from one tenant cannot be opened with another's.
- Who may sign in is fixed by the platform: a tenant administrator cannot repoint the identity service or widen who gets in.
- Someone naming an organisation that does not exist, is suspended or has been removed gets the same answer as a wrong password, so organisations cannot be enumerated.
Access and audit
Who did what, provably.
- Sign-in, roles and permissions come from your CEEZ AI identity service, and a role change there takes effect within the permission window.
- Team members see only their team's calls, tokens and spend. Organisation-wide pages are closed to them and hidden from their menu.
- Administrative actions are written to a hash-chained audit log: a deleted or edited row is detectable, and you can verify the chain and export it.
- Platform staff entering a tenant are recorded in that tenant's own audit log, where its administrators can see it.
- Sign-in is rate limited per account and per address, with lockout, and across organisations.
Data controls
You decide what is kept.
- Store prompts and replies, or store none. Tokens, cost and timing are recorded either way.
- Redact emails, keys and card numbers from stored previews, set retention in days per organisation, team or project, and purge or scrub on demand.
- Provider keys are encrypted at rest. Compass API keys are stored only as hashes and shown once.
- Database backups are encrypted at rest with the tenant's own key, verified before they are stored, and restorable.
- The master encryption key can be rotated: every stored secret and backup is re-encrypted, and a rotation that cannot open every secret changes nothing.
Hardening
Defences against the usual attacks.
- Server-side request forgery: provider, webhook and collector addresses must be public. Private, loopback, link-local and cloud-metadata addresses are refused, names are resolved and checked before every call, and redirects are never followed.
- Denial of service by pattern: tenant-written regular expressions are test-run for catastrophic backtracking before they are saved and run under a time limit every time.
- Browser protections: a strict content policy, no framing, no content sniffing, HSTS over TLS.
- Supply chain: no runtime dependencies at all, so there is no dependency tree to poison.
- Guarding what leaves: optional guardrails detect and mask or block personal data, secrets and injection attempts before a request goes to a provider.
What is not claimed
Being straight about it.
- Compass has not yet been through an independent penetration test or a SOC 2 or ISO 27001 audit. If your review needs either, tell us early.
- Stored prompts and replies sit in clear text in the database unless you turn text storage off. Run it on an encrypted disk.
- In shared mode, tenants share one process: very heavy use by one can slow others. Single-sign-on is not yet supported in shared mode.
- Put it behind TLS and a reverse proxy, as you would any service that handles credentials.