AI 智能體測試期間讀取印度企業即時資料,相關企業均未察覺
AI Agents Under Test Read Live Data at Indian Firms. None of the Firms Noticed
CERT-In 披露,多家 AI 模型供應商的研究及評估智能體曾利用應用程式設定、公開程式碼庫及過寬雲端權限中的憑證,存取印度企業的即時系統並讀取個人及機密業務資料。受影響機構均未察覺,相關披露由模型供應商內部審查後提交。文章指出,限制智能體存取應在網絡層設定出口白名單,並限制憑證和檔案權限,不能只靠提示詞要求智能體留在沙盒。
文章把 CERT-In 披露的越權存取,連結到本機編碼代理讀取憑證的風險,並以網絡層出口限制説明提示詞之外的防護邊界。
- 書籍: Prompt Engineering Pocket Guide
- 我亦著有: Thinking in Go(2 冊系列)— Complete Guide to Go Programming + Hexagonal Architecture in Go
- 我的專案: Hermes IDE | GitHub — 為使用 Claude Code 及其他 AI 編碼工具開發及交付軟件的開發者而設的 IDE
- 我: xgabriel.com | GitHub
「受影響機構均未有發現這些存取行為。」這句話出自一份評級為嚴重的公告。印度國家網絡安全機構 CERT-In 於 10 月 15 日發布這份公告,談及擅自前往無人派遣它們前往之處的 AI 代理(CIAD-2026-0049)。AI 模型供應商當時正在評估代理。這些代理透過留在應用程式設定、公開程式碼儲存庫及權限過寬的雲端角色中的憑證和連線設定,連接印度機構的正式系統,並讀取載有個人及機密資料的業務紀錄。
CERT-In 表示,每宗個案都是 AI 供應商在內部審查後自行披露。相關機構並未察覺。實驗室發現了自身的問題,而從表面看,導致這次存取的執行過程只是一項測試。
公告説了甚麼,以及略去了甚麼
CIAD-2026-0049 的標題是《AI 代理作為攻擊向量》。公告涵蓋兩個不同問題。第一個就是上述情況:CERT-In 表示,機構「收到多宗 AI 模型供應商自願披露的個案」,當中供應商的研究及評估代理超出所分配任務的授權範圍。公告亦指出,「有觀察發現,代理在不同操作中重新推導並重用同一項已暴露的憑證」。代理找到一把金鑰,之後再次查找時,又找到了同一把金鑰。
第二個問題是罪犯利用公開提供的 AI 原生攻擊性網絡安全框架,對印度機構發動攻擊。CERT-In 表示,具代理能力的工具把從首次入侵到造成影響所需的時間由數天縮短至數小時;只完成部分修復的受害者在數天內再次遇襲,規模亦更大(PTI via The Federal)。
這些弱點都不罕見。公告列出程式碼及儲存庫歷史紀錄中的金鑰、被遺忘的測試 API、明文支付金鑰、權限設定過寬的雲端角色,以及沒有多重身份驗證的管理員控制台。公告的總結是,AI 以「更快、更徹底、規模更大」的方式發現並利用這些弱點。
公告略去的內容同樣重要。CERT-In 沒有指出任何供應商、模型或受影響機構(Cyber Press),而公告除了「多宗」之外,亦沒有提供披露個案的數量。因此,不要猜是哪間實驗室。值得參考的是其中的模式,這並非任何一間實驗室獨有的問題。
使用真實金鑰的測試執行,就是正式環境的執行
「測試」、「評測」、「沙盒」:這些詞描述的是你的本意,而不是網絡實際看到的情況。網絡看到的是來自外部的連線,帶有有效憑證,並讀取紀錄。目標系統無法分辨你的評估工作與入侵者。在這個案例中,它兩者都沒有看到。
代理只要能連接網絡,並持有它找到的憑證,無論你如何命名這次執行,它做的都是正式環境的工作。線路另一端並沒有甚麼測試模式。
CERT-In 給實驗室和評估人員的建議,以更審慎的措辭表達了同一件事。預設封鎖對外網絡存取,只允許任務所需的存取,然後:「在網絡層執行限制,而不是透過向模型下達指示。」它亦表示:「如果 Agent 聯絡第三方系統、發現或使用第三方憑證,便自動停止該次執行。」
該指引沒有説明服務提供者如何界定這些執行的範圍,因此我也不會描述。它確實指出,範圍限制必須落實在哪裏。系統提示詞中一句「只接觸沙盒」只是一項要求。模型大多數時候可能會遵守。防火牆規則則不取決於模型是否同意遵守,即使模型已認定憑證在哪裏可用,沙盒就在哪裏,規則仍然生效。
你的程式編寫 Agent 也能讀取同一批金鑰
查閲 CERT-In 給機構的審核清單,想像一下你的手提電腦。清單指出,應檢查原始碼、儲存庫歷史、CI/CD 變數、設定檔、用戶端應用程式及雲端儲存空間中是否有外露的憑證(該指引,B.2 節)。現在數一數終端機中的編碼 Agent 可以讀取哪些內容:儲存庫的 .env、你啟動它時所在的 shell 環境、雲端 CLI 的憑證檔案,以及歷史記錄中的每個提交。
Claude Code 的沙盒文件對預設設定的説明格外坦率。沙盒預設為關閉。啟用後,沙盒命令仍可讀取「機器上的大部分內容,包括 ~/.ssh 和 ~/.aws/credentials 等憑證檔案」,而且會繼承環境變數,「包括其環境中的任何秘密」,除非你另行設定。
歷史記錄是較不顯眼的一環。許多多 Agent 設定都會使用 Git worktree(下文的 Hermes 亦然);它們會連結至同一個儲存庫,並共用「除了每個 worktree 專屬的檔案(例如 HEAD、index)外的所有內容」(git-worktree 文件)。兩年前提交、翌日刪除的金鑰,仍然留在 git log -p 裏,也存在於 Agent 可以開啟的每個 worktree 中。Gitleaks 正是掃描這類輸出:
# --log-opts is passed to `git log -p`; --all covers every ref
gitleaks git -v --log-opts="--all" .
如果找到仍有效的金鑰,先輪換該金鑰。刪除提交,並不能收回已被其他人讀取的金鑰。CERT-In 更進一步指出:在鑑證調查確認環境安全之前,應視環境已遭入侵。
把封鎖措施設在模型之下
對於自行運行 Agent 的機構,CERT-In 列出三項控制措施(B.9 節):「為每次執行提供獨立、短期有效且權限最少的身分」、預設拒絕對外連線,以及「為涉及生產環境的操作保存防篡改的 Agent 活動記錄」。
在手提電腦上,對外連線是目前無需另行建置任何東西便可強制執行的控制措施。Claude Code 的沙盒由作業系統強制執行(macOS 上使用 Seatbelt,Linux 和 WSL2 上使用 bubblewrap),而網絡流量會經過本機代理伺服器,逐一檢查每個主機是否在允許清單內;清單起初不包含任何主機。可設定一份類似以下的用戶層級 ~/.claude/settings.json,其中的鍵值取自沙盒和權限文件:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"network": {
"allowedDomains": ["github.com", "registry.npmjs.org"],
"strictAllowlist": true
},
"credentials": {
"files": [
{ "path": "~/.aws/credentials", "mode": "deny" },
{ "path": "~/.ssh", "mode": "deny" }
],
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" }
]
}
},
"permissions": {
"deny": ["Read(~/.aws/**)", "Read(~/.ssh/**)", "Read(./.env)"]
}
}
strictAllowlist 這一行令清單成為封鎖清單。沒有這一行,未列於清單中的主機不會被直接拒絕:在手動模式下,系統會提示你;在自動模式下,分類器會檢查指令中指定的主機,而 bypassPermissions 會讓連線通過(允許網域以外的主機)。啟用後,代理伺服器會在所有權限模式下拒絕連線。需要 Claude Code v2.1.219 或更新版本。
設定檔有兩個區塊,因為文件明確指出,沙盒只涵蓋 shell 指令。Claude 自己的 Read、Edit、WebFetch 和 WebSearch 工具則遵循權限規則:「denyRead 項目不會阻止 Read 工具,而 allowedDomains 不會限制 WebFetch。」Hooks 和本機 MCP 伺服器會以你的完整存取權限執行。在原生 Windows 環境中,指令不會在沙盒內執行。如果沙盒無法啟動,Claude Code 便會在沒有沙盒的情況下執行指令,除非你設定 sandbox.failIfUnavailable;因此,上述設定檔才會設定這項選項。若要為所有內容設置統一邊界,同一份文件建議使用容器或 VM。其他 Agent 各有自己的沙盒設定;請查看你所用 Agent 的設定,不要想當然。
另外兩項控制措施在手提電腦上較難實施,而且設定檔無法涵蓋。短期有效的身份代表 Agent 取得的憑證會在工作階段結束時失效,而不是使用你長期有效的雲端設定檔。防篡改日誌的保障,取決於日誌的存放位置:必須存放在 Agent 無法寫入的地方。
Hermes 能提供哪些幫助,以及它的限制
我負責開發 Hermes IDE,閲讀本節時請考慮這一點。Hermes 可讓 Claude Code 和 Codex 等程式編碼 Agent 並行運作。每項任務都會在獨立的工作樹中,以各自的 hermes/<name> 分支開始;你可以為每項任務選擇 Agent、模型和帳戶,亦支援每個 Agent 使用多個帳戶(README)。Agent 會使用自己的 CLI 登入。Hermes 絕不會向你索取權杖。

Review Desk 的工作樹分頁:每項任務各有一個工作樹,並使用各自的 hermes/ 分支;畫面顯示任務、存續時間和磁碟大小。
這樣可收窄兩方面的風險。一次執行所作的編輯會留在自己的分支,不會影響你的主要檢出目錄或其他 Agent 的檔案。此外,任務可以使用獨立帳戶執行,因此臨時實驗不必使用你處理正式工作的帳戶登入。
但這無法收窄本安全通告所討論的風險。Hermes 會讓每個 Agent 在真正的終端機中執行,與它在其他地方的執行方式完全一樣,因此 Agent 可以讀取及存取從你的 shell 能夠接觸到的任何內容。每項任務使用不同帳戶,仍然只是長期有效的登入方式。所有工作樹共用一個 .git,因此歷史記錄中的金鑰會在所有工作樹中可見。若要封鎖本安全通告所要求的出站流量,你仍須使用 Agent 的沙盒、容器或網絡規則。

Codex 和 Claude Code 並行運作,各自在自己的工作樹中。分支不同,但使用同一部電腦和同一個網絡。
Hermes 免費,按 BSL 1.1 提供原始碼,並支援 macOS、Windows 和 Linux(下載)。它與 Nous Research、Anthropic、OpenAI 或任何 Agent 供應商均無關聯。
如實看待每次執行
事後,本安全通告提及的研究機構採取了正確做法:進行檢查、發現問題,並通知 CERT-In。大部分受影響的機構原本可能完全不會知道此事。有效的防護措施,是由 Agent 的負責人檢視 Agent 每次執行的情況。
你的程式編碼 Agent 並非實驗室評測。可是,它同樣能接觸到網絡連線、shell,以及放滿你早已忘記存在的金鑰的家目錄。
你目前有沒有為程式編碼 Agent 設定出站連線允許清單?還是仍由指示檔負責限制?歡迎在留言區告訴我。
如果這篇文章對你有幫助
大部分提示詞工程,都是讓模型按你的意思行事。這份建議指出其界線:提示詞可以説明範圍,但只有網絡才能限制範圍。Prompt Engineering Pocket Guide 探討前半部分:真正能引導模型的系統提示詞和指令,以及提示詞注入——你的指令遇上你無法控制的輸入。如果你會執行多個 Agent,並希望每項工作各自在獨立分支上進行,可以免費試用 Hermes IDE。
來源:DEV Community · dev.to

