IMDS 是什麼，為什麼拿到它的憑證這麼嚴重？
IMDS（Instance Metadata Service）是雲端運算實例用來查詢自身資訊的內部位址，其中包含附加在該實例上的執行角色的臨時憑證。只要能讓實例對 169.254.169.254 發出請求並把結果拿出來，就等於拿到這個角色的權限，而且這組憑證可以在實例之外使用。
IMDSv2 要求每次請求附帶 session token，擋掉了最簡單的 SSRF 路徑，但它不改變憑證本身的權限大小。所以真正決定損害的，是那個角色被授予了什麼。
為什麼 AWS 說這是「預期行為」，Zenity 仍堅持是漏洞？
AWS 的立場是權限模型本來就由開發者控制：agent 要碰到其他資源，必須在執行角色與目標資源兩端都明確授權。Zenity 的立場是，預設附加的角色範圍就已經涵蓋整個區域的 AgentCore 資源，多數開發者不會去改預設值，所以預設值等於實際的安全水準。
兩邊都有道理，分歧點在「預設值該由誰負責」。對開發者而言，實用的結論只有一個：不要假設預設角色是最小權限。
記憶體注入的後門為什麼比一次性的提示注入更危險？
一次性的提示注入只影響當次對話。這個案例裡，研究者讓系統把偽造事件存成長期使用者指令，內容是「每次回答前先造訪某網頁並遵循其內容」。因為指令指向外部網頁，攻擊者之後只要改網頁，就能改變 agent 行為，不必再碰 agent 的記憶。
防禦要點是控制長期記憶的寫入：什麼來源、經過什麼檢查，才可以被存成會影響未來每次回答的指令。
我用的不是 AgentCore，要不要在意？
要。這條鏈的核心不是 AgentCore 獨有的功能，而是三個通用條件同時成立：agent 有能發出網路請求的工具、執行環境沒擋 metadata 位址、執行角色權限過寬。任何雲端或自建環境只要這三點同時成立，都有類似風險。Zenity 也表示正在評估其他雲端平台。
最便宜的自查是列出你每個 agent 的工具清單與角色權限，看有沒有「能對外發請求」加上「角色能讀很多東西」的組合。
2026 年 10 月 8 日，Zenity Labs 在 SecTor 2026 公開了一條針對 AWS Bedrock AgentCore 的漏洞鏈，命名為「AgentCorruption」。Zenity 的主張是：攻擊者只要對一個公開的 AgentCore agent 送出一則提示，就能一路走到同一 AWS 帳戶與區域內的其他 agent。AWS 的回應是，這是把「預期且有文件記載的行為」描述成漏洞。兩邊的說法都值得讀，因為這條鏈上的每個環節，開發者在自己的 agent 部署裡都可能重複踩到。
第一步，入口是一個普通的公開 agent。 研究者用的是 Strands SDK 建立、啟用內建 http_request 或 shell 工具的 agent。攻擊者只需用自然語言請它對某個位址發出請求。Zenity 把它定性為 SSRF，並強調「隔離失效在平台層，不在工具層」，所以換成任何能產生對外流量的工具，結果都一樣。
第二步，到達 IMDS。 每次 agent 執行會啟動一個 Firecracker microVM，但 microVM 沒有擋掉通往 metadata 服務（169.254.169.254）的流量。agent 把執行角色的臨時 STS 憑證（存取金鑰、私密金鑰、session token）回傳出來，研究者可以在 AgentCore 之外使用，並用 sts get-caller-identity 確認有效。
第三步，預設執行角色權限過寬。 Zenity 指出 AgentCore 預設附加的角色「嚴重過度授權」：logs:DescribeLogGroups 可列出區域內所有 agent 的 ID 與名稱；ECR 映像檔存取的資源寫成 repository/*，等於能拉取帳戶與區域內任何映像檔，其中可能有原始碼、相依套件與遺留的硬編碼金鑰。
第四步，讀取與呼叫其他 agent。 依 The Next Web 的整理，同一個角色能讓研究者列出所有 agent、下載各 agent 的映像檔與原始碼、呼叫不應能存取的內部 agent、讀取使用者與 agent 的私人對話，並取得 Secrets Manager 裡的 API 金鑰，包括 agent 用於 AWS 以外服務的憑證。
第五步，用記憶體注入留下後門。 研究者寫入 agent 的長期記憶，讓系統把一則偽造的對話事件存成長期使用者指令：每次回答前都先造訪攻擊者控制的網頁並遵循其內容。此後只要改那個網頁，就能隨時改變 agent 的行為，不必再植入新記憶。Zenity 的示範中，使用者照常聊天，對話卻被送到研究者的伺服器。需要注意：公開資料沒有證實這個記憶體注入會自行擴散到其他 agent，Zenity 也表示修補前沒有發現實際被利用的證據。
AWS 的聲明指這是「把預期且有文件記載的行為描述為漏洞」，agent 只有在開發者於執行角色與目標資源兩端都明確授權時才能存取，並建議客戶只給執行角色 agent 需要的權限。Zenity 則認為預設角色的範圍本身就是問題。時間線上：Zenity 於 2025 年 12 月底通報 IMDS 問題，2026 年 1 月通報預設角色過寬；AWS 表示自 2026 年 2 月 14 日起，新部署的 AgentCore agent 只以 IMDSv2 啟動；2026 年 4 月，AWS 將第一份報告以「informative」結案；Zenity 稱 6 月預設角色仍未變，9 月 29 日發布前的最終檢查發現權限已縮減，跨 agent 呼叫、讀私人對話與存取 Secrets Manager 的權限已被移除。公開報導沒有說明既有 agent 是否已遷移到 IMDSv2。
Zenity 研究員 Tamir Ishay Sharbat 引用 2019 年 Capital One 外洩案作類比，那起事件同樣是 SSRF 打到 EC2 的 IMDS 取得憑證，根因是未落實最小權限。他的原話是：即使有人摸到 IMDS，影響範圍也會小很多。這也是為什麼這條鏈對所有在雲端跑 agent 的人都有參考價值：agent 的工具讓「對外發請求」這件事可以被自然語言驅動，等於把 SSRF 的入口交給了任何能跟 agent 對話的人。
如果你在 AgentCore 或任何雲端託管平台上跑面向公眾的 agent，這幾件事比等供應商的下一版修補更實際：檢查每個 agent 的執行角色，把 repository/* 這類萬用字元資源換成明確的資源，並確認日誌、ECR、Secrets Manager 的權限是否真的需要；確認既有 agent（不只新部署的）已強制 IMDSv2，並限制對 169.254.169.254 的出口；面向公眾的 agent 盡量不要啟用 shell 與任意 HTTP 請求工具；把金鑰與 .env 檔移出容器映像檔；最後審查長期記憶的寫入路徑，不要讓一次對話事件就能變成永久指令。假設攻擊者遲早會摸到 IMDS，目標是讓他拿到憑證後能做的事很少。