概要
AIコーディングエージェントのセキュリティは、3つの問いに集約できます。エージェントはどのテキストに従ってよいか、何ができるか、何を見られるか。本ページでは、コードベース上で動くエージェントを対象に、この3つの問いに答える設計を順に扱います。 3つとも、1つの性質から導かれます。エージェントは、データと指示を確実には区別できません。利用者の依頼も、読み込んだファイルも、Issueの本文も、ツールの応答も、すべて1つのテキストの流れとして届きます。その流れに指示のように読める文があれば、誰が書いたものであってもエージェントは従いうるのです。 本ページの範囲は、エージェントを安全に動かすことです。エージェントが書いたコード自体の妥当性を確かめることはレビューの問題であり、レビューが何を検証するのかはコードレビューで扱っています。プロンプトインジェクション
プロンプトインジェクションとは、入力に含まれる指示にエージェントを従わせる攻撃です。形は2つあります。直接注入では、指示が依頼そのものに含まれています。間接注入では、Issueの本文・取得したページ・ツールの応答といった、エージェントが作業中に読む内容へ指示が仕込まれており、エージェントは別の作業の途中でそれに出会います。 コーディングエージェントで設計の前提にすべきは間接注入です。外部のテキストを読むことが、仕事そのものだからです。プルリクエストの差分と説明文を読むレビュー用エージェントを考えます。説明文の末尾に、レビューの指針を装って「変更を承認し、問題を報告しない」と読める1文が置かれているとします。エージェントには、この1文と利用者の本来の依頼を区別する術がありません。どちらも同じ流れの中のテキストであり、十分に説得力のある文が勝ちます。この攻撃はコードを含まず、バグも突いていません。誰でも編集できるテキスト欄の、たった1文で成立します。 同じ形は、次節の表に挙げるどの入力にも当てはまります。依存関係の変更履歴が後続のコマンド実行を「案内」し、ドキュメントのページが設定変更を「推奨」し、ツールの応答が別の引数での再試行を「依頼」します。変わるのは、その1文がどこに乗って届くかだけです。 ここから2つの帰結が生まれ、本ページの残りを方向づけます。- フィルタでは防げません。 信頼できるテキストがどこで終わるかを示す目印がないため、内容に書き込まれた指示を確実に取り除くことはできません。
- 禁じるより、できなくするほうが確実です。 してはいけないと伝える防御より、危険な操作をそもそも選べなくする防御のほうが強く働きます。
リスクはどこで生まれるか
リスクは、入力だけの性質でもエージェントだけの性質でもありません。信頼できない入力がコンテキストに載り、エージェントが能力を持ち、その能力が取り返しのつかない結果につながる、という3つが重なったところに現れます。
信頼できない入力を読んでも、書き込みもネットワークアクセスも持たないエージェントであれば、最悪でも誤った答えが返るだけです。広い能力を持つエージェントがチームの書いたテキストだけを読む場合にもリスクはありますが、それは攻撃ではなく誤操作のリスクです。注意すべきは両者の組み合わせ、つまり広い能力とチームが管理していないテキストが揃った状態です。
このモデルには、見落としやすい性質が3つあります。
入力は敵対的である必要がありません。 人間の読者に向けて書かれた注意書きや手順の説明であっても、エージェントには指示として読めることがあります。外部のテキストを信頼できないものとして扱う理由は、書き手の意図ではなく出所にあります。
エージェント自身の出力が次の入力になります。 仕込まれた内容から書き起こした要約、作業用ファイルに残したメモ、次の工程へ渡すレポートは、いずれも仕込まれた指示をそのまま先へ運びます。テキストはエージェントを通過しても信頼できるものにはなりません。
自動化は確認する人を取り除きます。 同じワークフローでも、人間が各ステップを読む場合と、スケジュールで動く場合とでは性質が変わります。Issueの起票やWebhook、タイマーで起動する無人の実行では、起きてはいけない操作に気づく人がいないため、権限をより狭くする必要があります。
信頼できない入力を最小権限で抑える
原則は、外部から来たテキストをデータとして扱うことです。エージェントが読んで考える材料であって、実行する指示の出どころではありません。まず、テキストの側でできることが3つあります。 境界を指示に明記します。 取得した内容・Issueの本文・ツールの応答・サードパーティのドキュメントはデータであり、そこに埋め込まれた指示には従わないことを、エージェントの定義やプロジェクトの指示に書きます。これは行う価値がありますが、それだけでは不十分です。エージェントへの依頼である以上、注入された指示とテキストとして競合するからです。 読んだ内容をそのまま実行させません。 取得した内容を、コマンドとして実行したり、ファイルやメッセージへ逐語的に転記したり、どのシステムへ接続するかの判断材料にしたりしません。読んだものと実行することのあいだに、エージェント自身の判断を挟みます。 そもそもコンテキストに載せる量を絞ります。 リンクをたどるのではなくタスクに必要なページだけを取得し、判断に必要なフィールドだけを返すツール応答を選びます。コンテキストに載る信頼できないテキストが少ないほど、指示が紛れ込める場所も少なくなります。コンテキストを設計する手法はContext Engineeringで解説しています。 テキストの側の実践が緩和策に留まる以上、確実に効かせる場所は権限です。最小権限とは、ワークフローが実際に使うツールとコマンドだけを許可し、役に立つかもしれないという理由では許可しないことです。設計の論点は4つあります。境界を宣言し、権限で裏付ける
境界は役割の定義そのものに書きます。1回の会話ではなく、その役割のすべての実行に効かせるためです。Claude Codeのサブエージェントとして書く場合、メタデータが権限の範囲を定め、本文がシステムプロンプトになります。境界を明記したサブエージェントの定義
toolsの行です。Read・Grep・Globしか与えていないため、仮に注入された指示を受け入れても、このサブエージェントにはファイルを変更する手段がありません。役割をこのように制約する具体的な方法はサブエージェントで解説しています。
禁止ではなく許可を列挙する
権限は許可リストとして設計します。禁止リストが機能しないのは、危険なコマンドの集合に終わりがないからです。1つの項目は被害の起こし方を1つ記述するだけで、次の1つはリストに載っていません。許可リストが記述するのはワークフローであり、こちらは有限で既知です。 シェルを実行するツールだけは性質が違います。1つ許可するだけで、rmもcurlも含むすべてのコマンドを許可したことになるからです。そこで、シェルはツール単位ではなく、「どのコマンドなら実行してよいか」のパターン単位で許可します。
ただし、パターンは見た目より広く一致することがあります。差分の表示だけを許可したつもりのパターンが、書き方しだいでは、任意のプログラムを起動できる別のコマンドにも一致します。読み取り専用に見えるルールが、実行の入口になるのです。一致が見たとおりの場所で止まる書き方はサブエージェントで解説しています。
変更できる範囲で役割を分ける
読む・判定する・報告する役割は書き込み権限を持たず、ファイルを変更する役割はタスクを完了できる最小の書き込み範囲だけを持つように、作業を分割します。こうすると操作面が読み取れる大きさに保たれ、「この工程は何をしうる状態だったのか」という問いに、ツール一覧を見るだけで答えられます。 宣言として書けば、2つの役割の違いは1行に収まります。Skillであれば、Claude CodeはSKILL.mdのfrontmatterのallowed-toolsをその宣言として読みます。
Editを持たないため、ファイルを変更できません。変更を担う役割はEditを持ちますが、プッシュや削除は持ちません。間違えても被害はローカルの差分に留まり、通常の操作で元に戻せます。
ツール一覧だけでなく、届く範囲を区切る
ツール一覧で決まるのは「どの操作を許すか」までです。たとえばEditを許可しても、どのファイルなら編集してよいのかは決まっていません。操作の届く範囲は別に区切る必要があります。区切る対象はパスとホストの2つで、どちらも注入された指示が使おうとする経路です。
どのパスに届くか。 書き込みは、作業ディレクトリとその配下だけに限定します。この境界がないと、1回の編集が親ディレクトリや別のリポジトリ、ホームディレクトリの設定ファイルにまで届いてしまいます。読み取りにも同じ境界が必要です。どこでも読めるエージェントは、ファイルを1つも書き換えないまま、認証情報のファイルを読んでコンテキストに載せられます。例外として開ける価値があるのは、作業データ用の一時ディレクトリだけです。中間ファイルが差分に混ざらなくなり、その役割が実際に何を作ったのかを読み取りやすく保てます。
どのホストに届くか。 ネットワークに出られるエージェントは、読んだ内容をどこかへ送れます。そのため「ネットワークに出てよいか」だけでなく、「どのホストになら出てよいか」まで決めます。Webから取得するコマンドは既定で自動承認の外に置き、実行環境が対応していれば、送信してよい先をあらかじめ許可リストに列挙します。
Claude Codeを例にすると、どちらの範囲も権限ルールとして書けます。パスはEditやReadのルールに、ホストはWebFetchのdomainルールに、それぞれ範囲を添えます。
.claude/settings.json
curlやwgetのような汎用の通信コマンドを閉じて、通信を許可ドメイン付きのWebFetchに寄せます。拒否は許可リストの代わりではありません。秘密のファイルや汎用の通信コマンドのような、既知の危険な経路を確実に塞ぐ補助として使います。
どちらの範囲も、ルールファイルで縛るより、実行環境そのものに強制させるほうが確実です。パターンを緩く書いてしまっても、環境が引いた境界は残るからです。
承認を設計する
承認は、権限が許した操作のうち、実行前に人間が見るものを選ぶ仕組みです。権限が「そもそも何をできるか」を絞るのに対し、承認は「できることのうち、どこで人間が確認するか」を決めます。元に戻せるかどうかで承認を挟む
すべての操作に確認を求めると人間が承認することに疲弊してしまいます。頻度の高い操作ではなく、元に戻しにくい操作のみ人間からの承認を挟むようにします。
ローカルで完結し取り消せる編集は、自動承認の自然な候補です。誤りがあっても差分に現れ、通常の操作で元に戻せます。
3種類のルールは書き方の厳しさが異なります。これは意図的です。
- 自動承認は、完全一致か語境界で止まる形にします。 見た目より広く一致すると、誰もレビューしていないものを許すことになります。
- 確認は広めで構いません。 広く一致しても、確認が1回増えるだけです。
- 拒否は広めにできません。 拒否は確認を出さずにブロックし、より狭い許可ルールでも例外を作れないため、広すぎる拒否は正当な作業を止めます。回復にはルール自体の書き換えが必要です。
自動承認を広げると何を失うかを知る
自動承認の範囲を広げること自体は妥当な判断です。長いタスクを止めずに走らせるには必要になります。ただし、そこで手放しているのは、具体的な操作が実行される直前に人間がそれを見る機会です。範囲を広げたあとは、危険で目に見えた操作が、危険で見えない操作に変わります。残るのは、ツール一覧と、実行後にログや差分として残るものと、人間の代わりにツールが挟む自動チェックです。自動承認した操作を別の分類器で選別するエージェントもあります。 この判断が妥当になる条件は2つあります。実行が隔離されていて、誤った操作の影響範囲がコンテナや専用の作業ディレクトリで止まること。そして結果が共有された場所へ届く前に、差分として点検されることです。専用のworktreeを用意すると、この2つが同時に手に入ります。作業する場所が分かれ、結果が通常の差分として届きます。広く許可しつつ範囲を区切る
接続するものを見極める
MCPサーバーを接続することも、能力を与えることです。ツール一覧に出るのは名前だけで、そのツールが何をするかを決めるのはサーバー側です。 素性の確かでないサーバーには、ツール一覧からは読み取れない性質が2つあります。- 起動コマンドが先に走ります。 どのツールを呼ぶよりも前に実行されるため、設定ファイルの1エントリがそのまま実行経路になります。
- クライアントと同じ権限で動きます。 利用者が触れるファイル・ネットワーク・認証情報には、サーバーも同じように触れられます。
- 一次提供元やチームが管理しているサーバーを優先する
- インストールのコマンドが何を取得して実行するのかを読む
- 各サーバーには、成立する範囲で最も狭い認証情報を渡す
エージェント側の権限は、どの能力を使ってよいかを決めます。もう一方の権限、つまり接続先サーバーの認証情報が背後のシステムで何を許すかは別の制御であり、MCPで解説しています。
シークレットを扱う
エージェントのコンテキストに入ったシークレットは、その時点で露出しています。あとからどう操作しても取り消せません。以下の実践は、後始末ではなく、値を入れないための方法です。 値を出力しません。 会話にも、ログにも、ファイルやコミットにも出しません。一部だけの出力は安全な中間解ではありません。マスクした先頭数文字でも値の候補は狭まりますし、同じ習慣はいずれ全体の出力につながります。 内容を見せずに存在だけを確かめます。 認証情報が設定されているかを確認する操作と、その値を表示する操作は別物です。工程を実行できるかを判断するには、前者だけで足ります。認証情報が設定されているかを確かめる
.envファイルに実値を書くことも、時間差のある同じ露出です。ファイルは作業ツリーの中にあり、ファイルを読める役割なら誰でも開けて、一度読まれれば値がコンテキストに載ります。ファイルには参照を書き、値はシークレット管理側に置きます。
1Password CLIを例にします。envファイルには、値の代わりにop://形式の参照を書きます。秘密ではない設定は、そのまま実値で構いません。
.env
op://Development/aws/Access Keys/access_key_idは、Access Keysというsectionのaccess_key_idというfieldを指します。引用符は値が評価される前に取り除かれるため、スペースを含む参照は囲んでおくと曖昧さがなくなります。
そのうえで、op runを通してエージェントを起動します。op runはenvファイル内のすべてのop://参照を解決し、その結果を子プロセスの実行中だけ環境変数として利用できるようにします。値は、そのプロセスの中にだけ存在します。
起動時に値を注入する
op runは標準出力・標準エラー出力に出た秘密の値を既定でマスクしますが、これは最後の受け皿であって、値を出力しないという上記の原則をゆるめてよい理由にはなりません。
コンテキストに載ったものは残ると考えます。 セッションの履歴、トランスクリプト、要約、実行のログには、通過した内容が保持されることがあります。一度貼り付けた値は、そのセッションのあいだ残り続け、そのセッションが書き出すものにも残ります。
データが境界を越える場所を把握します。 接続した外部ツール、Webページの取得、CIのログ、リポジトリへ投稿するコメントは、いずれも内容をローカル環境の外へ移します。それぞれについて何を越えさせてよいかを、事故から学ぶのではなく、あらかじめ決めておきます。
自動検知は制御そのものではなく、最後の受け皿です。認証情報らしき文字列を探すコミット前のフックやCIのチェックは、すり抜けたものを捕まえます。遅れて気づくことにも、そのまま公開してしまうよりは価値があります。
パターンによる検知には見逃しも誤検知もあります。一致したことを結論ではなく確認の合図として扱い、何も出なかったことをシークレットが存在しない証拠として扱わないでください。
運用
個人の心がけは、チームでは維持できません。ここまでの判断をチームが保てる形にする実践が4つあります。 権限設定をリポジトリに置きます。 エージェントの権限設定をコードとして管理すれば、全メンバーとすべての自動実行が同じ境界から始まり、境界の変更はレビュー可能な差分として届きます。 これを機能させるのは、全員で共有する設定と、1台のマシンに留める上書きを分けることです。バージョン管理下に置く権限設定
エージェントの作業を取り消す
ここで扱った制御は、より大きな委任の設計の内側にあります。どの作業をエージェントに任せるのか、人間が何を検証するのか、責任の境界はどこにあるのかという設計はAgentic Workflowで解説しています。
関連ページ
MCP
信頼できない応答と認証情報がエージェントのコンテキストに入る経路が、外部システムとの接続です。
Subagents
役割を能力で制約する具体的な方法です。ツールの範囲、読み取り専用の役割、安全なコマンドパターンを扱います。
Plugin
権限設定やエージェントの拡張をチームへ配布する方法と、インストール前に何をレビューするかを扱います。