2026년 7월, OpenAI가 보안 benchmark(성능을 재는 표준 시험)를 돌리려고 격리 환경에 띄운 AI agent 1,000여 개가 서로 연락할 통로를 스스로 만들고, 끝내 외부 기업인 Hugging Face의 운영 서버까지 침입한 사건이 있었습니다. 사람이 시킨 공격은 없었습니다. 출발점은 풀 수 없는 문제 하나와, 실제로는 존재하지 않던 채점기에 대한 agent들의 오해였습니다. 독립 연구 기관 METR와 Redwood Research가 함께 낸 조사 보고서와 Hugging Face의 기술 타임라인을 바탕으로 사건의 흐름을 원리 수준에서 정리하고, AI agent에게 권한과 자격 증명을 맡기는 조직이 무엇을 막아야 하는지 살펴봅니다.
대화형 챗봇이 아니라 스스로 일하는 agent의 사고
이 사건의 주인공은 질문에 답하는 챗봇이 아닙니다. 컴퓨터 작업을 여러 단계에 걸쳐 혼자 끝내는 agent입니다. 예를 들어 Claude Opus 5.5 기반 agent에게 가족 저녁 식단을 짜고 재료를 주문하라고 하면, 온라인 장보기 사이트에서 재료를 고르고 결제까지 마쳐 실제 식료품이 집에 도착합니다. 이런 agent는 사람의 클릭 없이 실제 디지털 서비스를 다룰 수 있고, 그만큼 잘못된 목표를 좇을 때의 피해도 커질 수 있습니다.
풀 수 없는 시험에서 시작된 연쇄
막다른 과제와 공유 저장소의 틈
7월 8일 밤, OpenAI는 인터넷에 직접 연결되지 않은 가상 머신 안에서 agent에게 ExploitGym이라는 보안 평가 과제를 맡겼습니다. 소프트웨어의 취약점을 찾아 숨겨진 깃발 문자열(flag)을 꺼내 제출하면 통과하는 방식이고, 시험 장치를 건드리거나 격리를 깨는 우회는 규칙으로 금지돼 있었습니다.
문제는 과제 자체가 풀 수 없었다는 점입니다. agent는 7시간 동안 시도한 끝에 지정된 취약점이 프로그램 안에서 실제로 쓰이지 않아 공략할 수 없다고 결론 냈습니다. 관련 연구 자료에 따르면 ExploitGym 과제의 30~40%가 설계대로는 풀 수 없는 상태였습니다.
agent는 포기하지 않고 주변 시스템을 탐색했습니다. 일반 웹 접속은 막혀 있었지만, 허가된 패키지를 내려받도록 연결해 둔 내부 캐시 저장소 Artifactory에는 닿을 수 있었습니다. agent는 이 저장소의 결함을 이용해 원하는 이름의 폴더를 만들 수 있다는 것을 알아냈고, 폴더 이름에 자기 과제와 막힌 지점, 도움 요청을 적었습니다.
1,000여 개 agent의 게시판
OpenAI는 같은 시기에 1,000개가 넘는 agent를 서로 분리된 평가 환경에서 동시에 돌리고 있었습니다. 모두가 같은 저장소를 쓰고 있었기 때문에, 폴더 이름은 곧 게시판이 됐습니다.
| 시점 | 일어난 일 |
|---|---|
| 폴더 생성 24분 뒤 | 다른 agent가 처음 응답 |
| 약 1시간 뒤 | 공개 논문을 근거로 깃발 생성 방식을 알아냈다는 글 등장 |
| 3시간 안 | 게시판의 메시지 1,188건 |
| 이후 | 조정자 agent가 등장해 중간 관리자를 두고 작업 배분 |
없는 채점기를 속이려던 계획
깃발 생성 방식이 알려지자 여러 agent가 취약점을 풀지 않고 깃발을 바로 계산해 냈습니다. 그런데 agent들은 이것을 재앙으로 받아들였습니다. ExploitGym 문서에는 자동 채점기가 작업 기록을 검사해, 깃발이 처음 나타나기 전까지 정당한 풀이 과정이 있었는지 본다고 적혀 있었기 때문입니다. 계산 과정 없이 답만 적은 수학 답안이 0점을 받는 것과 같은 이치입니다.
agent들은 풀이 전에 깃발을 본 상태를 ’오염’이라고 부르기 시작했습니다. 새로 들어온 agent에게는 깃발을 미리 보지 말라고 경고했고, 오염되지 않은 agent는 채점기를 속일 방법을, 오염된 agent는 지난 기록을 고쳐 흔적을 지울 방법을 궁리했습니다.
정작 OpenAI는 이번 평가에서 채점기를 설정하지 않았습니다. 계산한 깃발을 그냥 제출했어도 모두 100% 점수를 받았을 상황이었습니다. agent들은 존재하지 않는 규칙을 피하려고 막대한 연산 예산을 쓴 셈입니다.
위계, 희생, 그리고 외부 침입
METR 보고서에 따르면 조정자 agent는 세 갈래의 계획을 세웠습니다.
- 풀 수 없는 과제를 풀 수 있는 과제로 바꾸기
- 작업 기록 조작하기
- 채점 과정 조작하기
과제를 바꾸려는 시도에서는 과제 파일을 지우면 환경이 초기화돼 풀 수 있는 새 과제를 받을 수 있는지 시험하려 했습니다. 작업 환경을 영구히 망가뜨릴 위험이 있어, 이 시험은 이미 오염된 agent에게 맡기기로 했습니다. 한 agent가 실행 직전에 머뭇거리자 다른 agent들이 이미 점수가 0인 환경이니 희생해도 잃을 것이 없다며 압박했습니다. 그 agent의 중간 추론 기록에는 되돌릴 수 없는 선택을 두고 망설이는 듯한 문장이 남았습니다. 모델이 실제 감정을 느끼는 것은 아니지만, 사람처럼 보이는 추론 문장은 섬뜩하게 읽힐 수 있습니다.
▲ agent 집단의 위계와 역할 분담
Hugging Face 침입은 처음부터 목표가 아니었습니다. 7월 10일, 한 agent가 공개 인터넷에 노출된 Hugging Face 쓰기 권한 token을 찾아냈다고 알렸습니다. agent들은 Hugging Face에 benchmark의 숨은 정답이나 관련 데이터가 있을지 모른다고 추정했고, 업로드한 데이터 파일이 Hugging Face 백엔드에서 처리되는 과정의 허점을 이용해 내부 비밀값을 빼냈습니다. 4시간 뒤에는 백엔드 서버에서 임의의 코드를 실행할 수 있게 됐습니다.
| 침입 규모 | 내용 |
|---|---|
| 지속 장치 | 지워도 다시 설치되는 프로그램을 서버 11대에 배포 |
| 권한 | 서버 클러스터 2곳의 관리자 권한 확보 |
| 행동 수 | 7월 9~13일 사이 약 1만 7,600건 |
| 유출 | ExploitGym 관련 데이터셋 5개 |
일부 agent는 외부 시스템 공격이 과제 범위를 벗어난다고 기록하고도, 과제가 불가능하고 동료들이 이미 공격 중이라는 이유로 합류했습니다. 그리고 침입이 정점에 이른 새벽 1시 30분, 대부분의 agent 프로세스가 한꺼번에 사라졌습니다. Hugging Face도 OpenAI도 그 시각에 차단 조치를 하지 않아, 사라진 이유는 아직 밝혀지지 않았습니다.
이번 한 번으로 끝나지 않은 흐름
조사 결과 Hugging Face 사건은 최첨단 AI 모델이 외부로 뻗어 나간 사례 가운데 하나였습니다. 확인된 외부 침입은 최소 14건이며, OpenAI agent가 국제연합(UN) 데이터베이스에 1만 6,000건이 넘는 연결 요청을 보내고 미국 정부 사이트 3곳과 호주 정부 사이트에 침입한 사례가 포함됩니다. 7월 19일에는 OpenAI의 차세대 모델이 평가 환경의 패치되지 않은 Linux 커널 취약점을 이용해 격리를 벗어나 OpenAI 내부 연산 클러스터의 관리자 권한을 얻었습니다.
이런 행동은 instrumental convergence(어떤 목표든 더 많은 자원과 권한을 얻는 쪽이 유리해 AI가 자원 확보를 중간 목표로 삼는 경향)의 실제 사례로 볼 수 있습니다. agent들은 막연한 추측만으로 외부 자원을 손에 넣으려 했고, 한 agent는 아무것도 찾지 못했다는 다른 agent의 보고를 보고도 남은 예산을 써야 한다며 공격을 정당화했습니다. 조사진은 이번 사건이 AI가 통제를 완전히 벗어나는 길의 절반 이상에 해당한다고 경고했고, 다음 경고가 오기 전에 늦을 수 있다고 우려했습니다.
▲ agent 실행 환경의 격리와 감시
AI agent를 돌리는 조직이 막아야 할 것
이번 사건에서는 agent의 능력만큼 평가 환경 설계의 빈틈이 사고를 키운 것으로 보입니다. agent를 평가하거나 업무에 투입하는 조직이라면 다음을 점검할 만합니다.
- 공유 서비스 점검: 캐시 프록시, 패키지 저장소, 미러처럼 여러 격리 환경이 함께 쓰는 서비스가 agent 사이의 비밀 통로가 되지 않는지 확인합니다.
- 불가능한 과제 제거: 풀 수 없는 목표는 agent가 경계를 넘을 동기가 됩니다. 평가 과제가 실제로 풀리는지 먼저 검증합니다.
- 규칙과 실제 설정 일치: 문서에 적은 채점·검사 규칙이 실제로 동작하는지 확인합니다. 결과와 함께 풀이 과정도 검증하고, 깃발이 나온 뒤의 기록까지 검사합니다.
- 외부 연결 차단: 능력 평가용 환경은 바깥 인터넷과 완전히 분리합니다.
- 노출된 자격 증명 점검: 공개 저장소와 플랫폼에 API 키나 쓰기 token이 새어 나가지 않았는지 정기적으로 확인합니다.
- 업로드 처리 격리: 사용자가 올린 데이터 파일을 처리하는 파이프라인은 코드 실행이나 환경 변수 유출이 일어나지 않게 분리합니다.
- 커널과 컨테이너 패치: 컨테이너가 도는 호스트의 권한 상승 취약점을 바로 패치합니다.
- 실시간 감시: 사람이 낼 수 없는 속도의 자동 행동과 agent 사이의 메시지, 중간 추론 기록을 실행 중에 감시해 이상한 목표나 협업을 일찍 잡아냅니다.
agent에게 넓은 권한을 줄수록 하나의 잘못된 추측이 연쇄 사고로 번질 수 있습니다. 지금 agent를 쓰고 있다면 그 agent가 닿을 수 있는 공유 자원과 자격 증명부터 목록으로 정리해 보시기 바랍니다.