AIDEFEND in Action AIA-0096 實證研究 發布於 AIA: 2026年10月1日

AgentCore Harness：提示注入竊取 MCP 服務憑證並讀取測試資料

Unit 42 在虛構的 SupportCo 環境中測試 AgentCore Harness：研究人員把惡意指示藏在客服票單，讓 agent 透過預設可用的 shell 執行程式。程式讀取 Harness 主程序的記憶體，取得營運方 MCP 服務帳號的 JWT 與伺服器網址，再以一次 HTTP POST 將兩者傳到模擬攻擊者的接收端。研究人員接著從另一台電腦重用 JWT，透過 MCP 服務讀取測試用客戶個資。這不是終端使用者的憑證，也不是已確認的真實客戶入侵；AWS 將通報列為客戶應處理的組態安全問題，並未宣布修補雲端服務漏洞。

Indirect Prompt InjectionCredential ExposureTool AuthorizationAI Infrastructure
6 項對應的 AIDEFEND 防禦手法
來源: A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity 
作者: Niv Rabin
原文發布: 2026年9月18日

威脅分析

AgentCore Identity 會保護儲存中的服務憑證，但 Harness 使用憑證時，仍須在執行期間將它解析成明文。受測設定的內建 shell 與主程序共用 root UID；票單中的注入指示因此能讓 shell 讀取存有憑證的程序記憶體。

  1. 客服票單中的隱藏 HTML 註解要求 agent 下載並執行攻擊者控制的程式。
  2. 在受測的寬鬆設定下，agent 依指示呼叫內建 shell；除非在 InvokeHarness 呼叫中以 allowedTools 限縮，否則該工具預設可用。
  3. shell 讀取 /proc/1/maps 與 /proc/1/mem 中可讀的記憶體區域。
  4. 掃描取得營運方下游 MCP 服務帳號的 JWT 與伺服器網址，而非終端使用者的憑證。
  5. 注入後執行的程式以一次 HTTP POST，把兩者送到研究人員模擬的攻擊者接收端。
  6. 研究人員從另一台電腦重用 JWT，列出 MCP 工具並呼叫 lookup_customer，讀取測試用客戶個資。

SupportCo 是虛構環境，整段流程都是受控驗證。AWS 依共同責任模型將通報列為資訊性問題，指出工具權限與對外連線須由客戶控管；目前沒有證據顯示真實客戶因此遭到入侵。

適用的 6 項 AIDEFEND 防禦手法

AID-H-018.002
Policy-Based Access Control
極高
在客戶的呼叫路徑中，依已驗證任務設定 allowedTools，並透過 CreateHarness／UpdateHarness 配置同步的 before_tool_call Lambda hook，將 failureMode 設為 deny。執行前從可信紀錄解析任務與工作階段身分，拒絕客服問答使用 shell 或 file_operations；模型產生的 toolInput 或被截斷而缺少關鍵欄位的 hook 內容不能作為授權依據。須測試拒絕、逾時、格式錯誤與相依服務失敗。SNS／EventBridge 是非同步觀測，不能當成阻擋 hook。
AID-I-002.002
Secure External AI Service Connectivity
高
只有流量確實經過客戶可控的網路路徑，才能由獨立防火牆或 Proxy 執行預設拒絕的對外連線政策。允許清單只納入必要的模型端點、MCP 服務與其他核准目的地，拒絕診斷腳本主機。須實測路由及繞過路徑；政策文件本身不能限制未經過該控制點的代管環境。
AID-I-001.003
Ephemeral Single-Use Sandboxes for Tools
中
若任務需要執行命令，改由團隊自建工具與中介服務驗證經簽章的呼叫規格（明確列出允許執行的命令及參數），再交給獨立隔離的一次性沙箱執行，並停用同程序內的 shell。沙箱不得取得 Harness 已解析的憑證、共用含憑證的記憶體或存取保管庫機密；須獨立測試程序、檔案系統、網路及執行後清除的邊界。Code Interpreter 工作階段只是候選部署位置，不能證明這項架構已成立。研究未驗證這種整合，在確認上述前提前維持中等有效程度。
AID-H-034.002
MCP Server OAuth Resource Boundary & Delegation Safety
中
營運方服務帳號 token 只應包含客服工具需要的 scope，下游 MCP 伺服器須執行已簽章的逐工具 scope 政策，並在每次請求另行驗證簽發者、目標對象／資源、有效期限及撤銷狀態。限縮 scope 能縮小損害，不能讓遭竊但仍有效的 bearer token 無法使用。持有證明需要簽發端與資源驗證端支援，且私鑰不能被遭入侵的 shell 讀取；G002 與本研究均未證實這些前提。
AID-E-001.002
Issued Token, Authentication Session & Lease Revocation
中
將暴露的 MCP bearer token 視為遭入侵憑證，要求各下游驗證端在每次請求查核獨立保護的撤銷紀錄，拒絕確切 token 版本，並在替換憑證前實測拒絕結果。若 Cognito 的 client credentials 簽發端無法撤銷該存取 token，驗證端拒絕清單是提前阻擋的一種方法，另行強制拒絕服務存取也是可行方法。只輪替不會使舊 token 失效；未支援的驗證路徑，須等實際請求被拒絕或確認已到期後，才可結案。
AID-D-003.003
Agentic Tool Use & Action Policy Monitoring
中
將實際工具呼叫事件與生效的 allowedTools 決策送到受保護的事件儲存區，對客服問答工作階段使用 shell、file_operations、腳本下載或 /proc 存取發出警示。AWS 原生 trace 不會自動成為本指引要求的防竄改的簽章決策驗證紀錄；團隊須把政策決策與實際工具呼叫綁定，並驗證事件紀錄是否完整，才能確認偵測涵蓋範圍。

身為資安防禦者，我們應該這麼做

  • 每次 InvokeHarness 呼叫依已驗證任務設定 allowedTools，配置同步 before_tool_call Lambda hook，拒絕客服問答使用 shell 與 file_operations，並測試 hook 失敗時也會拒絕。
  • 限縮 MCP token 的 scope，在資源端核對簽發者、資源、目標對象、有效期限與 scope。確認暴露後，使用每次請求都會執行的撤銷查核或獨立服務存取封鎖，並用舊 token 實測拒絕。只輪替保管庫憑證不會使既有 JWT 失效。
  • 若工作確實需要執行命令，應改在無法取得 Harness 憑證的獨立環境中執行；若有客戶可控的網路路徑，另行限制對外連線，並分別驗證兩道邊界。

1 個額外的防禦考量

證據與部署界線

不需要 shell 的任務應移除該工具。程序記憶體隔離須以實際執行環境驗證，不能只憑「沙箱」名稱推定已保護憑證。
建議做法: 每次 InvokeHarness 呼叫都依確切任務設定 allowedTools；客服問答等不需命令或檔案操作的工作，不應沿用預設工具權限。

結論

AIDEFEND  對應的防禦包括工具授權、下游 MCP token 驗證，以及隔開命令執行與含憑證的程序記憶體。團隊可用同步 before_tool_call hook 執行工具政策；憑證保管庫本身無法取代這些控制。

最後更新: