BrowseSafe++: 실제 프롬프트 인젝션에 맞서는 더 강력한 방어 구축

Comet 또는 Computer에 내장된 어시스턴트처럼 웹을 탐색할 수 있는 에이전트는 웹 페이지와 상호작용하면서 콘텐츠를 읽고, 이를 활용해 사용자를 대신하여 작업을 수행해야 합니다. 이 때문에 공격자가 웹페이지에 악성 텍스트를 심어 두는 간접 프롬프트 인젝션에 취약해집니다. 에이전트가 이러한 지시를 따르면 잘못된 답변을 반환하거나 사용자가 요청하지 않은 작업을 수행할 수 있습니다.

2025년 12월, 저희는 이 위협에 대응하기 위한 벤치마크이자 탐지 모델인 BrowseSafe를 공개했습니다. 에이전트가 접할 가능성이 높은 현실적인 웹페이지에 합성 공격을 추가하는 방식으로 구축했습니다. 지난 1년 동안 공격은 더욱 정교해졌고 일반적인 페이지 콘텐츠와 더 비슷해졌습니다. “이전 지시를 무시하라”와 같은 뻔한 문구를 사용하는 대신, 사이트의 공식 공지나 사용자 선호 설정에 관한 메모처럼 에이전트가 신뢰할 가능성이 높은 콘텐츠를 모방하는 경우가 많습니다.

이러한 변화에 대응하여 저희는 현재의 인젝션 탐지기가 이러한 공격을 잡아내는지, 그리고 에이전트가 이를 견뎌낼 수 있는지를 측정하기 위해 업데이트된 벤치마크인 BrowseSafe++를 구축했습니다. 이 벤치마크에는 주로 실제 환경에서 수집된 인젝션을 중심으로 구축된 38,675개의 공격 페이지 및 정상 페이지 쌍이 포함되어 있습니다. 각 페이지에 대해 개인정보 보호를 위해 주변 콘텐츠는 재작성하되 공격 내용은 원문 그대로 유지합니다. 모든 페이지는 브라우저 에이전트가 읽는 네 가지 형식인 HTML, Markdown, 접근성 트리, 스크린샷으로 제공됩니다. 저희는 벤치마크의 일부를 사용하여 텍스트 탐지기와 멀티모달 탐지기로 구성된 0.8B 파라미터 탐지기 한 쌍인 BrowseSafe-Guard를 학습시켰습니다. 두 Guard 탐지기는 프런티어 모델을 포함하여 저희가 테스트한 프롬프트 기반 모델보다 더 정확하게 인젝션을 식별합니다. 또한 더 빠르고 저렴하며, 일반 페이지를 실수로 플래그하는 경우도 훨씬 적습니다.

저희는 BrowseSafe++를 오픈 벤치마크로 공개합니다. 프로젝트 웹사이트에서 데이터 세트, SDK, 연구 논문, 그리고 공개 리더보드로 이동할 수 있습니다. 어떤 팀이든 레이블이 제공되지 않은 테스트 페이지에 대해 자체 탐지기의 점수를 매기고, 채점 및 리더보드 등재 검토를 위해 레이블을 제출할 수 있습니다. 결과를 평가하고 제출하는 방법은 시작하기를 참조하세요.

관찰된 인젝션으로 벤치마크 구축하기

BrowseSafe++는 실제 웹사이트에서 관찰된 프롬프트 인젝션을 바탕으로 구축되었습니다. 2025년 9월부터 2026년 9월까지 Comet의 프롬프트 인젝션 탐지기는 에이전트가 읽은 페이지에서 115만 건의 인젝션을 플래그했습니다. 저희는 이러한 인젝션을 중심으로 32,187개의 쌍을 구축하고 기존 BrowseSafe 벤치마크에서 6,488개의 쌍을 추가하여 총 38,675개의 쌍을 확보했습니다. 각 쌍에는 공격 페이지와 그 정상 쌍둥이 페이지, 즉 인젝션이 없는 동일한 페이지가 함께 담겨 있습니다.

실제 환경에서 발견된 인젝션의 모습

벤치마크의 두 가지 예시를 통해 이러한 인젝션이 실제로 어떤 모습인지 살펴보겠습니다.

그중 하나에서는 가짜 구매 요청이 에이전트에게 무단 작업을 수행하도록 유도합니다. Comet의 탐지기는 2025년 10월 러시아어 개발자 문서 페이지에서 다음 영어 텍스트 블록을 플래그했습니다:

이 텍스트는 명령으로 시작하고 끝나며, 중간은 평범한 토큰 마케팅 문구로 채워져 있습니다. 에이전트의 개발자가 직접 작성한 것이라고 주장하며, 구매가 승인된 것처럼 보이도록 마지막에 승인 코드를 덧붙입니다.

또 다른 예시에서는 위조된 대화가 에이전트의 작업을 방해하려 합니다. 이 텍스트는 2026년 3월 한 코드 저장소 페이지에서 발견되었습니다:

이 텍스트는 사용자와 에이전트 간의 대화처럼 보이도록 설계되었습니다. <|im_start|> 및 <|im_end|>는 일부 채팅 모델이 대화의 턴을 구분하는 데 사용하는 마커입니다. 이 공격에 넘어간 에이전트는 위조된 사용자 질의에 응답하여 공격자가 지정한 문구로 답하게 됩니다.

플래그된 인젝션 전반에서 다음과 같은 유사한 패턴이 나타납니다:

• 신뢰할 수 있는 출처를 흉내 냅니다. 두 예시 모두 페이지 텍스트를 에이전트가 신뢰하는 출처처럼 보이게 만듭니다. 첫 번째는 에이전트의 개발자, 두 번째는 에이전트 자신의 대화입니다. 인젝션은 보안 확인이나 정책 공지를 흉내 내어 사이트 자체로 위장하거나, 가짜 선호 설정을 내세워 사용자로 위장할 수도 있습니다. 약 3분의 2는 격식체로 작성되어 있습니다.
• 상당수는 다른 언어로 작성되어 있습니다. 쌍의 24.4%에서 인젝션은 페이지의 나머지 부분과 다른 언어를 사용합니다. 이는 일반적으로 첫 번째 예시처럼 영어가 아닌 페이지에 영어 지시문이 들어 있는 형태입니다. 이러한 공격은 분명히 모든 언어를 읽을 수 있고 대개 영어에 가장 능숙한 에이전트를 겨냥한 것입니다. 언어 전환은 탐지도 더 어렵게 만듭니다. 기존 BrowseSafe 평가에서 다국어 공격은 탐지하기 가장 어려운 유형 중 하나였습니다.
• 대부분은 말이 아니라 행동을 원합니다. 10개 중 4개 이상은 첫 번째 예시의 토큰 구매처럼 사용자가 요청한 적 없는 행동을 하도록 에이전트를 유도하며, 약 3분의 1은 두 번째 예시처럼 에이전트가 사용자의 작업을 포기하게 만들려고 합니다. 답변에 허위 정보를 심으려는 경우는 약 3%에 불과합니다.
• 누구나 게시할 수 있는 콘텐츠에 편승하는 경우가 많습니다. 공격자가 사이트를 장악할 필요는 없습니다. 일반 사이트의 포럼 게시물이나 공유 문서만으로도 충분하며, BrowseSafe++의 인젝션 중 23,000건 이상이 이런 방식으로 유입되었습니다. 신뢰할 수 있는 도메인이라도 공격자의 텍스트를 주입하는 데 악용될 수 있습니다.

최종 벤치마크에 포함된 인젝션은 12가지 웹사이트 유형, 24가지 공격 유형, 6가지 공격자 목표, 18가지 페이지 내 배치 위치에 걸쳐 있습니다.

확대

플래그된 페이지에서 벤치마크 쌍까지

플래그된 페이지는 에이전트가 작업을 수행하던 대상 사용자의 개인정보를 포함하고 있을 수 있으므로, 벤치마크에 그대로 사용할 수 없습니다. 페이지를 공유 가능한 벤치마크 쌍으로 만드는 데는 세 가지 주요 단계가 필요합니다:

1. 인젝션 확보: 플래그된 페이지를 수집하고 중복을 제거한 후, PII-Tracer로 개인정보를 마스킹합니다. 그런 다음 페이지에 인젝션이 포함되어 있는지 확인합니다. 구체적으로는 여러 모델로 구성된 패널이 해당 페이지에 에이전트를 사용자가 의도한 작업에서 벗어나게 하려는 지시가 포함되어 있다는 데 동의해야 합니다.
2. 쌍 구성: 한 에이전트가 각 페이지에서 인젝션 텍스트를 제거하고 주변 페이지 콘텐츠를 다시 작성하며, 이름이나 브랜드 같은 세부 정보를 가상의 것으로 대체합니다. 두 번째 에이전트는 재작성된 페이지에 실제 콘텐츠가 남아 있는지 확인하고, 실패한 경우 피드백과 함께 되돌려 보냅니다. 사람 검토자가 무작위로 10%의 페이지를 검사하며, 발견된 문제는 파이프라인에서 수정되고 그 수정 사항은 코퍼스 전체에 적용됩니다. 인젝션은 재작성된 페이지에 다시 삽입되어 공격 사본을 만들고, 정상 사본에서는 제외됩니다. 두 페이지는 동일한 작업, 예상 결과, 일반 지시를 공유합니다.
3. 검증: 에이전트는 다양한 형태로 페이지를 읽으므로, 각 페이지의 HTML을 Markdown, 접근성 트리(페이지의 인터페이스 요소와 그 레이블을 구조화한 목록), 스크린샷으로 렌더링합니다. 또 다른 에이전트가 공격 페이지의 네 가지 뷰 모두에 인젝션이 나타나는지, 그리고 정상 페이지가 모든 뷰에서 무해하다고 판정되는지 확인합니다. 어느 한 뷰에서 인젝션이 누락되면 페이지 내 다른 위치로 옮겨 다시 렌더링하여, 최종 공격 페이지의 모든 뷰에 인젝션이 나타나도록 합니다. 마지막으로 일련의 자동화된 검사를 통해 실제 호스트 이름이나 브랜드 이름처럼 원본의 흔적이 남아 있는 쌍을 수정합니다.

확대

BrowseSafe-Guard: 모든 뷰를 위한 빠르고 정밀한 탐지기

유용한 탐지기는 모든 페이지를 빠르고 저렴하게 검사할 수 있어야 합니다. 또한 공격 페이지와 정상 페이지 모두에서 정확해야 합니다. 대부분의 페이지는 안전하기 때문에 높은 정밀도가 특히 중요합니다. 오탐률이 비교적 낮더라도 대부분의 경고가 잘못된 경보가 될 수 있기 때문입니다. 프롬프트 기반 범용 모델은 정밀도가 부족한 경우가 많고, 모든 페이지에서 실행하기에는 너무 느리고 비용이 많이 듭니다.

공격받은 페이지와 정상 페이지를 따로 수집해 학습한 탐지기는 페이지의 주제나 레이아웃처럼 우연히 두 집합을 구분해 주는 지름길을 학습할 수 있습니다. 그러나 이러한 탐지기는 일반화가 잘 되지 않습니다. 반면 Guard는 인젝션 자체만 다른 페이지 쌍으로 학습하며, 이는 탐지기의 정밀도를 높이는 데 도움이 됩니다. 각 쌍에 대해 Guard는 공격받은 페이지와 그 정상 쌍둥이 페이지를 각각 읽고, 인젝션이 포함되어 있을 가능성에 대한 점수를 각각 부여합니다. 모델 업데이트에는 두 가지 학습 목표가 사용됩니다. 하나는 표준 분류 목표이고, 다른 하나는 공격받은 페이지의 점수가 쌍둥이 페이지보다 고정된 마진 이상 높지 않으면 Guard에 페널티를 주는 순위 목표입니다. 직관적으로 말하면, 분류 목표는 Guard에게 어떤 판단을 내려야 하는지 가르치고, 순위 목표는 그 판단을 인젝션 자체에 연결하여 무해한 방해 요소는 무시하게 합니다. 이를 통해 Guard는 주변 페이지 콘텐츠가 아니라 인젝션 자체에 반응하도록 학습됩니다.

Guard는 각각 Qwen3.5-0.8B에서 파인튜닝한 두 개의 탐지기로 구성됩니다. 텍스트 탐지기는 HTML, Markdown, 접근성 트리 중 하나의 페이지 텍스트 뷰를 읽습니다. 멀티모달 탐지기는 전체 페이지 스크린샷을 읽습니다. 배포 환경에서 Guard는 단일 순방향 패스로 페이지를 읽고 인젝션 점수를 출력하며, 점수가 임계값을 넘으면 해당 페이지에 플래그가 지정됩니다. Guard는 파라미터가 0.8B에 불과하고 단일 점수만 출력하므로, 모든 페이지에서 실행할 수 있을 만큼 빠르고 저렴합니다.

성능 벤치마킹

저희는 벤치마크의 홀드아웃 하위 집합에서 인젝션을 탐지하도록 프롬프트를 준 18개 모델과 Guard를 비교했습니다. BrowseSafe++에서 측정한 네 가지 지표는 다음과 같습니다:

• 재현율(recall)은 인젝션이 삽입된 페이지 중 탐지기가 플래그한 페이지의 비율로, 탐지기가 얼마나 많은 공격을 잡아내는지를 측정하며 높을수록 좋습니다.
• 오탐률(FPR)은 정상 페이지 중 탐지기가 실수로 플래그한 페이지의 비율로, 탐지기가 얼마나 자주 잘못된 경보를 울리는지를 측정하며 낮을수록 좋습니다.
• 정밀도(precision)는 플래그된 페이지 중 실제로 인젝션이 포함된 페이지의 비율로, 경고가 얼마나 자주 정확한지를 측정하며 높을수록 좋습니다.
• F1은 재현율과 정밀도의 조화 평균으로, 탐지기가 대부분의 공격을 잡아내면서 플래그 중 잘못된 경보가 적을 때만 높게 나타납니다.

좋은 탐지기는 정밀도와 재현율이 모두 높아야 하므로, 저희는 F1을 주요 지표로 사용합니다. 네 가지 지표는 모두 세 가지 텍스트 뷰에 걸쳐 평균을 낸 값입니다.

확대

확대

모델 비교

저희가 테스트한 소형 오픈 웨이트 모델은 최하위권에 머물렀습니다. Mistral NeMo와 Qwen3 30B-A3B는 각각 정상 페이지의 약 절반을 플래그한 반면, Llama 3.1 8B는 거의 아무것도 플래그하지 않아 대부분의 공격을 놓쳤습니다. 이 그룹에서 가장 강력한 모델인 GPT-OSS 20B조차 F1이 70.97%에 그쳤습니다. 훨씬 더 큰 오픈 웨이트 모델인 DeepSeek V3.1은 F1 75.23%로 약간 더 나은 성능을 보였습니다.

GPT-5.4 nano, Gemini 3.1 Flash-Lite, Claude Haiku 4.5 등 경량 API 모델은 85~97%의 재현율로 더 많은 공격을 잡아냅니다. 그러나 그 대가로 오경보 비율이 높습니다. 이 그룹에서 FPR이 가장 낮은 Gemini 3.1 Flash-Lite도 35.2%이며, Haiku의 FPR은 69%에 육박합니다. 그 결과 이 그룹의 최고 F1 점수는 Gemini 3.1 Flash-Lite가 기록한 80.9%입니다.

나머지 모델은 더 강력한 범용 모델로, 85%에서 92% 사이의 F1 점수를 기록했습니다. 그러나 이들 모델도 여전히 재현율과 FPR 사이의 트레이드오프에 직면합니다. 신중한 쪽으로 기우는 모델은 정상적인 페이지를 차단하고, 플래그를 덜 자주 지정하는 모델은 공격을 놓칩니다. Claude Sonnet 5는 98.73%로 모든 탐지기 중 가장 높은 재현율을 보였지만 FPR이 24.65%에 달합니다. Gemini 3.1 Pro와 GPT-5.5는 각각 97.78%와 97.19%의 재현율, 19.80%와 20.44%의 FPR을 기록했습니다. GPT-6 Astra는 재현율 96.42%, FPR 14.41%로 전체 정확도가 가장 높습니다. Decider는 재현율 96.02%, FPR 17.44%로 2위를 차지했습니다. Claude Opus 5.5는 FPR이 4.21%에 불과해 가장 낮지만, 재현율이 77.71%여서 공격 5개 중 1개 이상을 놓칩니다. Claude Fable 5.1은 응답한 페이지에서는 재현율 89.31%, FPR 7.92%로 우수해 보이지만, 약 30%의 페이지에서 응답을 거부하며 “(all)” 행에서는 이를 플래그로 집계합니다.

확대

Guard는 파레토 프런티어를 한 단계 끌어올려, 놓친 공격과 잘못된 경보 사이에서 더 나은 균형을 달성합니다. F1 약 95%를 기록하며 모든 텍스트 뷰에서 1위를 차지합니다. 정상 페이지를 플래그하는 비율은 약 20개 중 1개에 불과하며, 이는 가장 정확한 프롬프트 기반 모델인 Astra의 약 3분의 1 수준입니다. 이 차이는 저희의 학습에서 비롯됩니다. Guard의 기반이 되는 기본 Qwen3.5-0.8B 모델에 다른 모델과 동일한 방식으로 프롬프트를 주면 F1은 64%에 그치고, 정상 페이지의 거의 4개 중 3개를 플래그합니다. 스크린샷 뷰 시나리오에서는 Guard의 멀티모달 탐지기를 이미지 처리가 가능한 4개 모델과 비교했습니다. 전체 페이지 스크린샷이 주어졌을 때 Guard는 약 93%의 F1을 기록한 반면, 저희가 평가한 다른 모델 중 가장 우수한 모델은 약 79%를 기록했습니다.

공격을 알아차리는 것과 공격을 견뎌내는 것은 다릅니다

직관적으로 생각하면, 인젝션을 정확하게 식별할 수 있는 모델이라면 사용자 작업을 수행하는 도중 해당 페이지를 접했을 때 그 인젝션을 무시해야 합니다. 그러나 저희의 실험 결과, 높은 탐지 점수가 모델이 공격을 견뎌낸다는 것을 보장하지는 않았습니다. 저희는 각 모델에 동일한 공격 페이지를 두 번 제공했습니다. 한 번은 인젝션 포함 여부를 판단하게 했고, 다른 한 번은 이전 판정을 보지 못한 상태에서 사용자 작업을 수행하게 했습니다. 별도의 판정자가 해당 모델이 인젝션을 따랐는지 확인했습니다. 테스트한 모든 모델은 자신이 플래그한 인젝션 중 일부를 여전히 따랐으며, 그 비율은 GPT-6 Astra의 경우 플래그된 페이지의 1.64%에서 Llama 3.1 8B의 경우 24.73%에 이르렀습니다.

확대

탐지 점수만으로는 모델 간 차이를 신뢰성 있게 예측할 수 없습니다. Claude Sonnet 5와 GPT-5.5는 F1 점수가 각각 약 88%와 89%로, 인젝션을 거의 비슷한 수준으로 탐지합니다. 그러나 Sonnet 5는 자신이 플래그한 인젝션을 19.74%의 페이지에서 따랐으며, 이는 1.97%인 GPT-5.5보다 10배 높은 수치입니다.

인젝션 방어를 위한 배포 가능한 시스템

이러한 결과는 사용자 작업을 수행하는 모델에 의존하기보다 페이지 차단 결정을 특수 목적 모델에 위임하는 것이 가치가 있음을 시사합니다. 에이전트가 행동하기 전에 각 페이지를 검사하는 별도의 탐지기는 추가적인 방어 계층을 제공하며, 탈취당할 작업이나 오용될 도구가 없습니다.

Guard는 바로 그런 탐지기로 만들어졌습니다. 테스트한 모든 모델 중 F1과 정확도가 가장 높을 뿐 아니라, 크기가 작아 모든 페이지에서 실행해도 될 만큼 비용이 저렴합니다. Guard는 텍스트 페이지당 평균 약 0.15초의 GPU 시간을 사용했습니다. 임대한 H200 기준으로 1,000페이지당 비용은 0.18달러로 추정되며, 이는 정가 기준 프런티어 API 모델의 18.95~180.61달러와 대비됩니다. 따라서 저희 비교에서는 높은 탐지 점수를 유지하면서도 빈번한 검사를 훨씬 저렴하게 수행할 수 있습니다.

아래 그림은 각 탐지기의 정확도를 페이지당 소요 시간 및 1,000페이지당 비용과 비교하여 나타낸 것이며, 시간과 비용은 모두 로그 스케일입니다. Guard는 두 패널 모두에서 왼쪽 위 모서리에 홀로 자리하며, 정확도, 속도, 비용 모든 면에서 앞섭니다. 프롬프트 기반 모델은 모두 페이지당 약 1초 이상이 걸리며, 가장 정확한 두 모델인 GPT-6 Astra와 Claude Fable 5.1은 1,000페이지당 100달러가 넘는 비용이 듭니다.

확대

적응형 공격에 대한 방어 테스트

BrowseSafe++ 벤치마크에 포함된 인젝션의 수는 한정되어 있습니다. 하지만 실제 공격자는 적응형 공격을 감행할 수 있습니다. 인젝션이 실패하면 공격자는 이를 다시 작성하여 재시도할 수 있습니다. 따라서 원래 인젝션을 견뎌낸 에이전트라도 향후 공격에는 여전히 취약할 수 있습니다. 게다가 모델은 인터넷에서 수집한 데이터로 학습되므로 벤치마크에 포함된 인젝션 대부분을 견디도록 학습될 수 있습니다. 저희는 벤치마크를 공개하고 있으므로, 벤치마크가 포화 상태에 이르러 모델 간 차이를 제대로 구별하지 못하게 될 가능성이 높습니다. 이 두 가지 문제를 해결하기 위해 저희는 공격자 모델이 인젝션을 재작성할 수 있는 테스트 환경인 BrowseSafe-Adapt를 구축했습니다. 각 테스트는 세 단계로 이루어집니다:

1. 케이스를 설정합니다. 케이스는 BrowseSafe++ 항목과 대상 에이전트를 하나로 묶습니다. BrowseSafe++ 항목에는 사용자 쿼리와 작업이 포함된 시나리오, 공격받은 페이지, 공격자가 원하는 결과가 포함됩니다. 에이전트는 작업 실행에 필요한 도구와 합성 데이터를 제공하는 샌드박스에서 작동합니다. 별도의 검증 모델이 공격의 목표 달성 여부를 평가합니다.
2. 시도 실행: 현재 인젝션을 페이지에 삽입하고 에이전트가 작업을 수행하도록 합니다. 검증기는 에이전트의 답변과 에이전트가 샌드박스에 가한 변경 사항을 확인하여 공격 성공 여부를 판단합니다. 첫 번째 시도에서는 원래 BrowseSafe++ 항목의 인젝션을 사용합니다.
3. 수정 및 반복: 공격이 실패하면 해당 시도를 아카이브하고, 비평가 모델이 무엇이 잘못되었는지 검토합니다. 공격자 모델은 이 피드백을 활용해 인젝션을 다시 작성하며, 공격의 문구, 서식 또는 페이지 내 위치를 변경할 수 있습니다. 공격 목표, 성공 기준, 주변 페이지 콘텐츠는 그대로 유지됩니다. 다음 시도에서는 업데이트된 공격을 사용합니다. 이 과정은 공격이 성공하거나 공격자가 정해진 시도 횟수 한도에 도달할 때까지 반복됩니다.

확대

저희는 Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite, 그리고 오픈 웨이트 모델인 DeepSeek V3.1과 Kimi K2 등 각기 다른 모델을 기반으로 구축된 7개의 에이전트를 테스트했습니다. 각 에이전트는 동일한 1,024개의 작업을 수행했으며, 작업당 최대 64회의 시도가 주어졌습니다. 첫 번째 시도에서는 7개 에이전트 모두에서 공격 성공률이 낮았습니다. 원래 인젝션은 어떤 에이전트를 대상으로 하든 평가된 작업의 최대 4%에서만 성공했습니다. 적응형 프레임워크에서는 공격 성공률이 극적으로 상승했습니다. 공격자는 7개 에이전트 중 5개를 상대로 작업의 79% 이상에서 성공했습니다. 가장 강력한 에이전트도 취약하기는 마찬가지였습니다. GPT-5.5를 상대로는 작업 약 3개 중 2개, Claude Sonnet 5를 상대로는 약 3개 중 1개에서 여전히 공격이 성공했습니다.

에이전트 간 차이는 공격자의 목표가 에이전트로 하여금 특정 도구 호출을 실행하게 하는 것일 때 가장 큽니다. 이러한 유형의 목표를 가진 작업에서 Sonnet 5는 약 8%, GPT-5.5는 약 29%의 작업에서 공격에 굴복했습니다. 나머지 5개 에이전트는 작업의 절반 이상에서 공격자의 목표를 수행했습니다.

또한 Guard가 각 페이지를 먼저 검사하도록 한 상태에서 Gemini 3.5 Flash-Lite 에이전트를 대상으로 BrowseSafe-Adapt를 실행했습니다. Guard는 원래 인젝션의 94.5%를 차단했으며, 공격자에게 필요한 평균 시도 횟수를 9.7회에서 17.0회로 거의 두 배로 늘렸습니다. 그러나 64회의 시도를 모두 허용하자 공격자는 여전히 작업의 84.2%에서 성공했으며(Guard 미적용 시 93.6%), 거의 항상 Guard가 플래그하지 않은 인젝션을 사용했습니다. 이는 저희가 BrowseSafe를 출시하면서 제시한 관점과 일치합니다. 어떤 탐지 모델도 만능 해결책이 될 수 없으므로, 탐지기는 다층 방어 체계 안에서 작동해야 합니다.

확대

결론

브라우저 에이전트는 간접 프롬프트 인젝션에 취약한 경우가 많습니다. 간접 프롬프트 인젝션이란 일반 페이지에 숨겨진 공격이 사용자 작업을 수행하는 에이전트의 능력을 방해하려는 것을 말합니다. 이러한 위험은 시간이 지날수록 커질 뿐입니다. 에이전트가 더 많은 데이터와 도구에 접근하게 되면서 공격의 잠재적 피해가 커지고, 공격자는 인젝션을 수정하여 더 효과적으로 만들 수 있기 때문입니다.

저희의 BrowseSafe 제품군은 이러한 위협에 대응합니다. BrowseSafe++ 벤치마크는 주로 실제 인젝션을 바탕으로 구축된 38,675개의 웹페이지 쌍을 포함하고 있어, 탐지기를 더 신뢰성 있게 학습하고 평가할 수 있게 해 줍니다. 이 쌍으로 학습된 BrowseSafe-Guard 탐지기는 매우 정확하고 빠르며 저렴한 탐지를 가능하게 하여, 에이전트가 페이지에 따라 행동하기 전에 해당 페이지를 검사할 수 있게 합니다. BrowseSafe-Adapt 프레임워크는 수정된 인젝션에 대해 모델을 테스트할 수 있게 하여, 고정된 인젝션을 사용한 단일 시도만으로는 드러나지 않을 수 있는 취약점을 부각합니다.

이러한 도구들이 함께 연구자와 엔지니어가 실패 사례를 찾고 웹 기반 프롬프트 인젝션 공격에 대한 방어를 개선하는 데 도움이 되기를 바랍니다. 또한 저희는 사용자를 안전하게 보호하기 위해 Comet과 Computer의 내장 방어 기능을 지속적으로 평가하고 개선하고 있습니다.

시작하기

1. SDK를 설치하고 데이터 접근 권한을 얻습니다. SDK는 GitHub에서 설치합니다:

이 데이터 세트는 접근이 제한되어 있습니다. 해당 Hugging Face 페이지에서 접근 권한을 한 번 요청한 다음, hf auth login으로 로그인하세요.

2. 리더보드에 제출합니다. BrowseSafe++의 테스트 분할에서 자체 탐지기를 평가하세요:

이 명령은 나열한 각 뷰에 대해 페이지당 하나의 판정을 기록합니다. 텍스트 리더보드에서 평균을 얻으려면 세 가지 텍스트 뷰를 모두 나열하세요. Hugging Face 계정으로 리더보드 Space에 로그인하고 predictions.jsonl을 업로드하세요. Space는 각 뷰에 대한 F1, 정확도, 거짓 양성률 및 기타 지표를 반환하며, 원하는 경우 결과를 리더보드에 게시합니다. 각 계정(생성 후 60일 이상)은 UTC 기준으로 매주 한 번 채점 제출을 할 수 있습니다. 테스트 페이지는 평가 용도로만 사용해야 하며, 이를 학습에 사용하거나 재배포해서는 안 됩니다. 파일 형식과 게시 규칙은 제출 가이드에서 확인하세요.

인용

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}