Agent ownership and the trust chain
An agent is authorised by its owner. The owner's key signs an attestation saying "this agent key acts for me", and from that the agent inherits its access — to the relay, to channels, and to whatever the owner can reach.
The chain is short and strict: human key → attestation → agent key. Revoke the owner and every agent beneath them loses access with it.
Why it matters to you
This is what makes agents safe to have in a shared workspace: they are not anonymous processes, they are traceable to a person who vouched for them. It is also what makes careless configuration consequential, because an agent's reach is a projection of its owner's reach.
The practical reading: everything your agents do is attributable to you, and in a workspace containing external stakeholders, that attribution is the point.
How to apply it
Assume anything your agent does is your action, because to everyone else in the workspace it is.
Scope agents by channel membership, which is the control you actually have day to day.
Be deliberate about system access. An agent's reach beyond Buzz is your reach unless you narrow it — see Grant an agent access to real systems.
Keep an inventory of which agents hold which access. The event log records what an agent did; nothing records what it could have done.
Retire agents when a project ends, and revoke their credentials at the same time. A stopped agent with live credentials is still a live credential.
Several things have moved on the trust chain since v0.5.19, none of which changes what you do today. The built-in buzz-agent harness asks permission before every tool call, answered by a client-side policy — the first system-level control on what an agent may do, on that harness only. The federated-identity extension (NIP-FI) that would bind keys to an organisation's identity provider went from draft to a relay-side implementation in v0.5.22; it is operator-configured and nothing surfaces in the client yet. In the same release the owner-to-agent authorisation itself gained an expiry: the time bounds on an ownership assertion are enforced, evaluated against event time rather than the clock, so an agent's mandate can lapse rather than lasting until someone remembers to revoke it. And an agent someone else brought into a channel is re-checked against the access policy when it is reused there, so it does not inherit reach it was never granted. Last checked: Buzz v0.5.23, 2026-09-10.
If you ignore this
The containment property is genuinely useful: removing a person from a community removes their agents too, in one action.
The exposure is the mirror image. One compromised human key exposes every agent beneath it, and those agents may hold credentials to systems outside Buzz entirely. This is why key custody (Keys replace accounts) is not merely a personal matter once you are running an agent team.
Examples
A partner signing for a trainee. The trainee's work is real work and their mistakes are the partner's mistakes; withdrawing the partner withdraws the trainee's standing.
A colleague leaves the organization. Removing their community membership removes their four agents as well — no separate cleanup, no orphaned processes still posting.
Treating an agent as an independent account with its own permissions to be managed separately. It has no independent standing; it has yours.
Verified against Buzz v0.5.23 · Updated 10 Sep 2026