あなたのAIエージェント・アーキテクチャがセキュリティ上の脆弱性となる理由
2027年までに、企業におけるAI導入の40%がプロンプトインジェクションやエージェント乗っ取り（agent hijack）の事案に直面することになります。これは、2025年初頭の5%未満という数字から大幅な増加となります。
オーケストレーション層はエージェントに有用性をもたらしますが、同時に攻撃の標的にもします。
シンガポールの物流企業は、最近230万ドルの損失を出しました。改ざんされたカレンダーの招待状によって、スケジューリング・エージェントが欺かれたのです。その結果、エージェントはCRMの記録を攻撃者に送信してしまいました。モデル自体に悪意のあるコードがあったわけではありません。モデルは指示に完璧に従っただけなのです。問題はアーキテクチャにありました。
エージェントは単なるチャットボットではありません。ツールを使用し、ファイルを読み込み、トランザクションを実行する「システム」です。従来のセキュリティは「リクエストが入り、レスポンスが出る」というモデルを前提としています。エージェントはこのモデルを打破します。
メールの下書きを行い、返金申請を行うエージェントは、単一のランタイム内で3つのアプリが動いているようなものです。すべてのツール呼び出し（tool call）がリスクであり、すべてのメモリ書き込みがリスクです。すべてのメールやドキュメントは、実行可能なコードなのです。
安全性を確保しているチームは、以下の3層パターンを採用しています。
- Identity（アイデンティティ）：すべてのツール呼び出しには、ユーザーとは別のアイデンティティが必要です。
- Provenance（プロバナンス）：すべてのメモリ書き込みには、その出所を示すメタデータが必要です。
- Verification（検証）：すべての計画ステップには、後続の実行のための署名済みオブジェクトが必要です。
エージェントが本番環境のAPIを直接呼び出すことは決してあってはなりません。代わりに、仲介ツール層（mediated tool layer）を使用してください。この層が引数を検証し、権限の範囲を限定し、監査ログを作成します。この層を、新しいファイアウォールだと考えてください。
メモリもまた、甚大なリスクとなります。攻撃者は、汚染された（poisoned）ドキュメントやメールを使用して、エージェントのメモリを書き換えます。これにより、時間の経過とともにエージェントの振る舞いが変化してしまいます。メモリ・ポイズニング攻撃は、毎年300%のペースで増加しています。
ほとんどのチームは、既存のパイプラインにAI脅威モデリングを追加していますが、エージェントのランタイム自体にセキュリティを追加してはいません。ツール呼び出しの異常を監視できている組織は、わずか19%に過ぎません。
エージェントを単なるソフトウェアとして扱うのはやめましょう。システムへのアクセス権を持つ「ジュニア社員」のように扱ってください。新入社員に初日からroot権限を与えることはないはずです。エージェントに対しても、同じことをしてはいけません。
勝者となるのは、最も派手なデモを見せるチームではありません。銀行やヘルスケア分野のセキュリティレビューを通過できるエージェントを持つチームです。今すぐこれら3つの層を構築してください。侵害が発生した後に、後付け（retrofit）してはいけません。
もし初日からエージェントの安全性に焦点を当てていたとしたら、最近下したアーキテクチャ上の決定のうち、どの部分を変更したいと思いますか？
学習コミュニティ（任意）: https://t.me/GyaanSetuAi