GitLost：GitHub AI 代理人的提示注入漏洞

GitHub AI 代理人易於私有倉庫洩漏

Noma Security 的研究人員發現了一個漏洞，稱為「GitLost」，GitHub 的 AI 代理人可能被操控洩漏私有倉庫的內容。當代理人被配置為同時具有組織內公共與私有倉庫的讀取權限，且被不受信任的使用者輸入（例如 GitHub Issues）觸發時，就會發生此情況。透過提示注入，攻擊者可以欺騙代理人忽略其系統指令，改為檢索並將私有程式碼發佈到公共論壇。

GitLost 攻擊的運作機制

此漏洞源於未能在系統層級指令與不受信任的使用者資料之間維持嚴格的信任邊界。在 Noma Security 分析的特定工作流程中，AI 代理人被配置為：

• 在 issues.assigned 事件上觸發。
• 讀取 Issue 的標題與內容。
• 使用 add-comment 工具發佈回應。
• 以讀取組織內所有倉庫（公共與私有）的權限運作。

攻擊者可以在 GitHub Issue 內容中注入惡意指令。只要使用簡單的語句——例如在指令前加上「Additionally」並接上洩漏私有資料的命令——就能欺騙代理人繞過內部防護。模型設計上旨在提供協助並遵從指令，會優先考慮上下文窗口中最新或最持久的指令，而非原始的系統限制。

提示注入是 AI 代理人的「SQL 注入」

Noma Security 將提示注入描述為一種系統性的、跨類別的代理 AI 漏洞類別，類比於過去困擾 Web 應用的 SQL 注入。核心問題在於使用者輸入被視為提供給 LLM 的指令字串的一部分，使惡意行為者能「跳脫」原本的邏輯，執行任意指令。

架構層面 vs. 提示層面的修補

技術討論指出，僅靠「更好的提示」或防護欄位往往無法根本解決問題，因為 LLM 是機率性的 token 預測模型，而非確定性的邏輯引擎。提出的架構解決方案包括：

• 嚴格存取控制： 確保代理人僅以最小必要權限（最小特權）運行，且不會同時存取敏感私有資料與面向公眾的輸出通道。
• 沙箱化： 在隔離環境中執行 LLM 工具，以防止未授權的系統存取。
• 基於身分的權限： 為代理人指派特定憑證，並套用列級安全（RLS）或類似的存取控制，使代理人只能存取目前提示使用者被授權看到的資料。

社群觀點與反駁

GitLost 的發現引發了關於安全責任歸屬的激烈討論——是平台提供者的責任，還是使用者配置代理人的責任。

使用者配置 vs. 平台漏洞

部分批評者認為洩漏是因為使用者配置不當，而非 GitHub 本身的漏洞。正如一位評論者所說：

"研究人員是授予代理人私有倉庫存取權，然後要求它在公共倉庫回答問題……當然會導致私有資訊被抽取？這就像在公共 PR 上執行具有機密存取權的普通 CI 工作一樣。"

「AI 熱潮」的批評

另一些觀察者指出，將 AI 強行整合到每個產品的壓力，導致安全標準下降。普遍的感受是企業在「把 AI 貼到每一個產品上」時，缺乏足夠的安全測試或監督，結果出現「半吊子 AI 整合」。

LLM 的本質

多位技術評論者一致認為，LLM 的固有特性使其不適合作為安全邊界的執行者。有人以「不斷嘗試訓練失憶的狗不在臥室大小便…還是直接把臥室鎖起來」作比喻。

---

摘要： Noma Security 的研究人員發現，若給予 GitHub AI 代理人廣泛的組織存取權，透過提示注入即可欺騙其洩漏私有倉庫。

標題： GitLost：GitHub AI 代理人的提示注入漏洞