【要約】「過去の行動」を加味したAgentCore Temporal Policyはセッション分ければ突破できる？ [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
AI Agentが自律的にアクションを行う際、単発のリクエスト評価だけでは安全性を判断できない課題がある。開発者は、一連の行動を通じた累積的な制限をどう制御すべきかという問題に直面している。
- ・従来の認可：個別のリクエストを独立して評価するため、文脈を無視しやすい。
- ・AI Agentの課題：情報の取得から送金に至る一連の流れにおいて、過去の行動を踏まえた認可が必要となる。
// Approach
検証者は、Amazon Bedrock AgentCoreのTemporal Policyがセッションを跨いだ制限をどう扱うかを確認した。セッションIDを分けることで、累積制限を回避できるかを検証する手法を採用した。
- ・検証環境：架空の銀行送金ツールを作成し、同一のPrincipalで実行。
- ・検証手順：セッションAとBに分け、各セッション内で閾値を超えない範囲の操作を実施。
- ・評価指標：セッションを分けた際、合計金額が閾値（20000）を突破するかを確認。
// Result
検証の結果、Temporal Policyはセッション単位での評価に留まることが判明した。これにより、セッションを分けることで累積制限を容易に突破できることが示された。
- ・検証結果：セッションAで18000、セッションBで18000の送金が許可された。
- ・実質的な影響：同一Principalの合計額は36000となり、閾値20000を大幅に超過した。
- ・推奨される対策：セッションIDの管理を信頼できるバックエンド（DynamoDB等）で行うべきである。
Senior Engineer Insight
> Temporal Policyは「セッション内の文脈」を守るには有効だが、「ユーザー全体の行動」を縛るには不十分だ。AI Agentの実装において、認可ロジックをAgentCoreの機能だけに依存させるのは設計ミスと言える。特に金融系などの高リスクなユースケースでは、セッションIDの管理をアプリケーション層で厳格に行い、ステートフルな制限をバックエンド側で実装する多層防御が不可欠である。