なぜAIエージェントがゼロトラストセキュリティを破壊しているのか

過去10年間、セキュリティチームはシステムを保護するためにゼロトラストアーキテクチャに依存してきました。その哲学はシンプルで、いかなるアクセス要求も決して信頼せず、常に検証するというものです。しかし、このモデル全体は「人間が意思決定を行う」という単一の前提に基づいて構築されていました。このギャップを検証した2026年7月4日の記事では、重大な課題が概説されています。その前提が崩れつつあり、その影響は深刻であるということです。

今日、2026年7月5日、この変化はかつてないほど重要になっています。AIエージェントはもはやテキストを生成するだけではありません。データベースへのクエリ、ワークフローのトリガー、APIの呼び出し、レコードの変更など、エンタープライズ環境内で直接アクションを実行しています。クラウドインフラストラクチャ内で、機械がユーザーの代わりに自律的に動作できるようになったとき、その機械のアイデンティティは人間のユーザーと同じくらい重要になります。そしてそれは、私たちがセキュリティについてどのように考えるべきかを根本的に変えるものです。

何が変わったのか：自律型AIの台頭

数年前、AIシステムはほとんど受動的でした。要約を生成し、電子メールを書き、質問に答えていました。今日、Amazon Bedrock Agentsのようなプラットフォームがそのアーキテクチャを完全に変えました。これらのシステムは今や、ユーザーのリクエストを解釈し、どのツールが必要かを判断し、承認を待たずにバックエンドの操作を自律的に実行することができます。

これが実際にどのようなものか見てみましょう。ユーザーが「過去30日間の顧客からのクレームを要約して」と入力します。するとAIエージェントが自ら行動を起こします。CRMデータベースにクエリを投げ、分析APIを呼び出し、サポートチケットのデータを抽出し、レポートを生成します。各ステップをチェックする人間が介在することなく、これらすべてが自動的に行われます。

これは生産性において非常に強力です。同時に、適切に保護されていなければ極めて危険でもあります。

新たなアタックサーフェス（攻撃対象領域）

何が問題になり得るかを考えれば、そのリスクは明らかです。エージェントの動作を乗っ取るように設計された巧妙な入力である、たった1回のプロンプトインジェクションが成功するだけで、エージェントの次の行動を完全に別の方向に変えることができます。そのエージェントが過剰に幅広い権限を持っている場合、攻撃者はエージェントに次のことを強制できます：

• 機密の顧客データにアクセスする
• 不正なAPI呼び出しを実行する
• データベースのレコードを変更する
• 特権を持つバックエンドワークフローをトリガーする

マルチエージェント環境では、問題はさらに悪化します。一般からのリクエストを処理する、顧客対応のAIエージェントを想像してみてください。もしそのエージェントが侵害された場合、インフラストラクチャの変更や制限されたシステムへのアクセス権限を持つ、高度な特権を持つバックエンドエージェントに悪意のある指示を渡す可能性があります。トラフィックが信頼できる内部サービスから来るため、従来のセキュリティツールではこれを完全に見逃してしまうことがよくあります。正規のものに見えるからです。

なぜゼロトラストではもはや不十分なのか

ゼロトラストは、人間の行動と比較的予測可能なアクセスパターンを想定して設計されました。人間はログインし、営業時間内に働き、プロセスに従います。しかし、AIエージェントはまったく異なる方法で動作します：

• 自律的に、かつ機械の速度で行動する
• リアルタイムでの人間の検証なしに意思決定を行う
• 他のエージェントと頻繁に通信する
• その行動は予測が困難である

従来のセキュリティシステムは現在、次のような難しい質問に答えるのに苦労しています：

• このアクションは、この特定のエージェントにとって妥当か？
• このリクエストは、意図された役割と一致しているか？
• このAI間の相互作用は正当なものか？
• その振る舞いは、通常期待されるものから逸脱しているか？

自分が何者であるかを証明する認証だけでは、もはや十分ではありません。エージェントが本物であることを検証できたとしても、それがこれから行おうとしていることを本当にすべきかどうかは、全くわからないままなのです。

AIエージェントを実際にどう保護するか

AIエージェントを通常のIAMユーザー（誰が何にアクセスできるかを制御するシステムであるIdentity and Access Management）のように扱うだけでは不十分です。セキュリティはアーキテクチャに直接組み込まれなければなりません。以下に重要な実践方法を示します：

ステップ1：有効期間の短い認証情報のみを使用する

すべてのエージェントの実行において、AWS STS（Security Token Service）または同等のサービスを通じて一時的な認証情報を受け取るようにすべきです。永久に機能するAPIキーのような有効期間の長い認証情報は、永続的な攻撃経路を生み出します。攻撃者が有効期間の短いトークンを盗んでも、数分または数時間で有効期限が切れます。しかし、永久的なキーを盗まれた場合、誰かが気づいて無効化するまでアクセスされ続けます。

ステップ2：真の最小特権を適用する

各エージェントには、厳格にスコープが設定された専用のIAMロールが必要です。エージェントに「データベース内のすべて」への幅広いアクセス権を与えないでください。代わりに、その仕事を実行するために実際に必要な、正確なLambda関数、API、およびデータベースに対する権限のみを与えてください。名前を挙げることができるなら、制限すべきです。

ステップ3：静的なAPIキーを排除する

AIワークフローにハードコードされた認証情報が存在してはなりません。コードに埋め込まれたシークレットは、バージョン管理、ログ、またはメモリダンプで漏洩する可能性があります。代わりに、Workload Identity FederationとOIDC（OpenID Connect）プロトコルを使用して、エージェントが一時的なロールを動的に引き受けられるようにします。エージェントはキーを保持する必要はありません。信頼できる機関に対して自らのアイデンティティを証明し、その機関が一時的な権限を発行します。

ステップ4：エージェントのワークフローを積極的に分離する

侵害が発生した場合の被害範囲（ブラスト半径）を制限するために、エージェントを別々のVPC（Virtual Private Cloud）またはAWSアカウントで実行します。小さく隔離されたネットワークゾーンを作成するマイクロセグメンテーションは、自律型環境において非常に重要です。あるエージェントが侵害された場合でも、攻撃者が自動的に他のすべてにアクセスできるようにしてはなりません。

ステップ5：エージェントの行動を継続的に監視する

CloudTrail（API呼び出しをログに記録する）、GuardDuty（脅威を検出する）、行動分析などのツールを使用して、異常を検出します。これまで触れたことのないデータベースにエージェントが突然アクセスしたり、権限昇格の試みがあったり、不審なエージェント間通信があったりするなど、異常なパターンがないか監視します。機械学習は、通常の行動からの逸脱を人間よりもはるかに早く見つけるのに役立ちます。

より大きな変化

ここで起きているのは、セキュリティの仕組みにおける根本的な変化です。機械のアイデンティティは指数関数的に増加しています。クラウドセキュリティの未来は、もはや従業員を保護することだけではありません。機械の速度で動作する自律型システムを管理することなのです。成功する組織は、AIエージェントを、動的な認可、厳密な分離、継続的な検証、およびリアルタイムの行動監視を備えたファーストクラスのアイデンティティとして扱うでしょう。

企業がゼロトラストの原則を自律型エージェントに拡張できなければ、セキュリティを近代化していることにはなりません。自らの脆弱性を自動化していることになるのです。

結論

ゼロトラストアーキテクチャは、ネットワーク境界内のものはすべて安全であるという前提に異議を唱えたため、画期的でした。今日、それらは再び異議を唱えられています。外部の攻撃者からではなく、私たちが自ら構築している自律型システムによってです。AIエージェントは強力なツールですが、適切な保護措置を伴わない力は、単なる別の種類の脆弱性にすぎません。

メリット

• 現実のギャップに対処する： 従来のゼロトラストフレームワークは自律型エージェントを考慮していなかったため、このガイダンスは真のセキュリティニーズを満たします。
• 実践的な推奨事項： このアドバイスは理論を超えて、具体的で実装可能な実践（有効期間の短い認証情報、最小特権、分離）にまで踏み込んでいます。
• 意識を高める： AIエージェントを展開している多くの組織は、これらのリスクをまだ考慮していません。この議論は今こそ重要です。
• プラットフォーム全体で適用可能： この原則は、AWS Bedrock、Google Cloud、その他のクラウドプロバイダーのいずれを使用している場合でも機能します。

デメリット

• 実装における大きなオーバーヘッド： OIDC、Workload Identity Federation、マルチアカウントの分離、継続的な監視を追加するには、多大なエンジニアリングの労力とコストが必要です。
• クラウド環境に限定される： このガイダンスはAWSまたは同様のクラウドインフラストラクチャを想定しています。オンプレミスへの展開では異なる課題に直面します。
• 監視の複雑さ： リアルタイムの行動分析には、多くのチームがまだ持っていない高度なツールと専門知識が必要です。
• トレーニングデータのポイズニングには対処していない： 焦点はランタイムのセキュリティに当てられています。モデルとトレーニングデータのセキュリティは、別の（そして同じくらい重要な）問題です。

注意

この記事は教育目的であり、2026年7月4日に公開された記事で議論されているセキュリティの実践に基づいています。これらの推奨事項を実装する予定の場合は、本番環境でそれらに依存する前に、現在のAWSドキュメント、OWASPガイドライン、およびNISTフレームワークと照らし合わせてすべての主張を検証してください。セキュリティアーキテクチャは、組織のセキュリティチームによってレビューされ、特定のリスクプロファイルおよびコンプライアンス要件に合わせて調整されるべきです。言及されているテクノロジー、API、およびサービス名は変更される場合があります。

よくある質問

• ゼロトラストセキュリティとは何ですか？また、どのように機能しますか？
• AIエージェントはネットワーク内で完全に信頼されることがありますか？
• プロンプトインジェクションとは何ですか？また、どのようにAIエージェントを侵害しますか？
• 有効期間の短い認証情報は、静的なAPIキーと比較してどのようにセキュリティを向上させますか？
• Workload Identity Federationとは何ですか？また、なぜAIエージェントにそれが必要なのですか？
• チームはセキュリティの異常について、どのようにAIエージェントの行動を監視できますか？
• 侵害されたAIエージェントの被害範囲（ブラスト半径）はどの程度ですか？
• 従来のファイアウォールやネットワークセキュリティツールは、AIエージェントの攻撃から保護してくれますか？

タグ

#security #cloudcomputing #ai #iam #zerotrust #aws #agents