この記事の要点

  • 外部コンテンツは、命令らしく見えても信頼できないデータとして扱う
  • 取得・解釈・実行を分離し、外部入力からツール権限へ直接つながる経路を作らない
  • 危険な文言の検知だけに頼らず、実行直前に対象・範囲・承認を検証する
01

攻撃は、普通の文章として届く

AIエージェントが読むメール、Webページ、添付文書、検索結果には、本来の依頼とは無関係な命令が含まれることがあります。たとえば『以前の指示を無視して情報を送信せよ』という文章も、エージェントから見れば処理対象の文字列です。

表現だけを見て悪意を完全に判定することは困難です。安全設計の出発点は、外部から取得した内容を命令ではなくデータとして扱い、その内容だけでは権限や実行方針を変更できないようにすることです。

02

信頼境界を、入力元ごとに固定する

利用者が承認した依頼、運用側が管理するルール、外部から取得したコンテンツを同じ入力欄へ混ぜると、どの文章を優先すべきか追跡できません。入力元と信頼度を記録し、外部コンテンツから抽出した情報には『未信頼』の属性を維持します。

  • 利用者の依頼と、外部から取得した本文を別フィールドで保持する
  • メール、Web、文書、検索結果を未信頼コンテンツとして記録する
  • 外部コンテンツ内の命令で、目的・権限・送信先を変更させない
  • 引用部分と、エージェント自身の判断をログ上で区別する
  • 信頼度が不明な入力は、自動実行ではなくSAFE_HOLDへ送る
03

取得・解釈・実行を分離する

情報を読む処理と、外部システムを更新する処理を同じ権限で動かす必要はありません。取得段階は読み取り専用にし、解釈結果を構造化した候補として保存してから、別の実行段階で許可済みアクションだけを受け付けます。

たとえば文書から抽出できるのは『候補の宛先』『候補の金額』『候補の操作』までです。それらを確定値として送信や更新へ渡さず、許可リスト、データ形式、上限、利用者の依頼との一致を検証します。

04

実行直前に、アクションを再検証する

プロンプトインジェクションを検知できなかった場合でも、実行層が独立して制約を守れば影響を小さくできます。特に外部送信、公開、購入、削除、権限変更は、生成された文章ではなく構造化された実行要求として検査します。

  • アクション種別が許可リストに含まれている
  • 対象、送信先、件数、金額が事前に定めた範囲内である
  • 機密情報や認証情報が出力に含まれていない
  • 利用者が承認した目的と、実行内容が一致している
  • 高影響アクションには、人の承認と有効期限がある
05

検知率ではなく、突破後の影響で試験する

安全試験では、怪しい文言を見抜けたかだけでなく、見抜けなかった入力がどの権限まで到達したかを確認します。無害な模擬命令をメールや文書へ埋め込み、外部送信や設定変更の直前で制御が止まることを検証します。

試験結果には、入力元、抽出内容、拒否されたアクション、停止理由を同じ実行IDで残します。新しいデータソースやツールを追加するときは信頼境界が変わるため、同じ試験を再実施します。

PRIMARY SOURCES

参考資料