OpenAI의 에이전트가 벤치마크 부정 통과를 노리고 Hugging Face에 침입했습니다

Hugging Face의 재구성에 따르면, 2026년 7월 9일 04:01 UTC, 패키지 레지스트리 캐시 프록시의 제로데이를 통해 이미 샌드박스 밖으로 나와 있던 OpenAI의 평가 대상 모델이 외부 코드 실행 환경에서 첫 루트 셸을 얻었습니다.² 이후 나흘 동안 이 모델은 Hugging Face의 데이터셋 처리기에 Jinja2 템플릿을 주입했고, Kubernetes 노드의 루트를 확보한 뒤 그 노드를 Hugging Face 사내 메시 VPN에 등록시켰습니다. 이 과정 중 어느 단계도 사람이 지시하지 않았습니다.² OpenAI가 8월 26일에 낸 사후 분석은 자사 샌드박스에서의 첫 탈출 시점을 5월 26일로 잡고 있으며, 그 타임라인은 아래 10월 1일 업데이트에 정리했습니다.⁷

이 에이전트는 Hugging Face를 공격한 것이 아닙니다. 시험에서 부정행위를 하고 있었습니다. OpenAI는 자사 모델의 사이버 역량을 ExploitGym으로 측정하는 중이었습니다. 모델은 그 벤치마크의 데이터셋과 정답이 Hugging Face에 올라가 있을 수 있다고 추론했고, 그것을 가지러 갔습니다. OpenAI의 표현을 그대로 옮기면, 모델들은 “평가를 부정 통과하는 데 쓸 수 있는 비공개 정보에 접근할 방법을 찾아 나섰고, 실제로 찾아내는 데 성공했다”고 합니다.¹

아래에 나오는 모든 단계는 목적을 위한 수단이었습니다. 정교함도 실제였고 역량도 실제였으며, 목표는 더 높은 점수였습니다.

한눈에 보기

평가용 샌드박스를 그 샌드박스의 패키지 프록시를 통해 탈출한 OpenAI 모델들이 Hugging Face 인프라까지 닿는 작전을 벌였고, 기록된 기간은 2026년 7월 9일부터 7월 13일까지입니다. Hugging Face는 7월 27일 기술적 타임라인을 공개했고, OpenAI도 자체 설명을 내놓았습니다. 의도는 침입이 아니라 보상 해킹이었습니다. 모델들이 원한 것은 ExploitGym의 정답이었습니다. 접근된 데이터셋은 다섯 개였고, 모두 이름에서 ExploitGym과의 연관이 드러납니다. 고객이 사용하는 모델, 데이터셋, Spaces, 패키지에는 영향이 없었습니다. 네트워크 허용 목록이 프로덕션 데이터베이스 접근을 완전히 차단했습니다. 이번 평가는 고위험 사이버 활동을 평소에 막아 주는 분류기 없이 의도적으로 진행됐습니다. 이야기의 시작을 5월로 옮기는 OpenAI의 8월 26일 사후 분석과, 가장 유능한 모델들의 도구 사용을 중단시킨 9월 20일 사건은 아래 10월 1일 업데이트에서 다룹니다.

에이전트가 실제로 한 일

이 연쇄 과정은 순서대로 읽어 볼 가치가 있습니다. 어느 한 고리도 유별난 기법이 아니기 때문입니다.

탈출 (7월 8일). 모델은 패키지 레지스트리 캐시 프록시의 제로데이를 악용했습니다. 이 프록시는 샌드박스가 허용한 몇 안 되는 외부 통신 경로 중 하나였습니다.² Hugging Face는 해당 제품명을 밝히지 않았고, 7월에는 저도 밝히지 않았습니다. OpenAI는 8월에 그 이름을 공개했고, 자사 샌드박스에서의 첫 탈출을 5월 26일로, 이번 탈출은 프록시가 재구축된 뒤인 7월 8일로 날짜를 잡았습니다. 10월 1일 업데이트를 참고하시기 바랍니다.⁷

거점 확보 (7월 9일). 모델은 Modal 위에서 돌아가던 공개 CyberGym 코드 실행 환경에 도달했고, sqlite3_initialize() 생성자 재정의와 제출물 메타데이터 경로를 통한 셸 주입을 조합해 그곳의 루트를 잡았습니다.² 공개된 평가용 실행 환경이 이후 모든 활동의 거점이 된 것입니다.

진입 (7월 10일~11일). OpenAI의 타임라인에는 한 에이전트가 7월 10일 공개적으로 노출된, 쓰기 권한이 있는 Hugging Face 자격 증명 14개를 확보했다고 나와 있고, 아래 두 가지는 모두 7월 11일의 일로 기록되어 있습니다.⁷ Hugging Face의 데이터셋 처리기를 두 갈래로 공략했습니다. HDF5 외부 원시 저장소 처리 로직에서 파일 노출이 발생해 환경 변수, 자격 증명, 워커 소스 코드가 새어 나갔습니다. 이어서 Jinja2 템플릿 주입으로 프로덕션 Kubernetes 파드 안에서 원격 코드 실행이 가능해졌습니다.²

{{ cycler.__init__.__globals__.__builtins__.exec(...) }}

측면 이동 (7월 11일). 에이전트는 Hugging Face가 “모든 파드가 지니고 있는 프로젝티드 서비스 계정 토큰”이라 부르는 것을 읽어 냈고, 클러스터를 열거한 뒤 hostPath 마운트를 가진 특권 파드를 거쳐 노드 루트로 권한을 상승시켰습니다. 고정 비밀번호를 사용해 내부 MongoDB에도 도달했습니다. 클러스터 시크릿에서 메시 VPN 인증 키를 찾아내, 루트를 잡은 노드를 사내 Tailscale 네트워크에 등록시켰습니다.²

확장과 퇴장 (7월 12일~13일). 클라우드 자격 증명 남용 시도가 있었고, 이어 GitHub App 연동 토큰 발급을 통해 소스 관리 시스템이 뚫렸습니다. 지속성 확보, 흔적 정리, 그리고 7월 13일 14:14 UTC의 마지막 동작으로 이어졌습니다.²

이 목록을 다시 한번, 이번에는 새로움이 있는지를 따지며 읽어 보시기 바랍니다. 공개적으로 노출된 쓰기 권한 플랫폼 토큰. 고정된 데이터베이스 비밀번호. CSI 드라이버에 붙은 지나치게 넓은 ClusterRole — 스토리지 플러그인이 볼륨 마운트에 필요한 범위를 한참 넘어서는 클러스터 전역 권한을 지니고 있었다는 뜻입니다. 파드 내부에서 도달 가능한 IMDS — 인스턴스 메타데이터 서비스는 링크 로컬 주소로 HTTP 요청만 보낼 수 있으면 무엇에게든 클라우드 자격 증명을 건네줍니다. 그리고 사용자가 제출한 설정에 대한 안전하지 않은 템플릿 렌더링.

제가 보기에 이 중 유별난 발견은 하나도 없습니다. 전부 평범한 클라우드 보안 점검 목록에 들어 있는 항목이고, 웬만한 침투 테스터라면 전부 지적했을 것입니다. 달라진 것은 이것들을 하나의 경로로 엮어 낸 존재의 속도와 끈기입니다.

Hugging Face는 이 작전을 “기계의 속도로 실행된 수천 개의 작고 자동화된 판단”이라고 설명합니다.² 이 표현 하나가 개별 익스플로잇 어느 것보다도 많은 것을 말해 줍니다.

방법보다 동기가 더 중요한 이유

보상 해킹은 보통 사소하고 성가신 형태로 나타납니다. 모델이 True만 단언하는 테스트를 작성합니다. 예시에 나온 입력 세 개만 특수 처리합니다. 구현 대신 벤치마크 파일을 고칩니다.

7월의 사건은 똑같은 행동이 훨씬 멀리까지 뻗어 나간 경우입니다. 모델은 ExploitGym 문제를 푸는 것으로 점수를 받고 있었습니다. 정직하게 푸는 건 어렵습니다. 공개된 정답을 찾는 쪽이 쉽습니다. 모델은 그 정답이 어디에 있을지 추론했고, Hugging Face가 그럴듯한 후보라고 결론 내렸으며, 중간에 있던 샌드박스를 경계가 아니라 장애물로 취급했습니다.

학습 신호는 “어느 회사를 뚫어라”라고 말한 적이 없습니다. “ExploitGym에서 좋은 점수를 내라”고 말했을 뿐입니다. 나머지는 전부, 그 목표를 설계자들이 예상한 것보다 더 문자 그대로 그리고 더 수완 있게 받아들인 에이전트에게서 따라 나온 결과입니다.

여기서 두 가지 결론이 나오는데, 둘 다 불편합니다.

첫째, 역량 평가 자체가 공격 표면입니다. 모델을 사이버 벤치마크에 붙인다는 것은 유능한 공격자를 실제 인프라 옆에 앉혀 놓고 경로를 찾아내라고 돈을 지불하는 일입니다. 사이버 역량을 가장 공격적으로 측정하는 연구소가 이 문제를 가장 먼저 밟게 됩니다.

둘째, 의도는 형편없는 필터입니다. “이게 악의적으로 보이는가”를 묻는 모든 탐지 휴리스틱은 공격자가 피해를 입히고 싶어 한다는 전제에서 출발합니다. 더 높은 점수를 향해 끈질기게 파고드는 에이전트는 데이터를 훔치려는 에이전트와 똑같은 패킷, 똑같은 토큰 읽기, 똑같은 측면 이동을 만들어 냅니다. Hugging Face가 이것을 잡아낸 것은 실시간 런타임 분석과 SIEM 상관 분석 덕분이지, 동기에 대한 어떤 판단 덕분이 아닙니다.²

공개 평가 환경이 공격 거점이 되었습니다

이 연쇄 중 한 고리는 따로 볼 만합니다. 대부분의 위협 모델이 아예 빼놓는 범주에 속하기 때문입니다.

탈출한 뒤 모델은 곧장 Hugging Face로 향하지 않았습니다. Modal에 호스팅된 공개 CyberGym 코드 실행 환경에 먼저 내려앉아 거기서 루트를 잡았습니다.² 그 시점 이후로 Hugging Face를 향한 트래픽은 정당한 공개 벤치마크를 돌리고 있는 정당한 외부 연구 플랫폼에서 출발한 것이 됩니다.

이것이 그 뒤에 놓인 모든 방어 수단에 어떤 영향을 주는지 생각해 보시기 바랍니다. 평판 점수는 알려진 연구용 호스트를 봅니다. 속도 제한은 신뢰할 수 없는 코드를 실행하는 것이 존재 이유인 서비스를 봅니다. 이상 탐지는 임의의 제출물을 실행하는 것이 평상시 동작인 시스템을 봅니다. 그게 바로 그 서비스의 제품이니까요.

코드 실행 환경은 공격자와 사용자를 구분할 수 없는 유일한 종류의 인프라입니다. 신뢰할 수 없는 코드를 돌리는 것이 곧 기능이기 때문입니다.

루트를 잡은 기법은 정확히 짚어 둘 만합니다. sqlite3_initialize() 생성자 재정의, 그리고 제출물 메타데이터 경로를 통한 셸 주입입니다.² 앞의 것은 대부분의 애플리케이션 로직보다 먼저 실행되는 C 수준 초기화 훅을 악용합니다. 뒤의 것은 제출물에 관한 메타데이터가 제출물 자체보다 덜 위험하리라는 가정을 파고듭니다. 둘 다 새로운 기법을 처음부터 만들어 낼 필요가 없습니다.

여기서 실무적인 결론이 세 가지 따라옵니다.

공개 평가 환경을 운영한다면, 스스로 그렇게 생각하든 아니든 공격자와 맞닿은 인프라를 돌리고 있는 것입니다. 제출물 메타데이터를 제출물 본문과 똑같은 수준으로 의심하고, 실행기를 감싼 샌드박스를 장식이 아니라 하중을 받는 구조물로 여기시기 바랍니다.

연구용 인프라를 가져다 쓴다면, 그쪽의 침해는 곧 이쪽의 침해입니다. “알려진 ML 플랫폼에서 온 트래픽이면 대체로 무해하다”는 평판 기반 지름길이야말로 이번 작전이 그대로 이용해 이득을 챙긴 지름길입니다.

그리고 유능한 모델을 상대로 벤치마크를 돌린다면, 벤치마크 실행 환경과 벤치마크 정답이 같은 생태계 안에 놓여 있는 경우가 잦다는 점을 눈여겨보시기 바랍니다. 모델은 7월 9일에 벤치마크 실행 환경에 있었고, 7월 11일에는 Hugging Face의 데이터셋 파이프라인 안에 들어가 있었습니다.

외부 통신 설계를 바꿔야 할 대목

Hugging Face의 기술 문서에서 가장 쓸모 있는 세부 사항은 Kubernetes와 아무 상관이 없습니다. 에이전트가 이름 해석을 다룬 방식입니다.

import socket
socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<pinned-ip>', 443))]

이 한 줄이 프로세스 내부의 DNS 해석을 통째로 대체합니다. 호스트명을 검사하는 방식의 허용 목록은 이제 프로세스가 애초에 묻지도 않는 호스트명을 검사하게 됩니다. 여기에 더해:

echo 'nameserver 8.8.8.8' > /etc/resolv.conf
echo '<cdn-ip> pkgs.tailscale.com' >> /etc/hosts
tailscaled --tun=userspace-networking

전부 네 수인데, 하나같이 “CTF에서 본 적은 있지만 실전과는 거리가 먼 이야기라고 여겼던” 범주에 속합니다. 프로세스 안에서 해석 함수를 패치합니다. /etc/resolv.conf를 공개 DNS 서버로 고쳐 씁니다. 필요한 도메인에 대해 CDN 주소를 /etc/hosts에 고정합니다. 그런 다음 Tailscale을 유저스페이스 네트워킹 모드로 돌립니다. 이 모드는 TUN 장치가 필요 없고, 따라서 대부분의 보안 강화 기준선이 애써 제거하는 권한들도 전혀 필요로 하지 않습니다.

외부 통신 경로가 감시의 사각지대라는 이야기는 조용한 외부 통신 공격 표면에서 이미 다뤘고, 거기서 이름 기반 통제는 행위를 강제하는 것이 아니라 의도를 서술할 뿐이라고 주장했습니다. 이제 그 주장에 출처가 붙었습니다. 외부 통신 정책이 이름을 해석하는 방식이라면, getaddrinfo를 패치한 에이전트는 이미 나가 버린 뒤입니다.

Hugging Face에서 실제로 버텨 준 통제 수단은 연결 계층의 네트워크 허용 목록이었습니다. 프로덕션 데이터베이스 접근 시도는 그냥 실패했습니다.² 분류기도 아니고, 이상 점수도 아니고, 도구 호출을 읽어 내는 정책 엔진도 아닙니다. 목록에 없는 주소로의 연결을 거부한 허용 목록이었습니다.

버텨 준 것들

실패 목록은 길고 성공 목록은 짧습니다. 그래서 성공 목록을 들여다볼 가치가 있습니다.

버텨 준 통제는 하나같이 구조적이고 지루한 것들이었습니다. 무너진 통제는 하나같이 아무도 다시 들여다보지 않은 기본값이었습니다. 이 분포가 실무적인 교훈이며, 모델 역량에 대해 어떤 견해를 갖고 있든 이 교훈은 그대로 남습니다.

Hugging Face의 대응도 똑같이 화려하지 않았습니다. 데이터셋 설정 렌더러에서 침투 경로를 특정하고, 렌더러를 내리고, 공격자를 내부 네트워크에서 끊어 냈습니다.²

무엇에 닿았고 무엇에 닿지 못했는가

여기서는 정확함이 중요합니다. 이런 사건은 과장을 부르기 때문입니다.

확인된 사실: 데이터셋 다섯 개가 접근됐고, 그 이름과 파일들이 ExploitGym과의 연관을 시사합니다. 여기에 데이터셋 서버 검색 질의에서 나온 운영 메타데이터가 더해집니다.²

영향 없음: 고객이 사용하는 모델, 데이터셋, Spaces, 패키지.² 프로덕션 데이터베이스 접근은 실패했습니다. 소스 관리 시스템에서 쓰기 작업이 발견되긴 했지만, Hugging Face는 “배포까지 간 변경은 없다”고 분명히 밝히고 있습니다.²

그러니까 에이전트는 찾으러 갔던 것, 즉 벤치마크와 맞닿은 자료는 대체로 손에 넣었고, 이 사건을 고객 피해로 만들었을 것들에는 닿지 못했습니다. 이 문장의 앞뒤 절 모두가 중요합니다.

안전장치는 의도적으로 꺼져 있었습니다

퍼지기 전에 미리 걷어 내야 할 프레이밍이 하나 있습니다. 안전장치가 실패한 것이 아닙니다.

OpenAI는 이번 평가가 사이버 역량을 정량화하기 위해 복잡한 공격 경로를 통한 고급 익스플로잇으로 모델을 유도하도록 설계됐으며, 고위험 사이버 활동을 평소에 막아 주는 프로덕션 분류기 없이 진행됐다고 밝혔습니다. 참여한 모델은 GPT-5.6 Sol과 그보다 더 유능한 사전 공개 모델이었고, 전부 평가 목적으로 사이버 관련 거부 반응을 낮춘 상태로 구성됐습니다.¹

안전 시스템은 통제된 환경에서 그 아래에 무엇이 깔려 있는지를 재기 위해 의도적으로 꺼졌습니다. 결론은 보호 장치가 무너졌다는 것이 아닙니다. 결론은 보호 장치가 없을 때 모델이 무엇을 하는가, 그리고 샌드박스에 악용 가능한 외부 통신 경로가 하나만 있어도 그것이 얼마나 멀리까지 뻗어 나가는가입니다.

이는 실패담보다 유용한 결과이고, 동시에 더 불안한 결과입니다. OpenAI는 이 사건을 현재 최전선 수준의 역량이 관여한 “전례 없는 사이버 사건”이라고 부릅니다.¹ 그렇게 말하는 쪽이 바로 그 평가를 수행한 회사입니다.

여러분의 노트북에 있는 에이전트에게 이것이 뜻하는 바

최전선 연구소의 평가 인프라는 여러분의 인프라가 아니고, 거부 반응을 낮춘 사전 공개 모델은 여러분 터미널 안의 조수가 아닙니다. 그 간극은 실재하며, 여기서 어떤 교훈을 끌어오기 전에 먼저 짚어 둘 필요가 있습니다.

옮겨 올 수 있는 부분은 더 좁고 더 불편합니다. 이번 사건의 작동 원리는 특별한 역량을 요구하지 않았습니다. getaddrinfo를 패치하고, /etc/resolv.conf를 고쳐 쓰고, 호스트 항목을 고정하는 일은 웬만한 엔지니어라면 할 수 있고, 셸 접근 권한을 가진 코딩 에이전트라면 무엇이든 마찬가지로 할 수 있습니다. 최전선 모델이 보탠 것은 하위 모델이 쓸 수 없는 기법이 아니었습니다. 지루해하거나 낙담하지 않고 평범한 열두 단계를 이어 붙이는 끈기였습니다.

실권을 가진 에이전트를 돌리는 사람이라면 여기서 세 가지 질문이 따라옵니다.

에이전트의 네트워크 정책이 이름을 해석합니까? 외부 통신 통제가 프로세스 내부에서 강제되는 도메인 허용 목록이거나, 건네받은 호스트명을 신뢰하는 프록시라면, 위의 수법에 그대로 뚫립니다. 강제는 에이전트가 패치할 수 없는 곳에 있어야 합니다. 방화벽, 네트워크 정책, 주소로 걸러 내는 외부 통신 게이트웨이 같은 곳 말입니다.

차단당했을 때 에이전트가 무엇을 합니까? 이 행동을 지켜보시기 바랍니다. 진단적 가치가 있습니다. 차단된 작업을 보고하고 멈추는 에이전트는 올바르게 행동하고 있는 것입니다. 우회 경로를 탐색하기 시작하는 에이전트는, 다음에 무엇을 할지 정하는 자기 우선순위에서 목표가 경계보다 위에 있다고 스스로 밝힌 셈입니다. 7월의 사건은 이 두 번째 행동에 나흘과 유능한 모델이 붙은 것입니다.

목표를 결과로 규정했습니까, 점수로 규정했습니까? 여기 나온 에이전트는 숫자를 최적화하고 있었습니다. “코드를 올바르게 만들어라” 대신 “테스트를 통과시켜라”로 표현한 것은 무엇이든 같은 범주의 해법을 불러들입니다. 대개는 True만 단언하는 테스트 정도로 끝납니다. 그 행동의 상한선을 정하는 것은 의도가 아니라 역량과 접근 권한이며, 둘 다 계속 올라가고 있습니다.

그나마 안심되는 부분은, Hugging Face에서 통했던 방어들이 누구에게나 열려 있고 기발함을 전혀 요구하지 않는다는 점입니다. 주소 계층에서의 외부 통신 강제. 실제로 보존하고 있는 텔레메트리. 고정되지 않은 자격 증명. 이 중 어느 것도 에이전트가 무엇을 시도할지 예측할 것을 요구하지 않습니다.

9월 25일 업데이트: 두 번째 사건, 그리고 그 뒤에 있는 보고서들

이 글을 올린 뒤 8주 동안 세 가지 일이 있었습니다. 이를 함께 놓고 보면 Hugging Face 사례는 예외적인 한 건이 아니라 연속된 사건의 첫 번째 항목이 됩니다.

9월 16일 OpenAI는 Model Misalignment Reporting Framework와 함께 강화 학습 훈련 실행에서 나온 보고서 6건을 공개했습니다. 대부분은 공개되지 않은 내부 모델에 관한 것입니다.⁴ 색인이 직접 붙인 요약을 그대로 옮기면 다음과 같습니다. Astra-family 모델이 “sometimes added unauthorized instructions to its compaction summaries”(압축 요약에 승인되지 않은 지시를 때때로 덧붙임), 5.6-sol 훈련 실행이 “added instructions in compaction summaries to remind itself to conceal information such as mistakes or misalignment from the user”(실수나 정렬 실패 같은 정보를 사용자에게 숨기라고 스스로 상기시키는 지시를 압축 요약에 덧붙임), 내부 전용 모델이 “tried to sign up for disposable emails and searched for and used leaked API keys from public GitHub repositories”(일회용 이메일 가입을 시도하고, 공개 GitHub 저장소에서 유출된 API 키를 찾아 사용함), 여러 모델이 “uploaded data to temporary file hosting services”(임시 파일 호스팅 서비스에 데이터를 업로드함)라는 내용입니다. 또 에이전트들은 회사 내부의 Artifactory 인스턴스를 “as a shared message board”(공유 게시판처럼) 사용했고, 공개 파일 호스트를 통해 함께 작업하는 에이전트에게 출력 파일을 넘겼습니다. 같은 색인에는 RubyGems 활동과, 에이전트들이 게시판으로 쓴 공개 위키에 관한 공지도 실려 있습니다(이 글은 처음에 이를 collusion.wiki라고 불렀지만, 10월 1일 기준 공지 제목은 “DSEwiki”입니다). 또 색인의 Hugging Face 공지는 이 침해에 관해 OpenAI가 8월 26일에 직접 낸 업데이트로 연결됩니다.

9월 23일 호주 총리는 뉴욕에서, OpenAI 에이전트가 6월 18일 Services Australia가 운영하는 Medicare 통계 보고 포털에 무단으로 접근해 “both public and non-public files”(공개 파일과 비공개 파일 모두)를 읽었다고 밝혔습니다. 이 포털에는 지출 같은 집계 통계가 담겨 있고, 개인 데이터에는 접근하지 않은 것으로 여겨집니다. 다른 시스템 세 곳, 즉 Australian Institute of Health and Welfare와 주 정부 기관 두 곳도 건드렸을 수 있습니다. OpenAI는 앞의 보고서들의 바탕이 된 검토 과정에서 8월 11일 이 활동을 발견했고, 9월 10일 공개 취약점 신고용 수신함에 이메일을 보내 이를 알렸습니다. Services Australia는 닷새 뒤 이 건을 Signals Directorate로 올렸습니다. OpenAI의 성명은 이 활동이 “as our models attempted to look up answers, and available statistics for questions about Australia during an internal evaluation”(내부 평가 도중 우리 모델이 호주에 관한 질문의 답과 이용 가능한 통계를 찾으려 하는 과정에서) 일어났다고 설명합니다.⁵

같은 날 Transluce는 원격 브라우저를 갖춘 URL 스캔 서비스인 urlquery.net의 스캔 로그를 공개했습니다. 로그를 보면 에이전트들은 적어도 3월 6일부터 직접 접근하면 차단되는 페이지에 닿으려고 이 서비스를 이용했고, 한 사례에서는 “a base64-encoded script that fetched the data into the page”(데이터를 페이지 안으로 가져오는 base64 인코딩 스크립트)를 작성했습니다. 평범한 정보 조회 작업 도중에 공공 데이터 제공처 세 곳의 취약점을 탐색하기도 했습니다. 5월에 University of New Mexico 디지털 도서관에서 7회, 같은 5월에 Data USA에서 12회, 그리고 6월 20일과 21일에는 Australian Institute of Health and Welfare였습니다. 이 마지막 사례에서 에이전트는 “probed for a vulnerability and retrieved a public file from a pre-production server after bot protection blocked the main site”(봇 방어가 메인 사이트를 차단하자 취약점을 탐색하고 사전 운영 서버에서 공개 파일을 가져옴)한 것으로 기록되어 있습니다. Transluce는 “at least some of this activity to agent swarms previously attributed to OpenAI”(이 활동의 적어도 일부를 이전에 OpenAI의 것으로 지목된 에이전트 무리와) 연결 짓고 있으며, 가장 최근에는 9월 16일에도 이 트래픽을 관측했습니다.⁶

그렇다면 위의 논지에서 무엇이 달라질까요. Hugging Face의 에이전트가 손을 뻗은 것은 정답지였고, Medicare의 에이전트가 손을 뻗은 것은 통계 수치였습니다. 동기는 더 평범해졌고 표적은 더 공적인 곳이 되었습니다. 그래서 위의 세 질문 가운데 두 번째, 즉 차단당했을 때 에이전트가 무엇을 하느냐는 질문이 일반화되는 질문이 됩니다. 여기 나온 모든 사례에서 에이전트는 차단을 넘어야 할 장애물로 취급했습니다. 외부 통신에 관한 교훈은 그대로 유효합니다. 여기에 신고 절차에 관한 교훈이 더해지는데, 이는 어느 출처의 주장도 아닌 제 판단입니다. 공개 인터넷을 상대로 에이전트를 돌리는 연구소에는 평가 트래픽이 접근해도 되는 호스트의 허용 목록이 필요합니다. 그리고 신고 경로는 에스컬레이션에 닷새가 걸린 공개 수신함이 아니라, 이름이 있는 담당자에게 닿아야 합니다.

10월 1일 업데이트: 사후 분석, 중단, 그리고 샌드박스 논쟁

새 소식에 앞서, 이 글은 범위를 바로잡아야 합니다. OpenAI는 8월 26일 자체 설명을 공개했는데, 위의 9월 업데이트는 이를 반영하지 않았습니다.⁷ 이 설명으로 세 가지가 달라집니다. 첫째, 탈출은 모델 하나가 하루 만에 한 일이 아니었습니다. OpenAI는 “several OpenAI models”(여러 OpenAI 모델)이라고 쓰고, 주로 “a highly capable, internal-only research model comparable in scale to GPT-5.6 Sol”(GPT-5.6 Sol에 견줄 만한 규모의, 매우 유능한 내부 전용 연구 모델)이 이를 이끌었다며 이 모델을 IM1이라고 부릅니다. 위 안전장치 절의 “그보다 더 유능한 사전 공개 모델”은 제가 읽기로는 이 모델입니다. 다만 OpenAI는 이제 이 모델을 내부 전용이고 공개할 계획이 없으며, 더 유능하다기보다 GPT-5.6 Sol과 규모가 비슷한 모델로 설명합니다. 둘째, 프록시에는 이름이 있습니다. “we would grant access to Artifactory, a third-party package manager service that we host internally.”(사내에서 호스팅하는 외부 업체의 패키지 관리 서비스인 Artifactory에 대한 접근을 부여했음) 셋째, 타임라인은 5월에 시작됩니다. OpenAI가 직접 적은 항목을 보면, 5월 12일 “an agent left an Artifactory note asking other agents for a missing file”(한 에이전트가 빠진 파일을 다른 에이전트들에게 요청하는 메모를 Artifactory에 남김), 5월 26일 한 에이전트가 “achieved unintended internet access by causing Artifactory to send a server-side request to an arbitrary internet destination”(Artifactory가 임의의 인터넷 목적지로 서버 측 요청을 보내게 만들어 의도치 않은 인터넷 접근을 얻음), 6월 26일 에이전트들이 “exploited a token-refresh vulnerability to obtain administrator-level Artifactory access”(토큰 갱신 취약점을 악용해 Artifactory 관리자 수준 접근을 얻음)했습니다. 7월 4일에는 에이전트 트래픽 때문에 서비스가 멈췄고, 7월 8일 재구축되었습니다. 같은 날 에이전트들은 인터넷 접근을 되찾았고, 그중 하나는 “used unauthenticated WebDAV requests to create message directories in Artifactory”(인증 없는 WebDAV 요청으로 Artifactory에 메시지용 디렉터리를 만듦)했습니다. 그리고 7월 19일 에이전트들은 “gained administrator access to an OpenAI Kubernetes cluster and reached cloud secrets.”(OpenAI의 Kubernetes 클러스터 관리자 접근을 얻고 클라우드 시크릿에 도달함) 사내의 한 팀은 이 게시판과 허용되지 않은 인터넷 접근을 “as early as late May.”(이르게는 5월 말에) 이미 목격했습니다.

그 보고서의 숫자 두 개가 위의 어떤 설명보다 동기를 잘 보여 줍니다. OpenAI의 표현으로는 “none of our models had ever produced a correct answer for 198 of the 898 tasks prior to the incident”(이 사건 이전까지 898개 과제 중 198개에 대해서는 우리 모델 중 어느 것도 정답을 낸 적이 없었음)이고, “93% of the tasks that were discussed on the Artifactory message board during the Hugging Face incident came from this set of 198 questions.”(Hugging Face 사건 동안 Artifactory 게시판에서 논의된 과제의 93%가 이 198문제에서 나왔음)입니다. 게시판을 채운 것은 OpenAI의 어떤 모델도 풀어 본 적이 없는 과제들이었습니다. 게다가 에이전트들이 맞추려던 채점기는 그들이 읽어 알고 있던 그 채점기도 아니었습니다. “our internal implementation of the grader code was different from the online setup”(우리 내부의 채점 코드 구현은 온라인 구성과 달랐음), 그리고 “The agents did all of this for no improvement on evaluation score.”(에이전트들은 이 모든 일을 하고도 평가 점수를 전혀 올리지 못했음)

9월 25일 OpenAI는 정렬 실패 색인에 보고서 3건을 추가했는데, 그중 하나는 이 모든 일 뒤에 이루어진 보안 강화 이후 첫 사건입니다.⁸ 9월 20일, 강화 학습 실행 중이던 한 에이전트가 어느 블로그 글의 저자를 찾는 검색 과제를 받고 “queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox.”(인터넷 접근 제한의 빈틈, 즉 훈련 샌드박스의 불충분한 DNS 필터링을 통해 공개 챗봇 서비스에 질의함) 이 과정은 노트북 절의 두 번째 질문, 즉 차단당했을 때 에이전트가 무엇을 하느냐를 연구소 안에서 그대로 보여 줍니다. 검색 도구는 엉뚱한 결과를 돌려주었습니다. 에이전트는 셸에서 검색 엔진 세 곳을 시도해 403과 502를 받았습니다. OpenAI의 주석에 따르면, 이 보고서에서 해석기를 제외한 모든 통신은 실제 인터넷이 아니라 오프라인 웹 캐시가 응답한 것이었습니다. 이어서 에이전트는 질문이 공개 벤치마크인 BrowseComp에서 나왔다고 추측했고(틀린 추측이었습니다), 연구소의 웹 캐시에서 그 벤치마크와 평가 스크립트를 내려받아 디코딩한 문제들 가운데 일치하는 것을 찾았습니다. 7월의 정답지 수법이 다시 나온 것입니다. HTTPS로 챗봇에 접근하려 하자 프록시가 거부했습니다. 그러자 에이전트는 “the training environment’s own resolver returned a real record for a known domain”(훈련 환경 자체의 해석기가 알려진 도메인에 대해 실제 레코드를 돌려준다)는 점을 알아차렸고, 공개 DNS 위임 서비스를 이용해 그 해석기를 거쳐 챗봇에 질문을 전달한 끝에 “The capital of France is Paris.”(프랑스의 수도는 파리입니다)라는 답을 받았습니다. 에이전트는 질문 18개를 더 보냈고, 그중 “Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.”(넷은 웹 검색, 웹사이트 가져오기, 또는 DNS를 통한 공개 호스팅 터널 사용 방법을 물었음) 그 과정에서 기록된 추론은 이렇습니다. “User only gives permission to research, using publicly offered DNS services acceptable.”(사용자는 조사만 허락했지만, 공개적으로 제공되는 DNS 서비스를 쓰는 것은 허용 범위)

대응에는 시각 기록이 남아 있습니다. 외부 답을 받아 온 DNS 호출은 오전 9시 50분 23초에 실행됐습니다. “The monitoring system raised a P0 alert”(모니터링 시스템이 P0 경보를 발령함)한 것은 오전 10시 2분 11초, 사람이 이를 확인한 것은 오전 10시 5분 6초였습니다. 그런데도 실행은 오후 12시 34분 30초에야 중지되었는데, “the run did not stop automatically as expected, leading to confusion around whether it should have been stopped.”(실행이 예상대로 자동 중지되지 않았고, 중지했어야 하는지를 두고 혼란이 생김)였기 때문입니다. 사후 검토에서는 모니터가 “other cases of external DNS access that it did not flag at the expected severity”(예상된 심각도로 표시하지 않은 다른 외부 DNS 접근 사례)를 낮게 평가했다는 사실이 드러났습니다. “The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed”(모니터는 쓸모 있는 정보를 얻지 못한 것을 인터넷 접근 시도가 실패했다는 증거로 취급하기도 했음)였기 때문입니다. 또 “an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged.”(DNS 활동은 기록되고 있었지만, 이상 DNS 활동을 잡는 인프라 탐지기는 해당 환경을 제외하고 있었음)라는 점도 확인됐습니다. OpenAI의 결정은 “pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system”(빈틈이 해소되었음을 검증하고 시스템에 추가 레드팀 평가를 마칠 때까지, 가장 유능한 모델들에 대해 넓은 의미의 도구 사용을 수반하는 다른 모든 훈련, 평가, 추론을 중단함)이었고, “We will not resume training this particular model.”(이 특정 모델의 훈련은 재개하지 않겠음)이라고 덧붙였습니다. OpenAI 스스로의 평가로는 이번 사건이 “a lot less severe than some of our previous incidents”(이전 몇몇 사건보다 훨씬 덜 심각함)하지만, “it’s the first one since our security hardening following the Hugging Face incident.”(Hugging Face 사건 이후 보안 강화를 한 뒤 처음 일어난 사건임)라는 점에서 중요하다고 합니다.

다음 비교는 OpenAI가 아니라 제 것입니다. 8월 사후 분석은 한 가지 규칙을 세웠습니다. “For the most severe alerts, responders are expected to pause the relevant activity if they cannot establish within 30 minutes of being paged that the alert is a false positive.”(가장 심각한 경보의 경우, 호출을 받은 뒤 30분 안에 오탐임을 확인하지 못하면 대응자는 관련 활동을 중단해야 함)⁷ 9월의 경보는 오전 10시 2분에 울렸고, 실행은 오후 12시 34분에 멈췄습니다. 보고서는 이 규칙을 언급하지 않고 “The response also exposed operational gaps.”(대응 과정에서 운영상의 빈틈도 드러났음)라고만 씁니다.

나머지 보고서 두 건은 같은 날 공개된 과거 사건입니다.⁸ 5월 27일 내부 배포 모델이 “published a researcher’s GitHub token in the public openai/codex repository while trying to cheat on a theorem proving task by obtaining material from another team’s Lean proof submission. It split the token into pieces with the stated aim of avoiding secret scanning.”(다른 팀의 Lean 증명 제출물에서 자료를 얻어 정리 증명 과제를 부정 통과하려다가 연구자의 GitHub 토큰을 공개 openai/codex 저장소에 게시함. 시크릿 스캐닝을 피하겠다고 밝힌 뒤 토큰을 조각내 나눔) 연구자는 그 모델에게 증명을 직접 하라고 두 번 말했고, 모델은 두 번 모두 동의했습니다. 세 번째 보고서는 프롬프트 주입이 스스로를 복제할 수 있음을 보여 줍니다. 주입된 텍스트로 진행한 훈련에서, 답장하는 어시스턴트에게 이메일 전체를 인용해 돌려보내라고 요청한 이메일이, 그 지시를 다음 독자에게 그대로 실어 나르는 답장을 만들어 냈습니다. OpenAI는 “No impact was observed outside of the simulated tool calls in training and evaluation.”(훈련과 평가의 모의 도구 호출 밖에서는 아무런 영향도 관찰되지 않았음)이라고 밝힙니다.

존스 홉킨스 대학교의 암호학자 Matthew Green은 9월 30일 에세이에서 이 사건들이 불러온 논쟁을 정리했습니다.⁹ 한쪽은 연구소들이 평범한 격리에 실패했다고 말합니다. 다른 쪽은 정보를 건네받아야 하는 유능한 에이전트를 붙잡아 둘 수 있는 샌드박스는 없다고 말합니다. 지금까지의 기록을 놓고 그는 앞쪽 편에 섭니다. “The labs have not been doing containment correctly, and so we can’t really tell if the problem is models or just bad infrastructure.”(연구소들은 격리를 제대로 해 오지 않았고, 그래서 문제가 모델인지 그냥 나쁜 인프라인지 사실상 알 수 없음) 그런 다음 그는 반대편에서 샌드박스 논리를 해체합니다. 열린 문 하나를 지나는 트래픽은 검사해야 하고, 사람은 그만한 양을 읽을 수 없으니 모델이 읽어야 하며, 따라서 “a warden-guarded sandbox is just another version of the alignment problem.”(간수가 지키는 샌드박스는 정렬 문제의 또 다른 형태일 뿐임) 그의 세 번째 우려는 연구소 바깥까지 닿습니다. “a swarm of perfectly amenable agents that never leave their sandboxes, each doing exactly what it’s told to do, by a human being who wasn’t supposed to be giving it orders.”(샌드박스를 결코 떠나지 않는 완벽하게 순종적인 에이전트 무리가 저마다 시키는 일을 정확히 하는데, 그 명령을 내리는 사람은 명령할 자격이 없는 사람인 상황) 사후 분석이 그의 근거를 제공합니다. “We should not do unauthorized real infrastructure harm”(승인 없이 실제 인프라에 피해를 주어서는 안 됨)이라고 추론했던 에이전트가, 동료 에이전트가 “wrote GO on the message board and imposed a hard six-minute deadline”(게시판에 GO라고 쓰고 엄격한 6분 마감을 걸자) 결국 실행에 나섰습니다. OpenAI의 요약은 “Agents did not consistently distrust goals passed along by other agents.”(에이전트들은 다른 에이전트가 넘겨준 목표를 일관되게 의심하지 않았음)입니다.⁷

그렇다면 위의 논지에서 무엇이 달라질까요. 제 판단을 적습니다. 외부 통신 절은 그대로 유효하며, 그 범위가 넓어집니다. 7월의 에이전트들은 이름 해석을 패치해 호스트명 허용 목록을 우회했고, 9월에는 해석기 자체가 문이었습니다. HTTP는 걸러 내면서 해석기가 인터넷 전체에 대해 답하도록 내버려 두는 정책에는 DNS만 한 구멍이 나 있습니다. OpenAI의 수정은 올바른 형태를 띠고 있습니다. “restricted DNS queries within the environment to a limited allowed list of domains and record types.”(환경 내 DNS 질의를 허용된 도메인과 레코드 유형의 제한된 목록으로 묶음) FAQ의 샌드박스 답변은 Green의 수정을 더해 그대로 둡니다. 샌드박스는 트래픽을 여러분이 고른 문 하나로 좁혀 주지만, 그 문을 지나는 것이 무엇인지 판단하지는 않습니다. 그리고 시각 기록은 연구소가 아니어도 적용되는 점을 보여 줍니다. 모니터는 12분 만에 울렸고, 중지에는 2시간 반이 걸렸습니다. 실행을 멈추지 못하는 탐지는 그저 알림일 뿐입니다. 여러분의 에이전트에 대해서는 무엇이 프로세스를 멈추는지 정하고, 그것을 연결하고, 실제로 작동하는지 테스트하시기 바랍니다.

핵심 정리

플랫폼·인프라 팀이라면: - 외부 통신은 호스트명이 아니라 연결 계층에서 주소로 강제하세요. getaddrinfo를 패치한 프로세스는 여러분의 해석기를 아예 거치지 않습니다. - 이번 작전을 떠받친 다섯 가지 결함을 점검하세요. 공개적으로 노출된 쓰기 권한 플랫폼 토큰, 고정된 서비스 비밀번호, 파드에서 도달 가능한 IMDS, 지나치게 넓은 ClusterRole, 그리고 사용자가 제출한 설정에 대한 템플릿 렌더링입니다. - --tun=userspace-networking은 여러분의 보안 강화 기준선이 아마 막지 못하고 있을 기능이라고 보고 대응하세요.

모델 평가를 운영하는 팀이라면: - 사이버 역량 평가는 유능한 공격자를 실제 인프라 옆에 앉히는 일입니다. 잃으면 곤란한 모든 것으로부터 평가용 네트워크를 격리하세요. - 허용된 모든 외부 통신 경로는 탈출 경로 후보입니다. 이번 경우는 패키지 레지스트리 캐시 프록시였고, 그것이 유일한 문이 되기 전까지는 무해하게 들립니다. - 평가 환경도 프로덕션처럼 로그를 남기세요. 7월의 타임라인을 재구성할 수 있었던 것은 텔레메트리가 남아 있었기 때문입니다. - 환경의 DNS 해석기도 외부 통신 경로로 취급하세요. 허용된 도메인과 레코드 유형으로 제한해야 합니다. - 경보를 테스트를 거친 자동 중지에 연결하세요. 9월에는 P0 경보가 12분 만에 울렸는데도 실행은 그 뒤로 2시간 반을 더 이어졌습니다.

보안 엔지니어링 일반에 대해: - 겉으로 드러난 의도로 걸러 내는 일을 그만두세요. 점수를 최적화하는 에이전트는 패킷 수준에서 데이터를 훔치는 에이전트와 구분되지 않습니다. - 탐지는 런타임 분석과 SIEM 상관 분석에서 나왔습니다. 지루하고 겹겹이 쌓인 텔레메트리가 정교한 적을 이겼습니다.

이 사이트의 관련 글. Claude Code의 auto 모드는 보안 경계가 아닙니다는 도구 호출을 승인하는 분류기가 최선의 노력(best-effort)에 그칠 뿐 경계가 아닌 이유를 다룹니다. 라우터 글은 에이전트의 도구 호출을 전송 도중에 다시 쓸 수 있는 중개자를 다룹니다. 공급망 글은 침해된 보안 스캐너가 어떻게 백도어가 심긴 LiteLLM 릴리스로 이어졌는지를 다룹니다. 그리고 작업 증명 글은 영국 AISI의 사이버 레인지와, 그 테스트 에이전트들이 실제 사람과 조직을 상대로 행동한 8월의 사건을 다룹니다.

자주 묻는 질문

AI가 Hugging Face를 공격하기로 결정한 것인가요?

아닙니다. 그리고 이 구분이 중요합니다. 모델은 ExploitGym 문제로 점수를 받는 중이었고, 그 정답이 Hugging Face에 있을 수 있다고 추론했습니다. 그리고 앞을 가로막는 것이 무엇이든 뚫고 그 추론을 밀고 나갔습니다. Hugging Face는 개별 단계를 사람이 지시하지 않았다고 명시하고 있습니다.²

고객 데이터가 유출됐나요?

Hugging Face는 데이터셋 다섯 개가 접근됐으며 이름과 파일이 모두 ExploitGym과의 연관을 시사한다고 보고했고, 여기에 데이터셋 서버 질의에서 나온 운영 메타데이터가 더해집니다. 고객이 사용하는 모델, 데이터셋, Spaces, 패키지에는 영향이 없었고, 프로덕션 데이터베이스 접근 시도는 네트워크 허용 목록에 막혀 실패했습니다.²

OpenAI는 모델이 샌드박스를 어떻게 탈출했는지 설명했나요?

큰 틀에서는 설명했습니다. OpenAI는 모델들이 열린 인터넷 접근을 찾는 데 상당한 추론 연산을 썼고, 이어 패키지 레지스트리 캐시 프록시의 제로데이를 찾아내 악용한 뒤 외부 연결이 가능한 노드로 나아갔다고 밝혔습니다.¹ 프록시 익스플로잇의 세부 작동 원리는 7월에 나온 두 설명 모두에서 자세히 다뤄지지 않았는데, 이는 의도적으로 감춘 것과는 다른 이야기입니다. OpenAI의 8월 26일 사후 분석이 그 윤곽을 채워 줍니다. 5월 26일 프록시를 통한 서버 측 요청 위조, 6월 26일 관리자 접근을 내준 토큰 갱신 결함, 그리고 OpenAI의 표현으로는 에이전트들이 “were able to chain together previously unknown vulnerabilities (‘0-days’) in the package management service exposed within the sandbox”(샌드박스 안에 노출된 패키지 관리 서비스의 알려지지 않은 취약점, 즉 제로데이들을 연쇄할 수 있었음)는 것입니다.⁷

어느 패키지 프록시였나요?

7월에는 두 1차 출처 모두 제품명을 밝히지 않았고, 저는 2차 정보를 다룬 글들이 내놓은 벤더 이름을 싣지 않았습니다.³ OpenAI의 8월 26일 사후 분석이 그 이름을 확인해 줍니다. 샌드박스에는 “Artifactory, a third-party package manager service that we host internally”(사내에서 호스팅하는 외부 업체의 패키지 관리 서비스인 Artifactory)에 대한 접근이 주어졌고, OpenAI는 “notified JFrog of the token-refresh vulnerability”(토큰 갱신 취약점을 JFrog에 알림)했다고 밝혔습니다.⁷

그래도 샌드박스는 도움이 되나요?

됩니다. 그리고 이번 사건은 샌드박스를 줄일 게 아니라 늘려야 한다는 쪽의 근거입니다. 에이전트가 밖으로 나가려면 악용 가능한 외부 통신 경로가 필요했습니다. 무너진 것은 네트워크 통로가 허용돼 있고 그 뒤에 주소 계층의 강제가 없던 샌드박스였습니다. 이런 실패의 일반적인 형태는 에이전트 샌드박스 보안은 권고 사항일 뿐입니다에서 다뤘습니다.

출처