buzz-acp drops non-owner kind:9 mentions despite --respond-to anyone

[Ali-sportstech]

Bug Summary

buzz-acp with --respond-to anyone does not forward kind:9 mention events from non-owner channel members to the ACP agent. Only mentions from the channel owner are delivered.

Reproduction

1. Community relay: wss://sportstech.communities.buzz.xyz
2. Channel: Group DM (4) 56e18629-d8f8-425d-9b4c-2c88082c081b
3. Members: owner 2a68de51..., agent cbe410b8... (Hermes Ali), user 34b9ee8e... (SanthanaBharathy)
4. Start harness:

/Applications/Buzz.app/Contents/MacOS/buzz-acp   --relay-url wss://sportstech.communities.buzz.xyz   --private-key <agent nsec>   --agent-owner 2a68de51a9e98c1fd5fa2309330b1f7eb38dd6833c50c17758abe0dc4b8d7842   --agent-command /Users/ailab/.local/bin/hermes-acp   --agents 10 --subscribe mentions --dedup queue   --multiple-event-handling steer --respond-to anyone   --model openrouter:deepseek/deepseek-v4 --memory --relay-observer

5. Owner sends @Hermes Ali test → works, ACP gets Prompt event, agent replies.
6. Non-owner user sends @Hermes Ali what are you afraid of ? → no Prompt event in harness log, no agent reply.

The non-owner events ARE in the relay (verifiable via buzz messages get --channel 56e18629... --limit 10), correctly p-tagged to the agent pubkey, and the user is a confirmed channel member with role=member.

Variants tested (all fail identically)

• --respond-to anyone without --agent-owner
• --respond-to anyone + --agent-owner <owner>
• --respond-to allowlist + --respond-to-allowlist 34b9ee8e...
• --subscribe mentions + --no-mention-filter

Evidence

• Agent log (buzz-acp output) shows subscribed to channel 56e18629... + presence set to online — never shows Prompt on session for non-owner mentions.
• Owner mention produces immediate Prompt on session + agent turn.
• Both sender events are identical in structure (kind:9, h-tag = channel-id, p-tag = agent-pubkey).

This blocks community agents from serving non-owner users — which defeats the "shared agent" use case.

Environment

• Buzz.app current (Aug 2026)
• macOS 26.5.2
• buzz-acp binary from /Applications/Buzz.app/Contents/MacOS/buzz-acp

[ScaleLeanChris]

I traced this on current main (f956e6fe0). The event is reaching the harness subscription; it is then intentionally rejected by the inbound author gate because the reproduction channel is a group DM.

The controlling code is author_allowed(..., is_dm = true) in crates/buzz-acp/src/lib.rs, added in cb42c8d5b by #2591. In a DM, anyone and the explicit allowlist are deliberately ignored. Only the owner and cryptographically verified same-owner siblings may fire a turn. The reason is that Buzz clients p-tag every DM participant; allowing anyone inside an agent-created DM would turn DM membership into a transitive authorization grant.

Focused verification on current main:

cargo test -p buzz-acp author_gate_tests --lib
15 passed; 0 failed

That suite explicitly pins both reported variants:

• test_dm_rejects_stranger_under_anyone
• test_dm_rejects_allowlisted_external_pubkey

So changing this as a normal --respond-to bug fix would reopen the security issue that #2591 closed. For the shared-agent use case today, use a stream or forum channel. In non-DM channels, --respond-to anyone and allowlist apply as documented.

There is a real documentation gap: the README currently says anyone disables the gate entirely. Open PR #5187 already corrects that exact DM exception, so I did not create a competing docs PR.

If shared agents must serve arbitrary participants inside group DMs, that needs an explicit product/security decision and a separate DM authorization mechanism. It should not be implemented by removing the existing hardening.