之前寫過你的電腦才是攻擊面，講的是本機這一側：殘留憑證、權限旗標、不可信輸入。這篇是另一側——agent 往外動系統的時候。這個月我在三個地方各踩一次，共通點是這些動作寄出去就收不回來，而錯誤是客戶端可見的。
代名詞指涉不唯一，就不要動會發通知的系統
我口述了一句「IG 跟他確認了、改行事曆」。那個「他」，agent 判成了某位客戶，直接改掉那個人的行事曆邀請日期，而且帶了 send-updates=all。實際上我講的是另一個人。
更糟的是回滾。把日期改回去的那一刻，同一位客戶又收到第二封更新通知。一次誤判，客戶端看到的是兩封莫名其妙的改期信。
教訓：代名詞指涉不唯一時，動外部系統前先確認對象。尤其是行事曆邀請、寄信這類寄出即無法收回的動作，成本不對稱——多問一句的代價，跟客戶端可見的錯誤不是同一個量級。
reply-all 會把對方自己加的副本一起帶上
某個合作方回信時，自己 cc 了三位同仁。我用 --reply-all 建草稿，收件人於是從原本的兩個人擴增為六個人。指令本身沒有錯，它就是這樣運作的；錯在我沒有在寄出前確認名單實際長什麼樣。
這裡有兩層。一層是隱私：範圍與費用會被更多人看到，而那幾位我根本不認識。另一層是訊號——對方把人拉進來這件事本身有意義，是參與人員的線索，值得看一眼再決定怎麼寫。
教訓：對外草稿建好後一律回頭讀一次 To 和 Cc 的實際名單，再決定要不要刪副本。不要憑「我是在回覆這封信」就假設收件人跟上一封一樣。
佔位事件的內部備註會隨邀請一起寄出去
我在行事曆上建過一個佔位事件，備註欄裡寫的是給自己看的內部判斷。那個事件之後發了邀請，備註就跟著寄到客戶信箱。後來改成對外版本，但第一封已經寄出去了，收不回來。
行事曆事件的內部備註跟寄信不太一樣，它感覺上像是自己的筆記，實際上一旦有受邀者就是對外欄位。
教訓：這個欄位一旦有受邀者就是對外欄位，事後改成對外版本，第一封也追不回來。
三件事的形狀是同一個：agent 執行的那一步本身都沒有 bug，出事的是它跟外部收件人之間那道我沒看的門。