Lesson 22.922.9 Three identities, never one

Part C. Identity, secrets and companies. The heart of the chapter. Chapter 18 kept companies apart at sign-in, and Chapter 19 kept them apart in the database. This part keeps them apart across sessions. Four concepts, then Sitting 3a, which ends Milestone 1.

Four kinds of token you will meet in this part. The word means different things, so here they are side by side. The full list is in "Words this chapter uses".

A model token, in 22.5, is different again: a piece of text the model reads or writes.

Figure 22.13. Three tokens from one sign-in, and where each one goes. A model token is a different thing altogether.

In everyday life. An apartment building has three kinds of pass. The property manager holds a booking card that can only book a contractor's visit to the site, and nothing more. The cleaning company's badge only names who came in: it opens no door by itself. And each resident's key opens that resident's unit, and only it. When the cleaner enters Unit 7C, the cleaner uses the key that 7C's resident left for that purpose, and the lock records both the badge and the key. In this concept, the manager's booking card is like your product identity, the cleaning company's badge is like the worker identity, and each resident's key is like that person's delegated token.

What you will learn. Why a hosted worker involves three different identities, what each one may do, and why one identity for everything is the mistake.

Why it matters. A worker that runs as one powerful identity can be fooled into reaching anyone's data, and its logs blame the wrong person. Separate identities keep each mistake small and each record true.

One request, start to finish. The builder's first test script for the portal had one shortcut: it started every session with the builder's own API key, and sent every connector call with the builder's own sign-in token. Ana and Luis both tried it.

1. Ana asks about Brightline's invoices. The answer is right, because the builder's token is for Brightline.
2. Luis asks about Cedar Ridge's invoices. He gets Brightline's, because the builder's token is for Brightline.
3. The connector's logs say the builder asked both questions.
4. The builder leaves for a week. The builder's personal key is the only way the portal can start a session, and nobody else can rotate it (replace it with a new key).

One identity for everything, and every one of its problems showed up in a day. It was the shortcut Chapters 20 and 21 took on purpose: the worker ran as you, with a test token, and Lab 21's specification said so in its last row. Fine on your own computer, for testing. Wrong the moment a second person uses it.

Which three identities does a hosted worker involve?

A hosted worker involves three identities. Each answers a different question, and each gets only what it needs:

A delegated token is one a person allowed an application to use for them, through the consent screen of Chapter 18. It carries the person, the company in its tenant claim, and the scopes they agreed to. (A tenant is Chapter 18's word for one customer company, and this chapter says "company" wherever it can.) The connector checks it on every call, and the database keeps the company's rows apart from it (Chapter 19). So the worker can do only what that person may do, for that company.

Why must a worker never act as you?

Four reasons, each from the story above:

• Blast radius. A worker with the builder's rights can do anything the builder can, for every company the builder can reach. A mistake or an injection inherits all of it.
• Audit. The connector's log should say Ana asked, not the builder. Otherwise no one can answer "who saw this invoice?"
• Revocation. If Luis leaves Cedar Ridge, only his access should stop. If everything runs as the builder, removing Luis removes nothing.
• People leave. A product that runs on one person's key stops when that person does. A product identity belongs to the product, not to a person.

A worker can also act with an organization's own authority, not one person's. That is a different kind of delegated authority, and "Beyond this chapter" explains it.

Where does the product identity come from?

An API key is a long secret string that your server sends with every request to the platform, so the platform knows which account is asking and whom to bill. Make it for a service account, an account for a program rather than a person, so the key belongs to the product and keeps working when people leave. And give it an expiry date, so a key that leaks stops working on its own. In Half 2, 22.13 goes further.

What does least privilege mean for each one?

The product identity works in one workspace only, with a spending limit. The worker identity has no secrets of its own. The person's token has only the scopes the worker's tools need, and lives only in that person's vault.

At work. In Lab 22, Task 10b, after Ana's session runs, the builder asks Claude Code to show three things. First, which key started the session: the portal's, in the staging workspace. Second, the session's agent definition id and version. Third, the connector's log line for the tool call. The log line names Ana and Brightline, not the builder.

The operating rule: give the product, the worker and each person their own identity. Never let a worker act as you, and never let one person's token serve another person's question.

Figure 22.14. Three identities, each with only what it needs. One identity for everything is the mistake.