エージェンティック AI システムのための 4 つのセキュリティ原則

エージェンティック AI は、ソフトウェアの動作のあり方を質的に変えるものです。従来のソフトウェアは決定論的な命令を実行します。生成 AI は人間のプロンプトに応答して出力を生成し、人間はその出力を確認したうえで、自らの判断で利用します。エージェンティック AI は、そのどちらとも異なります。エージェントはソフトウェアツールや API に接続し、大規模言語モデル (LLM) を推論エンジンとして使用して、一連のアクションを機械処理の速度で自律的に計画し、実行します。そして、その結果は現実世界に影響を及ぼします。この変化は、情報セキュリティに新たな問いを投げかけています。2026 年 1 月、NIST の Center for AI Standards and Innovation (CAISI) は、こうしたシステムを保護する方法について業界の意見を求める RFI (Request for Information: 情報提供依頼) を発行しました。AWS は、エージェンティック AI サービスの構築と運用の経験に基づいて回答を提出しました。この記事では、その回答の中核となる 4 つのセキュリティ原則と、それらを実装するアーキテクチャの構成要素について紹介します。

CAISI は、開発者、デプロイ担当者、セキュリティ研究者に対し、自律的に動作する AI システムを業界としてどのように保護すべきかについて意見を求めました。この RFI では、5 つの領域にわたって問いが提示されています。エージェンティックシステムはどのような固有のセキュリティ上の考慮事項をもたらし、システムの自律性が高まるにつれて、それらの考慮事項はどのように変化するのか? 開発とデプロイにおいて、どのようなプラクティスがセキュリティを向上させるのか? 組織は、エージェンティックシステムのセキュリティをどのように評価するのか? デプロイ環境をどのように制約し、監視できるのか? そして、業界は今後どの分野の研究に注力すべきか?

リスクとメリットを保守的に分析したとしても、多くの領域ではエージェンティック AI のメリットがリスクを明らかに上回るという結論になるでしょう。企業や政府機関でエージェンティックテクノロジーの導入が急速に進んでいることも、それを裏付けています。しかし、エージェントの価値はまさにその自律性と適応性にあり、こうした特性そのものがセキュリティ上の課題を生み出します。エージェンティックシステムは、意図しないアクションを、人間が介入する間もなく機械処理の速度で実行してしまう可能性があります。人間であれば、何かがおかしいと感じたときに作業を中断したり、エスカレーションしたりします。しかしエージェントは、人間には明らかなあいまいさを自ら認識できるとは限らず、明文化されていないポリシーの境界を直感的に把握できるとも限りません。

さいわいなことに、エージェンティック AI のセキュリティ対策をゼロから考える必要はありません。NIST Cybersecurity Framework、NIST AI Risk Management Framework、Secure Software Development Framework などの既存のセキュリティフレームワークは引き続き有効です。これらを置き換えるのではなく、エージェント固有の考慮事項に合わせて拡張すべきです。中でも最も重要なのは、アーキテクチャ面での拡張です。AWS は NIST への回答の中で、この拡張の進め方を示す 4 つの基本的なセキュリティ原則を挙げました。

これらの原則は、エージェンティック AI に新しいセキュリティパラダイムは必要ないものの、既存のプラクティスは進化させる必要があるという前提に基づいています。最初の 2 つの原則は従来から引き継がれる要素を扱い、残りの 2 つの原則は真に新しい要素を扱います。

原則 1: セキュアな開発ライフサイクルのプラクティスは、システムのすべてのコンポーネントに適用されます。エージェンティック AI システムは、従来のソフトウェアコンポーネント (API、データベース、オーケストレーションロジック) と、基盤モデル、プロンプトテンプレート、検索パイプラインなどの AI 要素を組み合わせたものです。セキュアな開発ライフサイクルは、この両方のコンポーネントを対象とする必要があります。従来のコンポーネントについては、コードレビュー、静的解析、依存関係のスキャン、脅威モデリングなどの確立されたプラクティスが引き続き不可欠です。ただし、これらのプラクティス自体も、AI ベースのツールによって強化されつつあることに留意してください。一方、AI コンポーネントには異なる課題があります。基盤モデルは確率的に動作するため、従来の回帰テストは必要ですが、それだけでは十分ではありません。組織は、動作テスト、敵対的評価、継続的なモニタリングによって回帰テストを補完し、AI コンポーネントが想定された範囲内で動作することを検証する必要があります。

動作のドリフトに対処するには、定期的な再評価も同様に重要です。モデルが更新されれば、動作が変わる可能性があります。チームがエージェントの機能を改良していくにつれて、プロンプトテンプレートも変化します。新しいツールやデータソースが追加されれば、エージェントの運用上の対象領域も広がります。こうした変更のたびに、新たな障害モードや潜在的なセキュリティ上の問題が生じる可能性があります。組織は、評価を一度きりの関門ではなく、継続的な運用プラクティスとして扱う必要があります。これには、モデル更新後の自動テスト、デプロイ済みのエージェントに対するレッドチーム演習、時間の経過に伴う動作のドリフトを検出するモニタリングが含まれます。

原則 2: 従来のセキュリティ制御は引き続き完全に適用されます。エージェンティック AI は新たな考慮事項をもたらしますが、既存のセキュリティリスクがなくなるわけではありません。従来のセキュリティ制御は、そのすべてが引き続き適用されます。エージェンティック AI システムは、従来のソフトウェアと、LLM とツールを組み合わせた新しい処理ループで構成されています。エージェンティックな要素を支える健全な基盤を整えるために、組織は既存のソフトウェア、ツール、設定を既知のリスクから保護する必要があります。

権限昇格、混乱した代理問題 (confused deputy)、セッションハイジャック、コードインジェクション、サプライチェーンリスクは、そのままエージェンティックシステムにも当てはまります。エージェンティックなコンテキストでは、これらのリスクの一部がさらに増大します。エージェントは人間よりも大規模かつ高速に動作するため、過剰な権限が意図しない結果を招く可能性も高くなります。つまり、エージェンティックなコンテキストでアクセス管理に最小権限の原則を適用することは、従来のシステムと同等か、それ以上に重要です。サプライチェーンの攻撃対象領域も広がります。エージェンティックシステムが利用するのは、サードパーティのコード依存関係だけではありません。基盤モデル、プラグイン、ツールサーバー、データ取得ソースも利用します。API を呼び出したり、データベースに対してクエリを実行したり、コードを生成したりするエージェントは、ツールとの境界に新たなインジェクションの攻撃対象領域を生み出す可能性があります。AI 固有の制御は、こうした基盤となるセキュリティを置き換えるものではなく、その上に追加するものでなければなりません。

原則 3: 決定論的な外部制御が、エージェンティックセキュリティの出発点です。これは、エージェンティック AI のセキュリティにとって最も重要なアーキテクチャ原則です。組織は、エージェント自身の推論、内部のガードレール、プロンプトベースの指示に頼るのではなく、エージェントの推論ループの外部にあるインフラストラクチャレベルの決定論的な制御によって、セキュリティを強制すべきです。理由は単純です。LLM は確率的な推論エンジンであり、セキュリティを強制するための仕組みではありません。開発者は LLM に特定のリクエストを拒否するよう指示できますが、プロンプトインジェクションの手法によってその指示が上書きされる可能性があります。LLM にアクセスの境界を守るよう指示することはできても、LLM にはその境界を確実に強制する仕組みがありません。プロンプトやアライメントだけでエージェントの動作を制約しようとするアプローチは、未知の状況に動的に適応できるというエージェント本来の価値に反するものです。

効果的なセキュリティを実現するには、完全に定義された決定論的な制御をエージェントの外部に配置し、その制御によって、エージェントがアクセスできるツール、実行できる操作、到達できるデータを管理する必要があります。モデルを操作しても、これらの制御を回避することはできません。AWS はこれをセキュリティボックス (security box) と呼んでいます。セキュリティボックスはエージェントの外部に置かれ、決定論的に適用され、対象を網羅的にカバーします。エージェントと外部とのやり取りはすべて、このボックスを経由します。Agentic AI Security Scoping Matrix を活用すると、組織はシステムの自律性レベルに応じて、これらの制御の厳格さを調整できます。スコープは、すべてのアクションの前に人間による明示的な承認を必要とするシステムから、外部イベントに基づいて自らアクティビティを開始する完全自律型のシステムまで多岐にわたります。

セキュリティボックスは、エージェントの価値を制限するものではありません。むしろ、その価値を責任ある形で実現するための前提条件です。エージェンティックテクノロジーが成熟するにつれて、このボックス自体も進化し、エージェンティックな要素を含むようになると考えられます。他のエージェントのスコープを制御するように設計された専用の AI エージェントが、時間の経過とともに一部の決定論的な制約に取って代わる可能性があります。そうしたエージェントは、新しい情報とコンテキストを活用し、人間が複雑な決定論的制御を管理する場合よりも適切な判断を自動で下せるようになる可能性があります。

原則 4: より大きな自律性は、継続的な評価を通じて獲得していくべきです。組織は、エージェントの自律性をデフォルトで付与するのではなく、実証されたパフォーマンスに基づいて段階的に拡大すべきです。出発点は、影響の大きい操作について人間が意思決定を行うことです。価値の高い本番データの変更、金融取引の開始、機密情報の外部への送信につながる可能性のあるアクションにエージェントが直面した場合は、人間が最終的な判断を下します。エージェントが推奨し、人間がそれを承認または却下するという形です。

ただし、このアプローチには、よく知られたリスクがあります。エージェントのすべてのアクションに人間の承認が必要になると、判断すべき件数がレビュー担当者の処理能力を超えてしまう可能性があります。その結果、承認が熟慮ではなく反射的に行われるようになり、失敗せざるを得ない立場に置かれた人間に責任が押し付けられることになります。組織は、人間による監督の対象を真に影響の大きい操作に絞り込み、リスクの低い日常的なアクションにまで安易にヒューマンインザループ (human-in-the-loop) の設計を求めないようにする必要があります。

人間による監督から自律性の拡大へと進む道筋は、評価によって切り開かれます。エージェントが何を推奨し、人間が何を決定し、実際に何が起きたかを組織が体系的に記録していくことで、自律性の拡大を裏付けるエビデンスが蓄積されます。これらの記録から、エージェントの推奨が人間の判断や実際の結果と継続的に整合していることが確認できれば、組織は事前承認から事後レビューへ、さらに最終的には特定の種類の操作について完全な自律へと移行できます。この移行は、関連性のない幅広いタスクに一括で適用するのではなく、操作またはワークフローの単位で進めるべきです。

この移行は一方通行ではありません。組織は、エビデンスから必要と判断される場合には、人間による監督を再導入できるよう備えておく必要があります。また、一部の決定論的な境界は、予見可能な将来にわたって恒久的に維持される可能性が高いでしょう。こうした境界が存在するのは、エージェントが信頼を獲得していないからではなく、合理的なリスク分析に照らして、特定のアクションがもたらす結果が許容できないからです。全体としてのモデルは、実証された能力によって自律性を獲得し、評価によって統制され、恒久的な制約によって範囲が限定され、継続的なレビューの対象となるというものです。いずれ、専門化された境界エージェント (boundary agent) が、純粋に決定論的な制御よりも優れた成果をもたらす可能性があります。ただし、その選択肢は、経験と評価を積み重ねる中で、時間をかけて初めて実現するものです。

4 つの原則は、目指すべき目標を定めるものです。目標を達成するには、セキュリティボックスとより広範なセキュリティアーキテクチャを構成する、具体的なアーキテクチャの構成要素が必要です。NIST への回答では、これらの構成要素をより詳しく説明しています。ここではその概要を紹介します。AWS はこれらの構成要素を Amazon Bedrock AgentCore に実装しています。Amazon Bedrock AgentCore は、セキュリティを基礎から組み込んだ、エージェンティック AI システムを構築、デプロイ、運用するためのフレームワークです。

コンピューティングの分離。エージェントのコンピューティング環境は、実行を分離し、エージェント間のデータ漏洩を防ぎ、定義された境界内にエージェントを封じ込める必要があります。Amazon Bedrock AgentCore は、エージェントを Firecracker 上で実行します。Firecracker は Rust で記述されたオープンソースの仮想マシンマネージャーです。Linux KVM とハードウェアベースの仮想化を基盤とする軽量なマイクロ VM を提供し、コンテナ並みの速度と、完全な仮想マシンと同等の分離特性を両立しています。Firecracker のセキュリティ上重要な中核要素は AWS のチームによって形式検証済みであり、Rust によるメモリ安全性に加えて、さらなる保証を提供しています。

アイデンティティとアクセス管理。エージェントには、固有のアイデンティティ、安全な認証情報の保管、インフラストラクチャレベルで強制される最小権限の認可が必要です。AgentCore Identity は、エージェントにマシンアイデンティティを提供し、OAuth と安全な認証情報のフローを管理します。また、きめ細かなアクセス制御を実現するために AWS Identity and Access Management (IAM) と統合されています。属性ベースのアクセス制御をサポートし、追跡可能な委任チェーンを維持することで、エージェントのアクションと呼び出し元のユーザーとの関係を監査可能な状態に保ちます。

ツールアクセスとポリシーの適用。エージェントがアクセスできるツールが増えるたびに、その有用性と潜在的なリスクの両方が拡大します。エージェントごとにツールへのアクセスを個別に管理すると、組み合わせが爆発的に増加し、管理しきれなくなります。AgentCore Gateway は、エージェントとツールの間で一元的な仲介役として機能し、単一の制御ポイントで認証と認可を適用します。API レベルだけでなく、個々のパラメータに至るまでツール呼び出しを検査できます。AgentCore Policy は、オープンソースの Cedar 認可言語に基づいて構築されており、形式検証済みのポリシー適用を実現します。チームは Cedar ポリシーを自然言語で作成してからレビューできるため、LLM の柔軟性と形式手法の厳密性を両立できます。

オブザーバビリティ。オブザーバビリティのインフラストラクチャには、リアルタイムのモニタリングと調査に十分なコンテキストを取得できること、そして監視対象のエージェント自身から保護されていることが求められます。組織が従業員に自分の監査ログの編集を許可しないのと同様に、この原則はエージェントにも当てはまります。AgentCore は、AgentCore Gateway、セッションレベルのテレメトリ、内部の状態変化を記録する詳細なトレースを通じてオブザーバビリティを提供します。これらの機能は、AgentCore の外部で実行されているエージェントにも適用できます。

モデル実行環境。モデル実行環境のセキュリティは、エージェント自体のセキュリティと同じくらい重要です。Amazon Bedrock は、AWS もモデルプロバイダーもお客様のプロンプトとレスポンスにアクセスしない、分離されたネットワーク環境でモデルを実行します。お客様がログ記録を有効にした場合、そのログは保存時に暗号化され、カスタマーマネージドキーによって保護されます。こうしたアーキテクチャレベルの分離は、政府機関や企業のお客様が Amazon Bedrock を採用している主な理由の 1 つです。

訳注: カスタマーマネージドキーによる保護を適用するには、ログの配信先の Amazon S3 バケットでカスタマーマネージドキーを使用する SSE-KMS を設定するか、Amazon CloudWatch Logs のロググループにカスタマーマネージドキーを関連付けて暗号化を設定する必要があります。参照: CloudWatch Logs と Amazon S3 を使用してモデル呼び出しをモニタリングする

決定論的な外部制御は、AI 処理ループ内の制御によって補完されます。Amazon Bedrock Guardrails は、分類器 (classifier) と呼ばれる小規模な AI モデルを使用してプロンプトとレスポンスを検査し、プロンプトインジェクションなどの課題に対処します。自動推論チェックはさらに一歩進んでおり、開発者は特定の知識領域の形式モデルを作成し、LLM の出力がそのモデルに準拠していることを検証できます。その結果は決定論的であり、正しさを証明できるものになります。

エージェンティック AI はソフトウェアの動作のあり方を変えますが、そのセキュリティ対策は数十年にわたって確立されてきたプラクティスの上に成り立っています。既存のフレームワークは適切な基盤となります。取り組むべきは、既存のフレームワークをエージェント固有の考慮事項に合わせて拡張することです。組織は、セキュアな開発ライフサイクルのプラクティスを AI コンポーネントに適用し、従来のセキュリティ制御を維持する必要があります。また、エージェントの外部にある決定論的な制御によってセキュリティを強制し、体系的な評価を通じてより大きな自律性を獲得していくべきです。

これらの原則は理論上のものではありません。AWS がエージェンティック AI サービスの構築と運用を通じて得た経験を反映したものであり、AWS のインフラストラクチャ設計にも組み込まれています。NIST が業界からの意見を基にガイダンスを策定していく中で、AWS は、お客様がエージェンティック AI システムを安心して構築、運用できるよう支援するための投資を今後も続けていきます。

AWS がお客様の AI ワークロードの保護をどのように支援しているかの詳細については、「AWS AI Security」ページをご覧いただくか、「Amazon response to the CAISI Request for Information regarding Security Considerations for Artificial Intelligence Agents」をお読みください。