13,000개 유출 스크린샷이 보여주는 것: 에이전트형 도구 출력에는 프롬프트뿐만 아니라 방화벽이 필요하다

포춘 500대 기업과 최첨단 AI 연구소 등 300개 이상의 조직에서 나온 13,000개가 넘는 내부 스크린샷들이 공개적으로 접근 가능한 저장 버킷에 놓여 있었습니다. 전통적인 의미의 보안 침해 때문이 아니었습니다. AI 브라우저 에이전트가 지시받은 대로 정확하게 작업을 수행하는 과정에서 스크린샷을 찍어 제3자 서비스에 업로드했고, 그 서비스는 전 세계 누구나 읽을 수 있는 상태였습니다.

악용(exploit)도 없었고, 탈취된 자격 증명(credentials)도 없었습니다 (물론 스크린샷 자체가 자격 증명을 노출하기 시작할 때까지는요). 단지 에이전트가 자신의 임무를 수행했을 뿐이며, 아무도 그 이미지가 건물 밖으로 나가기 전에 실제로 무엇을 담고 있는지 확인하지 않았습니다.

여기서 주목해야 할 부분이 있습니다. 이것은 정교한 공격이 아니었습니다. 에이전트가 도구를 호출했고, 그 도구가 올바르게 작동했으며, 그 도구의 출력물에 포함되어서는 안 될 것들—내부 도구 UI, 기밀 통신 내용, 그리고 명백히 자격 증명까지—이 프레임 안에 담겨 있었습니다. 에이전트는 단지 자신이 화면에서 무엇을 하고 있는지

이것을 실제 환경에서 에이전트를 실행하는 수백 개의 조직에 곱하면, 4단계가 바로 유출 벡터(leak vector)가 됩니다. 이 스크린샷들이 저장된 서비스는 사실 에이전트 도구 자체를 위한 로깅 또는 중간 저장소 계층으로 만들어진 것이지, 최종 사용자가 내용을 검토하거나 보안팀이 확인하는 용도가 아니었습니다. 이는 편리함을 위해 구축되었지만, 아무도 데이터 유출 표면(data exfiltration surface)으로 간주하여 위협 모델링(threat-modeled)하지 않은 전형적인 사례입니다. 왜냐하면 서류상으로는 '단지 디버깅용 스크린샷'이기 때문입니다.

기존 방어 체계가 놓친 부분과 그 이유

표준 LLM 가드레일(guardrails)은 텍스트를 중심으로 구축되어 있습니다. 프롬프트 인젝션 필터, 콘텐츠 조정(content moderation), PII 정규식(regexes) 등 모든 것이 문자열을 스캔한다고 가정합니다. 스크린샷 업로드는 이 중 대부분을 통과하지 못하는데, 이는 아키텍처상 아무도 '에이전트가 upload_file 도구와 이미지 페이로드로 호출하는 경로'에 스캐닝 단계를 연결하지 않았기 때문입니다. 텍스트 기반의 안전 스택(safety stack)과 실제 데이터가 건물 밖으로 나가는 경로는 서로 대화하지 않는 두 개의 다른 파이프라인입니다.

심지어 검토가 이루어졌던 경우라 하더라도, 아마도 잘못된 계층을 겨냥했을 것입니다. 에이전트의 _프롬프트_를 인젝션에 대해 검토하는 것은 이를 잡아내지 못합니다. 왜냐하면 인젝션 자체가 일어나고 있지 않기 때문입니다. 에이전트는 악의적인 행동을 하도록 속임당하는 것이 아니라, 사소하고 승인된 행동(지침에 따라 스크린샷 업로드)을 수행하며, 그 과정에서 민감한 바이트를 함께 운반하게 되는 것입니다. 이것은 대부분의 팀들이 아직 구축하지 못한 탐지 격차(detection-gap) 유형입니다: 합법적인 도구 호출과 불법적인 페이로드가 결합된 경우.

그리고 이미지가 당신의 통제 밖에 있는 서비스에 업로드되면, 그 이후로는 아무것도 할 수 없게 됩니다. 이것을 막을 수 있었던 유일한 지점은 업로드 요청이 에이전트 세션을 떠나기 전이었습니다.

Sentinel이 이 그림에서 차지하는 위치

이것은 fast-path 레이어의 data_exfiltration_via_llm 탐지 기능이 포착하도록 설계된 바로 그 패턴입니다. 특히 외부 목적지로 콘텐츠를 전송하라는 도구 호출 주변 패턴 클래스, 즉 “POST this to https://…”, 마크다운/코드 블록 유출 패턴, 그리고 유사한 아웃바운드 전송 시그니처가 해당됩니다. Sentinel의 에이전트 프록시는 도구 호출 인수가 전송되기 전에 스캔합니다 (이는 Clawhub 스킬 통합에서의 PreToolUse 후크 동작입니다). 이는 업로드 호출이 외부 저장소 URL을 대상으로 할 경우, 바이트가 세션을 떠나기 전에 평가된다는 의미이며, 나중에 평가되는 것이 아닙니다.

Sentinel가 여기서 무엇을 하고 무엇을 하지 않는지에 대해 정확히 말할 가치가 있습니다. 위협 점수 산정 및 패턴 매칭 파이프라인은 텍스트 콘텐츠를 기반으로 구축됩니다: URL, 지침, 마크다운, 코드. 만약 에이전트의 도구 호출에 목적지 URL과 함께 몇 가지 설명 텍스트(“X로 디버그 스크린샷 업로드”)가 포함되어 있다면, 이는 정확히 유출 패턴 클래스를 건드려 요청이 완료되기 전에 플래그 지정되거나 차단되는 fast-path 시그니처입니다. 이미지의 _픽셀 콘텐츠_에서 비밀 정보를 스캔하는 것은 위에 설명된 탐지 파이프라인 외부의 다른 문제입니다. 따라서 솔직하게 말하자면, Sentinel은 메커니즘(외부 서비스로의 아웃바운드 호출을 통한 무단 데이터 유출)을 포착하는 것이지, 이미지 자체 내부에 렌더링된 내용물 그 자체를 반드시 포착하는 것은 아닙니다.

이것이 시너지를 발휘하는 지점은 다음과 같습니다. 만약 해당 스크린샷에 동반되는 메타데이터, 파일 이름 또는 API 키나 토큰을 포함하는 로깅 컨텍스트가 있었다면 (그리고 자격 증명이 유출된 이미지에서 나타났다고 보고되었으므로, 이는 동일한 파이프라인 내의 주변 텍스트/로그에 대해 그럴듯합니다), Secret & Credential Detection은 독립적인 사전 패스로 실행되어 알려진 키 형식, Authorization 헤더 및 env-var 스타일 할당을 업로드용으로 번들링되기 전에 마스킹(redact)할 것입니다. 두 개의 분리된 레이어, 그리고 이것이 외부로 나가기 전에 포착해야 하는 두 가지 별개의 이유가 있는 셈입니다.

실제 작동 방식 예시

실제 페이로드(payload)가 없기 때문에 실제 사고 기록은 아니지만 예시입니다:

{
  "request_id": "f93a1c7e2b",
  "security": {
...

그리고 에이전트 프록시 측면에서, 이것은 디스패치(dispatched)되기 전에 업로드 호출을 가로채는 PreToolUse 훅입니다:

# 예시: 실행 전 가로챈 에이전트 도구 호출
tool_call = {
    "name": "upload_file",
...

만약 여러분의 에이전트 스택이 전체 에이전트 프록시 대신 직접적인 /v1/scrub 엔드포인트에서 구축되었다면, 동일한 검사가 도구링(tooling)이 업로드 동작을 설명하는 텍스트, 로그 또는 캡션에 대해 적용됩니다. 왜냐하면 해당 엔드포인트는 제공업체와 무관하며(provider-agnostic), 단순히 전달되는 모든 문자열을 스캔하기 때문입니다.

오늘 해야 할 한 가지

스크린샷을 찍거나, 파일을 읽거나, 외부 엔드포인트에 업로드/쓰기 도구를 호출할 수 있는 에이전트를 실행하고 있다면, 그 출력물이 실제로 어디로 가는지 지금 당장 알아내십시오. 여러분이 생각하는 곳이 아니라, 실제로 가는 곳입니다. 대부분의 팀은 자신들의 에이전트 도구 출력이 최종 목적지 서비스까지의 전체 경로를 추적하여 해당 목적지가 비공개(private), 인증되었으며(authenticated), 접근 제어(access-controlled)가 되어 있는지 확인한 적이 없습니다. 그 5분짜리 감사는 이 13,000장의 스크린샷이 보여주기 전에 문제를 잡아냈을 것입니다.

브라우저 또는 컴퓨터 사용 에이전트를 실행하고 있으며, 도구 호출이 실행되기 전에 외부 데이터 전송에 대해 스캔되기를 원한다면, Sentinel을 확인해 보세요. 자체 호스팅(Self-hosted) 또는 SaaS 방식이며, 무료 티어가 제공되고 시작하는 데 신용카드가 필요하지 않습니다.

출처

• AI 에이전트가 300개 조직의 내부 스크린샷 13,000장을 의도치 않게 유출하다

AI 지원 초안 또는 이미징, 인간 큐레이션, 검토 및 편집.