規程を配るより 触れる範囲を実装で狭める

AIエージェントに社内業務を任せたい、という相談が増えています。多くはまず利用ルールを文書で決めようとします。しかしエージェント相手には、規程より先に「何に触れられて、何を実行できるか」をコードで絞る方が効きます。

理由は単純です。人は規程を読んで従いますが、エージェントの挙動は入力するテキスト次第で変わります。OWASPはプロンプトインジェクションを「ユーザーのプロンプトがLLMの挙動や出力を意図しない形で変えるときに起きる」脆弱性と定義し、その入力は人間に見えなくてもモデルが解釈すれば成立するとしています（OWASP LLM01）。文書で「危険な操作はするな」と書いても、実行時に別の指示を差し込まれれば効きません。

正しく動くエージェントほど 外部データに乗っ取られる

危険なのは壊れたエージェントではなく、正しく動いているエージェントです。OWASPはインジェクションを、利用者が直接指示する Direct と、Webページやファイルなど外部データ経由で指示が混入する Indirect に分けています（OWASP LLM01）。業務エージェントは資料要約や検索で外部データを読むため、後者の的になります。

この間接プロンプトインジェクションを最初に体系化した研究は、「LLM統合アプリはデータと指示の境界を曖昧にする」と述べ、GPT-4搭載のBing Chatなど実在するシステムで攻撃が成立することを示しました（Greshakeら arXiv:2302.12173）。同研究は「LLMはシステム基盤への脆弱な門番であり、そのリスクは自律システムでのみ増幅される」と書いています。権限を渡すほど危うくなる、ということです。

Simon Willison は、エージェントが「機密データへのアクセス」「信頼できないコンテンツへの曝露」「外部への通信」の3つを同時に持つと成立する危険を lethal trifecta と呼びました（Simon Willison 2025）。業務エージェントはこの3つを兼ねやすく、彼は検知フィルタについて「Webアプリのセキュリティで95%の捕捉は落第点」「100%確実に防ぐ方法はまだない」と釘を刺しています。防ぐ前提ではなく、揃わせない前提で組む話です。

任される範囲は「機能 権限 自律性」の過剰で決まる

OWASPは、エージェントが有害な操作を実行してしまう脆弱性を Excessive Agency と呼び、その根本原因を「過剰な機能」「過剰な権限」「過剰な自律性」の3つに整理しています（OWASP LLM06）。例として、メールを要約するだけのアシスタントに送信機能まで持たせ、悪意ある受信メールで受信箱の情報を外部へ転送させられるケースを挙げ、対策を「読み取り専用にする」「read-onlyスコープで動かす」「送信は人が実行する」と示しています。任せる範囲は、この3つを削って決めます。

実装で切る4つの境界

規程ではなくコードで担保する設計を、受託でエージェントを組み込むときは次の順で決めています。

これらは、実行後に人がコードを確認するレビューとは別の層です。レビューは出てきた結果を見ますが、権限設計は結果が出る前に触れる範囲を狭めます。

受託で組み込むときの順番

vnodが業務システムにエージェントを組み込むときは、機能を作る前にエージェント専用の最小権限アカウントを切ります。読み取りと書き込みを別アカウントに分け、不可逆な操作の手前に承認ゲートをコードで埋めます。狙いは lethal trifecta のどれか1つを必ず欠けさせることです。外部データを読ませるなら書き込みと外部送信を止める、送信させるなら機密データを読ませない、という具合に、3つが同時に揃わない形に構成します。

既存システムへ後付けする場合は、ブラックボックス化した仕様の解析で現在の権限とデータの流れを把握してから境界を引きます。PoCから本番へ移す判断も、AIのPoCを本番にする進め方と同じく、権限設計を先に固めるほど後戻りが減ります。

防ぎ切るのでなく 壊れても広がらない形にする

プロンプトインジェクションを完全に消す方法は、現時点で確立していません。だから「絶対に入られない」を目標にすると設計が止まります。入られても、エージェントが read しか持たず、外部送信ができず、不可逆な操作の手前に人がいれば、被害は境界の内側で止まります。文書の規程はその上に乗せるもので、土台にするものではありません。

業務システムへのエージェント組み込みで、権限設計から相談したい方はお問い合わせからご連絡ください。