Collect nothing by default

That list is the precondition for the agent doing anything at all. A device that enrolls and receives no list does not fall back to reporting everything. It fails to enroll:

tok.AllowedAccountEmails = identity.NormalizeEmails(tok.AllowedAccountEmails)
if len(tok.AllowedAccountEmails) == 0 {
	return Token{}, errors.New("enroll: response contained no allowed account emails")
}

That refusal is the point. An enrollment that succeeds with an empty policy and starts capturing is the bug you cannot afford once, so an agent whose safe state is off has to refuse to start rather than start permissively. The list itself never leaves the machine.

A single check is a single line to get wrong, so the same list is enforced at capture, at forwarding, in the developer’s own menu bar, and at enrollment. The forwarding check is three lines, and its shape is the whole design:

func accountAllowed(email string, allowed map[string]bool) bool {
	return allowed[identity.NormalizeEmail(email)]
}

A map lookup with no default: an account nobody has approved is not on the map, and what is not on the map does not travel. Normalisation carries more weight than it looks. An address that differs by case or whitespace is the same account to a person and a different key to a map, so one rule normalises it everywhere it is compared, stored or sent.

Enrolling with a company email covers the company’s accounts and deliberately nothing else. The others are not always outside the org’s interest, though: a developer may be doing company work on a subscription that is not on a company seat, and that spend is real.

So an account can be added, and the sequence is the point. The developer offers it and cannot approve it; the admin approves and cannot originate it. A console that could attach a personal address without the person acting would be the feature this design exists to prevent, and a device that could bind an account by asserting it would let someone claim a colleague’s. An approval reaches the machine on the next ten-minute read, and capture begins without a restart.

An allowlist that can only grow is not a control. An admin can issue, rotate or revoke a device’s token in the console, and that is the off switch.

The care is needed on the machine, because two different situations look identical from inside a failed request: a revoked token, and a laptop on a plane. So the device refuses to draw conclusions from silence. A failed refresh keeps the credential it already holds:

emails, err := enroll.FetchAllowedAccounts(client, apiBaseURL, enrollment.Token)
if err != nil {
	return
}

An empty answer gets the same treatment, and so does an enrollment that arrives with no accounts. The device never switches itself off because of something it heard from the network.

What stops is the flow, and it stops at the collector. A few consecutive rejections flip the daemon’s reported state, capture keeps running locally, and the developer is told telemetry is paused rather than left to guess.

That asymmetry is deliberate. On what leaves the machine, the default is no. On whether the agent is working, the default is to say so loudly. Something quiet in both directions is something nobody can audit.

Surfacing an uncovered account creates a trap. If the app warns about every account it is not collecting, and the only way to clear the warning is to link it, the interface is pressing toward disclosure while appearing to respect the choice.

So dismissal is its own state, separate from linking. A developer can acknowledge an uncovered account and keep it uncovered. Not linking a personal account is an outcome the product supports, not a task left undone.

The hardest case is the one where the account cannot be determined at all. Some routes reach a model with no login behind them, so the device can see that spend happened without being able to say whose it was.

Treating unknown as excluded loses information the org needs. Forwarding it is worse:

normalized := identity.NormalizeEmail(email)
slot, ok := s.accountSlot[normalized]
if !ok {
	if normalized == "" && len(s.accountSlot) > 0 {
		return StateUnattributed, ""
	}
	return StateFiltered, ""
}
return allowedState, slot

So it stays on the device, counted separately from a decided exclusion and never sent: reporting usage with no established owner is exactly the leak the list exists to prevent. If you build one of these, design this state before you need it.

Asking for folder access on someone’s work machine deserves a straight answer about what happens next. The agent reads session files for token counts and resolves a working directory to a repository name. It sends 36 metadata fields, among them tokens, model, timestamps, latency, cost, a session id and the repository name. It does not send prompts, responses, API keys, file paths or the developer’s email, and that list is published in full. It sits outside the request path, so it cannot slow down or stop a coding session, and it does not cap or block usage.

Collecting nothing by default has a cost, and the cost is silence.

We hit it on our own machines. An account was not on the list. Its sessions were dropped at capture, exactly as designed, and nothing said so. The numbers were not wrong, only short by a slice. The single symptom was an absence.

The fix is the account list in the app: every account it finds, and whether this enrollment covers it. An exclusion is now something you see, not something you work out. Detection is careful about its own limits too, so an empty result reads as “we could not detect any”, never “you have none”.

That is the trade. A permissive agent warns you by showing data you did not expect. A restrictive one says nothing, and saying nothing looks exactly like working. If you exclude by default, budget the same effort for making the exclusions visible.