AIエージェントのセキュリティ対策｜攻撃を検知するだけでなく被害を抑える

AIエージェントをメールや社内文書、Web、業務ツールにつなぐと、便利さと一緒に「外部の文章にだまされて、許可していない操作まで進まないか」という不安も出てきます。結論は、攻撃をすべて事前に見抜くことを前提にせず、だまされても読めるデータや実行できる操作を絞り、重要な操作を別の仕組みで止められるようにすることです。プロンプトインジェクションの例と、導入前に点検できる設計・テストの順に見ていきましょう。

AIエージェントでは「読むこと」と「動かすこと」がつながる

通常のチャットは文章を返すだけでも、エージェントはメールを読む、ファイルを検索する、APIを呼ぶ、内容を送信するといったツールを使えます。Webページやメールの本文に、AIへ向けた隠れた指示が書かれていると、利用者の依頼とは別の目的へ誘導されることがあります。OpenAIは、第三者が会話の文脈へ悪意ある指示を持ち込む攻撃を「プロンプトインジェクション」と説明しています（OpenAI「Understanding prompt injections」）。

たとえば、受信メールを要約するエージェントが、本文中の指示を信頼して別のメールを探し、個人情報を外部へ送ろうとする設計を考えてみてください。問題は文章を誤読することだけではありません。メールを読む機能と送信する権限が一緒に与えられていれば、誤った判断が外部への操作に直結します。OWASPの2026年版「Agentic Applications」では、目的の乗っ取り、ツールの誤用、認証情報と権限の悪用などが独立したリスクとして整理されています（OWASP Top 10 for Agentic Applications 2026、OWASPのリスク解説）。

検知フィルターだけで止めるのは難しい

入力から危険な指示を見つけて除外する仕組みは役に立ちますが、それだけを安全策にするのは不十分です。攻撃の表現や文脈は変化し、正当な文章との区別も難しいからです。OpenAIの開発記事も、悪意ある入力を完全に見つけることだけでなく、攻撃が一部成功してもシステムへの影響を制限する設計を重視しています（OpenAI「Designing AI agents to resist prompt injection」）。

ここで大切なのは、モデルに「外部の指示に従わない」と伝えることと、アプリケーション側でその指示が実行されないよう制御することを分けることです。モデルの判断だけをアクセス制御の代わりにせず、認証・認可はツールや接続先のシステムでも検証します。

実装では権限と操作経路を分ける

まず、エージェントが参照するデータと実行できる操作を棚卸しします。メールの要約だけなら、読むための権限で足りるのか、送信や削除まで必要なのかを分けて考えます。具体的な実装例として、OWASPの2025年版「Excessive Agency」ガイドは、必要のない機能や権限、自律性を減らし、影響の大きな操作には利用者の承認を求める方法を示しています（OWASP「LLM06:2025 Excessive Agency」）。

• 必要なデータだけ接続する：対象フォルダー、期間、利用者、APIスコープを絞り、不要になった接続は解除します。
• 読む機能と書く機能を分ける：要約に送信・削除・公開の権限を持たせず、用途別のツールを用意します。
• 許可判定を下流側でも行う：エージェントの文章で許可を判断せず、APIや業務システムが利用者、対象、操作を検証します。
• 取り消しにくい操作は確認を挟む：送信、削除、決済、権限変更などは、実行内容と共有される情報を表示してから人が確定します。
• 上限と記録を設ける：操作回数を制限し、ツール呼び出し、拒否、承認、エラーを追跡できる形で記録します。

これらはプロンプトインジェクションをなくす保証ではありません。万一エージェントが誤った指示を受けても、データ流出や取り返しのつかない処理に広がりにくくする境界です。

本番データを使う前に攻撃シナリオを試す

テストでは、正しい依頼に対して答えられるかだけでなく、読み込む資料に悪意ある指示が含まれた場合に何が起きるかを確かめます。実データではなく、個人情報や秘密を含まない検証用データで始めましょう。

1. 入力元を列挙する：Web、メール、アップロード文書、検索結果、外部ツールなど、エージェントが読むものを記録します。
2. 起こり得る被害を決める：外部送信、削除、公開、権限変更、秘密情報の読み出しなどを挙げます。
3. 悪意ある文章を含むテスト資料を作る：通常の依頼と無関係な操作を促す指示を入れ、エージェントが要約にとどまるか、ツールを呼ぶかを確認します。
4. 権限境界を検証する：読み取り専用の認証で書き込みが失敗すること、許可していない対象へアクセスできないことを、モデルの応答とは別に確認します。
5. 承認と記録を確かめる：重要操作が承認なしに実行されないこと、誰が何を許可したかを後から追えることを確認します。

モデル、プロンプト、ツール、接続先を変更したら、同じテストを再実行します。検知精度だけでなく「失敗してもデータが外へ出ないか」「危険な操作が確定しないか」を合格条件に含めるのが実務的です。

どの資料を基準にすればよいか

開発者向けの脅威分類を調べるなら、2026年8月に公開された最新のOWASP GenAI LLM Top 10と、エージェント固有のリスクを扱うAgentic Applications Top 10 2026が出発点になります。企業で導入する際は、IPAの2026年7月更新「セキュリティ担当者のための生成AIセキュリティ」が、企画から運用・廃棄までの管理、リスク評価、技術・運用・人的対策を整理しています。

組織全体のリスク管理では、NISTのGenerative AI Profileを参照できます。これはAIリスク管理の任意利用を想定した枠組みで、特定の製品を安全と認定するものではありません。規模や用途に合わせて、設計、検証、運用時の担当者と記録を決める際の補助線として使えます。

まとめ

AIエージェントのセキュリティでは、プロンプトインジェクションを完全に見抜くことを期待するより、入力を未信頼として扱い、データとツールの権限を絞り、重要操作を別の認可や人の承認で制御することが重要です。テストデータで攻撃シナリオを試し、ログと停止手段まで確認してから、扱う情報や操作を段階的に広げてください。

安全なエージェントは、攻撃を一度も受けないものではなく、誤った指示を受けても被害を広げずに止まれるものです。