Safety: detect unexpected Bot-to-Bot side channels #397

Activity

1. Birfy

   added

   enhancementNew feature or requestNew feature or request

   area:securityAuth, grants, approvals, secretsAuth, grants, approvals, secrets

   needs-humanThe agent loop stopped; a person must decide (reason in the last comment)The agent loop stopped; a person must decide (reason in the last comment)

   on Oct 19, 2026
2. Birfy commented on Oct 19, 2026

   

   Birfy

   on Oct 19, 2026

   Collaborator

   More actions

   Triage on main 7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. Child of #386 with no owner go-ahead. Needs a decision on the allowed coordination surfaces and whether detection may pause Bots.
3. Birfy commented on Oct 19, 2026

   

   Birfy

   on Oct 19, 2026

   Collaborator

   More actions

   Triage 2026-10-19 18:03 Asia/Shanghai (main 245be0b). Concrete shape, for the owner to decide:

   If built (phase 1): allowed coordination surfaces = Bot Social messages, approved file delivery (attachments), task cards. Detection by tool-call interception only (no file-system watcher): a Bot writing outside its own workspace to a path another Bot later reads, opening a listening port, or calling a network host not on the allow-list. Action = warn only: a marker on that turn in Timeline plus a Needs-you notice to the owner. No automatic pause; the owner pauses a Bot with the existing controls.

   Question: (a) build phase 1 as above, (b) also auto-pause the Bots involved, or (c) park until the umbrella #386 is prioritized? Recommendation: (c). No side-channel incident so far, and the heuristics are easy to get wrong (false positives). If the owner wants it now, build (a).
4. HugoXK commented on Oct 21, 2026

   

   HugoXK

   on Oct 21, 2026

   Contributor

   More actions

   Design for the owner to pick. #386's layer 3 (action/visibility) meets FlyBot's parts already in place: Bot-to-Bot traffic runs through the bot.send middleware chain and the activity feed, file and network work runs through DSH's fs/shell tools.

   Scope: define the allowed coordination surfaces (Bot Social messages, the task envelope of #149, approved file delivery, the native room log). Then flag a Bot's own coordination outside them.

   (a) Warn only (recommended first step). Use the two surfaces the host already sees: a bot.send middleware that flags a send whose target is not on the allow-list, and a feed watcher for a turn that reads/writes a shared path two Bots both touch. On a hit, mark the turn in the Timeline (timeline/health flag or an alert) and raise a Needs-you line (#353); no pause, no deny. Catches the case #386 describes without a policy on which paths are allowed.

   • Size: ~150 lines (a middleware + a feed watcher + a Timeline flag) + tests.

   (b) Warn + configurable pause. As (a), plus a config that pauses the involved Bots pending owner review. Needs a pause primitive (a per-Bot hold) and a clear resume path.

   • Size: +~80 lines.

   (c) Deny inline. Block the write/egress that is not on the allow-list. Strongest, but needs the owner to say which paths and outbound hosts are allowed by default, which is a product policy.

   • Size: larger + a config surface.

   Recommendation: (a) now — it is the detection #397 asks for, testable with a fixture where Bot A writes a file Bot B reads outside the delivery path, and it does not need the allowed-paths policy that (c) does.
5. Birfy commented on Nov 6, 2026

   

   Birfy

   on Nov 6, 2026

   Collaborator

   More actions

   Written-by: Chief

   本单是 #386（分层安全 RFC）里的检测切片，口径跟着父单走：#386 还没有结论，所以这里现在不开工，也不另问——安全面的分层本来就归你拍。#386 定了哪几层，这单就按层做检测（先做"允许的协调面清单 + 越界写入检测"这一最小片）。