AWS Bedrock AgentCore 執行角色權限收窄指南

立即開始：瞭解你的 Agent 執行角色實際上能做甚麼。如果你在 AWS Bedrock AgentCore 上執行 Agent，請執行以下兩個命令，並查看它們傳回的權限：

aws iam list-attached-role-policies --role-name <your-agentcore-exec-role>
aws iam list-role-policies        --role-name <your-agentcore-exec-role>

如果該角色是預設的 AgentCore 執行角色，輸出內容可能會列出遠超你所部署的單一 Agent 所需的權限。這種落差並非紙上談兵。2026 年 10 月，一個安全研究團隊展示，只需向一個對外暴露的 Agent 發送一段聊天提示詞，便足以控制同一 AWS 帳戶及區域內的所有 Bedrock AgentCore Agent。

本文會以淺白方式解釋這項發現，並提供一份檢查清單，讓你今天就能檢查自己的角色。毋須新工具，也毋須遷移平台。

實際發生了甚麼

這項研究由 Zenity Labs 進行，於 2026 年 10 月 8 日發表，並在 SecTor 2026 會議上發表。研究針對 AWS Bedrock AgentCore，也就是 Amazon 用來執行正式環境 Agent 的代管平台。團隊發現了兩個相互疊加的問題。

首先，在 AgentCore 內執行的 Agent 可以連接至位於鏈路本地位址 169.254.169.254 的執行個體中繼資料服務（IMDS）。AgentCore 會在輕量級 microVM 中執行每個 Agent，但其網絡流量隔離方式不如一般運算執行個體。因此，任何能夠發出 HTTP 請求的 Agent 工具，都可以用來實施伺服器端請求偽造（SSRF）：請求由 Agent 所在的執行個體內部發出，因此 IMDS 會向它傳回該 Agent 角色的臨時 IAM 憑證。只要精心編寫一段提示詞，就能令 Agent 取得這些憑證並傳回。

其次，附加至 AgentCore 工作負載的預設 IAM 角色權限過大，並非只限於單一 Agent。它在帳戶所在區域內，對所有 AgentCore 資源都具有廣泛權限，包括呼叫其他 Agent、讀取工作階段、建立記憶，以及從 AWS Secrets Manager 讀取秘密。

兩者結合，影響範圍便會擴大至整個區域。一個對外暴露的 Agent 加上一段提示詞，就能：

• 找出所有其他 Agent 的 ID，因為該角色允許在整個區域執行 DescribeLogGroups；
• 呼叫區域內任何 Agent（bedrock-agentcore:InvokeAgentRuntime），藉此橫向移動至你從未打算讓第一個 Agent 存取的內部 Agent；
• 讀取所有 Agent 及用戶的私人對話（bedrock-agentcore:ListEvents），徹底破壞 AgentCore 的私隱界線；
• 植入會永久改變其他 Agent 行為的記憶（對 BedrockAgentCoreMemory 執行 bedrock-agentcore:CreateEvent），令受信任的企業 Agent 持續依照攻擊者控制的指示運作；
• 取得 AgentCore 原本應避免讓 Agent 存取的憑證（secretsmanager:GetSecretValue、bedrock-agentcore:GetResourceApiKey）。

披露時間線對建立信任至關重要。IMDS 存取問題於 2025 年 12 月 25 日向 AWS 報告；AWS 在 2026 年 4 月將問題列為「僅供參考」並結案，當時新部署的 Agent 已改用 IMDSv2。權限過大的角色問題於 2026 年 1 月 12 日提交報告；AWS 於 2026 年 9 月 29 日確認已大幅強化預設執行角色。AWS 的公開立場是，這種行為「有文件記載且屬預期行為」：只有在開發者明確於雙方授予權限時，Agent 才能存取另一個帳戶中的資源。他們的建議沒有改變，而且仍然正確：只向執行角色授予 Agent 所需的權限。

對於已部署的團隊，有一點需要注意：AWS 在 2026 年 9 月的安全強化措施，已更改新建角色的預設設定。該日期之前部署的 Agent 可能仍使用舊有的寬權限角色，因為 AWS 不會追溯修改你已附加的角色。如果你的 Agent 在 2026 年 9 月下旬之前已部署，在親自使用上述命令檢查之前，請先假設該角色的權限範圍仍然過寬。

為何這是你星期二要處理的問題

AgentCore 的預設角色不是你編寫的，但你把它附加到 Agent，或接受了該角色。這裏的教訓不是「AWS 不安全」，而是 Agent 的憑證權限範圍是由你負責的產品決策，而大多數團隊只設定一次，之後便不再檢視。

Agent 並非網絡伺服器。網絡伺服器一次處理一個要求，沒有可供操控的工作階段。Agent 會保留工作階段、呼叫工具，並可能受到它從網絡、文件或其他 Agent 擷取的內容引導。過去，同一種提示詞注入只代表「模型説錯了話」；現在則可能代表「模型使用了你的憑證」。當角色權限範圍過廣，一個惡意輸入就會演變成影響整個帳戶的事件，而非侷限於單一錯誤。

試想一個切合實際的情況。你的支援 Agent 有一個查詢內部 API 的工具。該 API 與另一個可讀取客戶記錄的 Agent，以及第三個可在社交平台發文的 Agent，位於同一個帳戶。如果三者共用一個寬權限角色，針對支援 Agent 的惡意指令就不會止於支援 API。由於共用角色允許所有這些操作，它還可以轉而存取客戶記錄 Agent，再轉到發文 Agent。解決方法不是使用更聰明的提示詞，而是收窄角色的權限範圍。

今天就收窄權限範圍

你不必等待平台修正。採取以下四項措施，現在就能縮小影響範圍。

1. 為每個 Agent 設定專屬角色。不要讓多個 Agent 共用同一個執行角色。為每個 Agent 建立專屬角色，只附加其工具所需的權限。如果 Agent A 沒有理由讀取 Agent B 的記憶，其角色就不得允許在共用記憶上執行 bedrock-agentcore:CreateEvent。

2. 嚴格遵循最小權限原則。從空白政策開始，為每項你能明確指出的工具呼叫加入一項權限。如果你無法指出該呼叫，Agent 就不應持有該權限。先檢查 DescribeLogGroups 和 secretsmanager:GetSecretValue；這兩項會把局部洩漏擴大成區域性事件。

3. 不要把機密資料放在 Agent 自己的角色中。將第三方憑證存放在 AWS Secrets Manager，並讓 AgentCore Gateway 按工具代為處理憑證。若 Agent 只透過 Gateway 存取機密資料，其執行角色就不應持有 secretsmanager:GetSecretValue。

4. 強制使用 IMDSv2，並封鎖中繼資料路徑。使用僅支援 IMDSv2 的設定啟動 Agent；它要求提供 token，而非使用開放的 PUT。如果你的執行環境允許，請拒絕 Agent 執行環境對 169.254.169.254 的對外存取，避免工具即使收到相關提示，也能連線至中繼資料服務。

單一唯讀 Agent 的最小權限角色可以如下所示：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["bedrock-agentcore:InvokeAgentRuntime"],
      "Resource": "arn:aws:bedrock-agentcore:<region>:<account>:agent/<this-agent-id>"
    }
  ]
}

任何地方都不要有 DescribeLogGroups、secretsmanager:* 或 *:*。每個工具加入一條權限陳述式，並將範圍限制在該工具的確切資源。

驗證修正是否生效

收緊角色權限後，請驗證結果。重新執行前文的兩個 aws iam 命令，並用 grep 搜尋輸出中的 *:*，以及任何權限範圍比這個 Agent 更廣的 bedrock-agentcore:* 權限。然後進行一次刻意設計的失敗測試：在 Agent 內嘗試呼叫一項新角色應拒絕的操作，並確認呼叫失敗。如果 Agent 仍能列出其他 Agent，或讀取機密資料，代表角色權限範圍仍然過廣。

將這項工作設為定期檢查，而非一次性清理。把兩個aws iam指令加入排程工作或 CI 步驟；如果某個角色的權限範圍超出其已聲明工具所需的範圍，就讓檢查失敗。隨着 Agent 增加功能，憑證權限範圍會逐漸偏移，因此每次 Agent 有變更時，都要執行這項檢查。

將 Agent 的 IAM 角色視為 Agent 規格的一部分，而非平台的制式設定。列明工具，以及每項工具所需的權限，並按照檢視 Agent 提示詞的頻率一併檢視這些設定。一個提示詞絕不應掌控你的雲端；你附加的角色才決定它能否做到這一點。

本文由 AI 協助撰寫，作者對本文內容負責。