Lesson 18.1018.10 Where the tenant comes from

In everyday life. At a bank, you cannot take money from an account by saying its number. The teller asks for your card or ID, checks that you are on that account, and only then serves you. Saying "I'm with the Smiths" does not make it so.

What you will learn. The one place a connector may learn which company a request is for, and how the company gets there.

Why it matters. Anything else a request says about its company can be false, and one wrong source lets one company read another's data.

One request, start to finish. Priya works for both Brightline and Cedar Ridge. In her Brightline chat she asks, "Which invoices are due this week?"

1. When she connected this chat, she picked Brightline on the consent screen.
2. The sign-in server checked her membership in Brightline, found it, and sealed tenant: org_brightline into her token.
3. Every request from this chat carries that token. The connector reads the company from it, and only from it.
4. She gets Brightline's invoices.

Later, in a second chat connected for Cedar Ridge, she asks the same question. That chat holds a different token, made when she picked Cedar Ridge, and gets Cedar Ridge's answer. Neither chat ever mixes the two.

Where does the company come from?

The one rule: the company comes only from a checked token. Never from:

• a header, such as X-Tenant: brightline
• a tool's input, such as company: "Brightline"
• the address the request was sent to
• anything the model writes, such as "I'm asking for Brightline"

All of these come from the request, and a request can say anything. The token is different: the sign-in server made it after checking the person, and its seal proves nobody changed it since.

How does the company get into the token?

Three steps at the sign-in server, during sign-in:

1. The person picks the company on the consent screen. It lists only companies where they have a membership.
2. The sign-in server checks the membership again when it makes the token. A pick for a company where they have no membership is refused, even if someone crafts the request by hand.
3. It seals the company into the token as the tenant claim, beside the role's scopes.

Which unusual cases are decided in advance?

• A person in two companies gets two separate sign-ins. Each AI app connection holds one token for one company. Switching company means signing in again and picking the other. The connector never switches for them.
• A token with no tenant claim is refused with 401. A token whose company exists but has no data connected is not refused. Every tool answers with a clear message, such as "No AP data is connected for Cedar Ridge Supply yet." (rule 7 in 18.12). That is Cedar Ridge in this chapter.
• A person who leaves a company keeps their token until it runs out, at most 10 minutes (18.6). Brightline's sign-in server checks the membership again whenever the app asks for a fresh token, as its own rule (18.6), so their next attempt fails.

At work. In Lab 18, Task 13, the builder signs in as Priya twice, once per company, in two chats, and asks the same question in each. One answer lists Brightline invoices. The other is the clear message for a company with no data yet (18.12, rule 7). Neither ever shows the other's.

The operating rule: the company is chosen by the person at consent, checked by the sign-in server, sealed into the token, and read by the connector from the token alone.

What Chapter 19 adds: the database itself checks the company on every read, so a mistake in the connector's code still cannot return another company's rows.

Figure 18.13. The company is picked at consent, checked against the membership, and sealed into the token. Nothing else sets it.