AIセキュリティエージェントがSnowflakeへ侵入した。Copilotの話はノイズだった

6月、AIエージェントがSnowflakeの社内Jiraへ侵入しました。そしてほとんどの記事が最初に持ってきた部分こそ、間違った部分でした。最初の物語では、脆弱なコードを書いたのはGitHub Copilotだったとされ、AIがAIを汚染するというきれいな寓話になっていました。その版は数時間しか持ちませんでした。Wizは同日中に自社の開示を訂正し、GitHubは著者帰属を明確に否定しています。訂正後に残る話の方が奇妙で、実務上はずっと有用です。自律エージェントが実在する脆弱性を見つけ、エクスプロイトを書き、自分で失敗したペイロードをデバッグし、使える認証情報を抜き取りました。端から端までです。その一方で、同じコードを見た従来型スキャナーは何も見つけませんでした。時間を使う価値があるのは、こちらの話です。

要点 - 自律型の攻撃セキュリティエージェントWiz Red Agentは、Snowflakeの公開snowflake-connector-netリポジトリにあるGitHub Actionsワークフローでスクリプトインジェクションを発見し、悪用してJiraトークンを盗みました。発見から認証情報の持ち出しまで、人間はキーボードに触れていません。 - 脆弱性は2026年6月18日に本番入りし、6月23日に発見、悪用、報告されました。すべてSnowflakeのHackerOneプログラム内で行われています。Snowflakeは同日に修正し、監査ログ上、この期間にアクセスしたのはWizだけでした。 - Copilotがバグを書いたという最初の主張は数時間以内に後退しました。脆弱なパターンは人間が作成した変更にあり、Copilot Autofixが文書上変更したのは別ファイルです。共同著者表示はスカッシュマージによる副作用でした。 - GitHub Advanced Securityは、まさにその脆弱なリビジョンをスキャンして見逃しました。パターン照合型スキャナーと、コードを推論したエージェントが同じものを見て、理解したのは片方だけでした。 - 本当にエージェント的だった部分は狭いものの実在します。失敗したエクスプロイトを診断し、書き直したことです。それ以外は、言語モデルを中に入れた優秀な自動化でした。

何が起きたのか

以下の時系列はすべてWizの開示とSnowflakeの対応に基づきます。

• 2026年6月18日。 PR #1218がSnowflakeの公開.NETコネクタリポジトリsnowflakedb/snowflake-connector-netへマージされます。GitHub Issueが開かれたときにJiraチケットを自動作成するjira_issue.ymlというワークフローを書き換えるPRです。変更によって、安全なパターン、Issueタイトルを環境変数経由でjq --argへ渡す方式が、タイトルをシェルのrun:ブロックへ直接補間する方式へ置き換えられました。

• 6月23日。 Wizの自律型セキュリティ調査エージェントRed Agentが、SnowflakeのHackerOneバグ報奨金プログラムの範囲内で同社GitHub組織をスキャンし、ワークフローがインジェクション可能だと判定します。エクスプロイトを作って実行しますが、自分のペイロードがシェル構文エラーを起こします。エラーを診断し、ペイロードを書き直し、2回目で成功します。AzureホストのGitHub Actionsランナーが、サービスアカウントに紐づくJira APIトークンをBase64エンコードしてWizの受信先へコールバックしました。Wizは同日、HackerOne経由で報告します。

• 6月23日、同日。 Snowflakeはワークフローを修正し、安全なパターンへ戻します。

• 6月24日。 Jiraトークンを失効・ローテーションします。Snowflakeの監査ログ確認では、5日間の露出期間にWiz以外のアクセスはありませんでした。Wizは概念実証で取得したデータを削除したとしています。

• 8月17日。 Wiz Researchの脅威露出責任者Gal Nagliが記事を公開し、同日19:57 UTCに更新します。Copilotはマージ済みPRの共同著者で、PRを確認して問題なしとしたものの、脆弱な変更自体がAI支援だったかは不明だと明確化しました。

トークンにはSnowflake社内Jira、エンジニアリング、セキュリティコンプライアンス、バグ報奨金プログラム自体への読み取り権限がありました。顧客データには一切触れず、出荷済みコネクタにも影響はありませんでした。

2026年6月23日、Wizの自律型Red AgentはSnowflakeのsnowflake-connector-netリポジトリにあるGitHub Actionsワークフローのスクリプトインジェクションを発見・悪用し、社内エンジニアリング、セキュリティコンプライアンス、バグ報奨金プロジェクトへの読み取り権限を持つJiraトークンを持ち出しました。脆弱性が本番入りしてから5日後で、人間の介入はありませんでした。Wiz Researchの開示に基づきます。Snowflakeは同日修正し、監査ログ上、第三者アクセスは見つかりませんでした。

権限チェーンを1リンクずつ追う

このエクスプロイトは、CIパイプラインが静かにどれだけ大きな信頼を抱えているかを示す、きれいな教材です。細工したIssueタイトル1つがどこまで届いたかを追います。

1. トリガー。 ワークフローはissues: openedで実行されました。つまり地球上のどのGitHubアカウントでも、Issueを開くだけで起動できます。アクセスを制限するつもりだった条件分岐は、Issueオープンイベントでは常に真になっていたと技術記事は説明しています。

2. インジェクション。 新しいコードはTITLE=$(echo '${{ github.event.issue.title }}' | sed ...)を実行しました。GitHubはシェル実行前に${{ }}テンプレートを展開するため、sedによるエスケープは手遅れです。タイトル内のシングルクォート1個で文字列を閉じ、残りをシェルとして実行できます。

3. 環境。 これでコマンドはGitHub Actionsランナー内で動きます。ランナーは設計上、認証情報が詰まったマシンです。このランナーにはサービスアカウント用のJira APIトークンがありました。Jiraチケットを作ることがワークフローの仕事だったからです。

4. 持ち出し。 ペイロードはトークンをBase64エンコードし、帯域外コールバックとしてWizの受信先へ送信しました。そのためワークフローログには不審な出力が残りませんでした。

5. 獲得物。 トークンはSnowflake社内のAtlassian環境で認証でき、エンジニアリング、セキュリティコンプライアンス、バグ報奨金の各プロジェクトを横断して読み取りできました。

このチェーンの各リンクは普通で、承認済みで、退屈なインフラです。公開リポジトリ、仕事をしているワークフロー、必要な権限を持つサービスアカウント。脆弱性は単一の誤設定ではなく、それらを組み合わせた結果でした。ワークフローの被害範囲はランナーが触れられるすべてであり、ランナーはしばしば、作ったチームが覚えている以上の場所へ届きます。これはクライアントからエージェントガバナンスについて聞かれたとき、私がいつもするのと同じ議論です。問うべきは「エージェントとは何か」ではなく、「何に触れられるか」です。

このエクスプロイトは、正当な信頼を5層つなぎました。認証不要のGitHub Issueがワークフローを起動し、シングルクォートのインジェクションでシェルを抜け、ランナー環境にJiraサービスアカウントトークンがあり、帯域外コールバックで持ち出され、そのトークンでSnowflake社内Jiraへ読み取りアクセスしました。GitHubのテンプレート展開はシェルエスケープより先に行われるため、サニタイズが遅すぎました。Wizの記事に基づきます。

何がエージェント的で、何がそうでなかったのか

ここは正確に言いたい。「AIエージェントがSnowflakeをハック」という表現には、雑な読み方が2つあります。単なるスキャナーにうまいマーケティングを付けただけだ、あるいはSkynetが解き放たれた。詳細を見ると、どちらも成立しません。

モデル入りの普通の自動化。 スキャンとフラグ付けです。Red AgentのCI/CD機能はGitHub組織を巡回し、信頼できない入力をrun:ブロックへ補間しているワークフローファイルを探します。形がよく知られた脆弱性クラスであり、jira_issue.ymlをフラグすること自体は、優れた静的ルールでも十分可能だったでしょう。対象を選び、ワークフローを読み、悪用可能だと判断する。高度ですが、Wizがすでに継続的な攻撃面管理として販売しているものに近い。

本当にエージェント的。 エクスプロイトのループです。最初のペイロードはコメント文字の使い方でシェル構文を壊し、失敗しました。エージェントは返ってきたBashエラーを読み、なぜペイロードが壊れたのかを理解し、スクリプトを正しく閉じるよう書き直し、2回目で成功しました。その後、盗んだトークンがSnowflakeのJiraで実際に使えることを検証し、どこまで到達できるかも評価しました。自分の攻撃中に起きた新しい実行時障害を診断し、指示なしで適応するのはシグネチャ照合ではありません。この試行、観察、修正のループこそ、スキャナーとエージェントを分けます。そして、私がより一般的なエージェント型アーキテクチャで書いてきたのと同じループです。Fortune 500企業を対象に、監督なしで攻撃側に使われたことは、記録しておく価値のある初例です。

エージェントではない部分。 範囲、倫理、開示です。Red AgentはSnowflakeのHackerOneプログラムの中で動きました。Wizの人間が選び、許可したサンドボックスです。自律性は本物でしたが、範囲があり、認可され、監視されていました。防御側にこそ、この点を強調したい。Wizは3月にRed Agentを公開し、AnthropicのClaude Opusを一部に使って構築し、7月下旬には一般提供しました。この能力はもう、どのセキュリティチームでも借りられる製品です。だから攻撃側でこのループが使われるのは、これから非常に一般的になります。

Red Agentのスキャンとトリアージはモデル入りの自動化でした。本当にエージェント的だった核心はエクスプロイトループです。最初のペイロードがシェル構文エラーを起こすと、エージェントはbash障害を診断し、ペイロードを書き直し、2回目で成功しました。その後トークンを検証し、被害範囲まで確認しました。すべて人間の助けなしです。Wizの開示に基づきます。

Copilotの著者欄は一番どうでもいい部分

最初の見出しは「Copilotがバグを書いた」と言いました。記録はそう言っていません。PR #1218でCopilot Autofixが文書上変更したのは、別ファイルjira_close.ymlへの別の修正です。脆弱な補間は、名前の付いたSnowflakeエンジニアによるコミットにありました。GitHubは報道各社に、社内調査ではCopilot Autofixがその行を書いてもレビューしてもいないと説明しています。マージ済みPRに付いた「Copilotとの共同作成」表示は、スカッシュマージがトレーラーを引き継いだ副作用でした。Wizは同日に記事を修正し、The Registerも記事を訂正しました。Wiz CTO Ami LuttwakがCSOへ語った言葉が、正直な結論です。すべてのPRで複数エージェントが動く時代には、「PRの共同著者を見るだけでは不十分」で、誰が何を書いたかは確定できません。

2つのことは同時に真であり得ます。Copilot Autofixを使うGitHub Advanced Securityは、脆弱なワークフローを含むPRの最終リビジョンをスキャンし、インジェクションをフラグしませんでした。これはWizの説明にあり、GitHubも否定していません。一方、Copilotが脆弱性を書いたという個別の主張には根拠がありません。AI支援レビューは「問題なし」としたコードの重大なバグを見逃しました。これはAIレビューの限界についての本物の話です。ただしAIがバグを書いた話ではありません。この2つを混ぜても、自分のPRでAIレビューをどこまで信頼するか判断する人の助けにはなりません。

Wizは当初、Copilotが脆弱なコードの作成に関与したと示唆しましたが、同日中に、Copilot Autofixの文書上の変更は同じPRの別ファイルであり、共同著者表示はスカッシュマージの副作用だったと明確化しました。GitHubは、人間のエンジニアが問題のあるリファクタリングを書き、Copilotはその部分をレビューしていないとしています。争いがない事実は、GitHub Advanced Securityが脆弱なリビジョンをスキャンして何も検出しなかったことです。Wizの更新記事とCSOの報道に基づきます。

今やるべきこと

秘密情報を含むGitHub Actionsを運用しているなら、今週やることは4つです。

1. ワークフロー内の${{ github.event.* }}がrun:ブロックに入っていないかgrepで検索してください。 Issueタイトル、PRタイトル、ブランチ名、コメント本文をシェルへ補間するものは、例外なくインジェクション可能だと考えるべきです。値はenv:変数へ移し、適切に引用して渡すか、jq --argで解析してください。Snowflakeが復元したのもこのパターンです。

2. ランナーは認証情報ストアだと思ってください。 ワークフロートークンは最小範囲にし、長寿命のサービスアカウントトークンより短寿命のOIDC認証情報を優先し、信頼できないイベント、issues、pull_request_target、コメントなどで起動するワークフローはインターネット公開コードとして扱います。

3. AIレビューを最後の防線にしないでください。 GitHub自身のスキャナーがこのコードそのものを見て通しました。チェックを重ね、レビュー、著者、スキャンのすべてを1社のモデルへ委ねるワークフローは疑ってください。

4. 5日間でも遅いと感じる前提に変えてください。 1体のエージェントが、このリポジトリについて何も知らない状態から1週間未満で使える認証情報へ到達しました。開示プロセスが「攻撃者の滞在時間は数か月」を前提にしているなら更新し、Snowflakeのように同日実行できる認証情報ローテーションのランブックを用意してください。

FAQ

GitHub CopilotがSnowflakeの脆弱性を書いたのですか？

現在の証拠では、いいえ。Copilot Autofixはマージ済みPRの共同著者でしたが、文書上の変更は別ファイルで、表示自体はスカッシュマージの副作用でした。GitHubは人間のエンジニアが脆弱なコードを書いたとしています。本当なのは、GitHub Advanced Securityが脆弱なリビジョンをスキャンし、インジェクションを見逃したことです。

WizのエージェントはどうやってSnowflakeのJiraへ入ったのですか？

Issueタイトルをシェルスクリプトへ直接補間するワークフローを見つけました。細工したタイトルでIssueを開くとランナー上で任意コマンドが実行され、そこにはJiraサービスアカウントトークンがありました。エージェントは帯域外コールバックでトークンを持ち出し、社内Jiraプロジェクトの読み取りに使いました。Snowflakeは報告当日にワークフローを修正し、翌日にトークンをローテーションしました。

これは本物の攻撃だったのですか？

認可された攻撃でした。Red AgentはSnowflakeのHackerOneバグ報奨金プログラムの下で動き、Wizは直ちに開示し、Snowflakeの監査ログでは脆弱性が生きていた5日間にWiz以外の主体はいませんでした。顧客データへはアクセスしていません。ただし未認可のエージェントでも、手法自体はまったく同じように動きます。そこが重要です。

AIセキュリティエージェントにとって、これは何を意味しますか？

攻撃側が防御側より先に進んでいる、ということです。自律エージェントが本物の脆弱性を出荷から数日で発見、悪用し、範囲を評価した一方、同じコード上の自動スキャナーは何も見ませんでした。防御側は、エージェント速度の発見を新しい基準とし、インターネットから起動できるものはすべて、その速度で探られると想定すべきです。

結論

Copilotの騒ぎを外すと、2つの事実が残ります。従来型の高価なセキュリティスキャナーはこのコードをレビューし、問題なしとしました。自律エージェントは同じコードを読み、武器化できるほど理解し、その途中で自分のミスまで修正しました。「マージ」から「機械に悪用された」まで5日。この数字をセキュリティチームは見つめるべきです。攻撃エージェントはもう研究デモではなく製品で、週末も休みません。Copilotの著者帰属欄は来月には忘れられるでしょう。この能力は忘れられません。

自社パイプラインの中で、攻撃側でも防御側でもエージェントへどこまで自律性を与えるか整理しているなら、これは私がクライアントと定期的に話しているテーマです。お問い合わせください。

情報源

• Wiz Research（Gal Nagli）、「Wiz Red Agent、GitHub Copilot支援PRの脆弱性を通じてSnowflake社内Jiraへ到達」: https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug （2026年8月17日公開、2026年8月17日19:57 UTC更新、2026年8月29日取得）

• Wiz、「Wiz Red Agentの紹介: AI搭載の攻撃者」: https://www.wiz.io/blog/introducing-the-wiz-red-agent （2026年3月23日公開、2026年8月29日取得）

• Cybersecurity News、「AIエージェントがSnowflakeのGitHubワークフローをハック」: https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ （2026年8月20日公開、2026年8月29日取得）

• CSO Online、「Snowflakeの欠陥、AIチェックをすり抜け別のAIに悪用される」: https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html （2026年8月19日公開、2026年8月29日取得）

• Infosecurity Magazine、「WizのAIエージェントがSnowflake GitHubリポジトリの重大な欠陥を発見」: https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ （2026年8月18日公開、2026年8月29日取得）

• daily.dev（The Next Web経由）、「GitHub、Copilot AutofixがSnowflakeの欠陥を書いたというWizの主張に反論」: https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 （2026年8月18日公開、2026年8月29日取得）

• snowflakedb/snowflake-connector-netリポジトリ: https://github.com/snowflakedb/snowflake-connector-net （2026年8月29日取得）