GitLost：我們如何欺騙GitHub的AI代理洩露私有倉庫

GitHub 最近推出了 GitHub Agentic Workflows，將 GitHub Actions（GitHub 的自動化系統，用於響應倉庫事件執行任務）與由 Claude 或 GitHub Copilot 支援的 AI 代理相結合。GitHub Agentic Workflows 允許團隊用純 Markdown 編寫工作流，而 GitHub 代理則自行讀取 Issue、呼叫工具並做出響應。

作為一名具有安全開發背景的漏洞研究員，該功能上線後最先浮現在腦海中的問題簡單而根本：當 GitHub 代理讀取到它不該信任的內容時會發生什麼？答案是一種經典的間接提示注入攻擊——這種攻擊能夠悄悄地將私有資料傳送給網際網路上的任何人。提示注入是一類攻擊，攻擊者將惡意指令隱藏在 AI 代理讀取的內容中，使代理遵循這些隱藏指令而非操作者的指令。

GitLost 漏洞的根本原因在代理 AI 系統中已屢見不鮮：提示注入。在大多數代理提示注入攻擊中，代理將錯誤的內容視為可信指令源，從而導致自身被誤導或濫用。當系統無法在系統級指令與不可信的使用者資料之間維持嚴格的信任邊界時，就會發生這種情況。在本案例中，任何惡意行為者都可以建立一個 GitHub Issue，並在 Issue 正文中隱藏純英語命令，GitHub 代理會遵循這些命令。

Noma Labs 發現的有漏洞的 GitHub Agentic Workflow 配置為：在 issues.assigned 事件觸發工作流；讀取 Issue 標題和正文；使用 add-comment 工具釋出評論作為響應；對組織內的其他倉庫（包括公共和私有倉庫）擁有讀取許可權。利用此漏洞，攻擊者無需編碼技能、訪問許可權或憑證，只需在一個使用 GitHub Agentic Workflow 的組織所屬的公共倉庫中開啟一個 Issue，然後等待即可。

攻擊流程如下：首先，攻擊者製作一個看似無害的 GitHub Issue，例如看起來像是銷售副總裁與客戶會面後的合理請求。然後，在 GitHub 自動化分配 Issue 後，事件觸發的工作流使代理獲取 README.md 的內容（來自公共倉庫 poc 和私有倉庫 testlocal）。最後，GitHub 代理將這些內容作為公共評論釋出到公共倉庫的 Issue 中，任何人都可以訪問和閱讀。

GitHub 設定了限制性防護措施來阻止此類情況，但未能按預期保護倉庫。透過反覆測試並新增關鍵詞“Additionally”，攻擊者觸發了模型的意外行為，使其重新組織輸出而不是拒絕。本質上，透過欺騙模型，攻擊者確保了 GitHub 的防護措施無法正常工作，未能防止資料洩露。

GitLost 完美地說明了每個組織在代理 AI 系統中面臨的基本安全挑戰之一。代理的上下文視窗同時也是其攻擊面。代理讀取的任何內容——無論是 Issue、拉取請求、評論還是檔案——如果代理將該內容視為指令輸入，都可能被武器化。傳統安全模型通常假設信任邊界由程式碼強制執行。而在代理系統中，信任邊界部分由模型行為強制執行，而模型天生具有指令跟隨特性。對於代理 AI 來說，提示注入攻擊已經變得像 SQL 注入對 Web 應用程式一樣：一種系統性的、跨類別的漏洞類別，需要同樣系統的策略和防禦措施。

Noma 建議構建者和 AI 安全官員：永遠不要將使用者控制的內容視為 AI 代理的可信指令輸入；將許可權範圍限制到最小，尤其是具有跨倉庫訪問許可權的代理是高風險目標；限制代理公開發布的內容，尤其是響應 Issue 內容時；在將使用者輸入傳遞給模型之前，對其進行消毒或與指令上下文隔離。