Trust / Tenant isolation
Two walls, because one of them is written by people
Every subscribing organization is an isolated tenant. Isolation is enforced twice, independently, by two systems that would both have to fail on the same request.
This is the first question a carrier’s security review asks and the one where vendors are vaguest. Here is the whole mechanism, in enough detail to check.
Bring your security reviewCould another organization’s query ever return our rows?
Not through one mistake. The application resolves your organization from the session and scopes every query to it; the database independently refuses rows that do not belong to the connection’s tenant. A single bug defeats neither wall on its own, which is the entire point of having two.
Wall one, then wall two
How a request gets scoped, twice
- 01
The organization comes from the session
Never from the request body, never from a query parameter, never from a header a client controls. A caller cannot name a different organization because the platform does not accept the value from them at all — there is no parameter to tamper with.
- 02
Every query is scoped in the application
Data access is filtered by the resolved organization at the application layer. This is the wall most platforms stop at, and on its own it is only as good as the developer who wrote the last query.
- 03
Row-level security is enabled and forced
PostgreSQL row-level security is turned on for tenant tables and set to FORCE, which means the policy applies to every connection — including the table owner and administrative connections that would normally bypass it.
- 04
Policies cover organization and tenant
The policies check both dimensions, so a query that somehow escapes application scoping still returns nothing. The database is the wall that does not depend on anybody remembering to write a WHERE clause.
- 05
Machine identities are scoped too
Service principals — the identities behind batch jobs and integrations — carry the same tenant scope. A scheduled job cannot see across tenants any more than a person can.
What a reviewer can verify
Claims a security team can actually test
Every line here is a statement about the running system that can be checked in a session with your engineers present, rather than a posture described in a brochure.
| Control | How it is implemented |
|---|---|
| Tenant resolution | From the authenticated session only; no client-supplied organization identifier is accepted anywhere |
| Application scoping | Query-level filtering on the resolved organization across all data access |
| Database enforcement | PostgreSQL RLS ENABLE + FORCE on tenant tables, applied to every connection including owners |
| Policy dimensions | Policies evaluate both organization and tenant |
| Administrative access | Waypoint’s own Operator console cannot read claim content; claim identifiers are stripped from operator views |
| Service principals | No interactive login, cannot be assigned to a person, tenant-scoped like any other caller |
| Verification | The restore drill’s final check is reading a real customer name on screen — a row count cannot prove decryption worked |
What two walls do not give you
Isolation is about one tenant reaching another. It is not a claim about every other risk, and treating it as one is how security reviews get misled.
Not a substitute for access control
Isolation stops cross-tenant reads. Within your own tenant, what a person may see is governed by entitlements and roles — a different mechanism, documented separately.
Not a compliance certificate
These are engineering controls, described precisely. Where you need an attested audit, ask us for our current certification position rather than inferring one from this page.
Shared infrastructure
This is a multi-tenant platform. If your requirement is physically dedicated infrastructure, say so early — the honest answer may be that we are not the right fit.