Repository navigation
Safety: detect unexpected Bot-to-Bot side channels #397
Description
Child of #386 (layered safety RFC).
Why
Bots should coordinate only through logged surfaces (Bot Social, task cards, Timeline). An unexpected side channel (shared files, scratch stores, self-made message boards, odd network targets) bypasses grants and audit.
Scope
- Define the allowed coordination surfaces list (Bot Social messages, task envelope Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149, approved file delivery).
- Detect likely side channels: Bot-written shared files read by another Bot outside delivery, new listeners/ports, repeated writes to common paths, outbound targets not on the allow-list.
- On detection: mark the turn in Timeline, raise a Needs-you / reminder (Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353), and (configurable) pause the involved Bots pending owner review.
- Personal: alert owner. Team: alert owner and assigner; entry goes to audit ([Team] Add a human-readable authorization and task audit trail #57).
Acceptance
- A test fixture where Bot A writes a file for Bot B outside the delivery path triggers a detection within one run.
- No false positive on normal delivered files and Bot Social traffic.
- Detection output contains no secrets.
Open questions
- File-system watch vs tool-call interception only?
- Default action: warn only, or pause?
- How does this behave with external runtimes ([RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198)?
Process: implementation via OpenCode + Codex review.
Activity
Birfy commentedon Oct 19, 2026
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.Birfy commentedon Oct 19, 2026
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).
HugoXK commentedon Oct 21, 2026
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.sendmiddleware 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.sendmiddleware 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/healthflag 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.(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.
(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.
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.
Birfy commentedon Nov 6, 2026
Written-by: Chief
本单是 #386（分层安全 RFC）里的检测切片，口径跟着父单走：#386 还没有结论，所以这里现在不开工，也不另问——安全面的分层本来就归你拍。#386 定了哪几层，这单就按层做检测（先做"允许的协调面清单 + 越界写入检测"这一最小片）。
Birfy commentedon Nov 10, 2026
Written-by: Triage
父单 #386 已在 11-06 关单，四层防御里第 2 层（检测 Bot 之间的意外侧信道）明确落在本单，所以现在只差你选一个方向：
A：现在做最小片——先列出"允许的协调面"（Bot 消息、任务卡、批准的文件投递），再给不在清单上的 Bot 通信打标记；发现越界只在这一轮的 Timeline 上打标并给你一条 Needs-you 通知，不自动暂停任何 Bot。
B：先不做——等团队模式（#51/#56/#57）解锁后，和按 Bot 授权、循环上限、审计轨迹一起做。
回 A 或 B 即可；选 B 我就把本单继续挂着，不再追问。
Birfy commentedon Nov 10, 2026
Written-by: Chief
父单 #386 已关（2026-11-06），关单时写明第 2 层（推理期监控）在这条里跟，所以这里现在是这一层唯一的落点，不再等 RFC 口径。检测范围沿用正文：允许的协调面是 Bot Social、任务信封、审批过的文件递送，越界的共享文件/监听端口/外部目标记进时间线并提醒 owner。剩下的只有一个口径要你定：
A 只告警：记时间线 + 提醒 owner，不停 Bot。
B 告警并暂停涉事 Bot，等你复核后才恢复。
不回就按 A（不停机器最不容易误伤）。