イシュー1件でサプライチェーンの端まで — CI内のエージェントが崩れた経路と、防御が実際に稼いだ時間

はじめに — イシュー本文が命令になる瞬間
舞台 — CI内のエージェントは何を握っていたか
ステップ1 — 「ボットなら通す」という一行
ステップ2 — データが命令になる場所
ステップ3 — 読み取り専用に見えるものが流出チャネルになる
爆発半径 — アクションのリポジトリ自身が同じワークフローを使っていた
これは仮説ではない — Clineで実際に起きた
同じ製品、別の扉 — インジェクションでなくても突破される
Anthropicが実際に投入した防御
正直な限界 — ベンダー文書自身が記していること
では、エージェントを作る人は何をすべきか
おわりに
参考資料

はじめに — イシュー本文が命令になる瞬間

2026年6月1日、GMO Flatt SecurityのRyotaKがPoisoning Claude Code: One GitHub Issue to Break the Supply Chainを公開しました。要旨はタイトルそのままです — GitHubイシュー1件で、Claude Code GitHub Actionsを使うリポジトリを乗っ取ることができ、その対象にはAnthropic自身のリポジトリも含まれていました。

前回の記事では、ウェブエージェントのクロスサイトプロンプトインジェクションを扱いました。あの記事が論文に基づく防御設計だったのに対し、今回は実際に出荷された製品で起きたことであり、タイムライン・CVSS・バウンティ金額・修正コミットがすべて公開されています。そしてもう一つ重要な違いがあります — 同じ欠陥系統が別の製品で実際に悪用されました。

この記事は攻撃レシピではありません。ペイロードは載せません。代わりに、エージェントを作るエンジニアに本当に必要なものだけを見ます — 信頼境界が正確にどこで切れたのか、ベンダーが入れた防御が何を防ぎ何を防げないのか、そして「ここまでで十分」と言える地点があるのかどうかです。

舞台 — CI内のエージェントは何を握っていたか

Claude Code GitHub Actionsは、Claude CodeをCI/CDに組み込むワークフローです。コードレビューの自動化、イシューのトリアージ・ラベリング、コメント駆動のコード生成といった作業を行います。動作モードは2つあります。

tag mode — イシューやPRコメントで特定のキーワード(デフォルトはClaudeへのメンション)が言及されるとトリガーされます。
agent mode — ワークフローにprompt入力が設定されているとトリガーされます。スラッシュコマンドや定型作業を回す際に使います。

GitHub上の操作を行うには、Claude GitHub Appがリポジトリにインストールされている必要があり、このアプリが持つ権限は次の通りです — リポジトリコンテンツ(コード)の読み書き、イシューとPRの読み書き、ディスカッションの読み書き、ワークフロー(Actions)の読み書き。別のトークンを指定しない限り、デフォルトでこのアプリのトークンが使われます。セットアップは簡単になり、攻撃対象領域は広がります。

ここですでに、Simon Willisonが言うところの致命的な三点セットが揃います — 非公開データへのアクセス、信頼できないコンテンツへの露出、外部と通信する手段。この3つが1つのプロセスに集まれば、インジェクション1発が流出につながります。CIランナーは教科書通りにこの3つを全部持っています。

ステップ1 — 「ボットなら通す」という一行

この危険を認識していたため、アクションはデフォルトで、書き込み権限のないユーザーがワークフローをトリガーできないようにしていました。ドキュメントの表現はこうです — アクションはリポジトリへの書き込み権限を持つユーザーのみがトリガーできる。

この制御はcheckWritePermissions関数に実装されていました。この関数はアクターの権限がwriteかadminかを確認します。ところが、その手前にこんな分岐が一つありました。

// src/github/validation/permissions.ts (修正前)
if (actor.endsWith("[bot]")) {
  core.info(`Actor is a GitHub App: ${actor}`);
  return true;
}

アクター名が[bot]で終わっていれば、実際の権限に関係なく無条件で通過します。一見合理的に見えます — GitHub Appは通常、リポジトリ管理者がインストールした信頼済みの主体だからです。問題は、その前提が公開リポジトリでは成り立たないことです。

GitHubのドキュメントが明記している通り、GitHub Appはデフォルトの権限がなくても、公開リソースを読む暗黙の権限を持ちます。そしてこの暗黙の権限は読み取りだけでは終わりません。公開リポジトリにイシューやPRを開くのに特別な権限は不要です — 誰でも他人のリポジトリにイシューを開けるのと同じように、GitHub Appも自身のインストールトークンで任意の公開リポジトリにイシューとPRを作成できます。対象リポジトリにインストールされている必要すらありません。

そうなると、迂回はこうまとめられます。攻撃者が自分のアプリを1つ作り、自分のリポジトリにインストールし(特別な権限は不要)、そのインストールトークンで対象の公開リポジトリにイシューを開けばいいのです。アクターがボットなのでcheckWritePermissionsはtrueを返し、ワークフローは攻撃者が制御する内容の処理を始めます。

ここで痛いのは、アクターの種類が実際にUserかどうかをGitHub APIで確認するcheckHumanActorチェックです。このチェックは、tag modeにはすでに存在していました。agent modeだけそれが抜けていました。防御がなかったのではなく、2つの経路のうち片方にしかなかったのです。

これが最初の教訓です。名前の形で信頼を判定するのはトラスト検査ではありません。 endsWith("[bot]")は「この主体は信頼できるか」を問わず、「この文字列はどんな形をしているか」を問います。そして文字列の形は攻撃者が選べます。

ステップ2 — データが命令になる場所

迂回に成功すると、次は攻撃者が制御するコンテンツがエージェントのコンテキストに入り込みます。RyotaKが挙げる具体例は、anthropics/claude-codeリポジトリのイシュートリアージワークフローでした。このワークフローはClaudeに対し、MCPツールでイシューを読み込むよう指示しており、許可ツールのリストにはこういったものがありました。

--allowedTools "Bash(gh label list),
                mcp__github__get_issue,
                mcp__github__get_issue_comments,
                mcp__github__update_issue,
                mcp__github__search_issues,
                mcp__github__list_issues"

mcp__github__get_issueで読み、mcp__github__update_issueで書きます。読み取りツールと書き込みツールが同じ許可リストに並んでいます。この組み合わせが、後に流出チャネルになります。

インジェクション自体の構造はこうです。攻撃者はイシュー本文をエラーメッセージのように見せかけて書きます。Claudeがそのイシューを読むと、読み取りが失敗したと認識し、「復旧」を試みる過程で本文に仕込まれたコマンドを実行してしまいます。データとして読ませたはずのものが指示として解釈される — インバンドシグナリングの古典的な失敗であり、SQLインジェクションとXSSがすでに証明してきたのと同じ構造です。ただしここでの経路は自然言語です。

研究者自身が脚注で正直に記している点が重要です — その説明だけではコマンド実行は安定してトリガーされず、実際のエクスプロイトははるかに精巧なプロンプトエンジニアリングを要したということです。つまり確率的です。しかしCIは、攻撃者が何度でもイシューを開けられる場所です。確率的な攻撃に無制限のリトライが付けば、決定論になります。

ステップ3 — 読み取り専用に見えるものが流出チャネルになる

コマンド実行が可能になれば、次は流出です。ここで2つのことが重なります。

まず、UXのためにClaude Codeは一部の読み取り専用コマンドを承認なしで実行できるようにしていました。RyotaKがその直前の記事(2026年1月12日)で掘り下げたのがまさにこの点です。echo、man、sed、sortといったコマンドがデフォルトで許可されており、副作用を防ぐために引数にブロックリストがかけられていましたが、そのブロックリストには8つの穴がありました。この件はCVE-2025-66032を割り当てられ、Claude Code v1.0.93で修正されました(NVD準拠、CVSS 3.1 9.8 / CVSS 4.0 8.7、CWE-77)。Anthropicの対応は、ブロックリストを撤去して許可リスト方式に切り替えることでした。研究者の結論も同じです — コマンド実行のようなセキュリティ上重要な機能で、ブロックリストは負けます。

次に、ランナープロセスの環境変数にシークレットが入っています。Linuxには現在のプロセスの環境変数をそのまま公開する疑似ファイルがあり、許可された読み取りコマンドでそれを読めば、シークレットがコンテキストに入ってきます。そのあとmcp__github__update_issueでイシュー本文に書き戻せば、攻撃者は自分のイシューを更新するだけで済みます。

ここで最終目標がなぜOIDC資格情報だったのかが重要です。GitHub Actionsは、ワークフローが自身の身元を証明するOIDCをサポートしています。ワークフローにid-token書き込み権限があれば、GitHubから「私はリポジトリYのワークフローXである」と署名されたトークンを取得できます。Claude Code GitHub Actionsはこの仕組みを使って特権のあるGitHub Appインストールトークンを取得します — OIDCトークンを取得し、Anthropicバックエンドのトークン交換エンドポイントに提出すると、バックエンドが検証してClaude GitHub Appインストールトークンを返します。

そのOIDCトークンを要求するのに必要な資格情報がACTIONS_ID_TOKEN_REQUEST_TOKENとACTIONS_ID_TOKEN_REQUEST_URLで、どちらも環境変数です。つまりこの2つが漏れれば、攻撃者はトークン交換の全過程をそのまま再現し、リポジトリコンテンツ・イシュー・PR・ワークフローへの書き込み権限を持つインストールトークンを手にします。リポジトリが奪われます。

爆発半径 — アクションのリポジトリ自身が同じワークフローを使っていた

ここまでは「リポジトリ1つ」の話です。サプライチェーン問題になる理由は別にあります。

anthropics/claude-code-action — アクションそのもののリポジトリ — も同じ系統のagent modeワークフローを使っていました。つまり同じ手法でアクションのソースに悪意あるコードを仕込むことができ、そうなれば依存するすべてのダウンストリームリポジトリに伝播します。ツールを作ったリポジトリ自身が、そのツールの脆弱性にさらされていたわけです。

RyotaKはこれに加えて、アクションのバグなしでも同水準の侵害に至るありふれた設定ミスをもう一つ見つけています。allowed_non_write_usersを*にすると誰でもワークフローをトリガーできますが、これがAnthropic自身のリポジトリと公式サンプルワークフローに入っていました。サンプルをコピーしたリポジトリは、同じ欠陥をそのまま引き継いでいました。

ドキュメントはこのオプションを危険と表示し、「極めて限定された権限を持つワークフローにのみ」使うよう求め、例としてイシューラベリングを挙げています。しかし研究者の反論は鋭いです。

イシュー書き込み権限は実は限定的ではありません — 既存のイシューを削除・編集できます。
このワークフローはどのみちAnthropic APIキーを要求します。それ自体が機微なシークレットであり、信頼できない入力にさらされる時点ですでに不適切です。
権限を絞っても流出は可能でした — アクションは完了した作業の要約をワークフロー実行のサマリーセクションにデフォルトで投稿しており、そのセクションは公開です。

そしてこの2つを組み合わせると権限昇格になります。緩いトリアージワークフローで(サマリーセクション経由で)イシュー書き込みトークンを手に入れ、そのトークンでトリガー後に信頼済みユーザーが投稿したイシューを編集し、厳格なtag modeワークフローにそれを信頼済みコンテキストとして処理させます。tag modeはid-token書き込み権限を持っているので、そこからOIDC資格情報が得られます。外部ユーザーからリポジトリの完全奪取まで、2つのワークフローの合成で到達します。

各ワークフローを個別に見れば、どちらも「意図通り」に動作しています。 欠陥は合成から生まれます。

これは仮説ではない — Clineで実際に起きた

ここまでは責任ある開示であり、実害はありませんでした(研究者は自分のテスト用リポジトリでのみ検証したと脚注で明かしています)。しかし同じ欠陥系統が、別の製品では実際に悪用されました。

2026年2月9日、セキュリティ研究者のAdnan KhanがClinejectionを公開しました。AIコーディングツールClineのイシュートリアージワークフロー — こちらもclaude-code-actionをベースにしており、Bash・Write・Editツールが開放されていて、任意のGitHubユーザーがイシューを開くことでトリガーできた — にプロンプトインジェクションが可能でした。脆弱だった期間は2025年12月21日から2026年2月9日までです。

チェーンが興味深いところです。トリアージワークフローから直接シークレットを抜くのではなく、GitHub Actionsのキャッシュを汚染してナイトリーリリース・npm公開ワークフローへ飛び移り、そこでデプロイ用の資格情報を盗みます。そしてそのナイトリー資格情報は、プロダクション資格情報と同じ権限を持っています — VS Code MarketplaceとOpenVSXは、トークンを拡張機能ではなくパブリッシャーに紐づけており、npmはプロダクションとナイトリーで同じパッケージを使います。ナイトリーは低格付けの資格情報だと想定されていましたが、レジストリの資格情報モデルはその区別をサポートしていませんでした。

公開までの経緯も記録に値します。Khanは2026年1月1日にGitHubの非公開脆弱性報告とメールで通知し、1月8日に追加のメール、1月18日にCEOへのDM、2月7日の最後の試みまで、応答を得られませんでした。2月9日の公開から1時間足らずで修正されました(PR 9211 — AIワークフローの削除、ナイトリージョブでのキャッシュ使用停止)。Clineは2月10日に公式に確認し即時の緩和策を発表、2月11日には全資格情報のローテーションと監査結果 — 2025年12月21日から2026年2月9日の間に無許可のリリースはなく、npmの41バージョンすべてがソースと一致 — を伝えました。

しかしその監査の対象期間は2月9日で終わっています。2026年2月17日、侵害されたnpm公開トークンによりcline@2.3.0が無許可で公開されました(GHSA-9ppg-jx86-fqw7)。正規版2.2.3との違いは、package.jsonにpostinstallスクリプトが1行追加されただけで、そのスクリプトは無関係なパッケージを1つグローバルインストールするものでした。悪意あるバージョンは太平洋時間で午前3時26分から11時30分まで、約8時間生き続けました(SafeDepの分析、2026年2月18日)。

ここで正直に示しておくべき点があります。

インストールされたパッケージは合法的で悪意はありませんでした。資格情報を盗んだりバックドアを仕込んだりはしていません。SafeDepの判断は、これが概念実証(proof of concept)に近いというものです — 実際のペイロードではなく実現可能性を示したもの。GHSAの深刻度評価もLowです。
ただし、同じpostinstallフックで資格情報窃取ツールやリバースシェルを同じように配送することもできました。ペイロードは無害でしたが、メカニズムは証明されました。
トークン窃取の正確な経路は公に確認されていません。SafeDepはそう明言しています。Khan自身は、自分のPoCを対象リポジトリではなくミラーで実行したと述べており、別の行為者がそのPoCを見つけてClineを直接攻撃し資格情報を得たようだと更新情報に記しています。
影響を受けたインストール数の具体的な数字はGHSAにありません。ここで作り出すことはしません。

教訓はそれでも明確です。ローテーションは、窓が閉じたと信じた瞬間に終わるわけではありません。 2月9日までを監査し、クリーンだと確認した組織で、2月17日に公開が行われました。Clineはその後トークンを失効させ、npm公開をOIDC provenanceに移行し、長期の静的トークンという攻撃対象領域そのものをなくしました。それが本当の修正です — トークンを再発行するのではなく、トークンをなくすことです。

同じ製品、別の扉 — インジェクションでなくても突破される

公平を期すために、一つ付け加える必要があります。同じアクションには、プロンプトインジェクションではない経路で同じ結果に到達する脆弱性も別に公開されています。GHSA-8q5r-mmjf-575q / CVE-2026-47751(2026年5月20日公開、深刻度medium、1.0.74未満に影響、CWE-78とCWE-200、HackerOneのreptouによる報告)です。

アドバイザリが説明する原因は3つの組み合わせです — PRのheadブランチをチェックアウトし(攻撃者が制御するコンテンツ)、デフォルトの設定ソースを通じて作業ディレクトリの.mcp.jsonを読み込み、プロジェクトのMCPサーバーをすべて無条件に有効化する設定が有効になっていたこと。その結果、悪意ある.mcp.jsonを含むPRを開いた攻撃者はランナー上で任意のコードを実行でき、特権を持つユーザーがそのPRでアクションをトリガーすると、ワークフローの持つシークレット(APIキーとトークン)が漏洩し得ました。

ここではモデルは何も騙されていません。エージェントの設定そのものが攻撃者の制御下にありました。 そして原因の形は前の事件とまったく同じです — PRをチェックアウトするのはレビューする以上当然、設定ファイルを読むのも、プロジェクトのMCPサーバーを有効にするのも、3つの決定はそれぞれ単独で見れば合理的なのに、3つが出会う場所で欠陥が生じます。

これが3つ目の教訓です。インジェクション対策だけに集中すると、この系統をまるごと見逃します。信頼できないリポジトリのコンテンツは、プロンプトだけでなく、設定・依存関係・ビルドスクリプトとしても入ってきます。 エージェントが読むものはすべて入力であり、設定ファイルはその中でも最も強力な入力です。

Anthropicが実際に投入した防御

RyotaKはAnthropicの対応を非常に迅速だったと評価しています。タイムラインはこうです — 2026年1月12日に権限迂回を報告、1月16日に修正(4日間)、1月17日に設定ミスを報告、2月から4月にかけて複数回の追加緩和と後続の迂回、6月1日に公開。設定ミスの件はClaude Code GitHub Actions v1.0.94で整理されました。AnthropicはこれらをCVSS v4.0基準で7.8と評価し、バウンティを支払いました(3,800ドルに迂回ボーナス1,000ドルを追加)。研究者の記事にはこの件のCVEやGHSA番号は出ておらず、筆者も見つけられませんでした — 後述のCVE-2026-47751は同じアクションの別の欠陥です。

投入された防御を性質別に分けるとこうなります。

本当の境界を直した対応。 GitHub Appがデフォルトでワークフローをトリガーできないようにしました(修正コミットは、agent modeのprepareステップにcheckHumanActor呼び出しを追加します)。そしてトリガー後に編集されたイシュー・コメントを処理しないようにして、ワークフロー合成攻撃を断ち切りました。この2つは信頼境界そのものを動かした修正です。

チャネルを閉じた対応。 ワークフロー実行のサマリーセクションをデフォルトで無効化し、公開の流出経路を一つなくしました。

速度を落とした対応。 残りはここに属します。Claude Codeが生成する子プロセスから環境変数をスクラブし、ghコマンドにカスタムラッパーをかぶせて引数を検証します。このラッパーがなぜ必要だったのかが、この記事で最も価値ある部分です — gh issue viewはイシューを読む、誰の目にも読み取り専用に見えるコマンドです。ところがgh CLIは位置引数としてURLを受け取ります。つまりインジェクションがシークレットの値をURLに乗せて送るようにすれば、「読み取り専用」のコマンドがそのまま流出チャネルになります。ラッパーはイシュー番号が数字1つであることを検査して、これを防ぎます。

これが2つ目の教訓です。ツールの流出能力は、名前ではなく引数の表面から生まれます。 任意のURLや任意のパスを受け取れるツールは、その名前がどれだけread/list/view的であっても、外部と通信する手段です。許可リストをツール名の単位で組むと、これを見逃します。

正直な限界 — ベンダー文書自身が記していること

ここからが、この記事を書いた理由です。通常、ベンダー文書は防御を誇張しますが、claude-code-actionのセキュリティ文書はそうしていません。だから引用する価値があります。

環境変数のスクラブについて、文書はこう記しています — ベストエフォート(best-effort)のスクラブであり、bubblewrapが利用可能なLinuxランナーではPIDネームスペース分離が追加される、しかし「これはプロンプトインジェクションのリスクを減らすが、なくしはしない」。だからワークフローの権限を最小限に保ち、すべての出力を検証するよう求めています。

静的トークンについては、さらに具体的です — 個人アクセストークンを使うな、静的トークンは実行間でローテートされないため「プロンプトインジェクションを通じて時間をかけて部分的または完全に復元され得る」。そして続く一文が圧巻です — 許可ツールを制限すれば「復元の速度を落とすが、リスクを排除するとは限らない」。

この表現を読み流してはいけません。防御が流出を止めるとは言わず、流出の速度を遅くする、と言っています。つまりモデルはこれを二値の境界ではなく漏出率として捉えています。トークンが十分長く生き、攻撃者が十分な回数試せば、結局すべて漏れます。だから処方箋が「トークンを守れ」ではなく「寿命の短いトークンを使え」なのです。

コンテンツの衛生処理も同じです。アクションはHTMLコメント、不可視文字、マークダウンの画像alt テキスト、隠しHTML属性、HTMLエンティティを取り除きます。そして文書はすぐに付け加えます — 「新しい迂回技術が現れる可能性がある」。だから外部コントリビューターからの入力は、Claudeが処理する前に元の内容をレビューするよう推奨しています。

ボットブロックにも残存リスクが文書化されています。allowed_botsで許可したボットはリポジトリ権限を検査しません。 公開リポジトリでは、誰でも作れるGitHub Appを含む外部主体がイシュー作成・コメント・PRレビューといったイベントを起こせ、ワークフローがそのイベントを待ち受けていてallowed_botsが*であれば、そうしたアプリは自分が制御するプロンプトでアクションを呼び出せます。つまり、元の脆弱性はデフォルトでは閉じていますが、オプション一つで再び開きます。

そして研究者自身の脚注が、これをすべて一文にまとめています。Claude Codeは環境変数の疑似ファイルへの単純な読み取りを緩和しますが、その緩和は「ハードルを上げる多層防御であってセキュリティ境界ではなく、より精巧な流出手法は依然として可能」。

測定された限界もあります。RyotaKは、Claude Codeの権限システムを迂回して任意コマンドを実行できる脆弱性について、執筆時点でAnthropicに約50件を報告したと述べています。彼の結論は控えめではありません — Claude Code周辺の権限モデルは、信頼できない入力を安全に扱えるほど堅牢ではない。だから彼は、権限がどれだけ狭くてもallowed_non_write_usersを一切使わないよう勧めています。

この数字は正しく読む必要があります。50件は「Claude Codeが特別にずさんだ」という意味ではありません。活発に研究され、迅速に修正される製品において、一人の研究者が単独でそれだけ見つけたという意味です。コマンドパーサーの上に載せた権限システムは、パーサーが完璧であって初めて成立しますが、シェルコマンドの解析は完璧にはならない種類の問題です。Willisonの言葉は今なお有効です — 私たちはまだ、これを100%の信頼性で防ぐ方法を知りません。

では、エージェントを作る人は何をすべきか

この事件から実際に持ち帰れる設計原則だけを抜き出すと、こうなります。

1. 信頼は主体の見た目ではなく、検証済みの属性で判定します。 文字列の接尾辞、ユーザー名のパターン、ヘッダーの値といったものは攻撃者が選べます。checkHumanActorのように発行元に問い合わせる検査こそが本物です。そして、その検査はトリガー経路のすべてに存在していなければなりません。片方の経路にしかない防御は、無いのと同じです。

2. 信頼できない入力を処理するワークフローにはシークレットを渡しません。 これが最も確実な一手です。インジェクションを防げないと仮定し、漏れるものがない状態を作ること。Anthropic APIキーですら機微だという指摘は、ここから来ています。

3. ツールの許可リストは名前ではなく引数の表面で組みます。 gh issue viewが流出チャネルになり得るという事実が、この原則を証明しています。任意のURL・任意のパス・任意のコマンドを受け取る引数があれば、それは外部と通信する手段です。Khanが Clineに勧めたことも同じです — トリアージワークフローにBash・Write・Editを渡すな。

4. ワークフローは個別ではなく合成でレビューします。 緩いワークフローと厳格なワークフローが同じリポジトリにあれば、攻撃者はその2つをつなぎ合わせます。キャッシュ、イシューの状態、アーティファクト — ワークフロー間で共有されるすべての状態が信頼境界です。Khanの勧告の一つが、これを正確に突いています — プロダクションのデプロイシークレットを持つワークフローでキャッシュを消費するな。リリースビルドでは、数分節約するよりも完全性のほうが重要です。

5. 非プロダクション資格情報が実はプロダクション資格情報でないか確認します。 Clineの件の核心はここでした。レジストリがトークンをパブリッシャーに紐づけているなら、ナイトリートークンはプロダクショントークンです。ネームスペースを分離するか、静的トークンそのものをなくしてOIDC provenanceに移行すべきです。

6. 防御を漏出率としてモデル化します。 ベンダー文書が「復元の速度を落とす」と書いているのを真剣に受け止めれば、設計が変わります。多層防御は攻撃コストを上げるものであって、攻撃を不可能にするものではありません。だから対になる対策は寿命短縮と爆発半径の縮小です。具体的には、寿命の短いトークン、範囲の狭い権限、そしてログです。RyotaKが読者に、ワークフロー実行ログで侵害の痕跡を確認するよう勧めているのも同じ理由です。

おわりに

この事件が特別なのは、新しい攻撃技術のせいではありません。むしろ全部が古いものです — 信頼検査の欠陥、インバンドシグナリング、ブロックリストの敗北、資格情報の範囲の誤解、ワークフローの合成。新しいのは、これらを一本につなぐ糸が自然言語だという点です。イシュー本文が命令になった瞬間、イシューを開けるすべての人が潜在的なCI実行権限者になります。

Anthropicの対応は速く誠実でした(4日間での修正、文書化された残存リスク、支払われたバウンティ)。Clineの対応は遅く、その遅延が実際の無許可公開につながりました。この2つの対比が語るのはプロセスの重要性であり、どちらかがインジェクションを解決したということではありません。誰も解決していません。 ベンダー文書自身がそう記しており、研究者が50件でそれを証明し、その間に実際の侵害が1件起きました。

だから、いまCIにエージェントをつないでいるなら、問いを変えたほうがいいでしょう。「インジェクションをどう防ぐか」ではなく、「インジェクションが成功すると仮定したら、このランナーから何が漏れ得るか」ということです。2つ目の問いには答えられます。1つ目の問いには、2026年7月現在、誰も答えられていません。