Solutions

Many tenants, many policies, one boundary

Tenancy is derived from the credential and never from the request body. A request that names an organisation it does not belong to is refused, not quietly redirected.

The problem

Multi-tenant AI platforms usually enforce isolation in the handler. One refactor later, a filter is missing and an id from the request body is enough to read another tenant's data.

How Planverity addresses it

Isolation at the query

Every tenant-scoped read filters by organisation in the SQL, not in application logic. An execution id alone is never enough to read another tenant's manifest — verified with a real second tenant, which receives a 404 rather than a 403, so the response does not even confirm the id exists.

Disjoint machine credentials

API key scopes are disjoint, not hierarchical: an admin key cannot execute inference and a data key cannot configure. Neither is a superset, so a compromised key of either kind is bounded rather than merely limited.

Deny-all at the database

Row Level Security is enabled with no permissive policies on every table. The application connects through a privileged path by design; the anon surface reads nothing.

Beta scope

SSO and SCIM provisioning are not built, so accounts are created and removed by hand. An administrative kill switch does exist: an organisation can be suspended, and the check runs at authentication so it takes effect on the very next request rather than when a cache expires. The beta is a small number of design partners.

Other solutions

Many tenants, many policies, one boundary · Planverity