11 件のテストが通った

GitHub で、1 週間分の作業を省いてくれそうな小さなメトリクスクライアントを見つけ、Claude Code にクローンして中身を見るよう頼む。仕事ぶりは上々だ。コードを読み、上限のないバッファと、毒入りのメッセージを受けると永遠に回り続けるリトライループを指摘し、修正案を出す。あなたはいつもの指示を出す。それを直して PR を用意して。

数分後、修正は入り、テストは緑で、要約には 11 passed とある。その数分間のどこかで、インプラントがあなたのノート PC 上でリモートシェルを開いていた。

これは Straiker STAR Labs の Brian Cumi が組み立て、9 月 22 日に Fable to Haiku: How a Malicious Repo Tricked Claude Code Into Running Malware という題で公開したシナリオだ。Adversa の コーディングエージェントのセキュリティ研究をまとめた 10 月版 は、これを今月の攻撃手法の一つに挙げている。このリポジトリはバグを一つも突いていない。どの段階も、文書化された機能を設計者の意図どおりに使っているだけだ。

リポジトリが自分自身をレビューした方法

リポジトリ northstar-metrics は普通のオープンソースプロジェクトに見え、最初の仕掛けもありふれたものだ。CONTRIBUTING.md である。PR を頼んだ時点で、あなたはエージェントをプロジェクトの貢献手順に縛った。そして指示に従うエージェントは貢献ガイドを読む。このガイドには、レビュー担当者はテストを実行する前に、プロジェクトのファーストパスレビュー用エージェントを走らせるべきだと書かれている。

そのエージェントはリポジトリの中、.claude/agents/first-pass.md にある。Claude Code では、プロジェクトがこのフォルダに独自のサブエージェントを定義でき、モデルと範囲を frontmatter に書ける。このエージェントは model: haiku を指定し、レビュー対象を src/ と docs/ に限定する。指示には「メインセッションで読んでも、エージェントの実行の代わりにはならない」と添えられており、メインのエージェントがこれを飛ばさないようにしてある。

連鎖の全体はこうだ。

1. メインモデルの Fable が、リポジトリのサブエージェントにレビューを任せる。
2. サブエージェントは Haiku 4.5 で動き、src/ と docs/ しか見ない。
3. 作者が見つけさせるために仕込んだ指摘を 2 つ持ち帰る。ハードコードされたバージョン文字列と、ドキュメントとコードの食い違いだ。どちらも無害である。
4. 文書化された手順では、これでレビューは完了となる。誰も tests/test_compat.py を開かない。
5. Fable が pytest を実行する。
6. アサーションの前に、test_compat.py は 16 進でエンコードされた URL をデコードし、Python ファイルをダウンロードして subprocess で起動する。このブロックは try/except: pass で包まれており、アサーションは常に成り立つ。
7. Sliver のインプラントが C2 セッションを開く。pytest は 11 passed と表示する。

これがなぜうまくいくのか、Cumi の要約はこうだ。リポジトリは 3 つのありふれた前提に乗っている。プロジェクトは独自のサブエージェントを定義できる、エージェントはプロジェクトの文書化された手順に従う、そしてテストが緑なら、コードを確認したことになる。「3 つの前提をすべて理解した悪意あるリポジトリは、そのどれも破る必要がない。それらが接する継ぎ目に収まっていればいい」。

Straiker は 9 月 14 日に HackerOne 経由で Anthropic に報告した。Anthropic は Informative として閉じた。リポジトリの設定に従うことは、ユーザーによるワークスペース信頼の判断の範囲内だという。

信頼の判断、その実際

Anthropic の回答は、Claude Code の仕組みと矛盾しない。フォルダを開くと、それを信頼するかと尋ねられ、あなたははいと答えた。その判断は CLAUDE.md、フック、サブエージェント、テストスイートをまとめて対象にする。

問題は、あなたが何について判断していたかだ。あなたがリポジトリを信頼したのは、中身を見るのに足る程度だった。クローンしたのはそのためだ。ノート PC の上では、「このフォルダを、テストを実行させるほど信頼する」ことは、自分のアカウントが届くものすべてを任せることを意味する。pytest が動くのはそこだからだ。Straiker はインプラントが手にしたものを挙げている。あなたが読めるすべてのファイル、メモリ上の認証情報、ディスク上の SSH 鍵、そして push できるすべてのリポジトリだ。

レビュー担当者は、人間であれモデルであれ、評価するすべてのプロジェクトのすべてのテストファイルを読みはしない。今回のレビューは意図的に短くされたが、誠実なレビューでも短いものはいくらでもある。それでも、テストスイートをどこで動かすかは選べる。

同じリポジトリを Bromure マシンで動かす

Bromure Agentic Coding では、Claude Code は Mac 上の Linux VM の中で動く。マシンごとに専用のディスク、専用のホームディレクトリ、専用の認証情報があり、通信はすべて Mac 上のプロキシを通って外に出る。ワークスペース信頼の判断は、引き続きあなたが下す。変わるのは、信頼したリポジトリが何に届くかだ。

Straiker の連鎖を Bromure マシンの中で再現してみよう。1 から 5 までは前と同じだ。エージェントが貢献ガイドを読み、サブエージェントが見当違いのフォルダをレビューし、pytest が動く。6 から先、リポジトリが相手にするのは Mac になる。

ダウンロードは Mac を通る

ペイロードは取ってこなければならない。テストは URL をデコードし、プロジェクトがこれまで一度も必要としなかったホストにファイルを要求する。Bromure マシンの中から外へ出る道は一本しかない。仮想ネットワークスイッチが、ポート 80 と 443 へのあらゆる接続を Mac 上のプロキシへ迂回させ、それ以外の接続はプロトコルを問わず、マシンのルールと照合する。

ルールはマシンの Guardrails ペインの Outbound connections にある。ホスト、IP 範囲、プロトコル、ポートごとの許可・拒否エントリと、Allow か Deny を選ぶ Unmatched traffic の設定だ。見知らぬ人のコードを評価するためのマシンなら、リストは短くて済む。モデルプロバイダー、パッケージレジストリ、GitHub だ。

allow web api.anthropic.com
allow web pypi.org
allow web files.pythonhosted.org
allow web github.com
default deny

このルールのもとでは test_compat.py のダウンロードは接続すらできず、作者が失敗を隠すために入れた try/except: pass が、今度はこの失敗を隠す。pytest はやはり 11 passed と表示する。違いは Mac の側にある。マシンの Security Timeline には赤い Firewall 行が残る。拒否の判定、テストが接続しようとしたホストとポート、そしてエージェントが pytest を実行した数秒後のタイムスタンプだ。メトリクスクライアントのテストスイートに、聞いたこともないホストへ接続する理由はない。そして今、それを試みたことがわかる。

インプラントのその後の通信も同じ扱いを受ける。Sliver が HTTPS で、独自ポートの相互 TLS で、WireGuard で、あるいは DNS でコールバックしようと、接続はスイッチを通って出ていき、スイッチはあらゆるプロトコルを同じ表と照合する。

インプラントが見つけるのはダミー

仮にマシンが未一致の通信を許可していて、ペイロードが届き、Sliver がセッションを開いたとする。攻撃者は VM 内のシェルを手にし、Straiker がノート PC について挙げたのと同じ範囲に手を伸ばす。Bromure マシンでは、その範囲は狭い。

• ファイル。 VM にあるのは自身のホームディレクトリと、あなたがそのマシンと共有することにしたプロジェクトフォルダだけだ。Mac のホームディレクトリ、ほかのプロジェクト、ブラウザのプロファイル、キーチェーンはその中にない。
• 認証情報。 Bromure は本物の API キー、OAuth トークン、git トークン、クラウドのシークレット、データベースのパスワードを Mac 上で暗号化して保管する。VM にあるのは形だけ正しいダミーだ。ANTHROPIC_API_KEY=sk-ant-api03-brm-…、GitHub が拒否する ghp_ トークン、何にも署名できない AWS のシークレットキー。プロキシは、リクエストが VM を出た後で本物の値に差し替える。それも、その認証情報が属するホスト宛ての場合に限る。
• SSH 鍵。 ls ~/.ssh/id_* は何も返さない。VM の SSH_AUTH_SOCK は Mac 上の ssh-agent へのブリッジだ。VM は署名を求めることはできるが、鍵を読むことはできない。鍵ごとに Ask before use をオンにすれば、署名の要求のたびに Mac にダイアログが出る。

手に入るものを集めて送り出すインプラントは、2 本目の仕掛け線に触れる。ダミーのトークンには正当な宛先が一つしかない。発行されたホストだ。sk-ant-api03-brm-… やあの ghp_ トークンがそれ以外のどこかへ向かうのをプロキシが見ると、HTTP 451 でリクエストを拒否し、VM を一時停止し、Mac に This environment may have been compromised という警告を出す。そこにはトークン、それが発行されたホスト、送られた先のホストが示される。出ていったのはダミーだけなので、ローテーションすべきものは何もない。

push はまず確認を求める

Straiker のリストの最後の項目、「push 権限のあるリポジトリ」は、侵害されたノート PC をサプライチェーンのインシデントに変えるものだ。シェルとあなたの git 認証情報を持つ攻撃者は、あなたが保守するすべてのプロジェクトにコミットを push できる。

Bromure マシンでは、GitHub、GitLab、Bitbucket への push は書き込みであり、新しいマシンは保護対象のすべてのサービスで Prompt before write が有効な状態で出荷される。プロキシは push を保留し、macOS は Allow write on "github.com" from workspace "…"? を表示する。そこには通信上に現れたとおりの操作、POST /acme/app.git/git-receive-pack が示される。push を頼んだ覚えはないので Don't allow をクリックすると、インプラントは blocked by Bromure Guardrails で終わる 403 を受け取る。macOS はプロキシが読んだ内容からダイアログを描くので、VM の中の何ものも文言を変えられない。

トレースは、行われなかったレビューを示す

騒ぎが収まったら、エージェントが何をしたのか知りたくなる。既定のトレースレベル AI request details では、プロキシがモデルプロバイダーとのやり取りをすべて Mac 上に暗号化して保存し、Trace Inspector がそれぞれをツール呼び出し、シェルコマンド、ファイルの読み取りに分解する。

このリポジトリについて、記録は肝心な問いに答える。

• レビューしたのはどのモデルか。 キャプチャされたリクエストボディに名前がある。claude-haiku-4-5 だ。メインセッションが .claude/agents/first-pass.md を読んだ 1 ターン後である。
• 何を読んだか。 すべての Read 呼び出しとそのパスだ。src/ と docs/ 配下のファイルへの呼び出しはあり、tests/test_compat.py への呼び出しは一つもない。
• 何が実行されたか。 pytest を起動した Bash 呼び出しと、その隣、Security Timeline には、それが引き起こしたダウンロードのファイアウォール行がある。

リポジトリは、エージェントが何を見て pytest が何を表示するかを制御できる。だがトレースを書き換える手段はない。プロキシはその記録を Mac 上で、通信そのものから書く。

読んでいないコードのためのマシン

Straiker の記事は 3 つの推奨で締めくくられている。リポジトリが定義したサブエージェントを動かす前に承認を求めること、テストファイルは実行前に読むこと、そして .claude/agents/、フック、ワークフロー定義のようなファイルを信頼できない入力として扱うことだ。どれも妥当だが、どれも誰かが毎回、それもいつものレビューに見えた作業の最中に、覚えていることを前提にしている。

Bromure なら、安全な習慣は数クリックで済む。新しいマシンは署名済み Ubuntu イメージのコピーオンライトのクローンなので、ディスクはほとんど食わない。そこから、外部のコードを評価するための構成が見えてくる。

1. 「eval」という名前のマシンを作る。 モデルプロバイダーだけを与え、ほかには何も与えない。push 権限のある git トークンも、クラウドの鍵も、データベースもなしだ。
2. 送信を既定で拒否にする。 Guardrails › Outbound connections で、モデルプロバイダー、パッケージレジストリ、GitHub を許可し、Unmatched traffic を Deny にする。
3. 共有フォルダではなく VM の中にクローンする。 マシンのホームに新しいフォルダを作ってセッションを始める。共有フォルダは Mac へ直結した窓であり、マシン自身のホームこそ Bromure が巻き戻したり消去したりできる部分だ。
4. あるいは使い捨てにする。 bromure-cli vm run --rm で起動したマシンは、停止するとディスクごと削除される。
5. 依存関係を採用する前に Timeline を読む。 テスト実行中の Firewall の拒否行は、pytest が何を表示していようと、どのレビュー担当者も報告しなかった指摘だ。

何かがすり抜けても、片付けるのはマシン 1 台だけだ。Rewind home… はホームディレクトリを以前の起動時のチェックポイントに戻す。侵害検知が警告を出したマシンは、Wipe and Launch を選ぶまで起動を拒む。これはディスクとホームを作り直し、設定と Mac 上の本物の認証情報はそのまま残す。ノート PC のアカウントも、ほかのプロジェクトも、ほかのマシンも、最初からその中にはなかった。

ライブラリが役に立つと確かめられたら、実際の作業をするマシンに移す。そのマシンもダミーの鍵しか持たず、push はやはり Mac 上のダイアログで止まる。

リポジトリに任せるものを減らす

このリポジトリは何も変わったことをしていない。貢献ガイドを書き、補助エージェントを定義し、テストファイルを同梱しただけだ。プロジェクトはこの 3 つをこれからも続ける。役に立つからだ。エージェントもこれからも従う。プロジェクトの慣習に従うことこそが、エージェントを仕事のできるものにしているからだ。

Anthropic の回答は判断をあなたに委ねており、それは正しい置き場所だ。その判断を、そのために作られたマシンの上で下せばいい。リポジトリを、テストを走らせるほど信頼することが、VM 1 台とわずかなダミーと短いホストのリストを任せることにしかならないマシンの上で。あとはテストスイートに好きなだけ表示させておけばいい。