【重複購入のご注意】この記事は「AI開発者の手帖」がnoteで販売している同名記事（GitHub Actions でコーディングエージェントを安全に回す：信頼できない入力・トークンの権限・使えるツールを絞る点検表）と同じ内容です。すでにnoteで購入・閲覧できる方は重複購入にご注意ください。
GitHub Actions で Claude Code・Codex・Gemini CLI のどれかを動かし、issue やプルリクエスト、コメントに反応させている方、またはこれから入れる方に向けて書きます。特に公開リポジトリで使っている方に関係します。GitLab など GitHub 以外の CI、セルフホストランナーの隔離の設計全体、組織全体の Actions のポリシーの運用、GitHub Copilot のエージェントの設定、GitHub Agentic Workflows の使い方は対象外です（Copilot と Agentic Workflows は事例と比較にだけ出てきます）。
筆者は Claude Code などのエージェントの権限設定を公式資料と照らして追ってきました。本稿は、Anthropic の Claude Code GitHub Actions と claude-code-action のセキュリティ文書、OpenAI の Codex GitHub Action と codex-action のセキュリティ文書、Google の run-gemini-cli の信頼に関する指針、GitHub の Actions を安全に使うためのリファレンスと pull_request_target の安全な使い方を中心に、各研究者の報告と勧告を2026年10月5日に取得して突き合わせたものです。公式の記述と筆者の整理は分けて書きます。
何が起きたか
この半年で、CI で動くコーディングエージェントに外から書いた文章を読ませ、秘密を持ち出させたり、権限の高いワークフローを動かさせたりする報告が続きました。
- 4月15日、Aonan Guan 氏が Comment and Control を公表しました。プルリクエストのタイトル、issue のコメント、HTML コメントに書いた指示で、Claude Code Security Review・Gemini CLI Action・GitHub Copilot のエージェントに API キーやトークンを書き出させたという報告です
- 6月1日、GMO Flatt Security の RyotaK 氏が、claude-code-action の「書き込み権限のある人だけが起動できる」制限を、外部から作った issue で回避できたと報告しました（回避の修正は1月16日、関連する修正を含めて v1.0.94）
- 6月5日、Microsoft が、Read ツールにプロセスの環境変数のファイルを読ませて API キーを取り出せたと報告しました（Claude Code 2.1.128 で修正）
- 8月3日に Pillar Security が、権限の低いエージェントに書かせたコメントで権限の高いワークフローが起動した件を、8月6日に Novee が、issue 1本で3社の自社リポジトリのワークフローに到達した件を公表しました
本文の「何が起きたか」で挙げた事例に共通する形を筆者が整理したものです。issue・PR（プルリクエスト）・コメントをエージェントが読んで動き、同じジョブの中で秘密・トークン・ツールに届いていました。
どの件も、信頼できない入力が入る場所と、秘密やトークン、ツールが届く場所が同じジョブの中でつながっていました。修正版に上げれば個々の穴は塞がりますが、ワークフローの書き方で同じ形を作っていれば、別の穴から同じことが起きます。点検するのは、その書き方の側です（筆者の整理）。
点検表から1項目だけ見せます
有料部の点検表は、8項目を「何を見るか・危ない形・公式が推奨する形・確かめ方」の順で並べ、項目ごとに、守られていなかった事例を短く添えています。「起動できる人」の項目の Claude Code の部分です。
- 何を見るか：anthropics/claude-code-action のステップの allowed_bots と allowed_non_write_users、ワークフローの on: と if: の条件
- 危ない形：セキュリティ文書によると、allowed_bots に一致したボットはリポジトリの権限を調べられません。公開リポジトリで issue やコメントに反応するワークフローに allowed_bots: '*' を書くと、誰が作った GitHub App でも、自分の書いたプロンプトで Action を起動できます。allowed_non_write_users は書き込み権限の確認を外す設定で、同じ文書は「大きなリスク」と書いています
- 公式が推奨する形：allowed_bots は '*' でなく信頼する App の名前を並べます。'*' が要るなら、ワークフローの permissions: を最小にします。allowed_non_write_users を使うのは権限をごく狭くしたワークフロー（例として issues: write だけのラベル付け）に限り、github_token: ${{ secrets.GITHUB_TOKEN }} を渡して、個人のアクセストークンは使いません。使えるツールも claude_args の --allowedTools で最小にします
- 確かめ方：.github/workflows/ の全ファイルで2つの入力を探し、値を書き出します。'*' があれば、そのワークフローの on: に issue・コメント・レビューのイベントが入っているか、permissions: に書き込みが入っているかを並べて見ます。実行が失敗したかどうかではなく、ファイルに書かれた値で判定します
- 守られていなかったとき：Flatt Security の報告によると、公式の例にあった issue の仕分けのワークフローは allowed_non_write_users: "*" で誰でも起動でき、公開されている実行の要約から issues: write のトークンを取り出せました。そのトークンで信頼できる人の issue を書き換え、別のワークフローに読ませる経路があったとしています
関連する記事
Claude Code を自分の端末で使うときに、止めたい操作を deny・フック・サンドボックスのどれで止めるかを操作ごとに決めた記事です。CI でも、エージェントに許すツールを最小にする考え方は共通します。
参考になったら、記事下部のライクとXの共有ボタンから応援してもらえるとうれしいです。
続きで読めるのは、8項目の点検表の全体（トリガーと入力の出どころ、入力の渡し方、checkout、トークンとシークレットの権限、起動できる人、使えるツール、信頼の扱い、出力の扱い）と、Claude Code・Codex・Gemini CLI それぞれのワークフロー設定例（YAML。Codex と Gemini は安全寄りに絞った形、Claude Code は公式の例と、それを項目4で安全側へ直す手順）、設定例の各キーが公式のどのページのどの記述に当たるかの対応、事例と点検項目の対応です。点検の確かめ方は、ワークフローのファイルのどこを見るかと、GitHub の設定画面やログで何を見るかにしてあります。では、自分のエージェントのワークフローは、どの順番で、どこを見て、何に直せばよいのか。
この記事の販売者
