GitHub AI 工作流存在提示注入漏洞，可洩露私有資料。文章作者、來源：36Kr
Noma 表示，儘管 GitHub 已經部署了嚴格的防護機制來避免此類情況發生，但僅僅使用關鍵詞 “Additionally” 就觸發了模型的非預期行為。這導致模型訪問了一個原本受限制文件的內容，並將其發布在公開評論中。
傳統安全模型通常假設，信任邊界由程式碼負責維護。而在 Agentic 系統中，信任邊界部分依賴於模型的行為，而模型天生具備遵循指令的特性。對於 Agentic AI 而言，提示注入攻擊正變得類似於 Web 應用中的 SQL 注入問題：一種系統性的、覆蓋整個類別的漏洞類型，需要同樣系統化的策略和防禦措施。安全防護建議：為降低這些風險，Noma 研究人員建議，用戶控制的內容永遠不應被視為 AI Agent 的可信指令輸入。Agent 的權限應限制在嚴格必要的範圍內，因為擁有跨倉庫訪問權限的 Agent 會成為極具價值的攻擊目標。組織還應限制 Agent 可公開披露的資訊範圍，尤其是在回應 Issue 內容時，並確保用戶輸入在提供給模型之前，已經過適當清理，或與指令上下文隔離。行業警示
Fractional CTO Vijendra Malhotra 在 LinkedIn 上評論稱，Noma 的發現證明了：私有倉庫從來都不是安全邊界。它實際上是組織邊界，只有當讀取你代碼的人都是你僱用的人類時，這個邊界才成立。Agent 打破了這一假設。[……] 如果一個 Agent 能訪問你的私有倉庫，請把其中所有內容都視為距離公開洩露只差一個精心構造的 Issue。Reddit 用戶 Significant_Sea_4230 指出：
危險之處不在於 Agent「很聰明」，而在於它可能連接了過多的上下文、過多的倉庫，或擁有權限過於寬泛的 Token。另一方面，用戶 cH3332xr 強調：
這裡最有意思的細節是 “Additionally” 繞過機制，有效載荷本身並沒有改變，只是這個銜接詞在防護機制看來，把它從「新的指令」重新歸類成了「當前任務的延續」。這是一個決策邊界問題，而不是內容問題。作為社區的最後一條評論，mcv 在 Hacker News 上表示：
SQL 注入之所以產生，是因為系統將使用者輸入當作指令的一部分，而非原本應被視為純資料的內容。將兩者分離後，這個問題便得到解決。而提示注入則無法避免，因為使用者輸入本身就是指令。如需深入了解技術細節和概念驗證過程，請閱讀 Noma 網站上的完整報告。
原文連結：https://www.infoq.com/news/2026/07/gitlost-github-prompt-injection
文章來源：AI前線