Agentic Security: Permissions, Provenance, and the Agent Supply Chain — Steve Yegge, Gas Town

Steve Yegge 在這場演講中提出了一個令人不安但務實的問題：當 AI 將代碼交付速度提升 10 倍時，如果缺陷率保持不變，表面上看是好事，但實際上缺陷的絕對數量會增加 10 倍。更糟的是，安全缺陷與功能缺陷不同——功能缺陷會因時間推移而失去重要性（隨著用戶適應系統），但安全漏洞反而會因 AI 代碼量的激增而不斷惡化。這不是傳統的「代碼增量 × 缺陷率 = 漏洞數」的線性問題，而是一場軍備競賽的加速度危機。

AI 生成的代碼引入了兩類安全風險。第一類是傳統漏洞的規模化放大——XSS、注入攻擊等已知攻擊面被自動化生成的代碼批量引入。第二類也是更令人擔憂的，是全新的攻擊面。Yegge 以「Hallucination」為例：AI 虛構了一個不存在的軟體包名稱（如「graphy123」），並在提示中教開發者使用它。聰慧的攻擊者觀察到 LLM 的幻覺模式後，預先在軟體包管理器上傳了同名的惡意包，功能與 LLM 期望的完全相同，只是暗藏後門。開發者被誘導執行自動化部署，結果拉下的是投毒的依賴。這種「為 AI 的幻覺提前佈置真實陷阱」的攻擊方式是前所未有的。

解決方案不在於指望 AI 預設生成安全代碼——就像無法指望它預設生成優雅或高效代碼一樣，安全性是需要額外工程介入的驗證層。Yegge 引用了他在谷歌的經驗：谷歌曾發現缺陷報告越早出現在開發流程中越容易修復，因此投入巨資將檢測前置到開發者輸入代碼的當下。但這個策略對安全漏洞無效，安全問題必須被視為持續、不衰減的威脅。解法是利用 AI 的「懶惰特性」——LLM 天生傾向節省代幣成本，因此會樂於使用工具來卸載認知負擔。在提示中強制要求執行 Snyk（代碼及依賴掃描）、ChainGuard（供應鏈安全）等工具，並讓多個工具互相交叉驗證，能有效地將 LLM 改造成安全檢查的執行者。

然而，分步驟至關重要。AI 無法在一次迴圈中同時保證功能正確性和安全性，兩個都給會導致兩個都敷衍。必須先給 AI 一個獨立任務「寫正確的代碼」，完成後在第二輪明確指派「進行安全加固審查」。Yegge 在自己 30 年的遊戲專案上運行了 Fable 的安全加固，一次就發現了 241 個漏洞。更大的威脅在於時間緊迫性——五眼聯盟已發出警告，供應鏈安全風險的時間窗口以月計而非年計，開源模型預計在 6-7 個月內追上閉源模型性能。組織必須立即開始在內部設計安全防護框架，否則工程師將無意中部署權限過度、無人監管的智能體執行長時間後台任務，帶來更大風險。