Purchasing · two customers
Two customers, one hub.
The same files, the same table.
Their orders carry the same numbers.
Fictional customers · synthetic data
The problem
A shared table can leak.
- A forgotten filter shows the other's rows.
- SQL generated by a model does not know the customer.
- A guessed id opens a run.
Nothing is duplicated
One hub, one table, two customers.
- The customer comes from the Keycloak token.
- Every row carries its tenant_id.
- The database filters every read.
A 56-line scenario, two declaration files.
The same question
SELECT COUNT(*) FROM "connector"."v_tenants_order_b"
WHERE "status" = 'cancelled'The same SQL, two answers: 26 and 5.
The model's SQL runs under the token's customer.
Each their own rows
PO-2025-0001 exists twice.
- Customer A: 240 orders, SUP-006.
- Customer B: 60 orders, SUP-104.
- Neither sees the other.
Replay of 3 November 2026, Keycloak OIDC.
The closed door
Customer B asks for customer A's run.
API error 404: run … not found
As for an id that does not exist.
The limit
The customer is a Keycloak attribute.
- Creating it stays an admin task.
- Customer A also administers its tenant.
- The model's answer can vary, the filtering cannot.
Try it
The scenario replays end to end.
Two tokens, one table, one question: every step is published with its output.