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, SCIM provisioning and an administrative kill switch are not built. The beta is a small number of design partners with one organisation each, onboarded manually.

Other solutions