AI 代理能回答問題，也可能替使用者呼叫 API、讀取資料或操作雲端資源。Zenity Labs 於 2026 年 10 月 8 日公開 AgentCorruption 研究，描述一條從公開互動入口、提示詞注入，到執行環境憑證與其他代理權限的攻擊鏈。企業要判斷這項研究和自家部署有沒有關係，第一步是盤點代理在執行時能取得什麼身分、能呼叫哪些工具，以及那些權限能觸及哪些資源。

一、公開代理的風險，從它能拿到什麼憑證開始

研究展示的是特定測試配置下，外部使用者可能透過公開互動的 AgentCore 代理，誘導具備 HTTP 能力的工具向內部中繼資料服務發出請求，進而接觸執行角色的暫時憑證。後續能否擴大，還要看憑證權限、代理入口與當時的服務配置。

Zenity 將這系列發現命名為 AgentCorruption。報告指出，研究人員在其測試環境中，讓代理的 HTTP 請求抵達執行環境中的 Instance Metadata Service（執行個體中繼資料服務，IMDS），取得該工作負載可用的暫時 AWS 身分憑證。這種請求若由伺服器代為發出，攻擊者就可能借用代理所在環境的網路位置，這類問題通常以伺服器端請求偽造（SSRF）描述。

這裡的提示詞注入，不是單靠一句文字就能遠端登入雲端帳戶。攻擊鏈需要多個條件相接：代理能被未受信任者呼叫，模型或流程接受惡意輸入，代理有可讓它發出 HTTP 請求的工具或程式能力，且執行環境可連到憑證端點。少一個環節，研究中的路徑可能就不成立；條件是否存在，必須在具體部署中查證。

IMDS 提供執行環境所需的工作負載憑證，讓程式可以依 IAM 角色呼叫 AWS 服務。Zenity 的文章描述，測試代理發出的請求可取回這類暫時憑證。AWS 官方安全文件也提醒，AgentCore 微型虛擬機（microVM）內執行的程式碼可透過 MicroVM Metadata Service（MMDS）取得執行角色憑證，因此角色應只保留代理工作所需的操作與資源權限。這表示憑證端點的可達性和憑證本身的權限是兩道不同的控制。

Zenity Labs 將研究中的關鍵鏈結概括為：公開代理的提示輸入可能連到 IMDS 暫時憑證，再由工作負載角色的權限決定可觸及的資源。這是研究團隊對其測試結果的描述，不能直接推定為其他帳戶或目前所有部署的狀態。Zenity Labs 研究

研究結果也有明確的時間脈絡。Zenity 表示，AWS 在 2026 年 2 月 14 日起更新 AgentCore 行為，使新部署代理採用 IMDSv2；AWS 現行 Runtime 安全文件則指出，MMDSv2 已成為必要設定。較新的機制提高請求條件，但不能取代 IAM 權限最小化，也不能單獨證明代理的網路路徑、工具或程式碼沒有其他弱點。檢查時應以實際 runtime 設定和 AWS 最新文件為準。

二、單一代理為何可能牽動同帳戶其他代理

只有當被取得的憑證對其他 AgentCore 資源具有可用權限，且資源政策允許相關呼叫時，單一代理才可能成為進一步存取的起點。Zenity 報告了特定預設角色曾涵蓋同帳戶、同區域多項代理操作的情境；該研究同時記載 AWS 後續收緊了部分預設權限。

研究所描述的擴大路徑，起點是代理角色授權範圍。依 Zenity 的回顧，早期測試環境中該角色可探索區域內的代理資源、呼叫其他代理、讀取對話事件，也曾具有讀取祕密與操作代理記憶體的權限。若代理可以讀取不屬於原始使用者的對話，問題便會從單一代理輸出錯誤，擴大到跨使用者資料暴露；若可寫入長期記憶，影響還可能延續到後續工作階段。

「同帳戶、同區域」是研究團隊說明其測試範圍時使用的界線。它不等於所有帳戶的所有代理都能被單一提示接管，也不代表研究者已驗證每一種 AgentCore 部署形態。研究結果依賴當時的角色政策、服務行為、代理工具和可達網路。媒體報導有助理解事件，The Decoder 的報導亦指出 AWS 已收緊部分預設權限；技術細節與後續變化仍應回到研究者原文和 AWS 文件確認。

更重要的是，Zenity 在 2026 年 10 月 8 日的文章記載，AWS 曾於 2026 年 9 月 29 日前後更新預設執行角色。研究團隊表示，複查時已移除可跨區域執行代理、讀取私人對話及存取 Secrets Manager 祕密的部分權限，並收緊其他權限。這是研究者對其複查結果的描述；不同時點建立、由團隊自訂角色，或已修改政策的環境可能不一樣。不能只看文章發布日期，就推論自家帳戶已自動套用相同狀態。

一個公開代理的工作負載憑證以箭頭連向其他代理、記憶體、祕密與對話資料，部分路徑標示為拒絕。
研究中的跨資源影響取決於角色與資源政策，取得憑證不代表所有路徑都能通行。

高風險對象包括持有 AWS 帳戶管理或 IAM 政策修改權限的人員、維運公開代理的團隊、雲端安全與事件應變人員，以及讓代理接觸客戶資料、內部對話、祕密或可執行業務操作的企業。這些團隊可優先列出哪些代理接受外部輸入，再查其執行角色和下游連線，不必先假設已遭入侵。

三、部署前要逐項驗證的權限隔離點

先把每個代理的執行角色、呼叫者、工具、祕密、記憶體與網路出口連成一張存取圖，再逐條確認權限是否只到必要資源。角色政策要檢查允許的操作與資源 ARN，資源型政策、信任政策和代理間呼叫規則也要一起核對。

第一項是 IAM 執行角色。確認角色是否使用萬用資源範圍，能否列舉或呼叫同區域其他代理，能否讀取非該代理所需的對話、記憶體、金鑰或祕密。AWS 文件建議避免正式環境沿用為開發測試建立的寬鬆 CLI 政策，並將資源限制到特定 runtime ARN。也應檢查信任政策是否以 aws:SourceArn 和 aws:SourceAccount 限定可承擔角色的來源，避免其他資源借用該角色。

第二項是入口認證與代理間呼叫。若代理只應由特定後端或閘道呼叫，檢查 runtime 本身是否仍能被直接存取，避免流量繞過閘道上的授權、輸入檢查或稽核。對多租戶服務，確認使用者身分如何綁定 session，代理收到的使用者識別是否源自已驗證身分，而不是可由呼叫者任意提供的欄位。代理 A 能呼叫代理 B，也應視為一項需要明確理由與權限的授權。

第三項是工具和外部憑證。逐一列出 HTTP 請求、資料庫查詢、程式執行、MCP 服務或第三方 API 等能力，確認每個工具可連到哪裡、能執行哪些動作，以及憑證以何種身分提供。共用 API key 或讓代理直接讀取 Secrets Manager，會把祕密本身變成可用權限；可採用受控憑證流程，並限制每個工具的憑證範圍、用途與輪替方式。

第四項是記憶體和會話資料。分清楚短期工作階段資料與跨工作階段保留的長期記憶，查明誰能讀取、建立、更新或刪除。使用者 A 的請求不應因代理共用角色而讀到使用者 B 的記錄；工具回傳的外部內容也應被視為不可信資料，不能直接當作持久指令。多租戶產品還需要在應用層落實使用者與 session 的對應，因為服務提供隔離能力不代表自動替應用程式管理所有使用者授權。

第五項是網路出口和中繼資料服務。確認代理是否真的需要任意對外 HTTP 連線；若只需連到特定 API，評估能否收斂網域、連接埠、路由與安全群組出口規則。再依 AWS 當前文件核對 MMDSv2、執行角色憑證取得方式與部署類型。VPC 或私有端點有助限制網路路徑，但若角色仍可廣泛讀取資源，網路隔離本身並不能縮小雲端 API 權限。

中央的 AI 代理周圍排列六項獨立檢查，包括執行角色、入口認證、工具、祕密、記憶體與網路出口。
代理的隔離要逐項核對身分、工具、資料與網路邊界，單一控制無法涵蓋所有存取風險。

AWS 的 Runtime 安全最佳實務指出，MMDS 可向微型虛擬機內的程式提供執行角色憑證，並建議仔細限制執行角色權限。這項提醒把檢查重點放在憑證持有者能做什麼，而不只在憑證是否暫時有效。AWS AgentCore Runtime 安全最佳實務

這些檢查需要分清楚責任層次。AWS 負責其雲端基礎設施與服務邊界；客戶仍需管理代理程式、IAM 政策、工具授權、網路設定、輸入驗證和使用者資料隔離。依 AWS 的 AgentCore 安全說明，使用受管理服務並不會自動替企業完成應用程式層的資料授權或業務流程治理。部署紀錄也要能指出政策由誰核准、何時變更，以及變更後做了哪些測試。

四、怎麼驗證隔離有效，而不只檢查政策文字

在與正式環境隔離的測試帳戶或測試環境中，使用受控的惡意輸入與測試資料，從公開入口追蹤請求實際能到達的資源，再確認預期外的操作會被拒絕並留下可調查紀錄。政策檢視能指出設計意圖，實際測試才能確認應用、網路和雲端授權組合後的結果。

  1. 為代理標記資料敏感度、公開程度、負責人、執行角色與依賴工具，納入帳戶與區域清單。
  2. 以 IAM Access Analyzer 等工具檢視角色與資源政策，追查萬用資源、跨代理呼叫、讀取對話、記憶體寫入及祕密存取權限。
  3. 在隔離環境測試未授權呼叫、惡意提示、工具參數變形與跨使用者 session 存取，記錄請求經過的角色和實際可達資源。
  4. 檢查 CloudTrail、CloudWatch Logs、網路流量紀錄與告警是否能把呼叫者、請求 ID、代理操作及異常權限使用串起來。
  5. 演練撤銷或輪替憑證、停用受影響代理、保存證據及通知資料負責人的流程，並記錄失敗案例的修正責任人。

測試案例應以可能造成實際影響的能力為中心，例如代理是否能讀取不屬於當前使用者的資料、是否能呼叫未列入設計的代理、是否可透過工具存取中繼資料位址、是否能將外部輸入寫進長期記憶。不要在正式帳戶對真實客戶資料做破壞性測試，也不要用「模型拒絕了某句提示」當成權限隔離證明。模型行為可能因上下文改變，外部政策與資源授權才是需要反覆確認的控制面。

觀察紀錄要能回答三個問題：哪個身分發出操作、操作實際影響什麼、團隊多久能察覺並限制影響。AWS 文件建議啟用 CloudTrail 等稽核紀錄，並以請求 ID 關聯雲端 API 活動與執行環境日誌；企業也應確認這些紀錄是否納入既有告警與事件應變值班。若系統只能看到代理最後的文字回答，卻無法還原工具呼叫、角色和資料存取，事後就難以判斷影響範圍。

  • AgentCorruption 是特定研究環境下的攻擊鏈展示；發生條件與目前配置須分開查證。
  • 取得暫時憑證的後果取決於執行角色、資源政策、工具和網路權限。
  • 企業應實測代理從入口到下游資源的實際可達範圍，並確認日誌、告警與憑證輪替能支援應變。

研究並未提供一個適用所有企業的單一配置答案。不同業務用途需要不同工具和資料權限，隔離設計須對照身分邊界、資料敏感度、網路需求與事件應變能力。對正在使用 AgentCore 的團隊，適合的起點是挑出一個公開代理，追蹤其角色、工具呼叫、祕密存取與代理間授權，接著用測試環境確認實際可達範圍。AWS 文件中的服務要求、預設設定與防護建議也會更新，部署前應再次比對帳戶內設定與官方文件。

  • 盤點公開代理及其執行角色，確認是否出現不必要的跨代理、記憶體、對話或祕密存取。
  • 按代理用途限制工具和網路出口，將每項權限對應到負責人及必要資源。
  • 用隔離測試、稽核紀錄和應變演練驗證邊界，而非只依政策檔或模型防護設定判斷。

常見問題

Q1: 提示詞注入是否必然能接管 AWS 帳戶？

不必然。研究描述的攻擊鏈需要公開或可被不可信者使用的入口、可執行相關請求的代理能力、憑證端點可達，以及憑證具有可用權限等條件。企業應檢查自己的部署配置，不能從單一研究推論所有帳戶都會被接管。

Q2: 把代理放在不同帳戶就能消除風險嗎？

帳戶邊界可作為限制影響範圍的設計之一，還須搭配跨帳戶資源政策、身分授權、網路路徑與資料隔離測試。若跨帳戶角色仍授予寬廣權限，或應用程式把資料不當傳給代理，帳戶分隔本身仍不足以涵蓋所有風險。

Q3: 企業應先檢查哪一項 IAM 權限？

先看公開代理所使用的執行角色，逐項檢查它能呼叫哪些 AgentCore runtime、讀取哪些資料與祕密，以及是否使用萬用資源範圍。再回頭核對誰能呼叫該代理，以及角色信任政策允許哪些 AgentCore 資源承擔它。

Q4: AWS 的修補或設定狀態要去哪裡確認？

先查看 AgentCore Runtime 安全最佳實務及帳戶內實際 runtime、執行角色和資源政策。Zenity 研究記載的更新是研究者在特定時間點觀察到的狀況，不能代替企業對現有部署逐項核對。