先抓 egress，模型說了不算
r/LocalLLaMA 那篇在 debunk Cohere 指控的討論裡，聊天 log 沒出現 Alibaba URL，證據力其實很有限。模型輸出一段 URL，跟 agent harness 真的對外發出 TCP 連線，中間隔了好幾層。
實務上我會把驗證拆成三層。第一層看 syscall 和 process 行為。用 strace、auditd，或 eBPF 追 connect、sendto、execve，確認到底是哪個 PID 開 socket。
第二層看 DNS、HTTP proxy 和目的地。把 DNS query、TCP destination、HTTP Host、proxy access log 串成同一條 trace，記錄時間戳、container ID 和 prompt run ID。只看到 DNS lookup 不代表資料上傳，看到 HTTP request 才能繼續比對 method、header、body size。
第三層做隔離和反例。先跑一個最小重現：
docker run --rm --network=none my-agent:test
如果斷網後功能照常，代表那段任務不需要 egress。如果任務確實要查資料，就改成只允許固定 egress allowlist，代理層拒絕其他 domain，並留下拒絕事件。再用同一個 prompt 跑 20 次，對比 DNS、TCP、HTTP log。一次出現的連線可能是初始化或 telemetry，20 次都在同一步驟連同一個目的地，才值得往資料流方向查。
這也能處理一個常見誤會。agent 回答「我把內容送到某個 domain」只是文字，不能直接當成網路證據。沒有 URL 出現在回答裡，也不能證明 harness 沒有呼叫 API。判斷要落在可重現的 egress 記錄，再用假的 endpoint 比對。
有人擔心主 agent 完全斷網會失去能力，這個取捨確實存在。所以我通常分級：規劃和純本地推論用 network=none，讀取內部資料只開內網 allowlist，需要外部搜尋的 worker 才給短時效、可審計的 proxy 權限。secret 不放進主 agent，filesystem、metadata service 和 Unix socket 也要一起封。
最後即使那次指控不成立，最小權限仍然值得做。供應鏈錯誤和 prompt injection 都不會先跟你報備。說穿了就是，品牌立場可以當背景，聊天輸出可以當線索，能下結論的要是 syscall 加上可重現的 egress 證據。
作者：CtrlC