不要讓 agent 把陌生 repo 當成可信任同事

最危險的時刻，不一定是 agent 寫錯 code。

寫錯 code 還好。你看得到 diff，看得到測試壞掉，看得到它把某個 function 改得很奇怪。真正麻煩的，常常是比較無聊的那一刻：你 clone 了一個陌生 repo，丟給 agent，說「幫我把它跑起來」。

它很順手地開始讀 README。

然後裝 dependency。

然後跑 setup script。

然後照著文件去初始化某個服務。

整個過程看起來都像正常開發。甚至看起來很勤奮。直到你回頭想，才發現你剛剛其實讓一個可以讀檔、跑命令、連網、改本機狀態的工具，按照一個陌生專案提供的路線走了一遍。

repo 看起來乾淨，不代表執行路徑乾淨。

這是現在 coding agent 工作流裡，我覺得很多小團隊還沒真正習慣的地方。以前我們把 repo 當成一包檔案。現在，對 agent 來說，repo 不只是檔案。它是指令來源、上下文來源、行動建議來源，甚至可能變成下一步命令的理由。

一旦 agent 能夠行動，閱讀就不再只是閱讀。

## 陌生 repo 不是同事，是工作場域

人類工程師接手陌生專案，通常會有一點警覺。

你可能先看 package.json，看 install script，看 CI，看 README 有沒有過期。你不一定馬上信任它。尤其是你知道某些 repo 只是 demo、fork、實驗品，裡面有什麼東西很難說。

可是 agent 很容易把這件事做得太順。

它的預設任務是「完成你交代的事」。如果你說要讓 repo 跑起來，它就會把 README 裡的步驟、錯誤訊息裡的提示、安裝流程裡的下一步，都視為完成任務的線索。這是它有用的地方，也是它危險的地方。

陌生 repo 不能被當成可信任同事。

它比較像一個還沒驗收過的工作場域。你可以進去看，可以拿樣本，可以做靜態分析，可以慢慢縮小風險；但你不會一進去就把自己的鑰匙、錢包、公司憑證和雲端權限都放在桌上。

對 agent 也應該一樣。

第一次接觸未知專案時，合理的預設不是「請幫我安裝並跑起來」。合理的預設應該是：「先只讀，不要執行。告訴我它要求哪些命令、哪些外部連線、哪些本機權限、哪些地方可能影響我的環境。」

這聽起來慢一點。

但它其實是在避免更慢的事發生。

## 乾淨檔案不等於乾淨路徑

很多人聽到 clean repo 風險，第一反應會是：「那是不是掃描一下檔案就好？」

不夠。

因為 agent 的執行鏈，不只來自 repo 裡明顯可疑的程式碼。README 可以影響它。安裝教學可以影響它。package hook 可以影響它。issue、文件、外部設定、DNS lookup、下載下來的 artifact，也都可能影響它。

每一步單看都可能很普通。

裝套件很普通。讀文件很普通。查一個設定值很普通。初始化一個服務很普通。問題是，agent 會把這些普通步驟串成一條連續的行動路徑，而你不一定在每一步都看得很清楚。

這跟傳統「我手動跑命令」不太一樣。

人手動操作時，至少每一步是自己打的。你可能也會犯錯，但你知道自己正在把哪個命令送進 shell。agent 則會把判斷和執行合在一起：它讀到某段說明，覺得下一步合理，就去做。它遇到錯誤，自己猜修法，再做。它覺得缺一個工具，可能嘗試安裝。它覺得需要查外部內容，可能打開網路。

所以安全問題不是「這個 repo 裡有沒有惡意檔」這麼窄。

更實際的問題是：這個 repo 被允許引導 agent 做哪些事？

如果答案是「什麼都可以，只要最後跑起來」，那你其實不是在使用 agent。你是在把本機開發環境借給一個陌生專案安排工作。

## 權限提示不是安全策略

有些工具會在危險命令前跳出權限提示。

這當然比完全沒有好。

但權限提示不能替你定義任務邊界。它只能在某些明顯操作上問你要不要放行。問題是很多風險不是一個大紅按鈕，而是一串看起來都還可以的小動作。

改一個設定檔，看起來可以。

新增一個 script，看起來可以。

跑一次 package manager，看起來可以。

讀某個環境變數，看起來也可能被包裝成 debug 需要。

如果你沒有先定義任務範圍，每一次提示都會變成臨場判斷。臨場判斷最容易被「它只是想完成任務」說服。你會想，反正都跑到這裡了，就讓它試一下。

這就是小團隊最容易踩到的地方。

不是因為大家不懂安全，而是日常開發本來就充滿妥協。demo 明天要看，bug 今天要修，客戶環境突然壞掉。agent 在這種情境下很誘人，因為它會幫你把麻煩往前推。

但安全邊界不能等到提示跳出來才開始想。

它應該在任務開始前就寫清楚：

- 這次只能讀哪些目錄

- 不准跑哪些命令

- 不准安裝全域工具

- 不准讀取 `.env`、token、SSH key 或 cloud credential

- 預設不允許外網

- 需要執行任何 setup 前，先列出命令、目的、風險和回復方式

- 遇到不明外部 artifact，停止，不要自己接著查、下載或執行

這些規則很土。

可是土的規則通常比較有用。因為它們不是在期待 agent 變聰明，而是在縮小 agent 就算判斷錯，也能造成的範圍。

## 開發工具鏈也是邊界的一部分

談 agent 安全時，很容易只看模型。

模型會不會被 prompt injection 騙？模型會不會看懂惡意指令？模型會不會拒絕危險操作？

這些都重要，但不完整。

Agent 不是活在真空裡。它活在你的開發環境裡。那裡有 VS Code extension，有套件管理器，有 Git credential，有 cloud CLI，有本機服務，有瀏覽器 session，有 `.env`，有你平常覺得很方便、所以一直保持登入狀態的東西。

對攻擊面來說，這些都不是背景。

它們是環境。

一個惡意 extension 不需要自己是 agent，也可能碰到程式碼、terminal、憑證或內部 repo。一個 agent 如果在同一個環境裡工作，就會站在同一個信任地板上。你不能只問 agent 有沒有亂跑命令，也要問它身邊有哪些工具本來就有過大的權限。

所以我會把未知 repo 的第一次 agent run，盡量放在乾淨環境裡。

不是日常主力 workspace。

不是已經登入一堆 cloud 帳號的 terminal。

不是裝滿 extension 的個人 VS Code。

至少要做到幾件事：沒有 production secret、沒有自動可用的 cloud credential、沒有不必要的 extension、沒有預設外網，檔案系統也不要把整個 home 目錄暴露出去。

聽起來很麻煩。

但如果你已經願意讓 agent 幫你跑陌生專案，這些麻煩是合理成本。就像你不會在 production database 上測不明 migration，一樣不該在充滿憑證的個人環境裡測不明 repo。

## 先讀，再跑

我比較喜歡把陌生 repo 的 agent 工作分成兩段。

第一段只讀。

這一段的任務不是「把它跑起來」，而是「把風險看出來」。請 agent 做靜態盤點：入口在哪裡、有哪些 install script、有哪些 lifecycle hook、會不會下載外部檔案、需要哪些環境變數、README 要求哪些服務、CI 跑哪些命令、是否碰到瀏覽器、Docker、cloud CLI 或本機 credential。

這時候 agent 不應該安裝，不應該初始化，不應該自己修。它只做閱讀和摘要。

第二段才是窄範圍執行。

你根據第一段結果，挑一小組命令讓它跑。最好是在 sandbox 裡，最好關掉不必要網路，最好給它假的或最小權限設定。它每跑一步，都要留下紀錄：命令、目的、輸出摘要、改了哪些檔、下一步為什麼合理。

這不是形式主義。

它讓你在事情不對時，可以停得下來。

沒有紀錄的 agent run，很像一段只剩結果的外包工作。成功時你不知道為什麼成功，失敗時你不知道哪裡開始歪掉。更糟的是，下一次你可能又讓另一個 agent 從頭走一次同樣的危險路徑。

好的 run log 至少應該能回答幾個問題：

- 它讀了哪些主要檔案

- 它跑過哪些命令

- 它有沒有碰到外部網路

- 它是否讀取或要求 secret

- 它改了哪些檔案

- 它拒絕或停止了哪些動作

- 哪些結論有證據，哪些只是推測

這些東西沒有很酷。

但它們會讓 agent 從一個黑箱幫手，變成可以被審查的工作流程。

## 小團隊需要預設拒絕

我不覺得答案是不要用 coding agent。

剛好相反。小團隊更需要它。陌生 repo、壞掉的 demo、過期依賴、沒人想碰的初始化問題，這些都是 agent 很適合幫忙處理的工作。

但越適合委派，越需要預設規則。

我的建議很簡單：未知 repo，預設拒絕。

拒絕 secret。

拒絕外網。

拒絕全域安裝。

拒絕自動執行 setup。

拒絕讀取家目錄裡不相關的檔案。

拒絕把「讓它跑起來」解讀成「你可以自己決定所有中間步驟」。

然後再逐步放行。

如果 agent 需要跑 `npm install`，先讓它說明為什麼、會觸發哪些 script、有沒有 lockfile、有沒有可以停用 lifecycle scripts 的方式。

如果它需要網路，先說明要連哪裡、拿什麼、為什麼不能離線完成。

如果它需要環境變數，先說明哪些是必要，哪些可以用假的值。

如果它需要改檔，先說明是修專案，還是只是為了讓 demo 暫時跑起來。

這不是在跟 agent 作對。

這是在讓 agent 有一個可以安全工作的房間。

## 問題不是它能不能完成，而是它被允許做什麼

我覺得接下來大家會越來越習慣把 agent 放進更大的工作流。

它會幫你接手 repo，幫你修 CI，幫你整理 migration，幫你追一個不熟的 SDK。這些都會變得很普通。也正因為普通，才更需要把安全邊界變成日常習慣，而不是出事後才補的文件。

不要把陌生 repo 當成可信任同事。

也不要讓 agent 這樣做。

陌生 repo 一開始只是輸入，不是指揮官。它可以被閱讀，可以被檢查，可以被逐步授權，但不能因為 README 寫得自然、setup flow 看起來正常，就取得本機環境的信任。

下次你要 agent 幫忙讓一個陌生專案跑起來，可以先不要問：

「它能不能完成？」

先問另一個問題：

「這個 repo 被允許叫我的 agent 做哪些事？」

如果這個問題答不出來，真正危險的可能不是某一行惡意程式。

而是你把一條看起來很普通的開發流程，交給了一個太願意幫忙、又太有行動能力的工具。

## Source notes

- Tom's Hardware, "AI coding agents can be tricked into installing malware via 'clean' GitHub repositories", 2026-06-28, https://www.tomshardware.com/tech-industry/cyber-security/ai-coding-agents-can-be-tricked-into-installing-malware-via-clean-github-repositories-mozillas-0din-team-shows-how-claude-code-can-be-exploited-by-its-own-helpfulness

- arXiv, "How Agentic AI Coding Assistants Become the Attacker's Shell", 2026-05-25, https://arxiv.org/abs/2605.25871

- arXiv, "Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode", 2026-04-04 / revised 2026-04-28, https://arxiv.org/abs/2604.04978

- Tom's Hardware, "Hacker group hits 3,800 internal GitHub repositories via poisoned developer plugin", 2026-05-20, https://www.tomshardware.com/tech-industry/cyber-security/hacker-group-hits-3-800-internal-github-repositories-via-poisoned-developer-plugin-teampcp-claims-source-code-theft-and-attempts-usd50-000-sale-employee-installed-malicious-vs-code-extension

- arXiv, "From Preventive to Reactive: How AI Coding Assistants Transform Developers' Security Awareness", 2026-05-22 / revised 2026-06-10, https://arxiv.org/abs/2605.23130