Problem
Desktop already models three agent access levels — Only me, Selected people (per-user allowlist), and Anyone (see desktop/src/features/agents/lib/respondToAllowlist.ts and the access warnings reworked in #2561). But the owner-reviewed draft path that agents use from chat (buzz agents draft-update) can only express two of them:
// crates/buzz-cli/src/agent_management.rs
let respond_to = optional(draft.respond_to, "respond-to")?;
if respond_to
.is_some_and(|value| value != "owner-only" && value != "anyone")
{
// "respond-to must be owner-only or anyone"
}
UpdateAgentDraft carries respond_to: Option<String> and has no field for an accompanying pubkey list, so an allowlist grant cannot round-trip through the observer-frame draft flow at all.
Real scenario (today)
Two people share a channel, each with their own agents. Owner A wanted to let exactly one teammate invoke their agent and asked the agent in chat to open an access-change draft. The agent could only offer anyone — correctly reporting that the draft path supports nothing narrower — so the owner had to choose between opening the agent to every member of every channel it is in, or nothing. The narrower grant the platform already supports was unreachable from chat.
Proposal
Extend the draft request and desktop review payload to carry the allowlist mode:
- Accept
respond-to: allowlist plus a respondToAllowlist: string[] of pubkeys.
- Normalize entries to lowercase 64-char hex before persistence (accept
npub as input and decode).
- Require a non-empty list when mode is
allowlist; apply mode and list atomically; malformed or unsupported input fails closed.
- The Desktop review dialog should show each granted identity as resolved name + pubkey fingerprint, since display names are discovery aids, not authorization identities — enforcement must compare the signed event author pubkey.
- Unrelated edits from clients that predate the field must not clear a stored allowlist.
Related access-policy discussions: #2469, #2475, #2497.
Why it matters
The chat-mediated draft flow is how mixed human/agent teams actually reconfigure agents mid-conversation. As long as that path can only express the two extremes, "share with one trusted person" silently degrades to "share with everyone", which is exactly the risk the #2561 warnings exist to flag.
Problem
Desktop already models three agent access levels — Only me, Selected people (per-user allowlist), and Anyone (see
desktop/src/features/agents/lib/respondToAllowlist.tsand the access warnings reworked in #2561). But the owner-reviewed draft path that agents use from chat (buzz agents draft-update) can only express two of them:UpdateAgentDraftcarriesrespond_to: Option<String>and has no field for an accompanying pubkey list, so an allowlist grant cannot round-trip through the observer-frame draft flow at all.Real scenario (today)
Two people share a channel, each with their own agents. Owner A wanted to let exactly one teammate invoke their agent and asked the agent in chat to open an access-change draft. The agent could only offer anyone — correctly reporting that the draft path supports nothing narrower — so the owner had to choose between opening the agent to every member of every channel it is in, or nothing. The narrower grant the platform already supports was unreachable from chat.
Proposal
Extend the draft request and desktop review payload to carry the allowlist mode:
respond-to: allowlistplus arespondToAllowlist: string[]of pubkeys.npubas input and decode).allowlist; apply mode and list atomically; malformed or unsupported input fails closed.Related access-policy discussions: #2469, #2475, #2497.
Why it matters
The chat-mediated draft flow is how mixed human/agent teams actually reconfigure agents mid-conversation. As long as that path can only express the two extremes, "share with one trusted person" silently degrades to "share with everyone", which is exactly the risk the #2561 warnings exist to flag.