Lesson 18.1218.12 What else carries the company

In everyday life. In a hotel, your room number goes everywhere you do: on your luggage tag, on each meal's bill, in the log of each key-card swipe. The laundry allowance is per room, not per guest, so one large family does not use up the whole floor's machines. And when a guest asks for a room that is not ready, the desk says so, instead of handing over someone else's key.

What you will learn. The four other places a request's company must travel: what the connector hands out, what it counts, what it records, and what it says when there is no data.

Why it matters. A connector can check every token perfectly and still leak through a page handle or a log, or let one busy company slow the rest.

One request, start to finish. Ana asks for all open invoices, page by page. Later the same morning, Luis asks about Cedar Ridge's invoices.

1. Ana's first page comes with a sealed page handle that now records Brightline and Ana.
2. Her app sends the handle back for page two. The connector checks that the handle's company and person match her token, and continues.
3. Every call counts against Brightline's limit, and Ana's own smaller limit inside it.
4. Every call writes a log line naming Brightline, Ana and her app.
5. Luis's call gets "No AP data is connected for Cedar Ridge Supply yet.", because Cedar Ridge has no data in this chapter.

What else must carry the company?

18.11 kept the company straight inside the connector. These four rules carry it into everything the connector leaves behind or hands out.

Rule 4. Page handles record the company and the person

Before: a handle said only "page 2, from the shared key". Now it says "page 2, for Ana, at Brightline", and it is marked version 2, so older handles are refused. The connector refuses a handle if its company or its person differs from the token's, and the person is told to start again from page one. Why the person too, even inside one company? A handle marks a place in one person's list. Another person might have different permissions, and the handle would also tell them what the first person was looking at. Test: a handle made for Ana is refused with Priya's token, and a Brightline handle is refused with any Cedar Ridge token.

Rule 5. Limits are counted per company

A rate limit caps how many calls a caller may make in a short time. If it were counted per person only, a company with fifty people could crowd out a company with three. That is called the noisy neighbor problem: one busy customer slowing everyone else, or running up costs. So the limit is counted per company, with a smaller one per person inside it. Test: using up one company's limit leaves the other's untouched.

Rule 6. Every log line names the company, the person and the app

A log is the record a server writes as it works (Chapter 17). Every tool call writes one line, refused calls included. It names the company, the person, the app, the tool, the outcome and how long the call took, and never the token, the inputs or the result. A call refused before its token is checked has no company or person to name, so it writes no line. 18.16 builds on this. Test: the log line for a call holds all three and no token.

Rule 7. A good token for a company with no data gets a clear message

"No AP data is connected for Cedar Ridge Supply yet." Never an empty list, which would look like "no invoices due", and never another company's data as a fallback. Test: a Cedar Ridge token calling each tool gets exactly that message.

Where does this chapter's guarantee stop?

After these seven rules, the connector knows exactly who is asking and for which company, on every request, and chooses data by that company. One risk is left: a bug inside a tool, such as a forgotten filter, could still read the wrong company's rows. Here that cannot happen, because only Brightline has data. Chapter 19 puts both companies' data in one database and makes the database itself block it.

At work. A reviewer reads the TypeScript connector against the seven rules and finds that the rate limit counts per person only, so fifty Brightline people could each use their full limit at once, with no cap on the company as a whole. The builder asks Claude Code for a failing test first, then a fix counted per company and per person.

The operating rule: tie handles, limits and log lines to the company and person from the token, and give a company with no data a clear message, never someone else's data.

What Chapter 19 adds: each company's data and settings kept apart in the database, row by row, and errors that never reveal that another company exists.

Figure 18.15. Four more places the company travels: handles, limits, logs, and the no-data message.