Skip to content

The customer facing trust boundary

Know why a customer signed in to your Commerce surface can see their own records and nothing else.

Updated 23 September 2026

Why
Letting customers sign in is only safe if a customer can never read another customer's rows or your costs.
What
A separate kind of user, a customer, that is never a member of your organisation.
How
Each table a customer may read has its own customer policy, every other table returns nothing, and an access code is the only way in.

The rules the database enforces

RuleWhat it means
Never a memberA customer has no membership row, so every member check in the database is false for them by construction.
Zero rows elsewhereA customer reads nothing from any table outside a short allow list. A test walks every table in the schema as four customers and expects zero rows, so a table added later is covered without anyone remembering.
Their own rows onlyCustomer A never sees customer B's rows, in the same organisation or another.
No internal columnsCost, internal notes, storage paths and approval tokens are reached only through views that leave them out.
Read under the database's rulesThe customer surface queries as the signed in customer, never with elevated access, so application code cannot widen what a customer sees.

The only way in

  • Each customer record gets an access code, issued by you. Redeeming it links the signed in person to that customer and nothing more.
  • Codes are long and random, and redemption is rate limited by address, by account and by organisation. A code that does not work always gets the same answer, so a guess learns nothing.
  • A session is bound to one host: signing in on one supplier's address gives no session on another's.
  • Nobody can create a workspace from a customer address.

Switching Commerce off makes the whole surface unreachable at the database, with every row kept. The customer AI is off until you switch it on and is pinned to the same rows.