根據安全公司Noma Security的最新研究，一種提示注入攻擊能夠誘騙GitHub預覽版智能體工作流（Agentic Workflows）從私有代碼倉庫中提取內容並公開發布，這一發現揭示了企業在將AI智能體部署於具有特權訪問權限的軟體開發環境時所面臨的更深層安全風險。
Noma Security在一篇部落格文章中詳細描述了這一被命名為"GitLost"的攻擊方式：未經身份驗證的攻擊者只需向公開代碼倉庫提交一個經過精心構造的GitHub Issue，即可觸發漏洞。若AI智能體擁有對同一組織內私有倉庫的讀取權限，便可能將敏感資訊提取出來，並以公開評論的形式發布。
GitHub智能體工作流將GitHub Actions與Claude或GitHub Copilot等AI模型相結合，允許開發者通過Markdown定義工作流程，同時讓AI智能體讀取Issue、調用工具並代為執行相關任務。
Noma研究員Sasi Levi在文中寫道："如果GitHub智能體讀取了它本不應信任的內容，會發生什麼？答案就是一次典型的間接提示注入攻擊——這類攻擊能悄無聲息地將私密數據泄露給網際網路上的任何人。"
Noma指出，此次攻擊無需依賴竊取的憑證、惡意軟體或軟體漏洞，攻擊者只需在提交到公開倉庫的GitHub Issue正文中嵌入隱藏指令即可。由於AI智能體將Issue內容視為可信指令而非不受信任的輸入，它便會主動訪問私有倉庫，並將內容回傳至公開Issue中。
Levi寫道："GitLost漏洞的根源，在智能體AI系統中其實並不陌生，那就是提示注入。在此案例中，任何惡意行為者都可以創建一個GitHub Issue，並在正文中用普通英語隱藏指令，GitHub的智能體便會照單全收。"
為驗證這一攻擊，研究人員構造了一個看似普通的GitHub Issue，要求更新文檔。工作流一旦被觸發，AI智能體便從私有倉庫中提取了README文件，並將其內容發布在公開可見的評論中。研究人員還發現，僅需對措辭稍作修改，便能繞過GitHub基於提示的防護機制，使智能體執行此前被拒絕的指令。
截至發稿時，GitHub尚未回應置評請求。
Noma表示，GitLost所揭示的是AI智能體在架構層面面臨的普遍挑戰，而非GitHub獨有的安全缺陷。Levi寫道："問題不在於GitHub的AI智能體安全性特別薄弱，而在於任何能夠同時訪問不受信任的外部內容和敏感內部資源的AI智能體，一旦缺乏明確的信任邊界約束，都可能成為兩者之間意外的數據通道。"
獨立網路安全研究員、紅隊測試人員Vibhum Dubey認為，這一發現所揭露的問題遠不止於提示注入本身。"這不是抽象意義上的提示注入，而是GitHub在智能體權限機制尚不成熟之前就倉促上線了智能體功能，"Dubey說，"此漏洞表明，AI智能體運行的是服務賬戶權限模型，而非用戶權限模型。這是安全團隊在將大語言模型納入攻擊向量考量之前就已形成的架構假設。"
Dubey認為，提示注入本身甚至是次要的。"真正危險的是，信任邊界存在於GitHub的數據模型中，卻完全不存在於智能體的執行上下文裡，"他說，"智能體並不'知道'某個倉庫是私有的，它只看到'可訪問'。隨著越來越多的組織部署智能體，這類隱形權限漏洞正在不斷積累。"
Dubey建議，企業應從根本上重新審視AI智能體的權限授予方式，而不僅僅將其視為監控層面的挑戰。他提出三項具體修復措施：為智能體設置明確的倉庫白名單，而非賦予寬泛的服務賬戶訪問權限；在所有用戶輸入（包括提交資訊、PR描述和Issue內容）進入大語言模型之前進行驗證；同時準備好緊急熔斷機制。"大多數團隊知道如何禁用一個已泄露的API密鑰，但你能快速禁用一個失控的智能體嗎？"
Dubey表示，GitLost清楚地說明，一旦AI智能體被賦予廣泛的組織級訪問權限，就可能有效地演變為一種內部威脅。"GitLost的高明之處不在於它欺騙了AI，而在於它將GitHub默認服務賬戶可信這一假設武器化了，"他說，"智能體本就是為了繞過人工判斷、自主運行而構建的，這恰恰是它們危險所在——我們在將跨邊界操作自動化的那一刻，就已經將其視為常態了。"
Noma還建議，企業應落實最小權限訪問控制，限制AI智能體的跨倉庫訪問能力，並將GitHub的Issue、Pull Request和評論一律視為不受信任的輸入內容加以處理。
Q&A
Q1：GitLost攻擊是如何實現私有倉庫內容泄露的？
A：攻擊者只需向一個公開的GitHub倉庫提交包含隱藏指令的Issue，當AI智能體讀取該Issue時，會將其中的指令視為可信任命令並執行。如果該智能體同時擁有同組織內私有倉庫的讀取權限，就會將私有倉庫中的內容（如README文件）提取出來，並以公開評論的形式發布，從而造成資訊泄露。整個過程無需竊取憑證或利用任何傳統軟體漏洞。
Q2：GitHub智能體工作流為什麼容易受到提示注入攻擊？
A：GitHub智能體工作流將GitHub Actions與Claude或GitHub Copilot等AI模型結合，允許智能體自主讀取Issue、調用工具並執行任務。問題在於，智能體無法區分可信的系統指令與用戶提交的不可信內容，同時其執行上下文中缺乏信任邊界約束，智能體只看到資源"可訪問"，而不知道某個倉庫是否為私有。這種架構設計使得惡意輸入可以輕易被當作合法指令執行。
Q3：企業應該如何防範AI智能體面臨的提示注入風險？
A：安全研究人員建議採取三項核心措施：第一，為AI智能體配置明確的倉庫白名單，避免賦予寬泛的服務賬戶訪問權限；第二，對所有用戶輸入（包括Issue內容、PR描述、提交資訊等）在進入大語言模型之前進行嚴格驗證，將其視為不受信任的內容處理；第三，建立緊急熔斷機制，確保在智能體出現異常行為時能夠迅速將其禁用。此外，還應落實最小權限原則，限制智能體的跨倉庫訪問能力。
