AWS、3段階のStrands hookでエージェントのツールフローを検査、ただし権限制御の代替にはならず

AWSは8月27日、Amazon Bedrock Guardrailsをモデル呼び出しの境界からStrandsのツールライフサイクルへ拡張する、エージェント保護の実装手法を公開した。問題は、モデル層のguardrailがプロンプトと回答を検査していても、データベース、MCPサーバー、外部APIへ送信されようとしている引数を確認できない可能性があり、信頼できないツールの結果が後続の推論に取り込まれる前に阻止できるとも限らない点にある。

サンプルではHookProviderを作成し、3つのチェックポイントを登録する。BeforeInvocationEventはモデル推論の前にユーザーまたは上流エージェントからの入力を検査する。BeforeToolCallEventは実際の操作に先立ってツール名とシリアライズされた引数を確認し、違反があれば呼び出しをキャンセルする。AfterToolCallEventは外部データを検査し、必要に応じて結果をブロックメッセージへ置き換える。3つはいずれもBoto3のApplyGuardrail APIを使用し、tool_namesによってメール送信、検索、決済などのツールに異なるポリシーを設定できる。この手法は個々のツールを変更する必要がなく、組織内の共通パッケージとしてまとめるのに適している。

技術面でより重要なのは、保護レイヤー間の役割分担だ。Strandsのドキュメントによると、hookを使ってツール呼び出しをキャンセルまたは書き換えられる。AWSはさらに、頻繁に呼び出されるツールの引数について、まずschema、正規表現、allowlistで検証し、意味内容の判定を機械学習ベースのguardrailに委ねることで、追加のレイテンシーを抑えることを推奨している。

ただし、これはリファレンスアーキテクチャであり、検証済みの新たなセキュリティ境界ではない。記事では、攻撃成功率、誤検知率、ApplyGuardrail呼び出しごとのコストやレイテンシーが報告されていない。また、正当なテキストに見せかけた危険なSQL、パストラバーサル、複数ステップにまたがる累積的なリスクも扱っていない。エンジニアリングチームは引き続き、IAMの最小権限、決定論的な引数検証、人による承認、監査ログによって副作用を伴う操作を保護し、guardrailサービスに障害が発生した際にfail-openとfail-closedのどちらを採用するかもテストする必要がある。