# 18.14 A company's life, in the sign-in server (/building-ai-workers/securing-connectors/a-companys-life)

---
type: Document
title: "18.14 A company's life, in the sign-in server"
description: "Onboarding, changes and offboarding a company in the sign-in server, and who may do each step."
status: stable
order: 318.14
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-02T18:20:57Z
chapter: "18"
part: III
expert_status: builder-only
concepts: [ "18.14" ]
objectives:
  - { id: CCDV-F.D2.S2, label: supporting }
last_verified: 2026-11-02
generated:
  at: 2026-11-02T18:20:57Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** An office building's front desk issues badges when a company moves in, adds and removes badges as people join and leave, and when a company moves out, cancels every badge. The desk does not clear out the company's filing cabinets. That is a different job, done by different people.

**What you will learn.** How a company comes in, changes and leaves in the sign-in server, and who may do each step.

**Why it matters.** Access that nobody takes away stays. So each step needs someone responsible for it, and a way of doing it that leaves a record.

**One week, start to finish.**

- **Monday, a company comes in.** Cedar Ridge Supply signs its contract. You create the company in the sign-in server, acting as the **platform operator**: the person who runs the connector for every customer company. Here that is you, the builder. It is not the same as a company's own `admin` role. Luis is its first `owner`. At his request you also add a colleague, Marco, and Priya, their outside bookkeeper, with their roles. Later, Luis can add people himself. Before anyone signs in for real, the sign-in matrix ([18.13](proving-the-sign-in-keeps-companies-apart.md)) runs against the new company.
- **Wednesday, a person leaves.** A contractor at Brightline finishes. Ana, Brightline's `owner`, removes their membership. The contractor's token works for up to 10 more minutes, then their app's next request for a fresh token is refused.
- **Friday, a company leaves.** A company that tried the connector for a month does not continue. You stop new tokens for the company. You delete its refresh tokens, so no app can get a fresh token. You delete its consent records, the sign-in server's memory of each approval its people gave, so any future sign-in starts from nothing. Then you wait out the last tokens' 10 minutes. After that, nothing for that company is accepted anywhere.

### What are the steps in a company's life?

A company has a life in the sign-in server, and someone is responsible for each step.

**Onboarding**, bringing a company in:

1. Create the company in the sign-in server.
2. Add its first `owner`, who then adds the others.
3. Set roles. Each role maps to scopes ([18.7](permission-per-tool.md)).
4. Run the sign-in matrix ([18.13](proving-the-sign-in-keeps-companies-apart.md)) against the new company before its first real sign-in.

**During its life**, changes:

- *A role changes.* The new scopes arrive with the person's next token, at most 10 minutes later.
- *A person leaves.* Their membership is removed. Their current token works until it runs out. Their next request for a fresh token fails.

**Offboarding**, taking a company out:

1. Stop new tokens: the sign-in server records on the company itself that it takes no new tokens, and from then on refuses to make any for it, at sign-in and at every refresh.
2. Delete the company's consent records and refresh tokens, so no app can get a fresh token.
3. Wait out the last sign-in tokens' lifetime. After that, the company is gone from the sign-in server's point of view.

### Who may do each step?

A company's own `owner` or `admin` manages its people and their roles. The platform operator creates and removes companies, and fixes what an owner cannot. Both work through scripts or screens that check who is asking. Nobody changes the sign-in server's tables by typing database queries by hand, because a hand-typed change skips the checks and leaves no record. (There are two small exceptions in [Lab 18](lab.md). Task 2 adds practice rows by hand, and Task 5 adds one person to time a sign-in. Both go on a scratch copy on your own computer, and are deleted straight after.)

**What this chapter does not do.** Loading a new company's business data, exporting a leaving company's data, and deleting it are Chapter 19's.

**At work.** In [Lab 18](lab.md), Claude Code writes three scripts: one to add a company with its owner and people, one to change a person's role or remove them, and one to offboard a company. The builder asks for each change in plain words, and Claude Code runs the script and shows the `member` rows before and after.

**The operating rule:** bring companies in, change them and take them out through scripts that check who is asking, run the sign-in matrix on every new company, and remember that a removal takes effect when the token runs out, not instantly.

**What Chapter 19 adds:** loading, exporting and deleting a company's business data, and its plan records.

![A timeline for one company, left to right. Onboarding: create the company, add its first owner, add people and set roles, run the sign-in matrix. Changes: a role changes, with new scopes at the next token. A person leaves, and their next fresh token is refused. Offboarding: stop new tokens, delete consent records and refresh tokens, wait out the last token's 10 minutes. Each step is labeled with who does it: the company's owner or the platform operator. A greyed box: not done here, loading, exporting and deleting the company's business data. A note below: a removal takes effect when the last token runs out, not instantly.](img/chapter-18-company-life.png)

*Figure 18.17. A company's life in the sign-in server, from onboarding to offboarding.*