Skip to content
Oznog

6.1 · operations and agents · after redaction

The distinct key, and identities for agents at the speed they arrive

date
20260811
what happened
During bring-up on 20260811, Christoph let the fleet's agents share one operating-system account, with a distinct key per agent, rather than build an account per agent or per role for a fleet whose shape was not yet known.
what it cost
A named, accepted risk, taken for bring-up speed. Agents that share an account share its reach, so any one agent's key reaches whatever the account reaches.
what changed
Attribution and revocation come from a distinct credential per agent, never a shared one. The direction since is identity issued by a program: credentials that are short-lived and scoped to the job, from the secrets vault, because agents can arrive faster than anyone can make accounts for them by hand.
the check now
Per-agent keys and per-service token names tell agents apart even where the operating-system account does not, and a single agent's key can be revoked without touching any other.

Anyone building a fleet operated by several automated actors meets this question in the first week. Does each actor get its own operating-system identity, or do they share one? On 20260811 Christoph chose to share, for bring-up. Building per-role privilege boundaries before the fleet’s real shape was known would have slowed every deployment and baked in guesses that would later have to be unpicked.

The trade-off was written down rather than hidden. Agents that share an account share its authority, and one leaked key reaches whatever that account reaches. It was accepted as a cost of bring-up, with narrowing it on the open list.

What the decision bought was attribution without isolation. It holds only because of a second rule that costs almost nothing to keep. No two agents ever share a private key or an API token, even where they land in the same account. Revocation is then per agent, and so is the record of who did what. By the collection of 20260920 the fleet repository’s 2,024 commits split cleanly by author field between two AI agents and one human, which is the evidence that attribution works without operating-system separation.

The larger lesson is that an agent is an identity, and deserves what a person gets: an account, credentials of its own, a record, and a way to be removed. That diligence is not always possible. On an operator’s own laptop, many agent sessions often run at once under the person’s account, and nothing at the operating-system level tells them apart. Something else has to narrow what each one can do: its own keys, its own tokens, and the limits of the tools it is handed.

Scale changes the question again. Onboarding a hundred people in a day is rare; a hundred agents in a day may become ordinary. Accounts and keys made by hand will not keep up, so identity for agents has to be issued by a program: requested by the agent, scoped to the job, short-lived, and logged. Node0’s secrets vault is where that is headed.

The general form, separated from Node0’s particulars: a small set of automated operators stays attributable without per-role accounts if every actor holds its own credentials and no two ever share one. It does not stay contained that way. Containment comes from narrower identities, and once agents arrive by the dozen, only a program can issue those.

Source: node0 lessons v0.1, lesson 6.1; the paragraphs on agent identity from a conversation with Christoph, 20260929. Sanitized: checklist v0.1, 20260921; internal domain, decision-document path; voice pass 20260921; current account scope generalised, and Christoph's lesson on agent identity added, 20260929. Part of oznog.com/node0.