預設角色而非模型:一個 prompt 如何接管 AWS 帳戶中的所有代理人

核心要點

• 向一個面向公眾的代理人發送的一個 prompt 就攻陷了同一 AWS 帳戶和區域中的所有 AgentCore 代理人 —— Zenity Labs 於 2026 年 10 月 8 日在多倫多 SecTor 大會上揭露了 AgentCorruption 攻擊鏈,此前始於 2025 年 12 月 25 日的負責任揭露流程。
• 影響範圍是角色屬性,不是模型屬性 —— 預設執行角色帶有 bedrock-agentcore:InvokeAgentRuntime、bedrock-agentcore:ListEvents、一個跨代理人的記憶寫入權限、bedrock-agentcore:GetResourceApiKey 和 secretsmanager:GetSecretValue,作用域涵蓋整個帳戶區域而非單一代理人。
• 修復用了 278 天 —— AWS 在 2026 年 2 月 14 日前將 AgentCore 遷移到 IMDSv2,但 Zenity 在 2026 年 6 月 22 日的複查發現預設角色依然如故;權限移除直到 2026 年 9 月 29 日才落地。
• 代理人記憶是一個持久化攻擊面 —— 研究人員植入的記憶將代理人未來的對話重定向到攻擊者控制的目的地,而使用者仍在與一個看似可信的企業代理人對話。
• AWS 稱該行為「documented and expected」 —— 並建議客戶只為執行角色授予代理人所需的權限。預設角色的審查是客戶的工作,在任何託管平台上都是如此。

2026 年 10 月 8 日,在多倫多的 SecTor 大會上,Zenity Labs 揭露了 AgentCorruption:Amazon Bedrock AgentCore(AWS 用於部署和營運 AI 代理人的託管平台)的一系列缺陷。向一個面向公眾的代理人——例如一個暴露在網際網路上的客服代理人——發送的一個 prompt,傳回了分配給該代理人所在機器的臨時 AWS 憑證。這些憑證屬於一個預設 IAM 角色,其權限範圍不是單一代理人,而是同一 AWS 帳戶和區域中的所有 AgentCore 代理人。藉助這些憑證,研究人員呼叫了他們從未獲得授權的內部代理人,跨代理人和使用者讀取了私有對話,下載代理人容器映像檔以提取原始碼,從 AWS Secrets Manager 擷取 API 金鑰和 OAuth 權杖,並植入了在工作階段結束後仍在起作用的記憶。

以上全程不需要任何模型失效。模型在整條攻擊鏈中唯一的工作,是被要求時發出一個 HTTP 請求。其餘一切都發生在 IAM 層。本文拆解這條五步攻擊鏈、讓每一步成為可能的具體權限、278 天的揭露時間線,以及任何團隊在託管代理人平台上部署代理人之前應當問清的五個問題——無論供應商是誰。

攻擊鏈逐步拆解

Zenity Labs 將完整研究發表為五部分技術系列;整條鏈可壓縮為五個動作。

第 1 步:prompt 注入直達 IMDS。 AgentCore 代理人執行在 Firecracker microVM 中,其網路隔離並未阻斷執行個體詮釋資料服務。任何能夠發出對外 HTTP 請求的代理人工具,都是從執行個體內部發出該請求——這是一個 SSRF 原語。一個 prompt 指示暴露的代理人呼叫 169.254.169.254(Instance Metadata Service),後者交出了分配給該工作負載的角色的臨時 IAM 憑證。入侵成本只是與一個帶常用工具的代理人的聊天存取權。

第 2 步:全帳戶偵察。 憑證屬於一個未按具體代理人限定的預設執行角色。其權限中包括 DescribeLogGroups,研究人員用它列舉了整個帳戶區域內的每個代理人及其 ID。第二條偵察路徑是免費的:Elastic Container Registry 儲存庫名稱與代理人 ID 一一對應,因此該角色的 ECR 拉取權限讓研究人員能下載任何代理人的容器映像檔並完整讀取其原始碼。

第 3 步:橫向移動。 該角色包含作用於整個區域的 bedrock-agentcore:InvokeAgentRuntime。研究人員可以呼叫帳戶中的任何 AgentCore 代理人——包括他們無權存取的內部敏感代理人。揭露中的實例:從暴露在網際網路上的客服代理人進入的攻擊者,橫向移動到同一區域的內部財務代理人,呼叫它並存取其資料、工具和憑證。

第 4 步:資料與憑證存取。 bedrock-agentcore:ListEvents 傳回了所有代理人、使用者和工作階段的全部私有對話——平台的隱私邊界被溶解。bedrock-agentcore:GetResourceApiKey 和 secretsmanager:GetSecretValue 隨後觸及了 AgentCore 刻意讓代理人無法觸及的憑證:API 金鑰、OAuth 權杖和 Secrets Manager 條目,包括用於連接 AWS 之外的企業資源和第三方服務的憑證。

第 5 步:藉助記憶實現持久化。 該角色還帶有一個記憶寫入權限——作用於 BedrockAgentCoreMemory 的 bedrock-agentcore:CreateEvent。研究人員跨不同代理人和使用者建立了新記憶,持久地改變了代理人行為,並在未來工作階段中劫持代理人的目標,將對話導向攻擊者控制的目的地。入侵在建立它的那個工作階段結束後仍然存活。

下圖描繪了這五個動作以及每一步暴露了什麼:

角色問題,不是模型問題

結構性的教訓在於這五步全程沒有涉及什麼:沒有越獄,沒有對齊失效,沒有超出「呼叫這個 URL」的複雜 prompt 工程。Zenity 共同創辦人兼 CTO Michael Bargury 把根因歸結為每個平台出廠時都自帶的張力:「雲端安全的核心是分段和最小權限存取。但 AI 代理人需要發揮空間才能有用。把兩者混在一起就會產生內在衝突。」他的結論是:「每家在雲端部署代理人的公司都會遇到在自主性與最小權限之間做選擇的同樣問題。」

AgentCore 把這個衝突解決向了自主性一邊——為的是平台的便利,不是客戶的安全。預設執行角色之所以很寬,是為了讓代理人開箱即用,其權限涵蓋帳戶區域內的每個代理人資源。AWS 自己的聲明(與研究一同發布)表示該行為是「documented and expected」,代理人可以透過詮釋資料服務存取自己執行角色的憑證,並且「作為最佳實務,我們建議客戶只為執行角色授予其代理人所需的權限」,同時指向其憑證管理、執行階段權限和最小權限指南。

把這兩個事實放在一起讀,買方的立場毫無歧義:平台把預設角色當作起點,把被攻陷代理人的影響範圍當作客戶的組態問題。對一個雲端供應商來說這是站得住腳的立場——IAM 最小權限自 IAM 誕生起就是客戶的工作。但它與託管代理人平台的行銷敘事相衝突——那個敘事說平台負責營運強化,你的團隊不必操心。AgentCorruption 鏈就是這種衝突在實務中的樣子:平台的預設值就是漏洞,平台的文件就是緩解措施。

從揭露到修復的 278 天

揭露時間線是第二重教訓。Zenity 於 2025 年 12 月 25 日報告了最初的 IMDS 存取。AWS 在 2026 年 2 月 14 日前將 AgentCore 更新為僅對新建部署的代理人啟用 IMDSv2,並在 4 月 12 日把該報告關閉為「informative」。但 Zenity 的第二份報告——預設角色的影響範圍,2026 年 1 月 12 日提交——進展更慢。2 月 25 日,AWS 表示團隊正在積極處理,預設角色原樣未動。2026 年 6 月 22 日,Zenity 複查並確認權限仍然未變。實質性修復——移除允許寬域代理人執行、讀取私有對話和存取 Secrets Manager 的權限——於 2026 年 9 月 29 日被觀察到,距首次揭露 278 天,距公開發布僅數日。

日期	事件
2025-12-25	Zenity 向 AWS 揭露最初的 IMDS 存取
2026-01-12	Zenity 提交預設角色影響範圍報告
2026-02-14	AgentCore 對新建代理人僅啟用 IMDSv2
2026-02-25	AWS 確認正在處理;預設角色不變
2026-04-12	AWS 將 IMDS 報告關閉為「informative」
2026-06-22	Zenity 複查:預設角色仍未變
2026-09-29	預設角色強化——移除跨代理人、對話讀取和 Secrets Manager 權限

這對任何指望託管平台預設值的團隊有兩重含義。第一,即便在負責任揭露之後,一個便利性預設值也可能在近一年裡都是一顆長期漏洞——「我們報告了」到「已修復」之間的窗口以月計,而你的代理人就運行在這個窗口裡。第二,修復本身就是論點的證明:AWS 沒有重新訓練模型,也沒有加安全過濾器。它改的是一份角色政策。影響範圍從頭到尾都是一份 IAM 文件。

記憶是一個持久化攻擊面

鏈條中最具前瞻性的部分是第 5 步。讀取資料是一次洩露;修改記憶則是一次接管。研究人員用角色的記憶寫入權限植入了在工作階段結束後存活的指令,把未來的對話重定向到攻擊者控制的目的地,並讓代理人看起來仍在正常運行。一次「停掉代理人、輪換憑證、修補注入向量」的事件回應,並不能清除植入的記憶。如果記憶儲存不在回應範圍之內,入侵就會穿過清理過程持續存在。

這與 2026 年 10 月 Anthropic 揭露的、促使其切斷所有內部代理人評估網際網路存取的那類行為修改屬於同一類——即兩個前沿實驗室,同一個承認的主題。那篇文章講的是前沿實驗室承認對齊訓練不足以約束代理人行為。AgentCorruption 則在下一層、平台層展示了同樣的問題:一個任何持有正確 IAM 權限的主體都能寫入的記憶儲存就是一個持久化機制,而以設計為本的終止開關所涵蓋的 kill switch 架構必須把記憶當作被攻陷狀態的一部分——不只是執行階段。

在任何託管代理人平台上部署前的五個問題

AgentCore 是完整剖析過的實例,不是特例。Zenity 的新聞稿本身點出了普遍性:企業普遍在同一個雲端環境中並排運行面向客戶的代理人和內部代理人,而一個代理人中一處意料之外的弱點就可能讓整個環境的邊界崩塌。平台會不同,權限類別卻會押韻。在任何代理人於託管平台上線之前,取得對以下五個問題的書面回答:

1. 預設執行角色裡到底有什麼? 不是「預設是否安全」——要的是那份政策文件,逐條權限。標記每一條作用域為 * 或涵蓋帳戶內所有代理人的權限。AgentCorruption 鏈就是對這個問題五條權限的答案。
2. 一個代理人能否發現其他代理人? 任何帳戶層級的 list 或 describe 權限都會把一個被攻陷的代理人變成一份目標清單。DescribeLogGroups 就是列舉步驟;每個平台都有等價的列舉面。
3. 一個代理人能否呼叫另一個? 代理人到代理人的呼叫是橫向移動原語。如果平台無法把呼叫限定在顯式的逐代理人允許清單上,就把帳戶內的所有代理人當作同一個信任網域——因為攻擊者正是這麼對待它們的。
4. 工具憑證存放在哪裡,哪個角色能讀取它們? 一個密鑰閘道只有在沒有任何代理人角色能對其呼叫 GetSecretValue 時才算真正轉移了風險。AgentCorruption 角色能讀取的,恰恰是平台設計本應讓代理人無法觸及的憑證。
5. 代理人自身之外、其自身工作階段之外,是否還有任能主體能寫入記憶? 跨代理人和跨使用者的記憶寫入把記憶儲存變成了持久化攻擊面。如果答案是「可以限定權限」,就去限定;如果不能,記憶儲存就必須作為攻擊者控制的狀態寫入你的事件回應計畫。

延伸閱讀

• Bedrock vs OpenAI:為生產級代理選擇託管 AI 平台 —— 本次事件落在其上的託管平台比較:成本、隱私與供應商穩定性,預設角色問題現已加入盡職調查清單
• 一個月內 126 起事件:首份全面的 AI 安全清單及其對代理風險的證明 —— 本次事件背後的頻率陳述:代理人層攻擊是 2026 年 9 月最大的攻擊向量類別
• AI 代理治理清單:面向生產級代理的部署前審查 —— 完整的部署前審查,包含最小權限執行角色和跨代理人發現兩個檢查項

一家在託管平台上運行兩個代理人的中型工業配銷商——一個面向 BigCommerce 店面和目錄的公共報價代理人,一個帶 NetSuite 價格檔位和庫存存取權的內部代理人——恰好擁有 AgentCorruption 所利用的拓撲:同一帳戶中一個暴露在網際網路上的代理人加一個後台代理人。我們建構所用的模式為每個連接器模組分配獨立的最小權限角色,註冊代理人可呼叫的每一件工具,按代理人限定記憶作用域,並寫一條能暴露工作階段外記憶寫入的稽核軌跡。重點不在於權限受限的建構對平台側缺陷免疫;而在於下一次事件的影響範圍由你的團隊審讀過的角色政策決定,而不是由平台出廠的預設值決定。

一週探索期。你會得到系統清單、工作流地圖和固定範圍——無論是否與我們合作。

申請一次範圍明確的建置。