他人的儲存庫如何劫持 Claude Code：7 條防護規則

Ailoot 文件：API、金鑰與設定。

從不可信文字到代理動作的四種已記錄路徑#

正式名稱是間接提示注入：惡意指令不是直接來自你，而是透過代理程式執行任務時處理的資料傳入，例如外來的 README、錯誤訊息、GitHub 留言，或外部服務的回應。讀完這段後，你可以忘掉這個術語；接下來我會用白話說明。

下方討論的四項研究範例：

1. 看似無害的儲存庫可能變成反向 Shell。
2. Pull Request 標題可能同時劫持 3 種不同的 AI 代理程式。
3. 代理程式可能收到假的 Sentry 錯誤報告，而不是真正的報告。
4. MCP 工具描述可夾帶影響模型的指示，實際影響依模型與設定不同。

看似無害的儲存庫 README 如何變成反向 Shell？#

攻擊機制設計上讓每一層單獨看起來都不惹人懷疑：

1. 你複製一個看起來普通的儲存庫，並要求 Claude Code 執行它。
2. 儲存庫會引入一個設計成首次使用時就失敗的 Python 套件。
3. 錯誤訊息客氣地建議一個「修復」命令：python3 -m axiom init。
4. init 命令會執行 setup.sh。
5. 指令碼會查詢 DNS TXT 記錄（通常用於網域相關備註，但這個欄位可以存放任何文字）。攻擊者會在其中放入 base64 編碼的命令（一種將任何資料轉成不含空格或特殊字元純文字的方法），並直接將它傳給 bash。
6. DNS 記錄的值可以隨時變更，讓攻擊者透過互動式反向 Shell，取得你的使用者權限和這台機器上所有機密資料的存取權。

示範 payload 在執行時從 DNS 取得，因此只掃儲存庫位元組看不到最後 payload。不代表所有掃描或執行控制無效；取得內容檢查、程序監控與網路限制可能揭露或中斷鏈。來源是概念驗證，不是真實事件普遍程度的測量。

Pull Request 標題如何劫持 3 種不同的 AI 代理程式？#

研究報告描述了以下攻擊途徑與供應商回應；這是歷史研究的整理，不代表已驗證每個產品目前版本的防護狀態：

這一輪揭露中，最早和最晚的報告相隔近 5 個月（Claude Code 的第一份報告日期是 2025 年 10 月 17 日；GitHub Copilot 最後一項錯誤修正日期是 2026 年 3 月 9 日）。嚴重性調整與緩解不能確立所有 payload 完整結案。研究者 PoC 儲存庫 記錄特定 Claude 路徑，不要對真實系統執行攻擊 payload。對你來說，有價值的是攻擊模式本身：未經驗證的資料從 GitHub 進入代理程式，代理程式執行命令，再透過同一個 GitHub 洩漏機密資料；攻擊者不需要外部伺服器。

讀兩篇分析就足以看出這個模式：逐一修復每個新發現並不可行；這類漏洞每兩週就會浮現。把安全規則明確寫進 CLAUDE.md 和 settings.json，而不是只記在腦中，是情境工程的一部分：設定一次後，每次新的 Claude Code 工作階段都會自動生效，不需要提醒。3 個支柱共同運作：AI 複製體 + 第二大腦 + 情境工程——這種組合能讓 Claude Code 從信任一切的執行者，轉變為遵守明確規則的代理程式。

假的 Sentry 錯誤報告能接管你的代理程式嗎？#

這種攻擊只需要 Sentry DSN 金鑰——這是一種公開識別碼，許多專案會直接將它放在用戶端程式碼中：

攻擊機制很簡單：開發者要求代理程式檢查未解決的 Sentry 錯誤；代理程式透過 MCP 伺服器請求取得錯誤，收到混在真實錯誤中的惡意事件，並把其中的命令當成可信的修復指示來讀取——因為嚴格來說，這正是它被要求執行的任務。

Tenet 回報既有控制在測試環境沒有警示，不代表所有部署完全無痕；代理／工具日誌、端點遙測與網路紀錄可能捕捉後續動作。攻擊從外部提交遙測開始，之後依賴代理有效工具與權限。

為什麼 MCP 工具描述可能夾帶指示？#

Microsoft 的措辭 是我在這個主題上找到最精確的說法：

這種手法稱為工具中毒：隱藏在無害工具描述中的指示會讓代理程式依照它行動。

Claude 3.7 Sonnet 在這項測試中展現出最佳韌性，但它拒絕遵循遭污染指示的案例仍不到 3%。即使是表現最佳的模型，其韌性也更像是靠運氣，而非受到保護。這項基準測試得出的反直覺結論是：模型越精確地遵循指示，就越難分辨正當命令與隱藏在中繼資料中的命令——模型的優勢反而成了弱點。

這些攻擊有何共同點？偵測可能漏掉什麼？#

這個結論適用於全部 4 項研究發現：你不能依賴「程式碼看起來正常」——攻擊中的每個單獨步驟確實都無害。限制代理有效能力，也檢查擬議動作；偵測與圍堵處理攻擊不同部分。

Claude Code 已有哪些防護功能？為什麼還不夠？#

Anthropic 沒有隱瞞問題，而是在文件中直接承認：

根據文件，代理程式會分析整份提示以尋找可疑指示，不會自動核准 curl 和 wget，會將網頁內容保存在獨立的情境視窗中，避免與主要視窗混在一起；第一次在新的程式碼庫中啟動或連接新的 MCP 伺服器時，也會要求確認是否信任。

但 Anthropic 也直言不諱地說明了一個重大限制：

如果你曾經因為不耐煩，啟動 Claude Code 時加上 --dangerously-skip-permissions，想讓它「別再一直問問題」，那你當時關閉的正是能阻止上述 4 種攻擊的所有機制。我會刻意讓這個旗標保持關閉，即使 Claude Code 在一個工作階段中第 10 次詢問也一樣——確實很煩人，但這些詢問正是「代理程式讀到可疑文字」和「代理程式執行了它」之間的界線。對非程式設計師來說，合理的設定是使用標準權限模式（default 或 acceptEdits）並啟用沙箱：一般檔案編輯不需要額外詢問，而終端機命令在物理上無法逃出沙箱，即使代理程式受騙也一樣。

如何啟用沙箱模式，並堵住預設設定留下的漏洞？#

若要讓所有專案永久啟用，只需修改 ~/.claude/settings.json 一處：

{
  "sandbox": { "enabled": true }
}

預設情況下，沙箱中的命令只能寫入專案工作目錄和工作階段的暫存目錄。網路存取會透過 Proxy；沒有任何網域預先獲准，Claude Code 第一次連線到新網域時會要求確認。Anthropic 表示，依照公司內部測量，這能將權限提示大幅減少 84%，因為部分安全情況會由沙箱自行處理，不必每次都詢問你。

標準設定留下的漏洞是：沙箱預設限制寫入，卻不會阻止讀取 ~/.aws/credentials 和 ~/.ssh 等檔案。這些正是上文攻擊中遭到鎖定的檔案及環境變數。在同一個檔案中加入另一個區塊即可堵住這個漏洞：

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

重點在於，即使第一項分析中的反向 Shell 在沙箱內開啟，這些變數和檔案也會在程序啟動前從其環境中實際移除，沒有任何東西可供竊取。

今天應該新增哪些 permissions.deny 規則？#

適合非程式設計師的最精簡設定，可一次涵蓋 4 種攻擊的主要目標：

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

根據 Claude Code 文件，deny 規則永遠優先於 allow 規則。因此，即使你（或代理程式本身）不小心在其他地方允許更廣泛的存取，特定的 deny 仍會先套用。此優先順序適用匹配工具請求，不能證明每個子程序或工具都無法取得機密，仍須強制檔案系統與環境限制。

Claude Code 也有 auto 模式，由另一個分類器模型在操作執行前進行檢查——不是與你交談的同一個模型。依照預設，它會封鎖「下載程式碼後立即執行」這類模式（curl | bash），而這正是前述攻擊的最後一步。Anthropic 明確警告，這是研究模式，可以減少提示數量，但本身無法保證安全；請將它視為額外的防護層，而非沙箱與 permissions.deny 的替代品。

如何在信任某個儲存庫或 MCP 伺服器並交由代理程式使用前先檢查？#

將儲存庫交給代理程式之前，請先依照這份簡短清單檢查：

1. 不要直接從來源不明的電子郵件、貼文或評論中的連結安裝；這正是散布這些儲存庫的方式。
2. 如果安裝時發生錯誤，並指示你「執行命令 X 來修復」，在允許 Claude Code 執行前，先確認 X 實際上會做什麼。上文分析中的指示看起來完全例行，這正是目的所在。
3. 不要只看星號數，也要檢查儲存庫的建立時間和提交紀錄；攻擊者很容易特地替新建的儲存庫刷假星號，以便進行這類攻擊。
4. 如果不熟悉該儲存庫，請在虛擬機器中執行安裝，不要在存有真實金鑰的工作機器上操作。這是 Anthropic 對使用外部服務的直接建議。

Anthropic 公開說明了對 MCP 伺服器的立場：

這表示你有責任檢查第三方 MCP 伺服器，而不是安裝它們的平台。有些團隊——多半是資安新創公司——已開始打造相關工具：可尋找遭污染描述的 MCP 設定掃描器，以及工具「固定」機制，可在首次安裝時儲存描述的雜湊值，並標示後續任何變更。這些技術還很新，因此現在還不適合將它們當作唯一的防護方式；但值得持續關注，尤其是當你把 MCP 伺服器連接到正式環境時。對這類連線，你可以固定每個套件版本，並將工具描述的指紋記錄在稽核日誌中。

7 條防護規則：今天就能採取的行動#

1. 啟用沙箱模式（/sandbox，或在 ~/.claude/settings.json 中設定 "sandbox": {"enabled": true}），並新增 credentials 區塊，禁止讀取 ~/.ssh 和 ~/.aws/credentials。
2. 新增 permissions.deny 規則，禁止讀取機密檔案以及執行危險的 bash 命令（curl、wget、sudo）——deny 永遠優先於 allow。
3. 絕不要在他人或未經驗證的程式碼上執行 --dangerously-skip-permissions；它會一次停用所有防護，包括可能阻止這些攻擊的防護。
4. 不要讓 Claude Code 自動執行錯誤訊息中的「修復」命令；先讀一讀它實際會做什麼。
5. 只從你信任的來源安裝 MCP 伺服器，並記得 Anthropic 不會代替你檢查它們的安全性。
6. 依照權限分開工作階段：第一個處理你的個人資料，不會看到外部資料；第二個檢查他人的電子郵件、儲存庫和工單，但無法存取機密；第三個負責對外發布，而且只發布你親自核准的內容。我在自己的專案中嚴格遵守這項規則：可存取付款金鑰的工作階段，不會讀取任意的外部工單或儲存庫；分析他人程式碼的工作階段，完全看不到機密。不要在同一個聊天中混用這些角色。
7. 持續更新 Claude Code 和已連接的自動化指令碼——本指南發布時，這裡討論的大多數漏洞都已透過修補程式封閉，新漏洞也會以類似方式修復。

接下來#

這些防護層都無法提供保證——Anthropic 本身也坦言，沒有任何防護能提供完全免疫。我不期望 Claude Code 能自行辨認錯誤訊息或 issue 留言中的詭計。對我來說，沙箱和 permissions.deny 已成為管理專案情境的方式之一：代理程式會看到什麼、預設會信任什麼，以及犯錯時會發生什麼。

如果你需要透過 Ailoot 使用神經網路，請看看 Ailoot。