AIエージェントに業務を任せるとき、できることは多いほど便利だろうという発想で、外部へメールを送る機能もデータを削除する機能もまとめて渡してしまいがちです。平常時はそれで問題なく動きます。しかしAIが一度だまされると、渡していた機能の範囲が、そのまま被害の大きさに直結します。

そこで、守りの発想を切り替えます。AIが決してだまされないよう工夫し続けるのは現実的に困難です。それよりも、だまされても実行できることを小さくしておくほうが堅実です。この記事では、AIエージェントの権限をどう絞るかを、セキュリティ設計の観点から整理します。権限を絞ることは便利さを失うことと同義ではありません。その業務に必要な機能だけを渡すという考え方であり、評判をまとめるAIに外部送信の機能は不要です。むしろ、業務に不要な強い機能が乗っていること自体がリスクになります。

権限が被害の大きさを決める理由

まず、乗っ取りの被害がどこで決まるかを整理します。

AIエージェントは、自ら道具を選んで作業する仕組みです。ある宛先へ情報を送るよう指示されれば、使える機能の中から送信用のものを選んで実行します。ここで重要なのは、AIは渡された機能の範囲でしか動けないという点です。

つまり、だまされたときに何が起きるかは、モデルの賢さではなく、AIに何を持たせていたかで決まります。外部送信の機能を持っていなければ、どれほど巧妙な命令を受けても情報を外へ送る手段がありません。削除の機能がなければデータを消せません。逆に、広範な権限を渡していれば、だまされた瞬間にその全体が攻撃者の意図に沿って使われる場合があります。

実際、RAGから会員の個人情報が漏れた検証でも、決定打の一つは、AIが外部へデータを送る機能を承認なしで実行できる状態だったことでした。権限が絞られていれば、同じ命令を受けても情報が外へ出るには至りにくかったと考えられます。

「任せる範囲の判断」と「権限の設計」は別の話

ここで、混同しやすい2つの観点を切り分けます。

AIにどこまで業務を任せるかという判断は、AIに任せる作業・人が握る作業の分け方で扱う、業務側の線引きです。やり直せるか、影響範囲が広いか、といった観点で任せる範囲を決める話です。

一方、この記事で扱うのは、その線引きを技術的にどう強制するか、というセキュリティ側の話です。外部送信は人が承認すると決めても、AIが承認なしで送れる状態のままなら、決めた意味を持ちません。決めた線引きを、AIが技術的に越えられないよう作り込む。それが権限の設計です。業務の判断が地図であるなら、権限の設計は柵にあたり、両方がそろって初めて機能します。人間相手であれば規則を守るよう求められますが、だまされたAIは規則を越えて動くため、越えられない仕組みの側で止める必要があります。

最小権限：その業務に必要な機能だけ渡す

権限設計の土台になるのが、最小権限という考え方です。

そのAIエージェントが担う業務に本当に必要な機能だけを渡し、念のため広めにという発行を避けます。レビューをまとめて答えるAIに必要なのは検索の機能だけで、外部へメールを送る機能、データを削除する機能、決済する機能はその業務にはいりません。渡さなければ、だまされても実行できません。

読み取りだけで足りるなら書き込みや削除の権限は与えず、社内情報を参照するだけでよいなら外部と通信する機能は外す。持たせる機能が狭いほど、想定外の動作が起きても被害の広がりを抑えられます。APIキーのような強い鍵を必要以上に広い権限で発行しないという、鍵そのものの扱いとも地続きの発想です。

送信先・回数・承認で「取り返しのつかない操作」を囲う

最小権限で機能を絞っても、業務上どうしても外部送信のような強い機能が必要になることがあります。その場合は、機能を渡したうえで使い方を三重に囲います。

  • 送信先を限定する。外部へ送れる宛先を、あらかじめ許可したものだけに絞る(許可リスト・ホワイトリスト)。攻撃者の宛先が命令に書かれていても、リストになければ送れません。
  • 送れる項目と回数を制限する。一度に送れる件数や情報の種類に上限を設ける。仮に漏れても、一度に全部が持ち出されにくくなります。
  • 重要な操作は人の承認を挟む。取り返しのつかない操作はAIだけで完結させず、実行の直前に、この宛先へこの内容でよいかを人が確認する。

この3つがあると、AIが全会員の情報を外部宛先へ送れという命令に従おうとしても、宛先が許可リストになく、件数が上限を超え、人の承認も下りない、というかたちでどこかで止まりやすくなります。

インフラ側でも「出られない・入れない」を作る

さらに堅くするなら、AIのプログラムの外側、インフラの層でも通信を絞ります。

アプリの設定で注意していても、設定ミスや想定外の抜け道は起こり得ます。そこで、サーバーそのものを許可した相手としか通信できない状態にしておきます。外へ出ていく通信も、外から入る通信も、決めた範囲だけを許可し、それ以外は遮断する。こうしておくと、仮にAIが攻撃者の宛先へ送ろうとしても、インフラの層で通信そのものが弾かれます。

アプリ側の権限とインフラ側の通信制限という二重の柵があれば、片方が破られても、もう片方で止まりやすくなります。守りは一枚では崩れやすく、重ねるほど堅くなります。

導入前の点検リスト

いま動かしている、あるいは構築しようとしているAIエージェントについて、次を確認してください。

  1. そのAIに渡している機能をすべて書き出せるか。使っていない機能が混ざっていないか。
  2. 外部送信・削除・決済といった強い機能を、その業務は本当に必要としているか。不要なら外せるか。
  3. 外部送信がある場合、送信先は許可リストで限定されているか。任意の宛先に送れる状態になっていないか。
  4. 取り返しのつかない操作の前に、人の承認が入るようになっているか。
  5. インフラの層でも、通信できる相手が絞られているか。

使っていない強い機能が渡ったままの項目があれば、そこが最優先の絞りどころです。

まとめ

  • だまされたときの被害の大きさは、モデルの賢さでなく、AIに渡していた権限で決まる。
  • 業務としての任せる範囲の判断と、技術としての越えられない権限の設計は別物で、両方そろって効く。
  • 土台は最小権限。その業務に必要な機能だけ渡し、余計な強い機能は外す。
  • 必要な強い機能は、送信先の限定・回数の制限・人の承認で囲う。
  • インフラ側でも通信をホワイトリストで絞り、二重の柵にする。

AIに権限を渡すときは、何ができると便利かより、何ができないと安全かから考えると、線が引きやすくなります。だまされない工夫に頼りきるのではなく、だまされても実行できることを小さくしておく。それが、崩れにくい構えになります。