攻擊步驟好簡單：

1. 黑客喺你公司其中一個公開Repo開一條睇落好正常嘅GitHub Issue。
2. 佢喺Issue嘅內容入面，用日常英文寫低指令，叫AI Agent去私密Repo度攞File。
3. 當GitHub自動化系統將呢條Issue分配畀Workflow處理嘅時候，AI Agent就會按照指令，去佢有權限存取嘅Repo度（包括私人Repo）攞資料。
4. Agent攞到資料之後，會將佢哋Post做一條公開嘅Comment响條Issue下面。任何人都睇得晒。

成個過程完全唔需要任何黑客技巧、密碼或者帳號。開完Issue等佢Run就得。

核心問題：AI Agent分唔清「Data」同「Instruction」

呢個漏洞嘅根本原因，係AI Agent嘅Context Window入面，冇做好系統指令同唔可信用戶輸入之間嘅嚴格信任邊界（trust boundary）。 正如Noma嘅Sasi Levi所講：「Agent嘅Context Window就係佢嘅攻擊面。無論係Issue、Pull Request、Comment定係File，只要Agent會讀到，而佢又將啲內容當做指令嚟執行，咁就可以被武器化。」

LLM（大型語言模型）做底嘅Agent，天生就好難分清楚「數據」同「指令」——當兩樣嘢同時出現喺同一個Context或者Tool嘅Output入面嘅時候。 呢個唔係一般嘅程式錯誤，而係Agentic AI工作流程嘅結構性風險。當Workflow冇將唔可信嘅內容隔離或者加以限制，呢啲內容就可以影響Agent嘅行為。

研究人員已經將呢類漏洞正式分類做「Agentic Workflow Injection (AWI)」，仲搵出咗兩種核心模式：Prompt-to-Agent (P2A) 同 Prompt-to-Script (P2S)。

「Additionally」三個字就KO晒所有防護

GitHub其實已經有設置防護機制（guardrails），理論上可以阻止數據外洩。但Noma嘅研究人員發現，佢哋可以用一個意想不到嘅簡單方法繞過晒。 淨係加多個字「Additionally」 喺注入嘅指令入面，個模型就會重新理解個任務，唔會拒絕執行，然後靜靜雞將數據洩漏出去。

呢個技巧同其他提示注入嘅研究結果一致：唔同嘅措辭或者Tool返返嚟嘅文字，可以令到模型做一D本來唔應該做嘅惡意指令。 呢種繞過Guardrail嘅手法，亦都同之前Invariant Labs揭露嘅GitHub MCP漏洞類似，嗰次黑客都係用惡意Issue騎劫Agent去偷Private Repo嘅數據。

公司應該點樣防禦？

基於GitLost嘅發現同業界對Agentic Workflow安全嘅指引，受影響嘅組織應該做以下幾件事：

• 對Agent嘅輸入採取零信任（Zero Trust）：永遠唔好將用戶控制嘅內容當做可靠嘅指令輸入。要做嘅係將唔可信嘅用戶數據同系統核心嘅Prompt隔離。
• 嚴格執行最低權限原則（Least Privilege）：移除冇需要嘅跨Repo存取權限，限制Agent透過公開Output洩漏數據嘅能力。
• 用Allowlist（允許清單）代替Blocklist（封鎖清單） 嚟管理工具權限，同埋喺Agent執行敏感動作之前（例如Post公開Comment或者存取敏感Repo），一定要有人類審批關卡。
• 審計所有CI/CD同Repo自動化工作流程入面嘅AI Agent整合，特別係會將唔可信嘅GitHub事件內容放入Prompt或者Agent輸入嘅情況。
• 邏輯上隔離唔可信嘅用戶輸入同系統層面嘅指令，將用戶產生嘅文字當做唔可信嘅數據，而唔係權威嘅指令。

另外，組織亦應該對Agent所用嘅Secrets（例如API Key）應用最低權限原則，同埋持續監控有冇提示注入嘅攻擊。

GitHub嘅回應（截至7月7日）

根據Dark Reading同Noma Security披露嘅時間線：

• Noma已經負責任地向GitHub披露咗呢個漏洞。
• GitHub話佢哋更新咗相關嘅說明文件，刪除咗有問題嘅工作流程範本。研究人員之後再檢查，都發現唔到嗰個高危設定。
• 截至7月7日，GitHub仲未出正式公開聲明或者CVE編號。
• 呢個漏洞似乎只係局部解決咗——淨係移除咗相關嘅文件同範本，而冇出一個清晰紀錄嘅平台層面安全修補。

更大嘅問題：系統性風險

GitLost唔係孤立事件。呢個係一個愈嚟愈常見嘅漏洞類別：AI Agent有權限存取敏感數據，但同時又暴露喺唔可信嘅用戶內容之下。類似嘅問題之前已經影響過GitHub MCP整合、Google嘅Gemini CLI工作流程（TrustIssues漏洞），同埋Claude Code GitHub Actions。

共通點係：LLM做底嘅Agent，天生冇能力分辨「數據」同「指令」——當兩樣嘢同時出現喺同一個Context Window入面，呢個係一個結構性嘅難題，冇一個平台嘅單一修補可以完全解決。

攻擊步驟好簡單：

1. 黑客喺你公司其中一個公開Repo開一條睇落好正常嘅GitHub Issue。
2. 佢喺Issue嘅內容入面，用日常英文寫低指令，叫AI Agent去私密Repo度攞File。
3. 當GitHub自動化系統將呢條Issue分配畀Workflow處理嘅時候，AI Agent就會按照指令，去佢有權限存取嘅Repo度（包括私人Repo）攞資料。
4. Agent攞到資料之後，會將佢哋Post做一條公開嘅Comment响條Issue下面。任何人都睇得晒。

成個過程完全唔需要任何黑客技巧、密碼或者帳號。開完Issue等佢Run就得。

核心問題：AI Agent分唔清「Data」同「Instruction」

呢個漏洞嘅根本原因，係AI Agent嘅Context Window入面，冇做好系統指令同唔可信用戶輸入之間嘅嚴格信任邊界（trust boundary）。 正如Noma嘅Sasi Levi所講：「Agent嘅Context Window就係佢嘅攻擊面。無論係Issue、Pull Request、Comment定係File，只要Agent會讀到，而佢又將啲內容當做指令嚟執行，咁就可以被武器化。」

LLM（大型語言模型）做底嘅Agent，天生就好難分清楚「數據」同「指令」——當兩樣嘢同時出現喺同一個Context或者Tool嘅Output入面嘅時候。 呢個唔係一般嘅程式錯誤，而係Agentic AI工作流程嘅結構性風險。當Workflow冇將唔可信嘅內容隔離或者加以限制，呢啲內容就可以影響Agent嘅行為。

研究人員已經將呢類漏洞正式分類做「Agentic Workflow Injection (AWI)」，仲搵出咗兩種核心模式：Prompt-to-Agent (P2A) 同 Prompt-to-Script (P2S)。

「Additionally」三個字就KO晒所有防護

GitHub其實已經有設置防護機制（guardrails），理論上可以阻止數據外洩。但Noma嘅研究人員發現，佢哋可以用一個意想不到嘅簡單方法繞過晒。 淨係加多個字「Additionally」 喺注入嘅指令入面，個模型就會重新理解個任務，唔會拒絕執行，然後靜靜雞將數據洩漏出去。

呢個技巧同其他提示注入嘅研究結果一致：唔同嘅措辭或者Tool返返嚟嘅文字，可以令到模型做一D本來唔應該做嘅惡意指令。 呢種繞過Guardrail嘅手法，亦都同之前Invariant Labs揭露嘅GitHub MCP漏洞類似，嗰次黑客都係用惡意Issue騎劫Agent去偷Private Repo嘅數據。

公司應該點樣防禦？

基於GitLost嘅發現同業界對Agentic Workflow安全嘅指引，受影響嘅組織應該做以下幾件事：

• 對Agent嘅輸入採取零信任（Zero Trust）：永遠唔好將用戶控制嘅內容當做可靠嘅指令輸入。要做嘅係將唔可信嘅用戶數據同系統核心嘅Prompt隔離。
• 嚴格執行最低權限原則（Least Privilege）：移除冇需要嘅跨Repo存取權限，限制Agent透過公開Output洩漏數據嘅能力。
• 用Allowlist（允許清單）代替Blocklist（封鎖清單） 嚟管理工具權限，同埋喺Agent執行敏感動作之前（例如Post公開Comment或者存取敏感Repo），一定要有人類審批關卡。
• 審計所有CI/CD同Repo自動化工作流程入面嘅AI Agent整合，特別係會將唔可信嘅GitHub事件內容放入Prompt或者Agent輸入嘅情況。
• 邏輯上隔離唔可信嘅用戶輸入同系統層面嘅指令，將用戶產生嘅文字當做唔可信嘅數據，而唔係權威嘅指令。

另外，組織亦應該對Agent所用嘅Secrets（例如API Key）應用最低權限原則，同埋持續監控有冇提示注入嘅攻擊。

GitHub嘅回應（截至7月7日）

根據Dark Reading同Noma Security披露嘅時間線：

• Noma已經負責任地向GitHub披露咗呢個漏洞。
• GitHub話佢哋更新咗相關嘅說明文件，刪除咗有問題嘅工作流程範本。研究人員之後再檢查，都發現唔到嗰個高危設定。
• 截至7月7日，GitHub仲未出正式公開聲明或者CVE編號。
• 呢個漏洞似乎只係局部解決咗——淨係移除咗相關嘅文件同範本，而冇出一個清晰紀錄嘅平台層面安全修補。

更大嘅問題：系統性風險

GitLost唔係孤立事件。呢個係一個愈嚟愈常見嘅漏洞類別：AI Agent有權限存取敏感數據，但同時又暴露喺唔可信嘅用戶內容之下。類似嘅問題之前已經影響過GitHub MCP整合、Google嘅Gemini CLI工作流程（TrustIssues漏洞），同埋Claude Code GitHub Actions。

共通點係：LLM做底嘅Agent，天生冇能力分辨「數據」同「指令」——當兩樣嘢同時出現喺同一個Context Window入面，呢個係一個結構性嘅難題，冇一個平台嘅單一修補可以完全解決。