AI 代理安全
AWS 以三段 Strands hook 審查代理工具流，但不能取代權限控制
AWS 提出在模型輸入、工具參數與工具輸出分別呼叫 Bedrock Guardrails，填補只檢查提示詞與回答的空隙。範例可按工具套用不同規則，卻未公布延遲、誤判率或對結構化動作的安全評測。
AWS 在 8 月 27 日公布一套代理防護實作，把 [Amazon Bedrock Guardrails](https://aws.amazon.com/blogs/security/extend-amazon-bedrock-guardrails-to-tool-interactions-using-the-strands-agents-sdk/) 從模型呼叫邊界延伸至 Strands 的工具生命週期。問題在於，模型層 guardrail 即使檢查了提示詞與回答，仍可能看不到即將送往資料庫、MCP 伺服器或外部 API 的參數，也未必在不可信工具結果進入後續推理前攔截它。
範例建立一個 `HookProvider`，註冊三個檢查點：`BeforeInvocationEvent` 在模型推論前審查使用者或上游代理輸入；`BeforeToolCallEvent` 在真實操作前檢查工具名稱與序列化參數，違規時取消呼叫；`AfterToolCallEvent` 則審查外部資料，必要時把結果換成封鎖訊息。三者共用 Boto3 的 `ApplyGuardrail` API，也能用 `tool_names` 為寄信、搜尋或付款工具配置不同政策。這套方式不必修改個別工具，適合封裝成組織內共用套件。
技術上更重要的是防護層次分工。[Strands 文件](https://strandsagents.com/docs/user-guide/concepts/agents/hooks/)顯示 hook 可取消或改寫工具呼叫；AWS 也建議在高頻工具參數上先用 schema、正規表示式與 allowlist，再把語意內容交給機器學習式 guardrail，以控制額外延遲。
不過，這是參考架構而非經驗證的新安全邊界。文章沒有報告攻擊成功率、誤攔截率、每次 `ApplyGuardrail` 的成本或延遲，也未處理合法文字包裝出的危險 SQL、路徑穿越及跨多步驟的累積風險。工程團隊仍須以 IAM 最小權限、確定性參數驗證、人工批准與稽核記錄保護有副作用的操作，並測試 guardrail 服務故障時採 fail-open 還是 fail-closed。