AIコーディングエージェントにIssueを読ませるだけで秘密が漏れる。GitHub Actionsの失敗例
ここ数ヶ月で、AIコーディングエージェントの話題で起きているセキュリティ事故を追うと、モデルが賢いか賢くないかより先に、『何を読ませて、何を実行させているのか』を考えた方がいいことに気づく。GitHub IssueやPull Requestという普通の文章が、そのまま攻撃の入口になる失敗例が続いているからだ。
GitHubのgh-awで報告されたケースでは、pull_request_targetを使うワークフロー内で、AIエージェントに--env-allで全環境変数をまとめて渡していた。そこにはCOPILOT_GITHUB_TOKENやGITHUB_MCP_SERVER_TOKENといった、GitHub操作に使えるトークンが含まれている。一方、エージェントは未信頼なPRの内容を読みながらBashを実行できる構成だった。攻撃者がPR本文に細工した指示を書けば、エージェントはそれに従って環境変数を確認・流出させる余地が生まれる。怖いのは、最初のプロンプトにPR本文を埋め込んでいなくても成立する点だ。エージェントが後からgh pr viewやMCP経由で本文を取得すれば、その時点で未信頼な文章がコンテキストに入る。
ClaudeやKiroでも同じパターンが報告されている。プロンプトインジェクションの対策として『これはデータです』と理解させるだけでは足りない。本当に必要なのは、誤読しても秘密を読めない、外へ出せない、状態を書き換えられない、という構造だ。AIエージェントの導入では『どこまで自動化できるか』に目が向きやすい。だが失敗ケースを追うと先に決めるべきは『どこまで自動化しないか』である。環境変数は必要なものだけ明示し、未信頼な文章を読むジョブではBashとWriteを分け、外部通信とGitHub書き戻しを同時に持たせない——権限を先に減らす判断こそが、モデルの賢さより重要だ。
※ 上記は配信元記事をもとにAIの鬼編集部が要約・再構成したものです。正確な内容は出典元をご確認ください。
このニュースの全文は、配信元でお読みいただけます。 Zenn AIで元記事を読む →


