「都是自己人的 Agent，應該可以信任吧」

這句話是這個陷阱的根源。多 Agent 系統設計時，很容易預設「系統內部的 Agent 之間可以互相信任」——Agent A 傳來的資料，Agent B 就直接採用，不做額外驗證。但這等於在系統內部留了一條繞過所有外部防線的捷徑：只要攻擊者能影響任何一個 Agent 的輸出，這份被污染的內容就能暢通無阻地流進其他 Agent。

這個陷阱怎麼被利用

回顧 Day7 的間接注入與 Day9 的記憶污染：如果攻擊者能透過外部內容影響 Agent A 的輸出，而 Agent B 無條件信任 Agent A 的輸出，那麼攻擊者實際上是透過 Agent A 這個跳板，間接控制了 Agent B 的輸入。整條攻擊鏈裡，攻擊者從頭到尾沒有直接接觸過 Agent B。

Workload Identity 怎麼幫上忙

Workload Identity（以及主題一 Day9 談過的 Workload Identity Federation）在這裡的價值是：讓每個 Agent 都有可驗證的獨立身份，而不是共用憑證或依賴模糊的「內部呼叫就是可信」假設。具體來說：

• 每個 Agent 有各自的 Service Account 身份，Agent 之間的呼叫可以被明確識別「這是哪個 Agent 發起的」
• 搭配 IAM Conditions（Day13），可以限制「Agent B 只接受來自特定 Agent 的特定類型請求」
• Cloud Audit Logs 能明確記錄跨 Agent 呼叫的來源身份，讓事後追溯成為可能

但身份驗證不等於內容驗證

要特別注意一個容易混淆的點：Workload Identity 解決的是「這個請求真的來自 Agent A 嗎」，但解決不了「Agent A 傳來的內容本身可不可信」。後者需要靠 Day15-16 的 ShieldGemma 或內容驗證機制——即使確認來源身份無誤，內容依然該被當成需要驗證的輸入，而非無條件採信。這兩層防護缺一不可。

這篇的檢查清單

• [ ] 每個 Agent 是否都有獨立可驗證的身份，而非共用憑證？
• [ ] Agent 之間的呼叫是否有明確的授權限制（誰能呼叫誰、能傳什麼類型的請求）？
• [ ] 除了身份驗證，是否也對跨 Agent 傳遞的內容做了驗證？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。