feat(buzz-acp): --allow-dm-allowlist opt-in for explicit allowlist in DMs - #5013
Open
joe-rodgers wants to merge 1 commit into
Open
feat(buzz-acp): --allow-dm-allowlist opt-in for explicit allowlist in DMs#5013joe-rodgers wants to merge 1 commit into
joe-rodgers wants to merge 1 commit into
Conversation
… DMs The inbound author gate hardens DMs: because clients auto-p-tag every DM participant, every DM message looks like a mention, so inside a DM only the owner and cryptographically verified same-owner siblings can fire a turn. Neither --respond-to=allowlist nor --respond-to=anyone applies there. That default is right, but it silently breaks a legitimate case: an operator puts a real person on --respond-to-allowlist, that person can talk to the agent in a stream channel, and then every DM they send is dropped with no turn and no error. It is indistinguishable from a broken agent. Add --allow-dm-allowlist / BUZZ_ACP_ALLOW_DM_ALLOWLIST (default false). When set AND --respond-to=allowlist, the explicit pubkey list also admits authors inside DMs. Security tradeoff, deliberately scoped: - Only RespondTo::Allowlist is affected. RespondTo::Anyone in a DM stays owner/sibling-only even with the flag on -- allowing it would restore the original transitive-grant hole, where anyone who lands in a DM with the agent (including a DM the agent itself was asked to open with a third party) could prompt it. RespondTo::Nobody still drops everything, including the owner. - Admission remains gated on a list the operator wrote by hand, so merely being in a DM with the agent grants nothing. - What is being accepted: an allowlisted pubkey can now prompt the agent in a 1:1 DM, with no channel membership around it -- no other participants, no shared audit surface. Default-off, so existing deployments are unchanged. Threaded through CliArgs -> Config -> author_allowed and the setup-mode gate. Summary line reports " dm_allowlist=on" when active. Tests: existing DM cases now pin the flag-OFF default explicitly; added coverage for flag-ON admitting an allowlisted pubkey, still rejecting an unlisted stranger, not loosening anyone/nobody/owner-only, and still admitting owner+sibling.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The inbound author gate hardens DMs: because clients auto-p-tag every DM participant, every DM message looks like a mention, so inside a DM only the owner and cryptographically verified same-owner siblings can fire a turn. Neither
--respond-to=allowlistnor--respond-to=anyoneapplies there.That default is right, but it silently breaks a legitimate case: an operator puts a real person on
--respond-to-allowlist, that person can talk to the agent in a stream channel, and then every DM they send is dropped with no turn and no error. It is indistinguishable from a broken agent.This adds
--allow-dm-allowlist/BUZZ_ACP_ALLOW_DM_ALLOWLIST(default false). When set and--respond-to=allowlist, the explicit pubkey list also admits authors inside DMs.Security tradeoff, deliberately scoped
RespondTo::Allowlistis affected.RespondTo::Anyonein a DM stays owner/sibling-only even with the flag on — allowing it would restore the original transitive-grant hole, where anyone who lands in a DM with the agent (including a DM the agent itself was asked to open with a third party) could prompt it.RespondTo::Nobodystill drops everything, including the owner.Threaded through
CliArgs→Config→author_allowedand the setup-mode gate. Summary line reportsdm_allowlist=onwhen active.Testing
Existing DM cases now pin the flag-OFF default explicitly. Added coverage for flag-ON admitting an allowlisted pubkey, still rejecting an unlisted stranger, not loosening anyone/nobody/owner-only, and still admitting owner+sibling.
cargo test -p buzz-acp --release: 675 passed, 0 failed.cargo fmt --checkclean.Context
Found while running a small fleet where a second trusted principal is on the allowlist — her DMs to the agents vanished with no error, which reads exactly like a dead agent.