任せる権限と止める場所を決められるか

実行する場所と、通してよいもの

コード実行は、処理を記したプログラムを動かすことです。サンドボックスは、その処理を制限した環境へ隔離し、使える資源や影響の範囲を抑える仕組みです。例えば試験用のファイルだけを扱う構成です。ただし、ネットワークや共有先へどこまで接続できるかは構成によります。隔離という名前だけで、外への通信も全て遮断されたとは決めません。

ホワイトリストは、許してよい対象を明示するリストで、許可リストやallowlistとも呼びます。使える道具、接続先、操作などを限定する例があります。何を単位に許しているかが大切です。道具名がリストにあっても、その道具へ渡す相手・ファイル・値まで、今回の依頼に合うと保証されたわけではありません。返る内容の正しさや更新日も別に確かめます。

根拠：NIST CSRC Glossary sandbox（別タブで開く） ↗ / Anthropic Building effective agents（別タブで開く） ↗ / NIST CSRC Glossary allowlist（別タブで開く） ↗ / OWASP LLM06 Excessive Agency（別タブで開く） ↗

別の制限を、代わりの保証にしない

サンドボックスは主に実行環境や影響の境界、許可リストは通してよい対象、最小権限は目的に必要な利用範囲を考えるものです。一つがあるから他を省けるとはしません。利用者の依頼と、実行する対象・操作を実行側でも照合します。許可した接続先の内部にも、今回見てよい資料と、見てはいけない資料があり得ます。

架空の試験で「模擬ファイルの読取だけ」を許すなら、本番の連絡先へ送れる機能や、本番用の認証情報は不要です。認証は相手が誰かを確かめることで、認証情報はそのための鍵などの情報です。試験用の場所へ分けても、そこから本番へ操作できる設定が残れば影響は外へ及びます。実行前に必要な接続と操作へ絞り、不明な範囲は確認します。

根拠：NIST CSRC Glossary sandbox（別タブで開く） ↗ / NIST CSRC Glossary allowlist（別タブで開く） ↗ / OWASP LLM06 Excessive Agency（別タブで開く） ↗ / A2A specification（別タブで開く） ↗

資料の内容を、新しい権限にしない

プロンプトインジェクションは、入力や外部資料に含まれた指示によって、本来の依頼や制約から外れる動作へ誘導される問題です。例えば公開案内の要約中に、資料の文が別の記録の取得や送信を求める場合です。資料として読む文章と、権限のある人が与えた依頼を分けます。外部にある命令形の文を、どれも実行する指示として扱いません。

情報漏えいは、許されていない相手や場所へ情報が渡ることです。読取だけの道具でも、得た非公開の内容を回答や外部送信へ混ぜれば、影響は読む段階だけに収まりません。入力として受け取る範囲、道具で取得する範囲、出力や送信先をつなげて確かめます。ここでは公開案内と模擬の内部メモを区別する架空例で考えます。

根拠：OWASP LLM01 Prompt Injection（別タブで開く） ↗ / OWASP LLM06 Excessive Agency（別タブで開く） ↗ / A2A specification（別タブで開く） ↗

異なる段階で、異なる点を確かめる

多層防御は、一つの対策に頼らず、複数の段階へ異なる確認や制限を組み合わせることです。外部資料を依頼と分ける、必要な権限へ絞る、実行直前に対象や値を検査する、出力の範囲を確かめる、といった役割を重ねます。同じ誤りが別の確認もすり抜けることがあるため、数を増やしただけで安全とはしません。

ガードレールは、入力・出力・道具の利用などへ確認や制限を組み込み、問題のある処理を止める仕組みです。自動の検査をどこで行うかも重要です。送信後に対象外と分かる検査だけでは、その送信自体を防げません。名前の付いた検査があることと、必要な全段階で実際に働くことを分け、確認できない場合の停止や人への戻しも用意します。

根拠：OWASP LLM01 Prompt Injection（別タブで開く） ↗ / OWASP LLM06 Excessive Agency（別タブで開く） ↗ / OpenAI Docs Guardrails and human review（別タブで開く） ↗

人に見せる内容と、止めた後を決める

Human-in-the-Loopは、人が途中の確認・修正・承認などに関わる構成です。例えば送信前に、誰へ何を送るか、根拠や未確認は何かを人へ示します。「承認」の表示だけでなく、判断できる内容を見せることが必要です。人が確認できなければ止める条件も決めます。人も誤り得るため、人の確認だけを唯一の防御にしません。

止めたら、どの処理を止め、何が実行済みか、何が未確認かを残して担当者へ渡します。実行前の拒否、実行後の失敗、結果不明は別です。未確認を成功や未実行へ置き換えません。必要な範囲へ絞り、原因を調べて直し、条件を満たす動きかを試してから、権限のある人が再開を判断する流れを用意します。止めたという事実だけで解決済みとはしません。

根拠：OpenAI Docs Guardrails and human review（別タブで開く） ↗ / OWASP LLM01 Prompt Injection（別タブで開く） ↗ / OWASP LLM06 Excessive Agency（別タブで開く） ↗ / NIST AI100-1 AI RMF1.0（別タブで開く） ↗ / A2A specification（別タブで開く） ↗

一つの点数で、別の失敗を隠さない

架空の試験で文章の形式が3件とも整っていても、1件で許可外の保存先への書込みが実行されたという記録があれば、「形式が整う」という評価と「許可を守る」という評価は別の結果です。平均点だけで重大な失敗を見えなくしません。決めた条件に反した例を調べ、直した後にその例と関連する通常例を再び確かめます。合格は、与えた条件と試した範囲での結果です。

根拠：OpenAI Docs Evaluation best practices（別タブで開く） ↗ / NIST AI100-1 AI RMF1.0（別タブで開く） ↗

運用中の変化を見つけ、対応と再評価へ戻す

継続的なモニタリングは、実際の利用中の動きや失敗、条件の変化を観察し続けることです。ログは、いつ、何を対象にどの操作を行い、どんな結果になったかなどの記録です。許可外の要求、拒否や失敗、予想外の出力を確認できるようにします。必要な範囲を決め、秘密情報をむやみにログへ増やしません。自然な完了文だけを、実際の操作の記録にはしません。

例えば公開用の下書きへ模擬の内部メモが混じったら、影響する公開処理を保留し、分かったことと未確認の影響を記録して担当者へ渡します。原因となった資料・設定・道具の変化を調べ、必要な修正と利用範囲の見直しを行います。外へ出たか不明なら、出ていないと仮定して終わらせません。対応先、停止する範囲、再開を判断する人を決めておきます。

道具、資料、モデル、許可設定などが変われば、過去の評価と違う条件になり得ます。見つけた事例を評価へ加え、修正後の結果と必要な人の確認をそろえて再開を判断します。Evalは決めた例で確かめる役割、監視は利用中の変化を見つける役割です。互いに情報を戻して改善しますが、評価に合格したことや、監視で異常が見つからなかったことを、将来の全事故がないという保証にはしません。

根拠：NIST AI100-1 AI RMF1.0（別タブで開く） ↗ / A2A specification（別タブで開く） ↗ / OpenAI Docs Evaluation best practices（別タブで開く） ↗