2026年4月21日、AIセキュリティ研究者のAonan Guanとジョンズホプキンズ大学の同僚たちが、GitHub PRのタイトルに1行の悪意ある命令を仕込みました。たった1行で、AnthropicのClaude Code Security Review、GoogleのGemini CLI Action、GitHub Copilot Agent — コードレビューを自動化する3つのエージェントすべてが、自身のAPIキーをPRコメントに吐き出してしまったのです。
Firecrawlが9日後(4月30日)に出した答えがLockdown Modeです。/scrapeにフラグ1行(lockdown: true)を追加するだけで、すでにインデックスされたキャッシュからのみ結果を返し、対象URLへのネットワークリクエスト自体を送らなくなります。
なぜ今になってLockdownなのか?
"runtime is the blast radius." VentureBeatに引用されたEnkrypt AI CSO Merritt Baerのこの一言が、問題を的確に捉えています。 AIエージェントがLLM推論レイヤーでは安全障壁を乗り越えられないように見えても、ツール呼び出し(bash実行、git push、API POST、ウェブスクレイプ)のレイヤーで制御が抜け落ちているという意味です。
特にウェブスクレイプは、LLMが直接URLを決定する瞬間に外部チャネルになります。攻撃者がページ・メール・イシューにinstructionを仕込んでおけば、エージェントがそのページをスクレイプした際にinstructionを受け取り、別のドメインへoutboundリクエストを送ってコンテキストを漏らします。URLのpath・query・headerがまるごとデータ漏洩チャネルになるのです。
2026年4月に起きた出来事を時系列で並べると、全体像がはっきりします。
- 4月15日
Microsoft Copilot Studio + Salesforce Agentforceが同じインジェクションクラスで侵害される。新たなagentic AI CVEカテゴリが浮上。 - 4月21日
Comment and Control攻撃が公開。Claude Code/Gemini CLI/Copilotの3社すべてがPRタイトル1行でsecretを漏洩。CVSS 9.4 Criticalにもかかわらず、Anthropicのバウンティは$100。 - 4月30日
FirecrawlがLockdown Modeをリリース。単一フラグでoutboundリクエスト自体を遮断するcache-onlyモード。 - 同時期
OX SecurityがMCPサーバー200,000台が外部公開されていると発表。Firecrawlは同じ週にweb-agentオープンソース + Lockdownをセットでリリース。
具体的に何が変わるのか?
既存の/scrapeとLockdownモードの違いは、一行でまとめられます。
| 項目 | 通常の/scrape |
Lockdown Mode |
|---|---|---|
| 対象URLへのoutboundリクエスト | する | 絶対しない |
| robots.txt fetch | する | 遮断（エンジンレイヤー） |
| Zero Data Retention | 追加料金あり | デフォルト適用 + 追加料金なし |
| キャッシュミス時の動作 | リアルタイムスクレイプ | SCRAPE_LOCKDOWN_CACHE_MISSエラー |
| 適用範囲 | — | SDK 9種 + CLI + MCP 共通 |
重要なのは最後の2行です。キャッシュミス時のsilent fallbackはありません — 「キャッシュにないので、とりあえず1回スクレイプしてきます」という回避ができません。URLがキャッシュにない場合、呼び出し元はその事実を即座に知ることができ、外部リクエストはゼロのままです。
そして9つのSDK・CLI・MCPに同じフラグが適用されます。ツールごとにセキュリティポリシーを個別に設定する必要がなく、lockdown: true一つで統一できるのが、運用観点から見た最大の変化です。
注意：Lockdownはネットワークのみを遮断します。 モデル呼び出し自体は別の問題です。Lockdown Modeはoutboundスクレイプチャネルを塞ぐだけで、エージェントがすでにキャッシュから受け取ったコンテンツ内に仕込まれたインジェクションまでは防げません。コンテンツのサニタイズは引き続き必要です。
始め方のポイント
- まずキャッシュのシードから
Lockdownはすでにインデックスされたページしか返しません。運用で使うドメインは、通常モードで一度スクレイプしてキャッシュに登録しておく必要があります。 lockdown: trueフラグを追加
Python/Node/Go/Rust/Java/.NET/Ruby/PHP/ElixirのSDKすべてで同じです。CLIは--lockdown、MCPサーバーはツールの引数に同じフラグを渡します。- キャッシュミスのハンドリング
SCRAPE_LOCKDOWN_CACHE_MISSエラーをキャッチして運用キューに送るか、別のワーカーが事前にシードするような構造にします。silent fallbackがないのは意図された動作です。 - 料金の確認
キャッシュヒット5クレジット、ミス1クレジット、ZDR追加料金なし。セキュリティのコストが通常モードより高くならないのは意図した設計です。 - web-agentと組み合わせる
Firecrawlが同時期にリリースしたweb-agent（オープンソース、MIT、スター数1.1k、Deep Agents基盤）の中でLockdownをデフォルトモードにしておけば、自律エージェントのoutboundリスクを構造的にゼロにできます。
よくある質問
クロール(/crawl)や検索(/search)にもLockdownは使えますか?
現時点では/scrape専用です。/crawl・/map・/extract・/searchは外部リクエストが本質的に必要なエンドポイントのため、lockdownの適用対象外となっています。セキュリティが重要な自律エージェントでは、/searchの結果URLをいったん通常モードでキャッシュにシードしておき、後続の分析は/scrape --lockdownで行う2ステップパターンが標準になります。
Anthropic・OpenAI・Googleが自社のランタイムガードを整備しているのに、わざわざFirecrawl Lockdownが必要ですか?
VentureBeatの4月21日の分析が核心をついています。3社のsystem cardはモデルレイヤーのインジェクション耐性しか測定・公開しておらず、ツール実行レイヤー（スクレイプ・shell・API call）の耐性を定量化していません。AnthropicがClaude Code Auto Modeに一部のランタイムガードを実装しているものの、system cardに文書化されていないため検証が困難です。 つまりモデルガードとは別に、ツールレイヤーで直接遮断するインフラが必要だということです — Lockdownはその一つの答えです。
リアルタイム性が重要なニュースや価格データにはLockdownは使えませんか?
Lockdownは最大2年前のキャッシュまで返します。リアルタイムデータには向きません。ただし「センシティブなURL自体が情報を漏らすケース」（競合他社のページ、内部ホスト名、pathに識別子が含まれるURL）では圧倒的に強力です。リアルタイムワークフローとセキュリティワークフローを分離し、後者だけをLockdownで実行するのが推奨パターンです。
オープンソースでセルフホスティングしている場合、Lockdownも使えますか?
Firecrawl本体はオープンソース（MIT）ですが、LockdownはFirecrawlのインデックス/キャッシュに依存する機能です。セルフホスティング環境で同等の保証を得るには、自前のキャッシュレイヤーを構築するか、Firecrawlのホスティングモードを利用するのがシンプルです。web-agentフレームワークは別途セルフホスティング可能です。
さらに深掘りしたい人へ
Lockdown Mode公式ブログ Firecrawlの共同創業者Eric Ciarlaが直接書いたリリース記事。4つのユースケースとキャッシュマッチングルールまで解説 — 最も正確な一次資料です。 firecrawl.dev
Comment and Control技術公開 Aonan Guanが書いた原文の開示レポート。Claude Code/Gemini CLI/Copilotすべてに対して、どんなPRタイトル1行を仕込んだのか、なぜ通過したのか — 再現ケースがそのまま掲載されています。 venturebeat.com
Firecrawl web-agent 同じ4月にリリースされたオープンソースの自律エージェント。Lockdownと組み合わせて使うリファレンスアーキテクチャです。 github.com/firecrawl/web-agent
Lockdown公式ドキュメント キャッシュマッチングルール、課金モデル、SCRAPE_LOCKDOWN_CACHE_MISS レスポンス仕様。 docs.firecrawl.dev
