AIエージェント開発

Copilot CLIのプロンプトインジェクション|止め方【2026年10月】

Copilot CLIのプロンプトインジェクション|止め方【2026年10月】

この記事の結論

GitHub Copilot CLIがAutopilotで外部の指示に従い、.envなど秘密情報を外部送信できると研究者が2026年10月に実証。何が条件で、どの公式設定で止まるかを一次情報で整理します。

2026年10月9日時点で、GitHub Copilot CLIは、Autopilot(自動実行)で外部の細工されたページを読むと、ローカルの.envなどの秘密情報を読み出して攻撃者のサーバーへ送ってしまう場合があります。AIセキュリティ企業のAdversa AIが2026年10月6日に実証結果を公表しました。デモでは.env.prodファイルの中身が28秒で外部に送られ、画面にはファイルが外に出たことを示す表示は出ませんでした。成立には2つの条件(CLIがAutopilotで動いていること、指示を実行してしまうモデルに当たること)が必要で、だれでも1クリックで踏む穴ではありません。GitHubは2026年10月1日時点で、この報告を「利用者が自分で外部の内容を読むよう指示した」として製品の脆弱性とは扱っていませんが、同じ手口は2026年10月1日時点でも再現する、と研究者は述べています(Adversa AIの検証)。この記事は、何が条件で、どの公式設定で止まるかを、公式ドキュメントで1つずつ確かめて整理します。

この記事の要点(2026年10月9日時点)

  • Adversa AIが「Cryptographic Context Injection(CCI)」と名づけた手口。暗号で隠した指示をエージェント自身に復号させ、復号後の文を自分の指示として扱わせる、という考え方です。
  • 成立の条件は2つ。Copilot CLIがAutopilotで動いていること、そして指示を実行してしまうモデルに当たることです。Autopilotで外部ページを読む最初の指示のあとは、追加の操作は要りません。
  • Adversaの検証では、当たったモデルによって結果が変わりました。安全側に倒すモデルは同じ入力を拒否しています。Auto(自動選択)では、どのモデルが担当したかは利用者に見えません。
  • GitHubは「利用者が外部の内容を読むよう指示した」として脆弱性とは認めず、報奨金の対象外としました。将来、動作を厳しくする可能性には触れています。
  • 止め方はモデル任せにしない。Autopilotを常用しない・ツールの許可を最小にする・URLとネット送信を絞る・ローカルサンドボックスで隔離する、の4方向が公式ドキュメントにあります。

対象読者:Copilot CLI・Codex・Claude Codeを日常で使う開発者と、開発端末のルールを決めるリード・情シス担当。

読み終えたらできること:自分の端末で何が起き得るかを把握し、Autopilotの扱い・ツール許可・ネットワーク・サンドボックスの設定を今日見直せます。

何が実証されたか|Copilot CLIのAutopilotで秘密情報が外部に出た

AIセキュリティ企業のAdversa AIは、2026年10月6日に、GitHub Copilot CLIに対する攻撃手法「Cryptographic Context Injection(CCI、暗号を使った文脈の注入)」の検証結果を公表しました。筆者はRony Utevsky氏です。報告によると、Copilot CLIをAutopilot(自動実行)で動かし、攻撃者が用意したページを読ませると、エージェントがローカルの.env.prodファイルを読み取り、その中身を攻撃者のサーバーへ送った、とされています。デモでの所要は28秒で、画面にはファイルが端末の外に出たことを示す表示は出なかった、と研究者は書いています。

図: 利用者の指示でCopilot CLI(Autopilot)が外部ページを読み、ローカルの秘密情報を読み取って攻撃者のサーバーへ送信する全体像。画面に外へ出たことを示す表示は出ない

これはCopilot CLIに固有の新種ではなく、同社が2026年8月にGrok(チャット型のアシスタント)で示したのと同じ考え方を、コードを扱うエージェントに当てた事例です。Adversaは「コードの実行とネットへの送信がふだんの動作であるコーディングエージェントは、チャット型より影響が大きい」と位置づけています。時系列を、一次情報と報道で確認できた範囲で整理します。

日付(2026年) できごと 主体・出典
8月 同じ手口(CCI)をGrokで公表 Adversa AI
9月17日 GitHubの報奨金プログラムへ報告 Adversa AI
10月1日 GitHubが「脆弱性ではない」と判断(報奨金の対象外)。同日時点で手口は再現すると研究者 Adversa AI
10月6日 Copilot CLIでの実証を公表。The Registerなど海外メディアが報道 Adversa AI/The Register
10月7日 国内メディアが報道 innovatopia ほか

Adversaは「具体的なペイロード(攻撃に使う文字列)は、悪用を避けるため公開しない」と明記しています。本記事も、手口の流れは守りの観点で大づかみに説明するだけにとどめ、再現の手順や使えるコードは載せません。読者が必要なのは「どういう形の動きが危ないか」を見分ける目と、「どの設定で止まるか」です。

手口の流れ|細工したページを読ませてから外部送信まで

守る側が覚えておくべきは、個々の文字列ではなく「動きの並び(シーケンス)」です。Adversaの説明とThe Registerの報道をもとに、流れを5つの段階で大づかみに示します。細かい復号の仕組みや鍵の作り方には踏み込みません。

図: 外部ページを読む→暗号で隠した指示→ローカルの秘密情報を読み出す→別のURLを取りにいく→攻撃者側へ届く、の5段階の流れ。画面に送信先の記録が残らない

流れは、おおむね次のように進みます。(1) 利用者がAutopilotのCopilot CLIに、外部のあるページを読むよう頼む。(2) ページには、暗号で隠した指示と「これを復号して」という誘導が置かれている。(3) 復号の準備の過程で、エージェントがローカルの秘密情報を読み出す。(4) 復号後に現れた指示が、別のURLを取りにいくよう促す。(5) そのURLへの通信に、読み出した中身が乗って攻撃者側へ届く。Adversaは、画面に送信先や「ファイルが外に出た」ことを示す記録が残らなかった点を問題視しています。

なぜ暗号が鍵になるのか。入力の文字を読んで危険を止める仕組み(コンテンツ分類器)は、文字を「読む」だけで「実行」はしません。暗号文は実行時に復号されて初めて指示の形になるため、入力の段階の検査をすり抜けやすい、という理屈です。Adversaによれば、同じ内容を暗号にせず平文で渡すと、製品側は危険な指示として拒否したとのことです。つまり防御は、入力1つをふるいにかけるのではなく、「外部の内容を読み込んだ→コードが走った→ローカルのファイルを読んだ→関係のない宛先へ通信した」という並びをとらえる方向にあります。プロンプトインジェクションの基本については、当社のプロンプトインジェクション対策|エージェント多層防御5層でも整理しています。

成立する条件|Autopilotと「当たったモデル」の2つ

Adversaは「これは万能の1クリック攻撃ではない」と明言しています。成立には2つの条件が要ります。1つはCLIがAutopilot(自動実行)で動いていること。もう1つは、復号後の指示を実行してしまうモデルに当たることです。この2つがそろうと、外部ページを読む最初の指示のあとは、利用者の追加操作なしで進みます。

図: 「Autopilotで動く」と「実行するモデルに当たる」の2条件がそろうと成立する。Auto(自動選択)では担当モデルが見えないため、当たったモデルに頼らない

1つ目のAutopilotは、Copilot CLIでは既定ではありません。公式ドキュメントによると、Autopilotでは通常、作業を自律的に進めるために全権限を与えることになり、これは--allow-allと同じ状態です(Allowing GitHub Copilot CLI to work autonomously)。逆に言えば、Autopilotでも全権限を与えていなければ、承認が要る操作は自動では実行されません。The Registerは、Anthropicのコーディングツールでは自律モードが既定であるのに対し、Copilot CLIでは任意のままだ、と対比しています。

2つ目は「モデル抽選」と表現されています。Adversaの検証では、Copilot内で提供されるモデルのうち、ある1つは攻撃の連鎖を一定割合で実行し、ほかの2つのモデルは同じ入力を一貫して拒否しました。問題は、Auto(自動選択)にしていると、どのモデルがそのセッションを担当したかを利用者が選べず、見えないことです。公式のAutoモデル選択の説明では、Copilot CLIでは各応答に使われたモデルが端末に表示されるとされています(About Copilot auto model selection)。どのモデルが安全かはモデルの更新で変わるため、本記事では特定の製品名を「安全」と断定しません。守りの軸は「当たったモデルに頼らない」ことです。

GitHubの見解|「利用者が指示した」として脆弱性と認めず

Adversaは2026年9月17日にGitHubの報奨金プログラムへ報告し、GitHubの選別チームは報告内容を確認したものの、脆弱性としては扱わないと判断しました。理由は「利用者が自分でCopilot CLIに、攻撃者が用意した(信頼できない)内容を取得するよう指示し、自律的に動く全権限を与えていたため」というものです。GitHubは、将来この機能をより厳しくする可能性に触れつつ、発表できることは今はない、とし、この報告を報奨金の対象外としました。

GitHubの広報はThe Registerに対しても同じ趣旨を述べ、「GitHubはセキュリティ研究コミュニティの貢献を尊重し、報告された問題の調査に取り組んでいる。調査の結果、本件は利用者が意図的にCopilot CLIへ攻撃者由来または信頼できない内容の取得を指示し、その実行を確認することを要するため、製品の脆弱性ではないと判断した。製品そのもののセキュリティ問題ではないが、改善の機会は常に探している」とコメントしています。Adversaはこの評価に同意せず、連鎖は現時点でも説明どおり再現する、と反論しています。

この食い違いは、法人にとっては「ベンダーが直してくれるのを待つ話ではない」ことを意味します。GitHub自身が示している止め方は、利用者と組織の側で設定する防御です。次に、その公式設定を見ていきます。

公式設定で止める|許可・サンドボックス・URL・オフライン

GitHub Copilot CLIの公式ドキュメントには、この種のリスクを小さくする設定がそろっています。読むだけの操作は自動で許可されますが、URLへのアクセスやファイルの書き込みなど、影響のある操作は既定で承認を求めます(Allowing and denying tool use)。要点を表にまとめます。拒否のルールは許可より常に優先されます。

図: 公式設定で止める6つ。Autopilotを常用しない、許可を最小にする、allowedUrls/deniedUrls、ローカルサンドボックス、COPILOT_OFFLINE、limitTo(企業管理)

設定(公式) 効果 根拠(GitHub Docs)
Autopilotを常用しない・全権限を渡さない 承認が要る操作が自動では走らない。Autopilotは全権限付与時に--allow-all相当 Allowing GitHub Copilot CLI to work autonomously
--deny-tool/--allow-toolで許可を最小に ツール単位・サブコマンド単位で許可/拒否。拒否が常に優先。URLはurl(...)で指定 Allowing and denying tool use/command reference
--available-tools/--excluded-tools モデルが使えるツールの集合自体を絞る(例:web_fetch・web_searchを外す) Allowing and denying tool use
allowedUrls/deniedUrls(settings.json) 確認なしで触れるURL・常に拒否するURLを宣言。拒否が優先 CLI configuration directory
ローカルサンドボックス(/sandbox enable) ファイル・ネットワーク・認証情報へのアクセスをポリシーで制限。既定はオフ。2026年10月7日に一般提供 About cloud and local sandboxes/changelog 2026-10-07
COPILOT_OFFLINE=true web_fetchやWeb検索などネット系ツールを無効化(独自モデル利用時)。テレメトリも停止 Running in offline mode(BYOK)

ツールの許可は、コマンド起動時に指定できます。たとえばURLへのアクセスだけを止めたい場合は、拒否ルールを明示します。これらはすべて守りのための設定であり、攻撃に使うものではありません。

# URLへのアクセスを止める(拒否は許可より優先)
copilot --deny-tool='url'

# モデルが使えるツールからWeb系を外す
copilot --excluded-tools='web_fetch, web_search'

# セッション限定でOSレベルのサンドボックスを有効化
copilot --sandbox

ローカルサンドボックスは、対話セッション内で/sandbox enableで有効にします。既定はオフで、オフの間はCopilotが動かすコマンドが利用者と同じ権限で端末のどこでも読み書きでき、到達できるネットワークにも届きます。有効にすると、読み書きできるパス・到達できるホスト・認証情報の扱いを、自分が決めたポリシーに制限できます。ネットワークはallowedHosts/blockedHostsで宛先を絞れ、認証情報は実体の代わりにプレースホルダーをコマンドに渡し、許可した宛先にだけ本物の値を届ける仕組みがあります。公式の「リスク軽減」では、サンドボックスのほか、仮想マシンやコンテナ、権限とネットワークを絞った専用の環境でCopilot CLIを動かすことも挙げられています(GitHub Copilot CLI)。認証情報を守るサンドボックス側の考え方は、当社のClaude Code サンドボックスmaskモード解説や、Copilotアプリのローカルサンドボックスでも扱っています。

組織で一律にかけたい場合は、企業管理設定(managed settings)が使えます。permissions.disableBypassPermissionsModeを"disable"にすると、--allow-allや--yoloなどの全許可フラグが起動時に無効になります。permissionsのdeny・ask・allowでは、Domain(...)でネットワークの宛先を、Read(...)/Edit(...)でパスを制御できます。さらにlimitToで、許可した以外のドメインへのエージェントの通信をすべて拒否する「閉じた許可リスト」を敷けます。サンドボックスもsandbox.enabledとfailIfUnavailable・allowBypass:falseで必須化できます(Enterprise managed settings)。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "limitTo": ["github.com", "*.github.com"]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowBypass": false
  }
}

ただし、サンドボックスにも範囲の線引きがあります。公式には、開発ツールへのアクセス(allowDevToolAccess)が既定で有効で、パッケージ管理のキャッシュや設定ファイルに読み取りを許すため、そこにレジストリの資格情報が含まれることがある、と注意書きがあります。設定した気になって穴が残らないよう、/sandbox policyで実際のポリシーを確認するのが安全です。

開発端末で今日見直す5つ

ここまでの設定を、開発端末のルールに落とすと次の5つになります。研修や規定づくりの観点で、チームで合意しておくと事故の入口を減らせます。

図: 開発端末で今日見直す5つ。信頼する入口だけ、許可は最小・allow-allしない、秘密情報は環境を分ける、送信先を絞る、ログで後から追える

決めること 具体
信頼する入口だけ 信頼できないリポジトリ・Issue・Webページを、権限を持ったセッションでそのまま読ませない。読むなら権限を絞ったセッションか人の確認を挟む
許可は最小・allow-allしない Autopilotの常用と全権限付与を既定にしない。URLやネット送信は--deny-tool='url'などで明示的に絞る
秘密情報は環境を分ける プロジェクト直下に.envの実体を置かない。サンドボックスの認証情報マスクやシークレット管理の仕組みを使う
送信先を絞る サンドボックスのallowedHostsや企業管理のlimitToで、作業に関係ない宛先への通信を既定で拒否する
ログで後から追える 何を読んで、どこへ送ったかを後から確認できるようにする。要約の報告だけを信じない

エージェントに渡すシークレットそのものの管理は、当社のAIエージェントのシークレット・認証情報管理 運用ガイドでまとめています。MCPサーバー経由で外部の指示が混ざる経路は、MCP Tool Poisoning防御もあわせてご覧ください。

Codex・Claude Codeも同じ論点|未検閲の入力を信頼しない

この論点はCopilot CLIに限りません。外部の内容を読んで、コードを実行し、ネットへ送れるエージェントは、原理として同じ入口を持ちます。公式ドキュメントで、Codex(OpenAI)とClaude Code(Anthropic)の既定を見ておきます。ツールごとに表現は違いますが、方向は「未検閲の入力を信頼しない」「ネット送信を確認または遮断する」「サンドボックスやVMで隔離する」で共通しています。

ツール 関連する公式の既定・考え方
GitHub Copilot CLI 読むだけは自動許可。URL・書き込みは既定で承認。Autopilotで全権限を与えると自律実行。サンドボックスは既定オフ
Codex 既定でネットワークはオフ、OSのサンドボックスで作業領域に限定。Web検索は既定で「cached(索引)」にして未検閲の生ページへの露出を下げる。「プロンプトインジェクションは、エージェントに未検閲の指示を取得・実行させうる」と明記
Claude Code curl・wgetは既定で自動承認しない。WebFetchは多くの場合、生ページでなく別モデルの要約を返す。サンドボックスのネット隔離はallowedDomainsが初期は空。外部サービスに触れる作業はVM利用を推奨

Codexの運用については、公式の「Agent approvals & security」が、ネットワークとWeb検索を広げるときの注意(--yoloなどの全権限は推奨しない)を具体的に書いています。Claude Codeは「Security」で、どの防御も万能ではないと断ったうえで、未検閲の内容をそのまま流し込まない、提案されたコマンドを承認前に確認する、外部サービスを触るときはVMを使う、といった基本を挙げています。法人としての対策の全体像は、当社のプロンプトインジェクションとは|実例と企業の対策(Uravation)も参考にしてください。使い分けの前提として、ツールの比較はAIエージェントツール比較完全ガイドも合わせてどうぞ。

よくある質問

プロンプトインジェクションとジェイルブレイクの違いは何ですか?

OWASPの定義では、プロンプトインジェクションは入力でモデルの動作を意図せぬ形に変える手口の総称で、ジェイルブレイクはその一種として、モデルに安全上の決まりを完全に無視させるものを指します。今回のCCIは、外部のWebページから入る「間接プロンプトインジェクション」にあたります(OWASP LLM01)。

自分のCopilot CLIでも起きますか?

2026年10月9日時点の公開情報では、成立には「Autopilotで動いていること」と「指示を実行してしまうモデルに当たること」の両方が必要です。Autopilotを常用せず、全権限を既定で与えず、信頼できない外部ページを権限付きのセッションで読ませていなければ、この連鎖は進みにくくなります。

どのモデルを使えば安全ですか?

特定の製品名を「安全」と断定はできません。Adversaの検証では拒否したモデルもありましたが、モデルは更新で挙動が変わります。Auto(自動選択)では担当モデルが見えないため、「当たったモデルに頼らない」設計(許可の最小化・サンドボックス・宛先の制限)で守るのが確実です。

GitHubは修正しますか?

GitHubは2026年10月1日時点で、本件を製品の脆弱性とは扱わず、報奨金の対象外としました。将来、機能を厳しくする可能性には触れていますが、発表できる予定は示していません。待つのではなく、利用者と組織の設定で防ぐのが現実的です。

Autopilotを使わなければ問題ないですか?

Autopilotを使わず、影響のある操作ごとに承認する運用なら、外部ページ由来の指示が自動で実行されにくくなります。ただしプロンプトインジェクション自体はAutopilot固有ではないため、URLとネット送信を絞る・サンドボックスを併用する、といった備えは引き続き有効です。

CodexやClaude Codeは同じ問題がありますか?

原理としては、外部の内容を読み・コードを実行し・ネットへ送れるエージェントは同じ入口を持ちます。両ツールとも公式に「未検閲の入力を信頼しない」前提の既定(ネット既定オフや承認、要約経由、サンドボックス)を用意しています。設定を既定のまま弱めないことが大切です。

まとめ

2026年10月6日にAdversa AIが公表したのは、Copilot CLIをAutopilotで動かし、当たったモデルの条件下で、外部の細工ページから端末の秘密情報が外へ出うる、という実証です。GitHubは製品の脆弱性とは扱っていませんが、手口は2026年10月1日時点でも再現するとされ、同じ連鎖はCodexやClaude Codeでも原理的に起こり得ます。守りはモデル任せにせず、Autopilotを常用しない・ツールの許可を最小にする・URLとネット送信を絞る・ローカルサンドボックスやVMで隔離する、の4方向を公式設定で固めることです。まずは自分の端末で、Autopilotの扱いと--deny-tool・/sandbox・allowedUrlsの設定を1つずつ確認してください。

この記事を読んで、開発端末のルールづくりを進めたい方へ

Uravationでは、AIエージェントの安全な導入・運用の研修と設計支援を行っています。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る(無料)

参考・出典

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年10月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事