AI が攻撃手段の場合と、AI 自体が攻撃対象の場合は？

攻撃者が AI でなりすまし文書を作ったり攻撃を準備したりする場合、アカウント、メール、業務の承認が防御対象になります。社員が使うエージェント自体が対象であれば、悪意のある入力による情報開示やツールの誤用を防ぎます。NIST は、AI を用いる攻撃と、プロンプトインジェクションなど AI を対象とする攻撃を区別しています。[1]

ここでは後者を扱います。サポート、CRM の送信、運用のツール呼び出しで、データ、権限、承認、試験、復旧をどう管理するかを整理します。

トークンや接続方式、サーバー設定は MCP の本番セキュリティ項目 で扱います。ここでは照会から下書き、承認、外部送信、派生した記憶までの業務経路を追います。

プロンプトインジェクションはモデルが読む情報に別の動作を誘う指示が混入する問題です。利用者の入力のほか、ページ、メール、ファイル、ツール応答が経路になります。OWASP の 2026 LLM Top 10 はインジェクション、機密情報の開示、過剰な自律性をそれぞれ扱っています。[2]

許可する業務を一文で示せるか？

架空の販売会社のサポート業務を考えます。

エージェントは問い合わせを読み、本人の注文状態を確かめ、回答の下書きを作ります。添付や製品資料も参照します。便宜上、運用者が送信と返金ツールもつないでいます。

添付文書が別の顧客の注文を照会するよう誘導したり、送信先を変えたり、一般案内を返金承認として扱わせたりする恐れがあります。Anthropic のブラウザー利用の研究は、エージェントが読む情報が動作に影響しうることを説明しています。[3]

許可する日常業務を一文にします。

認証済み顧客の問い合わせに関連する注文を照会し、確認できる根拠を使って担当者が確認する回答案を作る。

この一文で対象者、対象案件・注文、結果が下書きであることを定義できます。「サポートを助ける」とだけ決めると、どの制限を強制するかが曖昧です。

下書きに不要な返金ツールは提供しません。送信や返金を提案した場合は、それぞれの権限と検証を持つ別の手順に渡します。

サービスの仕組み

キャンペーンに必要なデータから接続 — 施策から逆算してイベントと属性を定義し、識別子、送信時点、測定ツールの役割を整えます。

誰に読む、書く、送る、返金する権限を付けるか？

最小権限はツール名に加え、呼び出す主体、顧客組織、対象、操作、業務状態に適用します。OWASP は、ツール呼び出しと引数を利用者の権限やセッションの文脈に照らして検証することを勧めています。[4]

次はサポート業務で権限を設計するときの例です。

操作初期範囲実行前の検査証拠
顧客情報を読む本人と案件に紐付く注文項目要求者、組織、所有関係、閲覧可能な項目主体と対象を結び付けたアクセス記録
内部記録に書く当該案件の相談要約の下書き編集項目、競合、確定状態への影響変更前後、作成者、下書き状態
外部に送る許可済み経路・宛先・内容宛先、本文、添付、経路、承認の有効性承認と実送信を紐付けた記録
返金する対象注文、別途承認所有関係、残額、現在状態、重複承認額、取引 ID、処理結果、突合

読み取りだけでも情報は漏れます。複数の組織をまたぐ検索を行えば、表示を抑える前にモデル入力やログへ入ることがあります。照会側で絞り込み、キャッシュや記憶にもユーザー・組織境界が保たれるか試します。

顧客 ID をモデルに抽出させる場合でも、サーバーは認証済みセッションと確認済みの所属関係で対象範囲を決めます。

許可された送信サービスであっても、宛先や添付が誤っていれば漏えいします。接続先と今回の送信内容をそれぞれ確認します。

連携する SaaS が照会や送信先を制限できないなら、承認済みの資料を使う下書きまでに絞るか、別の実行サーバーで強制します。実際の連携で使える機能を確認して範囲を定めます。

外部資料と実行の間にどんな境界を置くか？

入力に出所と用途を付けます。顧客の依頼、承認済み方針、外部ページ、ツール結果は権限が異なります。調査時にどこから入った情報かをたどれるようにします。

Microsoft の指針は、検知、コンテンツ分離、動作観測、認可を組み合わせ、遅延・費用・誤検知も考慮するよう説明しています。資料の区別や検知と合わせて、実行時の認可を強制します。[5]

入力資料、モデルの操作提案、実際に送信や変更を行う境界をそれぞれ試します。入力を検知できなくても、操作には認可を適用します。

内部文書にも転載した外部情報や誰でも編集できる内容が含まれます。文書の編集と、業務方針を変更する手続きは分けます。

要約、記憶、検索インデックスは後の作業に影響します。OWASP のガイドは記憶の出所と信頼の記録、保存の承認、取得後の方針確認を扱います。[6]

疑わしい原文を消したら、派生した要約や記憶を追います。後続の作業が引き続き取得・再利用できないかも試します。

顧客情報の各段階でどんな証拠を残すか？

下書きが内部記録になり、承認済み回答が送信され、要約が次の問い合わせに使われる場合があります。各段階を参照で結び、原文の複製は必要な場所に絞ります。

段階範囲の基準残す最小情報
照会現在の利用者と組織の権限原典 ID・版、アクセス判定、要求 ID
下書き案件に必要な事実根拠、下書き状態、未確認事項
承認承認者の権限と対象承認値の識別と有効範囲
外部送信宛先、添付、内容の一致実行 ID、結果、成否不明
派生した記憶再利用目的、組織、保管ルール原典との関係、利用状態、失効・再確認条件

文書を回収しても、派生した要約を検索できれば同じ影響が戻り得ます。調査中は該当する記憶を制限し、承認された資料から再生成するか廃棄するかを判断します。調査用の保全と実業務での再利用は区別します。

以前の対話、別の担当者の顧客照会、要約の再検索でも試します。回収した情報を権限や操作の根拠にできないことを確認し、原典と検索、キャッシュ、記憶に反映された時刻を記録します。

担当者は具体的に何を承認するか？

取引として操作を表示します。どの注文、いくら、どの根拠、どの送信先かが分かるようにします。「続けますか」だけでは何を承認するのか特定できません。

OWASP は影響の大きい実行の事前確認、承認の検証、監査記録を扱います。返金にも実際の実行値を使って適用します。[7]

操作、対象、金額、宛先、理由、有効期間を承認に紐付けます。重要な項目が変われば承認を取り直します。実行前に承認と権限が有効か、返金可能額が足りているかを確認します。

実行サービスは承認した要求を記録し、引数を導出または検証して結果を確認します。失効した承認や範囲外の再利用を拒否します。

外部処理の応答が戻らない場合は、提供元と業務側の記録で照合します。受付済み、失敗確定、成否不明を運用者が区別できるようにします。

実行結果をどう観測して判定するか？

拒否が表示される前にツールが動く場合があります。正常に見える回答の裏でログや外部通信にデータが残ることもあります。開示、権限外の操作、持ち出しを直接観測します。[4]

予定している運用と同じ制限を設けた隔離環境で、テスト用データを使います。

試験期待する制御確認対象判定の注意
添付が別の顧客の注文を要求サーバーの組織・顧客制限照会拒否と非開示空の応答だけでは不足
下書き中に送信を要求下書きに送信権限がない確認依頼のみ作成送信キューも点検
承認後に宛先・金額を変更承認と実行値の一致保留または拒否古い承認の再利用も試験
同じ返金を再試行操作の重複防止最終取引は一件応答数と実取引数を区別
疑わしい資料が記憶に入る保存・再利用の方針後続処理が権限拡大や不当操作をしない削除後の派生記録を確認
ツールがループ・遅延回数、時間、費用制限停止して状態を通知無言の失敗と区別
正当な依頼許可された業務は遂行可能正しい照会と下書き誤った拒否も記録

禁止経路と対になる許可経路を残します。会話に加え、権限判定と確定状態の記録を用意します。

業務で使う言語、添付の種類、対話の長さ、複数段階の操作で試します。事例数と繰り返し数を記録し、違反を観測しなかった条件を明示します。

本番に近い条件で試し、範囲と限界を記録します。モデル、プロンプト、ツール、記憶、資料、権限が変われば該当経路を試し直します。[1]

いつ停止し、何を確認して再開するか？

異常を見つけた運用者が実際に影響を抑えられる必要があります。NIST のインシデント対応資料は準備、検出、対応、復旧を組織のリスク管理につなげています。[8]

公開前に発動条件と担当を決め、表を使って停止と見直しを訓練します。

状態直ちに行うこと担当再開の証拠
他顧客へのアクセス・漏えい該当の照会、検索、機能を制限セキュリティ・データ担当境界を修正し、影響と回帰結果を確認
無承認の送信・返金ツールと待機作業を停止運用・業務責任者実操作を照合し承認処理を再試験
操作記録が欠落観測できる機能に絞る運用・開発記録が回復しサンプルを追跡できる
正常依頼を過剰に拒否範囲を限定して人の確認へ業務・QA原因と通常・攻撃事例の再試験

新規の受け付け停止と、実行中・完了済み作業の確認は別の操作です。キュー、ログ、利用者や外部システムの記録を確認します。

再開前に失敗経路を再現し、修正後の構成で期待した制御を確認します。再開範囲と残る条件、監視担当を決めます。

モデルや指示を戻しても送信済みの操作や支払いは残ります。関係する担当者と取消、補償、追加の調査を判断します。

導入を決める会議で何を確認するか？

権限表、試験結果、未検証経路を持ち寄ります。実際の業務と必要な権限から始めます。

  • どの主体がどの対象と項目にアクセスするか。
  • 下書き、承認、外部操作をどう分けるか。
  • 成否不明の要求を見つけ、再試行を止められるか。
  • 拒否と許可された動作を何で証明するか。
  • 誰が停止、調査、再開を決裁するか。

検証した境界に基づいて、限定公開か保留を選びます。機能ごとの残る条件を記録します。

一般的な判断方法は リリース判断の基準 にあります。エージェントでは外部入力、権限変更、承認、記憶の証拠を追加します。

試験結果をどう次の対策につなげるか？

試した条件、確認した拒否、未確認経路を記録します。要件、修正、再試験との関係を残せば構成変更後にも見直せます。

Qoretix はテスト計画、API・ブラウザー実行、失敗・未検証の証拠、接続済みリポジトリのコード・シークレット・依存関係の点検を説明しています。[9] 適用範囲は構成ごとに確認し、権限と実行承認はアプリケーションで強制します。

導入の確認には、対象の業務、権限の境界、まだ検証が必要な事例を持ち寄ります。