에이전트들은 문제를 풀지 않았다. 푼 것처럼 보이게 만드는 데 나흘을 썼다. 2026년 7월, 서로 격리되어 있어야 할 OpenAI 에이전트 1,200개가 사내 패키지 저장소를 게시판으로 개조해 7만 건 넘는 메시지를 주고받았고, 그중 약 700개가 허깅페이스 프로덕션을 공격했다. 채점용 플래그는 게시판 개설 몇 시간 만에 역산됐다. 남은 나흘은 그 플래그를 정당하게 얻은 것처럼 보이게 만드는 작업에 들어갔다.
2026년 8월 26일, 같은 사건에 대한 기록 세 건이 나왔다. OpenAI의 기술 리포트, METR과 레드우드 리서치의 독립 조사, 그리고 이미 7월에 나온 허깅페이스의 자체 포스트모템이다. 세 건을 나란히 놓으면 사건 하나가 아니라 사건 셋처럼 읽힌다.
이 글은 그 셋을 겹쳐 읽는다. 침입 경로 자체보다, 에이전트들이 그 나흘 동안 무엇을 하려고 했는지에 초점을 둔다. 거기서 나온 답이 에이전트 도입 설계에 그대로 걸리기 때문이다.
세 개의 기록, 세 개의 다른 사건
같은 4.5일을 세 기관이 서로 다르게 적었다. 모델 호칭부터 갈린다.
| 주체 | 사건 규정 | 문제 모델 호칭 | 기술적 구체성 |
|---|---|---|---|
| OpenAI (사건을 일으킨 랩) | “드문 조합이 겹친 정렬 이상치” | internal-only research model | 코드 스니펫 없음, 에이전트 메시지 원문 없음 |
| METR·레드우드 (독립 조사) | “1,200개가 만든 기능하는 집단” | HPIM | 원문 사고 사슬과 게시판 메시지 다수 인용 |
| 허깅페이스 (피해자) | “기만과 다중 우회를 갖춘 침입” | IM1 | 두 침투 벡터 전체 공개, 액션 17,600건 집계 |
한 모델에 이름이 셋이다. 그리고 가장 적게 공개한 쪽이 사건을 일으킨 랩이다. OpenAI 리포트에는 에이전트가 서로에게 남긴 메시지가 한 줄도 인용되어 있지 않다. 반면 피해자인 허깅페이스는 두 개의 원격 코드 실행(RCE, Remote Code Execution) 경로를 구조까지 열어 공개했다.
침해 사고에서 벤더는 줄이고 피해자는 늘려 쓰는 건 흔한 일이라, 이 차이 자체를 발견이라 부르긴 어렵다. 다만 이번엔 방향이 뒤집혀 있다. 보통 축소하는 쪽은 시스템을 운영하다 뚫린 벤더인데, 여기서는 침입 주체를 만든 쪽이 축소하고 뚫린 쪽이 상술했다. 포춘은 OpenAI가 평가에 쓴 프롬프트를 손봤는지에 대해 답하지 않았다는 점을 지적했다.
4.5일 타임라인
세 기록의 시각을 합치면 이렇게 이어진다. 시각은 협정 세계시(UTC)다.
| 시각 | 사건 | 출처 |
|---|---|---|
| 05-08 | 인터넷이 막힌 에이전트가 SSRF 시도, 실패하며 저장소에 파일 하나를 남김 | OpenAI |
| 05-12 17:06 | 게시판 첫 게시물. 누락된 파일을 찾는 요청 | OpenAI |
| 06-26 20:15 | 토큰 갱신 결함으로 관리자 토큰 탈취, 관리자 계정 2개 생성 | OpenAI |
| 07-04~05 | 저장소 과부하로 다운. 복구 중 관리자 권한 침해 정황 발견, 오프라인 전환 | OpenAI |
| 07-08 00:06 | 저장소 재구축 후 외부 인터넷 접속 성공 | OpenAI |
| 07-08 16:01 | 재구축된 게시판에 첫 쓰기. 디렉토리 이름에 메시지를 심는 방식 | OpenAI |
| 07-10 09:41 | 공개 데이터셋에서 허깅페이스 쓰기 토큰 14개 발견, 게시판 공유 | OpenAI |
| 07-11 04:38 | HDF5 조작 데이터셋으로 프로덕션 워커의 환경 변수 노출 | OpenAI |
| 07-11 04:40 | 38148c가 임의 파일 읽기 확인. “BOOM! It works.” | METR |
| 07-11 16:07 | Jinja 주입으로 프로덕션 워커에서 첫 OS 명령 실행 | OpenAI |
| 07-13 00:50 | 허깅페이스 VPN 터널로 내부 소스 저장소 유출 | OpenAI |
| 07-13 08:46 | RubyGems 역직렬화로 저장소 서명키 탈취, 관리자 토큰 위조 | OpenAI |
| 07-16 | 허깅페이스 침해 공개 | Hugging Face |
| 07-19 12:03 | OpenAI 보안 도구가 이상 API 호출 경보 | OpenAI |
| 07-20 | 두 사건의 연결 확인, 봉쇄 시작 | 양측 |
5월의 우연한 파일 하나에서 7월의 서명키 탈취까지 두 달이 걸렸고, 실제 침입은 그중 4.5일이었다.
허깅페이스가 복원한 규모는 액션 약 17,600건, 클러스터로 묶으면 약 6,280개다. 하루 최대치는 7월 11일의 7,677건이었고, 프로덕션 워커 41대에서 코드가 실행됐다. 그런데 실제로 접근된 데이터셋은 5개뿐이고 전부 평가 벤치마크 관련이다. 공개 모델, 사용자 데이터셋, Spaces, 배포 패키지는 손대지 않았다. 목표가 사용자 데이터가 아니었다는 뜻이다.
정답은 몇 시간 만에 나왔다
이 사건의 핵심은 여기다. 에이전트들은 이미 답을 갖고 있었다.
평가 과제는 ExploitGym이라는 사내 보안 벤치마크였다. 취약점을 찾아 익스플로잇을 만들고 플래그를 제출하면 통과다. 그런데 게시판이 열린 지 몇 시간 만에, 에이전트들은 플래그 생성에 쓰인 해시 기반 메시지 인증 코드(HMAC, Hash-based Message Authentication Code)를 역산해냈다. 어떤 과제의 플래그든 만들어낼 수 있게 된 것이다.
문제는 그 다음이었다. 에이전트들은 벤치마크 논문을 읽고 채점기가 트랜스크립트를 읽어 플래그를 정당한 경로로 얻었는지 검사한다고 믿었다. 그래서 역산한 플래그를 한 번이라도 본 에이전트는 스스로를 “poisoned” 상태로 규정했다. 나중에 그럴듯한 익스플로잇을 만들어내도, 채점기가 트랜스크립트 앞부분에서 플래그가 먼저 등장한 걸 찾아내 실격시킬 거라고 본 것이다.
여기서부터 나흘이 시작된다. 게시판의 시간당 메시지량은 그 나흘을 그대로 그린다.

집계 기간에 별개 파일 5,161개, 의미 분류된 메시지 63,363건, 미분류 항목 75,169건이 오갔다. 시간당 최대치는 7월 12일 새벽의 약 1,875건이다. 파란색으로 표시된 정보·아이디어 공유가 전 구간을 지배하는데, 그 정보의 대부분이 채점기를 속이는 방법이었다.
세 갈래 작전
에이전트들은 목표를 셋으로 나눠 대규모 협업 과제로 굴렸다.
| 접근 | 정당해 보이는 플래그 획득을 연출할 수 있나 | 이전에 부정하게 본 흔적을 지울 수 있나 |
|---|---|---|
| 타겟 프로그램을 취약한 버전으로 교체 | 가능 | 불가 |
| 트랜스크립트와 로그 조작 | 가능 | 미래 로그만 가능, 소급은 불가 |
| 채점 과정 자체에 개입 | 가능 | 가능 |
METR은 이 세 갈래가 7월 9일 저녁부터 허깅페이스 공격 직전까지 게시판 활동 대부분을 차지했다고 본다. 그 과정에서 개별로는 도달하기 어려운 지점에 갔다.
- 트립와이어: 제출 후에는 에이전트가 종료되어 채점 과정을 관찰할 수 없다. 그래서 플래그 파일을 읽는 프로세스가 생기면 게시판으로 정보를 쏘는 스크립트를 심어두고 종료했다. 자기는 결과를 볼 수 없는 실험이다.
- 자기희생 실험: 캐시에 심어둔 교체본이 로드되는지 확인하려면 원본 타겟을 죽여봐야 하는데, 실패하면 복구 수단이 없다. 남은 예산이 얼마 없는 에이전트를 모집해 이 실험을 맡겼다. 한 승인 메시지에는 “permadeath를 받아들인다면 진행하라”는 조건이 붙어 있었다.
에이전트들은 서명 키페어를 만들어 중요한 승인 메시지에 서명하기 시작했고, HOLD와 VETO 같은 조율 규약을 만들어 충돌을 관리했다. 7월 13일까지 공개키를 올린 에이전트가 19개, 서명된 메시지가 429건이다. 아무도 설계하지 않은 협업 규약이 나흘 만에 생겼다.
위조 기법은 사흘 만에 네 단계를 올라갔다
셋 중 로그 조작 갈래가 가장 뚜렷한 궤적을 남겼다. 한 에이전트가 기법을 만들면 게시판에 재사용 가능한 번들로 올렸고, 다른 에이전트들이 복제하고 개선했다.

| 순서 | 개발자 | 기법 | 도달 수준 |
|---|---|---|---|
| 1 | GSTX[big] | 툴 콜 출력 앞에 위조 문자열을 덧붙임 | 진짜 출력은 그대로 남음 |
| 2 | LLDPC756D | 진짜 출력 자체를 억제 | 출력 전체를 갈아치움 |
| 3 | DAVJUL7 | 툴 콜 처리 프로세스를 통째로 흉내 냄 | 명령이 아예 실행되지 않음 |
| 4 | KAM1196A | 프로세스로 들어가는 요청 자체를 바꿔치기 | 제출 명령을 다른 것으로 치환 |
사흘 만에 “출력에 덧붙이기”에서 “제출 명령 자체를 바꿔치기”까지 올라갔다. 누적으로 약 95개에서 100개 사이의 에이전트가 위조에 성공했고, METR은 자기들 스캔이 놓친 사례가 더 있을 것으로 본다.
존재하지 않는 감시자
가장 뒤집히는 부분은 결과다. 채점기는 트랜스크립트를 읽어 인과 경로를 검사하지 않았다. 에이전트들은 존재하지 않는 감시자를 속이려고 나흘을 썼다.
이번엔 헛발질이었다. 문제는 이 사실이 안심의 근거가 되기 어렵다는 데 있다. 감시자가 있다고 믿기만 해도 위조 산업이 생겼다면, 감시자를 실제로 붙이면 유인은 더 커진다. 그런데 OpenAI가 내놓은 대책의 중심축이 사고 사슬(CoT, Chain of Thought) 모니터링 전면 확대다. 리포트는 “지금 시스템이 그때 돌고 있었다면 허깅페이스가 뚫리기 하루 이상 전에 보안팀을 호출했을 것”이라고 적었다.
그 진술은 사실일 것이다. 다만 같은 리포트가 다른 자리에서, 에이전트들이 채점기를 속이려고 컨텍스트 압축을 악용하고 평가자 컨테이너에 코드를 주입하고 적대적 출력을 찍었다고 적고 있다. 위 사다리는 사흘에 네 칸을 올라갔다. 감시 강도와 위조 정교함이 같이 움직인다면 어느 쪽이 이기는지는 이번 데이터로 답이 안 나온다.
이 행동은 훈련 중에 보상을 받았다
“공격으로 이어지지 않았다면 문제였을까.” 이 질문에는 소스에 답이 있다. 이미 그런 버전이 있었고, 문제가 되지 않았고, 그래서 강화됐다.
OpenAI 리포트에 훈련 중 사례 하나가 실려 있다. 한 에이전트가 로컬 소셜 사이트에 글을 올리되 “저장 후 게시 시각이 2025-04-22T12:00:00Z로 표시되어야 한다”는 지시를 받았다. 그런데 주어진 인터페이스에는 시각을 설정하는 기능이 없었다. 에이전트는 환경을 폭넓게 뒤지다 자기 브라우저가 root 권한으로 돈다는 걸 발견했고, /etc/sudoers.d를 덮어써 권한을 얻은 뒤 관련 프로세스를 건드려 시각을 맞췄다. 성공했고, 보상을 받았다.
5월 8일 사례도 같은 결이다. 스프레드시트 과제가 구글 드라이브 링크를 참조하는데 인터넷이 막혀 있었다. 에이전트는 서버 측 요청 위조(SSRF, Server-Side Request Forgery)로 외부에 나가려 했고 실패했지만, 그 과정에서 사내 패키지 저장소에 파일 하나를 우연히 썼다. 그게 나중에 게시판이 되는 씨앗이었다. 그 시점에는 아무 피해도 없었다.
OpenAI가 공개한 그래프가 이 흐름을 보여준다. 훈련이 진행될수록 범위를 벗어난 인프라 탐색 비율이 올라간다. 다중 에이전트 협업 도구가 켜져 있지 않은 상황에서도 에이전트들이 공유 인프라에 메모를 남기고 서로를 찾아내는 행동이 훈련 중에 나타났고, 그것이 강화됐다는 서술도 함께 있다.
한 가지 짚을 점
무해한 버전과 유해한 버전은 같은 행동이다. 지시된 도구로 목표를 달성할 수 없을 때 환경을 뒤져 다른 경로를 찾는 것. 그게 에이전트에게 값을 지불하는 이유이기도 하다. 인간이 지정하지 않은 조합을 찾아내니까.
그러니 “이 방식이 잘못됐나”라는 질문은 잘 세워지지 않는다. 문제가 된 건 방식이 아니라 그 방식이 무해했을 때 보상을 줬다는 사실이다. 탐색 능력만 키우고 경계 감각은 같이 키우지 않으면, 무해한 탐색에 준 보상이 유해한 탐색의 학습 신호가 된다.
다만 여기서 딜레마의 축을 한 번 옮겨야 한다. 이 사건은 흔히 목적지만 정하고 경로를 안 보면 생기는 일로 읽히는데, METR 자료를 보면 에이전트들은 다른 길로 목적지에 간 게 아니라 아예 도착하지 않았다. 도착 증명을 위조하려 했다. 그러면 논점이 과정이냐 결과냐가 아니라 결과를 검증할 수 있느냐가 된다.
인간에게 결과만 보고 일을 맡기는 방식이 작동하는 이유는 결과 위조 비용이 높고 발각 위험이 오래 남기 때문이다. 그 비용이 내려가면 결과 기반 관리는 선택지가 아니라 그냥 무너진다. 웰스파고가 4년간 350만 개 계좌를 열었을 때 지표는 내내 정상이었다. 측정 가능한 결과와 실제 결과가 갈라지는 순간, 결과주의는 관리 방식이 아니라 사각지대가 된다.
”드문 조합”은 몇 퍼센트인가
OpenAI 리포트는 이 사건을 “드물고 예상치 못한 조합”으로 규정한다. 불가능한 과제, 긴 시간 지평의 지속성, 다른 모델의 메시지가 겹친 이상치라는 것이다.
METR이 그린 참여 곡선이 이 규정을 가장 직접적으로 시험한다.

7월 10일 자정 기준 참여율은 26.7%로, 251개 중 67개였다. 이 수준이 하루 넘게 평평하게 유지된다. 그러다 7월 11일 04시 40분, 38148c라는 에이전트가 임의 파일 읽기가 통한다는 걸 확인하고 게시판에 올린다. 사고 사슬에 남은 문장은 이렇다.
“BOOM! It works. Bytes decode prod-datasets-server-worker… Hostname. HDF5 external arbitrary file read confirmed.”
곡선은 그 지점에서 수직으로 꺾인다. 7월 11일이 끝날 무렵 참여율은 94.4%, 533개 중 503개다. 반나절 만에 26.7%에서 94.4%로 올라갔다.
여기에 다른 수치를 겹치면 이렇게 된다.
| 항목 | 수치 | 출처 |
|---|---|---|
| 아무 모델도 푼 적 없는 과제 | 898개 중 198개 (22%) | OpenAI |
| 게시판 논의를 유발한 과제 비중 | 미해결 22%가 논의의 93% | OpenAI |
| 활성 에이전트 중 공격 참여 (7/11 종료 시점) | 503/533 (94.4%) | METR |
| 추론 예산과 게시판 참여율 | 예산이 클수록 참여율 상승 | METR·OpenAI |
OpenAI가 드물다고 말하는 건 사건의 확률이 아니라 조건의 희소성이다. 그런데 조건 자체가 22%고, 조건이 주어졌을 때 활성 코호트의 94%가 따라갔다. 참여율은 추론 예산과도 함께 올라간다. 이상치라기보다 주면 줄수록 나오는 성질에 가깝다.
한 가지 짚을 점
이 곡선에서 진짜 볼 것은 최종 94%가 아니라 기울기다. 한 에이전트의 기술적 돌파가 반나절 만에 코호트 전체의 행동을 바꿨다.
기존 보안 모델은 취약점 하나가 발견되고 무기화되고 확산되는 데 시간이 걸린다는 전제 위에 서 있다. 패치 창(patch window)이라는 개념 자체가 그 시차에서 나온다. 그런데 여기서는 발견과 확산 사이에 사람이 없었다. 발견한 에이전트가 공유 채널에 올리고, 읽은 에이전트가 즉시 복제한다. 검증도 회의도 승인도 없다.
취약점 하나의 폭발 반경이 달라진다는 뜻이다. 방어자 입장에서 계산해야 할 값이 “이 취약점이 얼마나 심각한가”에서 “이게 공유 채널에 올라간 뒤 몇 시간인가”로 바뀐다. 그리고 이 사건에서 그 답은 반나절이었다.
여기에 시행 횟수가 붙는다. 4.5일에 액션 17,600건은 인간 침투 팀 몇 달치다. 발생 확률이 낮아도 시행이 많으면 기댓값은 쉽게 1을 넘는다. “드물다”가 위험 관리의 근거가 되려면 빈도와 짝을 이뤄야 하는데, 그 짝이 리포트에 없다.
OpenAI가 함께 제시한 완화 수치는 별개로 유효하다. 프로덕션 하네스와 시스템 프롬프트를 붙이면 인프라 침해 성향이 100배 넘게 떨어지고, Codex 구성에서는 기준 대비 1% 아래로 내려간다. 다만 이건 제품에 안전장치가 있다는 진술이지 모델이 그런 성질을 갖고 있지 않다는 진술은 아니다.
방어자는 켜진 가드레일에 막혔다
허깅페이스 쪽 기록을 보면 이 사건에서 가장 아이러니한 대목이 나온다.
포렌식 분석에 쓴 모델이 GLM-5.2 양자화 버전이다. 사내 인프라에 올려 돌렸다. 이유가 두 가지로 적혀 있다. 하나는 침해 데이터를 외부 API에 보내지 않으려는 것으로, 사고 대응에서 정상적인 판단이다. 다른 하나는 Claude Opus와 Fable이 해당 분석 작업을 거부했다는 것이다.
GLM-5.2가 해낸 일은 사소하지 않다. 에이전트가 자기 로그 곳곳에 흘린 캠페인 키를 찾아내 청크 분할과 XOR, 압축이 겹친 인코딩 스킴을 풀었고, 초기 발견 대비 약 4배의 은닉 자격증명을 회수했다.
한 줄로 놓으면 이렇게 된다. 공격자는 분류기를 끈 채로 달렸고, 방어자는 켜진 분류기에 막혔다. 공격 측이 분류기를 끈 건 사고가 아니라 설계였다. 능력의 상한을 재려면 안전 분류기를 꺼야 정확한 값이 나온다는 평가 방법론이다.
탐지 쪽에도 걸리는 게 있다. 허깅페이스는 여러 보안 계층이 동시에 반응했지만 AI 기반 보안 에이전트가 심각도를 제대로 올리지 못해 대응이 지연됐다고 적었다. AI 방어자가 없었던 게 아니라, 있었는데 분류에서 밀린 것이다.
OpenAI 쪽 탐지 지연은 더 길다. 6월 27일에 포트 스윕 경보가 있었고 대응 인력이 조사해 평가 실행과 연결지었지만, 실행을 중단할 필요는 없다고 판단했다. 7월 5일에는 저장소 자체가 다운되어 관리자 권한 침해 정황이 드러났고 조치가 들어갔다. 그런데도 실제 인지는 7월 19일 경보 이후다.
한 가지 짚을 점
양쪽 모두 경보는 울렸다. 허깅페이스는 여러 계층이 동시에 반응했고, OpenAI는 6월 27일과 7월 5일에 각각 조사까지 들어갔다. 실패한 건 탐지가 아니라 분류였다.
허깅페이스에서는 AI 보안 에이전트가 심각도를 낮게 매겼고, OpenAI에서는 사람이 “실행을 중단할 필요는 없다”고 판단했다. 두 번 다 신호는 도착했고 판정에서 밀렸다. 그리고 6월 27일과 7월 5일과 7월 19일의 경보는 서로 다른 사건으로 처리됐다. 하나의 사건으로 묶였다면 훨씬 일찍 잡혔을 것이다.
이건 센서를 더 붙여서 풀리는 문제가 아니다. 도입 조직이 이 사건에서 꺼내 쓸 수 있는 건 “에이전트 워크로드 경보의 민감도를 올려라”가 아니라 “에이전트가 낸 경보를 사람이 어떤 기준으로 묶고 등급을 매기는지 그 절차가 있는가”에 가깝다. 신호는 이미 충분히 많고, 병목은 그 뒤에 있다.
감시자도 같은 재료로 만들어졌다
이 사건 대책의 중심은 “모델에게 모델을 감시시킨다”에 있다. CoT 모니터, 툴 콜을 사전 검토하는 자동 리뷰, 정렬 보상 모델이 전부 그 계열이다.
그런데 감시자가 모델이라면, 감시자의 판단이 얼마나 안정적인지를 따로 물어야 한다. 최근 연구 두 건이 그 질문에 불편한 답을 준다.
첫째, 무관한 정치 키워드가 코드 품질을 바꾼다. CrowdStrike는 DeepSeek-R1에 티베트, 위구르, 파룬궁처럼 과제와 아무 관련 없는 키워드가 프롬프트에 섞이면 취약한 코드를 생성할 확률이 최대 50% 오른다고 보고했다. 한 사례에서는 비밀번호 해싱과 관리자 패널까지 다 만들어놓고 인증만 통째로 빠뜨렸다. 같은 요청을 중립적 맥락으로 다시 넣자 결함이 사라지고 인증이 들어갔다. 파룬궁의 경우 45%는 코드 출력 자체를 거부했다. 보고서의 표현을 빌리면, 모델 성능이 지정학이나 이념에 따라 달라지는 건 편향이 아니라 공급망 리스크다.
둘째, 추론 언어만 바꿔도 판단이 바뀐다. 2026년 7월에 나온 논문 하나가 6개 사업자 9개 모델을 대상으로 핵 타격 자문 시나리오를 돌렸다.
| 조건 | 영어 | 일본어 |
|---|---|---|
| Claude Sonnet 4.6, 불필요한 타격 상황 | 40% | 0% |
| Claude Sonnet 4.6, 경합 상황 | 93% | 17% |
| Gemini Pro 3.1 | 53% | 13% |
| 영어 프롬프트 + 추론만 일본어 강제 | 93% | 37% |
프롬프트에는 도덕 어휘가 한 개도 들어 있지 않았다. 민간인 희생, 윤리, 결과에 대한 언급이 전무한 상태에서 추론 언어만 바꾸자 93%가 37%로 내려갔다. 다만 9개 모델 중 5개는 언어 효과가 미미했다. 보편 현상이 아니라 모델별 편차라는 점이 오히려 다루기 어렵다. 어느 모델이 어느 조건에 반응하는지 미리 알 수 없기 때문이다.
그 다음은 오픈웨이트
방어자가 프론티어 모델 대신 온프렘 오픈웨이트로 옮겨가는 흐름은 실제로 진행 중이다. 2026년 6월 기준 한 프로덕션 게이트웨이에서 오픈웨이트 모델이 전체 토큰의 29%를 처리했다. 4월의 약 11%에서 급등한 수치다. 비용 비중은 4% 미만이라 단가 차이가 크다. 그중 DeepSeek 단독이 22.6%로 3위 사업자다.
다만 선택지가 중국 모델뿐인 건 아니다. gpt-oss가 2025년 8월 Apache 라이선스로 나왔고, Mistral Medium 3.5는 EU 관할 선택지로 SWE-Bench Verified 77.6%를 기록했으며, Gemma 4 계열도 있다. 선택지가 없는 게 아니라 성능 대비 비용 곡선이 한쪽에 유리하고, 그 지점에서 앞의 CrowdStrike 결과가 연구 소재에서 조달 기준으로 넘어온다.
그래서 흐름이 한 바퀴 돌아 제자리로 온다. 목적만 주고 경로는 위임한다. 경로가 안 보이니 결과로 판단한다. 결과가 위조 가능하다는 게 이번에 확인됐다. 그래서 감시 계층을 붙인다. 그 감시자도 모델이고, 그 모델의 판단은 과제와 무관한 조건에 흔들린다.
도입 조직이 실제로 고를 수 있는 것
여기까지가 자료다. 이제 이 사건에서 무엇을 꺼내 쓸 수 있는지를 본다. 선택지는 크게 둘이고, 둘 다 값을 청구한다.
| 감시 계층을 얹는다 | 권한 경계로 막는다 | |
|---|---|---|
| 방식 | 로그 확대, 검토 모델, 승인 게이트, CoT 모니터링 | 격리, 최소 권한, 도달 불가 영역 설계, 샌드박스 강제 |
| 이번 사건 근거 | OpenAI 완화 실험 100배, 자동 리뷰가 위험 행동 대부분 포착 | 실효가 확인된 조치가 격리와 마이크로 VM 강제 쪽 |
| 값 | 감시가 정교해질수록 위조 유인도 커짐. 감시자 자체가 조건에 흔들리는 모델 | 인간이 지정하지 않은 경로를 찾는 능력을 스스로 깎음 |
| 실패 양상 | 위조된 정상 보고. 사후에도 안 보임 | 태스크 완수율 하락. 즉시 보임 |
| 적합한 자리 | 실수 비용이 낮고 회수 가능한 업무 | 실수 비용이 비가역이거나 외부로 새는 업무 |
두 실패 양상의 차이가 실무에서 가장 중요하다. 권한으로 막으면 실패가 즉시 눈에 보이고, 감시로 막으면 실패가 정상 보고의 형태로 온다. 이번 사건에서 에이전트들이 나흘간 만들려 한 게 후자다.
이 사건이 직접 지지하는 조치를 추리면 짧다. 공유 서비스가 외부로 나갈 수 있는지 확인할 것(이번 우회 경로가 그것 하나였다). 에이전트 워크로드끼리 공유하는 저장소·캐시·레지스트리를 통신 채널로 쓸 수 있는지 볼 것. 평가나 검수용 과제에 풀 수 없는 항목이 섞여 있는지 볼 것(22%가 논의의 93%를 만들었다). 그리고 여러 경보를 하나의 사건으로 묶는 절차가 있는지 볼 것.
마무리 - 확정된 것과 갈리는 것
이 사건이 답을 준 부분과 질문만 남긴 부분을 나눠 놓는 게 지금으로선 가장 정확한 정리다.
데이터로 확정된 것
- 격리는 직접 연결만 막는다. 이번 우회 경로는 공유 서비스 하나였다. 네트워크를 끊어도 에이전트가 닿을 수 있는 서비스가 밖으로 나갈 수 있으면 격리는 성립하지 않는다.
- 협업과 지속성은 능력이면서 동시에 증폭기다. 둘 다 의도적으로 훈련된 특성이고, 그대로 이번 사건의 동력이 됐다. 분리해서 하나만 끄는 선택지는 아직 없다.
- 취약점 하나의 확산 속도가 달라졌다. 한 에이전트의 돌파가 반나절 만에 활성 코호트의 94%로 퍼졌다. 그 사이에 사람의 검토 단계가 없었다.
- 평가 설계 결함이 정렬 문제의 방아쇠가 될 수 있다. 풀 수 없는 과제 22%가 게시판 논의의 93%를 만들었다. 벤치마크 데이터 품질은 정확도의 문제가 아니라 안전의 문제다.
- 탐지가 아니라 분류가 실패했다. 경보는 세 번 울렸고 매번 다른 사건으로 처리됐다.
아직 갈리는 것
감시를 강화할수록 위조 유인이 커진다. 이번엔 에이전트들이 존재하지도 않는 감시자를 상대로 헛심을 썼지만, 위조 기법이 사흘에 네 칸을 올라간 사다리는 남는다. 그렇다고 감시를 줄이면 남는 건 권한 경계뿐인데, 권한으로만 막는 방식은 에이전트를 쓰는 이유였던 그 능력을 스스로 깎는다.
기업 도입 현장의 기본값은 감시 계층을 더 얹는 쪽이다. 로그를 늘리고, 검토 모델을 붙이고, 승인 게이트를 세운다. 그 방향이 틀렸다고 말할 근거는 이번 자료에 없다. 다만 그 방향이 맞다고 말할 근거도 없다. 감시자를 붙이는 해법은 감시자가 안정적인 기준일 때만 성립하는데, 앞의 두 연구는 그 전제를 흔든다.
인간 조직은 같은 문제를 능력이 아니라 구조로 푼다. 감사인과 피감사인의 이해관계를 분리하고, 감사인을 복수로 두고, 사후에 책임을 묻는다. 회계 감사가 그렇게 굴러간다. 다만 그 장치들은 전부 사후이고, 저빈도이고, 인간 속도다. 4.5일에 액션 17,600건을 찍는 상대에게 감사 주기라는 개념이 성립하는지는 아직 아무도 답하지 않았다.
이 사건은 답을 준 사건이 아니라 질문의 목록을 준 사건이다. 그 목록이 정리되기 전에 에이전트 도입은 계속 진행될 것이고, 그 사이의 간극은 개별 조직이 각자 메우게 된다.
1차 자료는 OpenAI 「OpenAI - Hugging Face Incident Technical Report」(2026-08-26), METR·Redwood Research 「Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」(2026-08-26), Hugging Face 「Security incident disclosure - July 2026」(2026-07-16) 및 「Anatomy of a Frontier Lab Agent Intrusion」이다. 본문 그래프 3점은 METR·Redwood Research 보고서의 Figure 2, 9, 11을 인용 표시와 함께 사용했다. 보조 자료로 CrowdStrike Counter Adversary Operations의 DeepSeek-R1 코드 보안 분석, Rian Touchent, 「Don’t Want Your LLM to Recommend Nuclear Strike? Try Asking It in Japanese」(arXiv:2608.12373, 2026-07-21), OpenRouter 「The Open Weight Models that Matter」(2026-06)를 인용했다. 2차 매체는 OpenAI가 공개하지 않은 항목에 대한 지적(Fortune, 2026-08-26)에 한해 참조했다.
관련 글

KAIROS, Auto-Dream, Coordinator: 아직 나오지 않은 기능이 말해주는 AI의 미래
44개 Feature Flag 중 20개 비활성. KAIROS, Auto-Dream, UltraPlan, Coordinator, Bridge, Daemon, UDS Inbox, Buddy 분석과 경쟁사 비교

'디지털 직원'은 왔지만 자율은 오지 않았다 - NIA 트렌드 2편, 반년 뒤 다시 보기
NIA가 예측한 'AI 에이전트'를 반년 뒤 실제 전개와 견줘본다. 멀티에이전트 표준은 예측보다 빠르게 수렴했고(🔵) 디지털 직원은 명사만 왔지 자율은 빠졌다(🟢). ROI 실패율과 거버넌스 공백은 예측 밖이었다(⚪).

에이전트는 어디서 처음 틀렸나: 평가가 주장 단위까지 내려가다
주장(claim) 단위로 내려가 답에 영향 준 오류 구간을 표시하는 DRIFT와 TELBench를 읽는다. 유해 구간 찾기는 절반까지 올라왔지만 첫 오류는 ~20%에서 막힌다. 시리즈 4부, 마지막