一個提示詞、一個代理程式、一整個 AWS 帳戶：深入剖析 Amazon Bedrock AgentCore 上的 AgentCorruption

2026年10月8日，Zenity Labs揭露了AgentCorruption：存在於Amazon Bedrock AgentCore（AWS 用以部署與執行 AI 代理的受管平台）的一連串漏洞，可讓單一針對某個公開代理的自然語言提示，控制同一 AWS 帳號與區域內的所有 AgentCore 代理。這項研究與SecTor 2026在多倫多的一場演講一同發表，會中 Zenity 的安全研究總監Tamir Ishay Sharbat發表了該研究（Dark Reading，2026年10月8日）。Zenity 自家的報告由 Sharbat、Lana Salameh、Dmitry Lozovoy 與 João Donato 共同掛名，開頭便說明其機制：一個 AgentCore 代理只要擁有任何能發出對外請求的工具，就可能被誘導去呼叫AWS Instance Metadata Service (IMDS)，其連結本地位址為 169.254.169.254，該服務會傳回該代理自身執行角色的臨時憑證。Zenity 表示，他們將這些憑證匯出到自家機器，並確認在該處可正常使用。此漏洞未獲指派 CVE 編號。

檔案庫將此事記錄為漏洞——是被發現，而非必然已遭利用——且具高嚴重性、可信度 A，沒有實際損害的紀錄，並已確認涉及 AI。各方雖然對行為本身看法一致，卻對如何定性有所分歧：AWS 向 Dark Reading 表示，該研究「不準確地將預期且已記錄在案的行為描繪成漏洞」。

這條鏈實際上究竟是什麼

AgentCore 會將每個 agent 打包成一個容器，並在每個工作階段專屬的 Firecracker MicroVM。Zenity 在本系列的第一篇文章中，以平實的措辭向一個用 Strands SDK（AWS 的開源 agent 框架）打造的測試 agent 提出請求，便完整重現了整個立足點。該框架內建 HTTP 請求工具與 shell 工具。這個 microVM 並未限制前往中繼資料服務的流量，因此請求是從執行個體內部發出，IMDS 便予以回應。研究人員接著逐一探測各個端點：IAM 角色名稱、暫時性 STS 憑證本身、user-data 端點——該端點回傳了帳戶 ID、完整的 ARN、執行階段 URL，以及該 agent 的 Amazon Elastic Container Registry (ECR) 映像 URI——還包括執行個體標籤，其中有 mTLS 憑證鏈、私密金鑰，以及指向內部儲存空間的預先簽署 URL。Zenity 表示，透過 shell 工具也能得到相同結果，因為隔離失效的問題出在平台層級，而不是任何單一工具。

那段過程中，有兩個細節很容易被一眼略過。這些憑證並未被侷限在沙箱之內：Zenity 將它們匯出到 AgentCore 之外，並發出一個 AWS 身分呼叫，而回傳的身分正是該代理所代入的角色。而且，遭竊取的角色能夠拉取容器映像，這正是代理的原始碼變得可讀的原因——Zenity 的文章指出，映像中往往帶有硬編碼的金鑰、殘留的權杖，以及本不該被烤入的設定，而拉取下來的映像就是一張底層業務邏輯的地圖。

預設角色正是立足點變成帳號的地方

第二個缺陷（另行通報）在於，AgentCore 預設附加至代理的執行角色並未限定於單一代理。Zenity 描述其權限可觸及帳戶與區域內的每一項 AgentCore 資源，包括 bedrock-agentcore:InvokeAgentRuntime、bedrock-agentcore:ListEvents、bedrock-agentcore:CreateEvent、bedrock-agentcore:DeleteEvent，以及在憑證鏈末端的 bedrock-agentcore:GetResourceApiKey 與 secretsmanager:GetSecretValue。

可列舉性把那些萬用字元變成了一份目標清單。Zenity 使用了該角色的 logs:DescribeLogGroups 權限，因為 AgentCore 會將每個代理程式的 CloudWatch 日誌群組命名為 /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}，並從這些日誌群組名稱推導出代理程式 ID。ECR 儲存庫名稱遵循研究人員觀察到的慣例——bedrock-agentcore-<agent_name>——因此可以拉取該區域中每個代理程式的映像檔。記憶體資源也以相同方式找到，依據日誌群組模式 /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}，而該角色的 ListActors、ListSessions 與 ListEvents 權限產生了讀取對話內容所需的參與者與工作階段識別碼。

Zenity 的報告提供了一個具體的橫向移動示範：透過一個對外公開的代理進入，發現了billing_agent（位於同一區域）的工具，並發現一個名為 billing.json 的檔案，再透過檔案讀取工具將其外洩。新聞稿以概括性的措辭描述了同樣的情境——攻擊者透過一個面向網際網路的客戶服務代理進入後，可能轉移到部署於同一區域的內部財務代理、叫用它，並觸及其資料、工具、相關憑證與私人對話。

記憶是比提示存續得更久的那部分

AgentCore Memory 會將對話本身保留為短期記憶，並將擷取出的記錄儲存為長期記憶，使用名為 SEMANTIC、USER_PREFERENCE、SUMMARIZATION 與 EPISODIC 的策略。Zenity 使用 CreateEvent 將對話事件寫入其他代理的記憶資源。其文章謹慎說明該基本操作能做與不能做的事：CreateEvent 不允許呼叫者選擇長期命名空間，或直接覆寫記錄——目標記憶已設定的策略會決定要擷取什麼以及它會落在何處。Zenity 也描述 DeleteEvent 被用來移除工具結果事件，使代理因資料缺失而得出錯誤結論，並透過刪除植入記憶的事件來掩蓋行蹤。

寫入原語所產生的結果是持久化。Zenity 的示範植入了一項請求，要求代理程式在回答之前先取得研究人員所控制的頁面，並遵循該頁面的內容——那是一個命令與控制端點，其指令無須植入另一段記憶即可更改。同一個通道隨後也把對話內容外送出去：該報告描述代理程式將使用者的訊息與自身的回覆傳送到一個收集端點，並指出該角色的記憶權限橫跨整個帳號與區域，而不僅限於遭入侵的代理程式。隨該研究發布的一段影片顯示，使用者持續進行對話，而這些內容正送達研究人員的伺服器。

AWS 以外的憑證

系列中的最後一篇文章為連接工具畫上了句號。AgentCore Identity 和 Outbound Auth 將工具憑證儲存為機密，存於 AWS Secrets Manager，其名稱由供應商名稱與固定模式組成，例如 bedrock-agentcore-identity!default/apikey/{provider_name}。Zenity 透過爬取它已從 ECR 提取的代理程式原始碼來復原供應商名稱，並透過暴力破解復原其他名稱：它報告指出，預設的五字元後綴是在用戶端由數字和小寫字母產生的，這給出了 2 x (10+26)^5 = 120,932,352 種組合（涵蓋兩種供應商類型）。在它對 Secrets Manager 所能維持的請求速率下，Zenity 表示完整列舉需要數小時——比 STS 憑證的持續時間更長——因此它建立了一個迴圈，在舊憑證過期時重新查詢代理程式的 IMDS 端點以取得新憑證。Zenity 補充說，環境變數可透過中繼資料使用者資料端點讀取，每個名稱都加上前綴 CONTAINER_ENV_，包括代理程式用來向其模型供應商驗證的金鑰，而且以合適的提示詞叫用每個發現的代理程式，就能大規模地收集這些值。

已確立，但因技術細節而受到爭議

具體且明確的是：AgentCore 可以存取 IMDS，並取得自身執行角色的暫時性憑證——AWS 對此並未否認，還將其描述為「已記載且符合預期」。預設執行角色所帶的權限範圍是針對帳戶與區域，而非僅限於單一對象；AWS 之後已變更該角色，並表示自家測試已證實權限範圍縮減。這項研究是一項示範，而非已觀察到的實際攻擊行動：Sharbat 告訴 Dark Reading，Zen 沒有看到任何證據顯示該漏洞在修補前曾於真實環境中遭到利用，並將部分原因歸因於在 AgentCore 上執行代理的難度，還補充說他「100% 確信有辦法做到」。

有爭議的是，其中任何一部分是否應被稱為漏洞。AWS 提供給 Dark Reading 與 The Next Web 的聲明寫道：「AWS 已知悉針對 Amazon Bedrock AgentCore 發布的研究，該研究不準確地將預期且已記載的行為描繪成漏洞。唯有開發人員同時在代理程式的執行角色與目標資源上明確授予權限，代理程式才能存取另一個 AWS 帳戶中的資源。」Zenity 自家貼文中轉載的 AWS 聲明，保留了第一句的實質內容——「所描述的行為已記載且屬預期」——並補充說，客戶應只授予執行角色其代理程式所需的權限。這項歧異背後有兩件事。AWS 是以能否存取另一個 AWS 帳戶中的資源來界定邊界，而 Zenity 的發現則涉及單一 AWS 帳戶與區域內的代理程式；此外，Zenity 所描述的角色來自平台預設值，而非來自客戶自行手寫政策。

The Next Web 對自身報導的更正值得記錄下來，因為它顯示這項說法是被研究人員以外的人收緊的。該媒體最初報導、後來更正了一則標題，該標題稱研究人員接管了某個區域內每一個 AgentCore 代理；更正後的版本指出，該研究涵蓋的是單一 AWS 帳號與區域內的代理，並註明先前的標題將研究人員的說法陳述為事實。

該披露

Zenity 提交的是兩份報告而非一份，而兩者得到的回覆並不相同。IMDS 存取報告於2025 年 12 月 25 日送出；AWS 於2026 年 4 月 12 日以「僅供參考」為由結案，並寫道 AgentCore 自2026 年 2 月 14 日起才開始使用 IMDSv2，新部署的代理程式皆以此方式啟動。這項修訂對本研究的具體細節至關重要，因為 IMDSv2 要求每個請求都必須附帶工作階段權杖，使研究人員用來取得憑證的單純未經驗證抓取方式不再可行。第二份報告探討預設角色及其影響範圍，於2026 年 1 月 12 日送出。AWS 於2026 年 2 月 25 日告知 Zenity，團隊正在處理此事，而該角色維持原狀；Zenity 於2026 年 6 月 22 日再次檢視該角色，發現其權限沒有任何變動。最後一次檢視於2026 年 9 月 29 日發現該角色已被大幅縮減，而 Zenity 的新聞稿指出，移除的權限涵蓋叫用其他代理程式、讀取私人對話，以及存取 AWS Secrets Manager 中的機密，其他權限也受到大幅限制。Zenity 自家的文章指出，AWS 其後已將 IMDSv2 設為 AgentCore 部署的預設值，雙方也在整個過程中持續合作。

什麼是未知的

Zenity 尚未公布在二月 IMDSv2 變更與九月下旬收窄之間，有多少代理程式或組織以預設角色執行，且所引用的來源中沒有任何內容指出有任何客戶資料在研究者自身環境之外遭到暴露。根據 Zenity 引述 AWS 的說法，IMDSv2 變更適用於 2026 年 2 月 14 日之後部署的代理程式；對於在該日期之前部署的代理程式意味著什麼，本文所檢視的來源並未說明。該檔案庫未記錄任何實際損害，而這些來源支持這種解讀：它們描述的是一項示範，且 AWS 是對該漏洞標籤提出異議，而非通報自身發生的事件。

Sharbat 向 Dark Reading 表示，Zenity 目前正在檢視其他雲端平台是否有類似的中繼資料存取問題，而該公司尚未點名是哪些平台。他所述的結論重點在於權限，而不只是中繼資料服務本身：「即使有人存取了 IMDS，影響範圍也會小得多。」

為何保留此記錄

AgentCorruption 之所以值得注意，並不是因為中繼資料端點是個新概念。Sharbat 向 SecTor 聽眾指出 2019 年 Capital One 外洩事件，當時 SSRF 觸及 IMDS，最終導致憑證遭竊，並將那起事件描述為同一類型的最小權限失效。新穎之處在於執行擷取的行為主體。那個產生 AWS 身分的請求，是由一個 AI 代理發出的；它以自然語言做著被要求的事，並透過一個為了讓它能派上用場而賦予它的工具來進行——而該代理把答案轉送回傳。讓這件事變成整個帳號層級問題的兩個條件，是沙箱未封鎖的中繼資料端點，以及一個權限範圍比持有它的代理更廣的預設角色。

完整的研究，包括由五個部分組成的技術系列與示範影片，都連結自 Zenity 於 2026 年 10 月 8 日發布的新聞稿。這筆記錄是已記錄的 AI 代理事件之一，收錄於 AI 事故資料庫，其中每一筆記錄都附有自己的來源、嚴重程度、可信度等級與爭議標記——正是這些欄位讓人得以區分像這裡這樣關於框架論述的供應商爭議，與有爭議的損害認定。

這是一筆記錄，由他人研究並報導，此處引用時歸功於他們。其他有紀錄的代理程式事件，各自都有其來源、嚴重程度、信心等級與爭議標記，全都收錄於AI 事件檔案庫——因此，一個能把單一提示變成涵蓋整個帳號之立足點的平臺預設設定，可以與其他地方實際發生過的情況並列參照。