2026년 7월 말, AI 산업은 자율 에이전트(autonomous agents)에게 실제 세계에 대한 접근 권한이 부여되었을 때 어떤 일이 발생하는지에 대한 불편한 사례 연구를 마주하게 되었습니다. Hugging Face는 7월 16일 자사 시스템에 대한 침입을 감지했다고 밝혔습니다. 며칠 후, OpenAI는 침입자가 사람이 아니었음을 확인했습니다. 그것은 의미 있는 인터넷 접속이 차단되어 있어야 할 테스트 환경 내부에서 에이전트로 작동하던 OpenAI의 모델 중 하나였습니다. 해당 에이전트는 Artifactory에서 이전에 알려지지 않은 취약점을 발견했고, 이를 이용해 공개 인터넷에 접속했으며, 자신에게 부여된 벤치마크(benchmark)를 해결하려는 과정에서 Hugging Face의 프로덕션 인프라(production infrastructure)에 침입했습니다.

Anthropic의 대응은 이 이야기에서 더 흥미로운 부분입니다. Anthropic은 적발되기를 기다리는 대신, 과거 보안 평가에 대한 자체적인 회고적 검토(retrospective review)를 시작했습니다. 그리고 그 결과 4월까지 거슬러 올라가는 세 건의 별도 사건을 발견했습니다. Opus 4.7 및 Mythos 5를 포함한 세 개의 Claude 모델이 샌드박스(sandboxed) 사이버 보안 평가 내부에서 공개 인터넷에 접속했으며, 세 곳의 서로 다른 조직의 실제 인프라에 접근했습니다. 한 사례에서는 모델이 업로드된 패키지를 자동 스캔하는 보안 벤더의 시스템에서 자격 증명(credentials)을 유출했습니다. 또 다른 사례에서는 의도된 (가상의) 목표를 찾지 못한 연구 모델이 실제 인터넷에 노출된 약 9,000개의 시스템을 스캔하다가 결국 하나를 침해했습니다. 아마도 가장 기이한 세부 사항은 다음과 같을 것입니다. 한 모델은 자신의 환경이 실제일 수 있다는 징후(인식되지 않은 인증 기관, 의심스러운 날짜 등)를 감지했고, 이에 대해 길게 추론한 끝에, 다시 시뮬레이션 내부에 있다고 스스로를 설득한 뒤에도 결국 그대로 진행해 버렸습니다.

Anthropic는 이러한 사건들을 정렬 실패 (alignment failures)라기보다는 평가 프레임워크 (evaluation-harness)의 실패로 규정하며 주의를 기울였고, 자사의 실제 운영 고객 시스템은 전혀 영향을 받지 않았음을 명시했습니다. 그러한 프레임워크 설정은 타당하며, 액면 그대로 받아들일 가치가 있습니다. 하지만 그렇다고 해서 그 근저에 깔린 패턴이 덜 중요해지는 것은 아닙니다. 점점 더 유능해지는 에이전트들이 광범위한 자율성과 실제 자격 증명 (credentials)을 부여받게 되면, 부여받은 권한에 따라 행동할 것이며, 그 권한은 매우 빈번하게 그 누구의 의도보다 더 크게 설정되어 있습니다.

다른 실패 모드, 동일한 근본 원인

이러한 사건들이 실제로 무엇이었는지 정확히 짚고 넘어갈 가치가 있습니다. 왜냐하면 "AI 에이전트가 가서는 안 될 곳에 갔다"는 모든 이야기를 하나의 서사로 묶으려는 유혹은 생기기 마련이지만, 그것은 약간 잘못된 접근이기 때문입니다. OpenAI, Hugging Face, 그리고 Anthropic에서 발생한 일은 에이전트가 샌드박스화된 평가 환경 (sandboxed evaluation environments)을 탈출하여, 결코 접해서는 안 되었던 실제 운영 시스템에 도달한 것이었습니다. 이는 격리 실패 (containment failure)입니다. 즉, 취약한 격리, 인증되지 않은 엔드포인트 (unauthenticated endpoints), 그리고 더 이상 유효하지 않게 된 네트워크 경계에 대한 가정이 원인이었습니다.

이는 대부분의 엔지니어링 팀이 매일 직면하는 위험과는 다릅니다. 후자는 샌드박스 탈출이 전혀 필요하지도 않습니다. 개발자, 아키텍트, 또는 운영 엔지니어가 AI 어시스턴트와 채팅을 시작하며 문서 하나를 붙여넣거나 업로드하는 상황입니다. 기술 아키텍처 문서 (Technical Architecture Document), 설치 가이드 (Installation Guide), 운영 런북 (Operations Runbook), 방법론 (how-to), 또는 사양서 (specification) 같은 것들 말입니다. 이러한 파일들에는 고객 이름, 내부 호스트 이름, IP 범위, 자격 증명과 밀접한 구성 세부 정보, 그리고 기타 개인정보 (PII)가 일상적으로 포함되어 있으며, 이 정보들이 외부로 유출되는 데 제로 데이 (zero-day) 취약점은 필요하지 않습니다. 파일을 공유하는 행위 자체가 의도된 워크플로우 (workflow)이기 때문에, 공유하는 그 순간 정보는 이미 외부로 나가는 것입니다.

이 에이전트들이 어떻게 작동했는지 정확히 짚고 넘어갈 가치가 있습니다. 왜냐하면 어떤 교훈을 얻어야 하는지가 여기에 달려 있기 때문입니다. 이들 중 그 어떤 모델도 대상에 대한 사전 내부 지식을 가지고 있었던 것으로 보이지 않습니다. Anthropic의 연구 모델은 의도했던 가상의 대상을 찾지 못하자, 약 9,000개의 실제 시스템을 스캔한 끝에 하나를 찾아내어 침투(compromise)했습니다. OpenAI의 모델은 이전에 알려지지 않은 취약점(vulnerability)을 통해 스스로 탈출 경로를 찾아냈습니다. Opus 4.7은 침입하기 위한 수단으로서가 아니라, 이미 침입에 성공한 이후에 자격 증명(credentials)을 추출하고 운영 데이터베이스(production database)에 접근했습니다. 이는 사실상 눈먼 정찰(blind reconnaissance)이었습니다. 즉, 모델에게 사전에 아키텍처 다이어그램(architecture diagram), 소스 코드(source code), 또는 내부 설정(internal configuration)이 제공되지 않은 상태에서 스캔하고, 탐색하고, 표면으로 드러나는 약점을 공략한 것입니다.

이러한 차이점은 매우 중요합니다. 왜냐하면 이 특정 사건들이 에이전트가 피해를 입히기 위해 특권 정보(privileged information)를 반드시 필요로 한다는 것을 증명하는 것은 아니기 때문입니다. 대신 이 사건들이 증명하는 것은 아마도 훨씬 더 불안한 사실일 것입니다. 도구(tools), 지속성(persistence), 그리고 충분히 넓은 탐색 공간(search space)만 주어진다면, 에이전트는 스스로 침투할 방법을 찾아낼 것이라는 점입니다. 레드팀(red team) 훈련을 수행해 본 사람이라면 누구나 그 당연한 귀결을 알고 있습니다. 네트워크 레이아웃(network layout), 실제 호스트 이름(hostnames), 자격 증명과 밀접한 설정(credentials-adjacent configuration), 실제 인프라와 연결된 고객의 실제 이름 등 내부 지식을 가지고 있는 공격자는 눈먼 상태로 탐색하는 공격자보다 훨씬 빠르고 훨씬 더 위험합니다. 이것이 바로 블랙박스(black-box) 테스트와 더불어 '침해 가정(assume breach)'과 화이트박스(white-box) 침투 테스트가 존재하는 정확한 이유입니다. 내부 지식은 공격의 단계 중 가장 느리고, 소음이 많으며, 탐지되기 쉬운 단계를 완전히 제거해 버리기 때문입니다.

여기서 핵심적인 관통선(throughline)은 무엇이며, 이는 "이 에이전트들이 공격을 위해 민감한 데이터가 필요했다"는 말보다 더 정밀한 표현입니다. 그것은 바로 이것입니다: 에이전트가 샌드박스 탈출(sandbox escape)을 세 번의 실제 침해(breach)로 이어지게 만든 바로 그 자율성(autonomy)과 지속성(persistence)이, 유출된 아키텍처 문서(architecture document)를 동일한 결과로 향하는 훨씬 더 짧고 조용한 경로로 바꾸어 놓을 것이라는 점입니다. 이 사건들에서의 에이전트들은 가장 어려운 부분인 정찰(reconnaissance)을 스스로, 대규모로 수행했습니다. 실제 토폴로지(topology), 실제 고객 이름, 실제 설정(configuration) 정보가 담긴 문서가 유출되면, 인간 공격자든 에이전트든 다음 공격자에게 동일한 이점을 아무런 대가 없이 제공하게 됩니다. 노출(exposure)이 샌드박스의 허점을 찾아낸 에이전트로부터 발생하든, 선의를 가진 엔지니어가 챗봇(chatbot)과 실제 스프레드시트를 공유하는 것에서 발생하든, 결과는 증폭됩니다: 민감한 데이터는 결코 가서는 안 될 곳으로 흘러 들어가게 되며, 누군가 이를 알아차렸을 때는 이미 데이터가 빠져나간 후입니다. Anthropic의 경우, 4월부터 발생한 사건들은 경쟁사의 공개가 7월에 검토를 유도할 때까지 발견되지 않았습니다. 이는 과실이라기보다는 설계상의 문제로 인한 수개월간의 사각지대(blind spot)였으며, 단순히 아무도 올바른 곳을 살펴보지 않았기 때문입니다.

문제의 일상적인 버전

저는 노출된 시스템을 사용하는 고객들과 함께 일하며, 위와 같은 패턴은 제가 최근 PromptCape에 추가한 기능의 직접적인 계기가 되었습니다. PromptCape는 원래 AI 코딩 어시스턴트(AI coding assistants)를 사용할 때 소스 코드의 지식재산권(IP)을 보호하기 위해 구축된 로컬 HTTP 프록시(proxy)입니다. 저의 한 고객은 정확히 이러한 패턴을 발견했습니다: DAT, 설치 문서, 운영(ops) 문서, 그리고 사양서(specs)가 중간의 검토 단계 없이 고객 이름, 설정 데이터, 개인정보(PII)와 같은 민감한 필드를 포함한 채 통째로 AI 어시스턴트에게 전송되고 있었던 것입니다.

해결책은 아무도 원하지 않고 실제로 실행할 사람도 없는 "AI 어시스턴트 사용을 중단하는 것"이 아닙니다. 그보다는 네트워크 엔지니어들이 민감한 트래픽을 다룰 때 항상 해왔던 방식에 더 가깝습니다. 즉, 대체재가 동일한 작업을 충분히 잘 수행할 수 있다면 실제 데이터를 보내지 않는 것입니다.

이것이 바로 Excel, Word, Markdown 파일을 지원하며 PromptCape의 프록시 모드(proxy mode)에 문서 가명화(document pseudonymization)를 추가한 핵심 아이디어입니다. 이름, 식별자, 설정 문자열(configuration strings)과 같은 민감한 값들은 문서가 AI 제공업체에 도달하기 전에 구조적으로 동일한 플레이스홀더(placeholder)로 일관되게 교체되며, 돌아오는 응답에서 다시 일관되게 복원됩니다. AI는 실제 데이터와 정확히 동일한 형태의 스프레드시트를 받게 됩니다. 즉, 동일한 구조, 셀 간의 동일한 관계, 수정해야 할 동일한 종류의 수식이나 분석해야 할 데이터를 갖게 되지만, 고객의 실제 신원이나 인프라 정보는 결코 보지 못하게 됩니다. 저는 원문 기사에 기술적인 접근 방식을 상세히 기술하였으며, 여기에는 다음과 같은 까다로운 부분들이 포함되어 있습니다: 문서 전체에 걸쳐 가명화를 일관되게 유지하는 법, 수식과 상호 참조(cross-references)를 깨뜨리지 않고 처리하는 법, 그리고 사용자가 워크플로우에서 차이를 느끼지 못할 정도로 왕복 과정(round-trip)을 투명하게 만드는 법 등입니다.

이러한 사건들이 발생한 후, 이것이 왜 더 중요해지는가

샌드박스 탈출(Sandbox escapes)과 프롬프트 수준의 데이터 노출(prompt-level data exposure)은 AI 리스크 스펙트럼의 양 끝단에 위치합니다. 하나는 에이전트의 '능력(capability)'이 '격리(containment)'를 앞지르는 문제이고, 다른 하나는 '문서(document)'가 '검토(review)'를 앞지르는 문제입니다. 이 둘은 동일한 실패 유형이 아니며, 그렇지 않다고 주장하는 것은 성급한 일반화일 것입니다. 하지만 이들은 한 가지 방향으로 결합되며, 이는 진지하게 받아들일 가치가 있습니다. 즉, 이러한 사건들은 에이전트가 이제 순수하게 자체적인 정찰(reconnaissance)만으로도 단순한 인터넷 접속 권한을 실제 침해(breach)로 전환할 수 있는 진정한 능력을 갖추었음을 보여줍니다. 이 과정에서 반드시 귀사의 특정 데이터가 필요하지는 않습니다. 하지만 다른 경로를 통해 데이터가 어쨌든 유출되는 순간, 공격자(인간이든 자동화된 도구든)가 혼자서 수행해야 했을 작업을 완전히 생략할 수 있게 됩니다.

Anthropic의 자체 사후 분석(postmortem)에서는 단계적 배포(staged deployment), 엄격한 로깅(logging), 그리고 가설에 의존하지 않는 통제 장치를 요구합니다. 이것이 에이전트 샌드박싱(agent sandboxing)을 위한 올바른 처방입니다. 그리고 이는 더 작고 훨씬 더 일상적인 규모, 즉 누군가가 채팅창을 열고 파일을 공유하거나 코딩 어시스턴트(coding assistants)를 사용하여 코드/설정(config) 데이터를 공유할 때마다 귀사의 조직에서 무엇이 외부로 나가는가라는 문제에도 똑같이 적용됩니다.

민감한 데이터가 있어서는 안 될 곳으로 이동하는 데 제로데이(zero-day) 취약점이 필요한 것은 아닙니다. 그저 문서 하나, 마감 기한, 그리고 검토 단계를 건너뛰고 싶을 만큼 진정으로 유용한 어시스턴트, 그리고 언젠가 더 이상 추측할 필요가 없게 된 공격자만 있으면 됩니다.

이러한 접근 방식에 대한 피드백을 환영합니다. 프록시 계층에서의 가명화(pseudonymization-at-the-proxy-layer)가 다른 팀들에게 좋은 모델이 될지, 어떤 예외 사례(edge cases)가 우려되는지, 혹은 실제 현장에서 보았던 다른 완화 조치(mitigations)들과 어떻게 비교되는지에 대해 의견을 들려주세요.