Amazon Web ServicesはAmazon Bedrock AgentCoreに時間的ポリシーを追加し、開発者が同じセッション内でその前にエージェントが何をしたかに基づいて、AIエージェントの現在のアクションを承認できるようにする。これは、個々のツール呼び出しは安全に見えても、その前の一連の動作によってリスクが生じるワークフロー向けに設計された制御だ。

この変更は、従来のアクセス制御のギャップを埋めるものだ。従来のアプリケーション権限は多くの場合、要求を個別に評価するが、AIエージェントは実行時にツール、引数、実行順序を選択する。AWSによれば、この新しいアプローチは、必要なワークフローステップの強制、ツール呼び出し間のデータ整合性の維持、累積的な金銭的エクスポージャーの制限、機微なアクションの前の人間による承認要求を可能にする。

AWSが変更する内容

AWSは時間的ポリシーを、Bedrock AgentCoreの既存ポリシー制御を状態保持型に拡張したものと説明している。ある主体が特定のツールを呼び出せるかどうかだけを問うのではなく、ポリシーエンジンはエージェントの最近の軌跡を検査し、その文脈で現在の要求が認可されているかを判断できる。

たとえば、エージェントが顧客検索ツールを使って1つの口座番号を受け取り、その後、別の番号を資金移動ツールに渡すことがある。どちらの呼び出しもステートレスな権限を満たす可能性がある。時間的ポリシーは、送金引数が前回のツール出力と一致することを要求し、エージェントがその値を変更または捏造した場合に要求をブロックできる。

AWS Machine Learning Blogの他の例では、取引の前にポートフォリオ検索を要求する、意思決定を支えるためにデータ照会が十分最近に行われたことを確認する、累積取引エクスポージャーが定義された限度に達したらセッションを停止する、などが挙げられている。AWSはまた、エージェントが同じ保険請求を短時間で承認し、かつ拒否するといった矛盾する行動を防ぐ制御も説明している。

この機能は、AIエージェントを構築・運用するためのAWSのサービス群であるAmazon Bedrock AgentCoreの一部だ。適用ポイントはAgentCore Gatewayで、対応するモデル、ツール、エージェント間通信を中央エンドポイント経由でルーティングする。

時間的認可の仕組み

時間的ポリシーで評価される要求には、x-amzn-bedrock-agentcore-policy-session-id ヘッダーが付与される。この識別子は、関連する過去のアクション、入力、出力を含む軌跡に要求を結び付ける。アプリケーションチームは、セッションが会話なのか、複数ステップのタスクなのか、より長時間のワークフローなのかを決定する。

AWSは、1つのセッションにつき同時に有効な認可要求は1つだけなので、セッションを比較的狭く保つことを推奨している。サービスはセッション識別子と最終ユーザーのIDを組み合わせるため、同じ識別子を提示した2人のユーザーでも別々の軌跡として評価される。AWSによると、参照可能な履歴は24時間に制限され、それ以降の古いイベントは自動的に削除される。

時間的ポリシーはエージェント自身のコード内ではなくゲートウェイで実行される。このアーキテクチャは重要で、エージェントはポリシーロジックを書き換えたり、認可に使われる状態を直接操作したりできない。AWSは、エンジンが決定論的な許可または拒否の結果を返し、決定コンテキストを記録し、デフォルトで拒否し、許可と禁止のルールが衝突した場合は禁止を優先すると述べている。

これらの制御はオーケストレーション層ではない。要求を変換したり、データを分析したり、エージェントがどのツールを呼ぶべきかを決めたりはしない。その役割はより狭く、観測された履歴を踏まえてゲートウェイ経由の要求が許可されるかどうかを判断することだ。

証拠と実装の詳細

この変更の主な証拠はAWS自身の技術投稿であり、機能の説明と、プライベートバンキングのエージェントを使った具体例を示している。そのシナリオでは、エージェントが顧客情報を取得し、ポートフォリオ保有を読み込み、市場価格を取得し、分析を行い、金融アドバイザーの代理として取引を実行する。

AWSによれば、この例ではアイデンティティにAmazon Cognito、入力認証にJSON Web Tokens、AgentCore Gateway経由で公開されるMCPツールが使われている。例で使用されるポリシー言語はDogwoodで、AWSはこれをエージェントとそのツールのためのオープンソースのガバナンス言語と説明している。AWSによると、Dogwoodは既存のCedarポリシーを評価しつつ時間的条件への対応を追加でき、顧客は移行せずに現在のCedarルールを維持できる。

このソースには、独立したテスト結果、顧客採用数、あるいは制御があらゆる種類のエージェント失敗を防ぐという証拠は示されていない。迂回耐性や運用挙動に関する主張は、AWSの製品・アーキテクチャ上の主張だ。利用可能なメディア要素は発表タイトルを繰り返しているだけで、独自報道の詳細は追加していない。

この機能を評価するチームには運用上の制約もある。セッションヘッダーが欠落するとAgentCoreが新しいセッションを生成し、ポリシーエンジンは意図された履歴ではなく空の軌跡を見ることになる。AWSによれば、ポリシー変更は既存セッションを無効化し、その後の判断が現在のポリシーセットと期待されるイベントスキーマを使うようにする。こうした挙動は、セッション管理とポリシー展開をセキュリティ設計の一部にしており、単なる設定の詳細ではない。

開発者と企業にとっての重要性

AI開発者にとって、時間的ポリシーは、プロンプトやアプリ側のチェックだけでは信頼性高く解くのが難しい問題、つまりモデルが選択した一連のアクション全体で不変条件を維持することに対する制御点を提供する。あるポリシーは、ツール呼び出しが以前に検証された出力を使うこと、高影響のアクションが定義された手順に従うこと、人間の承認イベントが実行に先行することを要求できる。

企業にとっての主な価値は、エージェントのトラフィックがツールやモデルに到達する境界で一貫性を確保できることだ。共有ゲートウェイは、AgentCore Gatewayを通過する要求に対して、MCP呼び出し、モデル推論呼び出し、エージェント間相互作用にルールを適用できる。これにより、各エージェント実装がワークフロー制御を個別に再現する必要が減る可能性があるが、ポリシー、IDモデル、セッション境界、承認プロセスを設計する必要は依然として残る。

このアプローチは、限定された金銭的・運用リスクにも役立つ可能性がある。たとえばステートレスなルールは1回の取引サイズを制限できるが、セッション全体でどれだけのエクスポージャーが蓄積したかは自体では判断できない。時間的状態は、この種の累積制約を表現可能にする。代償は、正確なイベント捕捉と慎重に範囲設定された軌跡への依存が増すことだ。新しいセッションは、ポリシーが検査すると想定していた履歴を消してしまうこともある。

これによりAgentCoreは、実行時ガバナンス、ツール権限、人間参加型制御を重視するエージェント・プラットフォームにより直接対抗する位置づけとなる。現時点の証拠では、AWSの実装を競合製品とレイテンシ、ポリシー表現力、デプロイコストで比較するには不十分だ。

今後注目すべき点

次に注目すべきシグナルは、宣伝より実務的なものになる。開発者はDogwoodとその時間的意味論に関するより広範なドキュメント、銀行業務のワークフロー以外の例、本番規模でのポリシー評価レイテンシやログ記録の詳細を確認したいはずだ。

企業の購入者も、チームが軌跡依存ルールをどのようにテストするか、失敗したり放棄されたセッションからどう復旧するか、正当なワークフローを妨げずにポリシー変更をどう管理するかを検討すべきだ。独立した顧客レポートがあれば、ゲートウェイレベルの強制が、エージェントコード内に組み込まれた制御と比べてインシデントや実装労力を減らすかどうかを判断しやすくなる。

対応トラフィックの範囲も重要だ。AWSは、時間的ポリシーがゲートウェイを通じたモデル、MCPツール、エージェント間の呼び出しを管理できると述べている。採用は、組織のエージェントアーキテクチャのどれだけがボトルネックを生まずにその経路を使えるかに依存する。

Creati.aiの見解

AWSは、エージェントセキュリティにおける実際の弱点、つまり認可判断には記憶が必要なことに対応している。最も重大なリスクは、必ずしも禁止されたツール呼び出しではなく、信頼できない検索、古いデータ取得、承認の欠如、過度の事前活動の後に行われた許可済みの呼び出しかもしれない。

時間的ポリシーだけでエージェントが信頼できるようになるわけではない。だが、開発者が信頼できるセッションIDを定義し、適切なイベントを捕捉し、失敗シーケンスに対してポリシーをテストするなら、エージェントの振る舞いに対するより強い強制境界を作る。金融、顧客サービス、その他の高影響ワークフローへエージェントを移行するチームにとって、この違い――モデルの順守ではなくポリシーの強制――が、より重要な進展となる可能性がある。