2026년 4월 21일, AI 보안 연구자 Aonan Guan과 Johns Hopkins 동료들이 GitHub PR 제목에 한 줄짜리 악성 명령을 끼워 넣었다. 그 한 줄로 Anthropic의 Claude Code Security Review, Google의 Gemini CLI Action, GitHub Copilot Agent — 코드 리뷰 자동화 에이전트 3개 모두가 자기 API 키를 PR 댓글로 토해냈다.
Firecrawl이 9일 뒤(4월 30일) 푼 답이 Lockdown Mode다. /scrape에 플래그 한 줄(lockdown: true) 끼우면 이미 인덱싱된 캐시에서만 결과를 뽑고, target URL로 네트워크 요청 자체를 안 보낸다.
왜 지금 갑자기 락다운인데?
"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 제목 한 줄로 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 동일 |
중요한 건 마지막 두 줄이다. 캐시 미스 시 silent fallback이 없다 — 즉 "캐시에 없으니 그냥 한 번 긁어올게요" 같은 회피가 안 된다. URL이 캐시에 없으면 호출자가 그 사실을 즉시 알게 되고, 외부 요청은 끝까지 0이다.
그리고 9개 SDK·CLI·MCP에 같은 플래그가 깔린다. 보안 정책을 도구별로 따로 짤 필요 없이 lockdown: true 하나로 통일된다는 게 운영 관점에서 가장 큰 변화다.
주의: Lockdown은 네트워크만 막는다. 모델 호출 자체는 별개 문제다. Lockdown Mode는 outbound 스크레이프 채널을 막을 뿐, 에이전트가 이미 캐시에서 받은 콘텐츠 안에 들어간 인젝션까지 차단하지 않는다. content sanitization은 여전히 필요하다.
핵심만 정리: 시작하는 법
- 먼저 캐시 시드부터
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 stars, Deep Agents 기반) 안에서 Lockdown을 기본 모드로 두면 자율 에이전트 outbound 위험을 구조적으로 0으로 가져갈 수 있다.
자주 묻는 질문
크롤(/crawl)이나 검색(/search)에도 Lockdown이 되나?
현재는 /scrape 전용이다. /crawl·/map·/extract·/search는 외부 요청이 본질적으로 필요한 엔드포인트라 lockdown 적용 대상에서 빠져 있다. 보안이 중요한 자율 에이전트는 /search 결과 URL을 일단 정상 모드로 캐시에 시드한 뒤, 후속 분석은 /scrape --lockdown으로 돌리는 2단계 패턴이 표준이 된다.
Anthropic·OpenAI·Google이 자체 런타임 가드를 다 만들고 있는데, 굳이 Firecrawl Lockdown이 필요한가?
VentureBeat의 4월 21일 분석이 핵심을 짚었다. 세 곳의 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 프레임워크는 별도로 셀프 호스팅 가능.
