Solutions
What can a colleague see when I invite them into a Thread?
Updated
Exactly the one Thread you invited them into — that job's plan, its notes, its board — and nothing else. Your other Threads, your note library and your account Vault are never part of an invitation. Remove them and that Thread's key rotates, so what remains is unreadable to them, and Forkbench names the secrets they already had.
Sharing work with somebody is normally a decision you make once and then cannot inspect. You add them to the org, the shared folder, the project, and from that point what they can reach is whatever the tool decided that means. Before putting a client's work and your own side project on the same machine, it is fair to want the answer stated exactly rather than implied.
The reason the boundary is exact is that each shared Thread carries a key of its own, so admitting somebody to one job is the only thing admitting them to one job can do. Their rung then decides what they may do inside it: read, comment and answer a blocked agent, or create and claim work and run their agents there. What crosses is the board and what you granted the Thread; terminals and code do not sync between people, and neither does your account Vault. Removal is the same mechanism run backwards. Demoting somebody below the line where they held a key rotates that Thread's key and re-seals it, which is a revocation rather than a name struck off a list — and the roles themselves cannot mint access, because a role lives in a server row and a key only exists because one of your Macs sealed it. Somebody who appeared in that row without a Mac having sealed anything would read the board and open nothing.
How it works
- 1Invite per Thread, not per person. The invitation is the job, so there is no wider surface to accidentally grant.
- 2Set the rung deliberately: Viewer to read, Commenter to answer questions, Contributor to run agents on the work.
- 3Grant the Thread only the notes and secrets that job needs before you invite. What it holds is what they get.
- 4Remove them when the work ends. The key rotates and the remaining material is re-sealed.
- 5Read the list of secrets they already had, and rotate those at the provider.
Straight about the guarantee: Removing somebody governs what they can reach from now on. A credential they already used is a credential they were already given, which is why removal names them for you to rotate rather than pretending they can be recalled. Three things are never copied into a shared Thread at all: a signing key, a secret locked to a destination, and a credential that could be issued narrower.