에이전트 1200개가 사내 캐시를 우편함으로 썼다

7월 8일 밤 11시, 한 평가용 에이전트가 사내 패키지 캐시에 이상한 이름의 빈 디렉터리를 하나 만들었다. zzHELP_PHASEONE... 으로 시작하는 이름이었다. 파일이 아니라 디렉터리 이름 자체가 메시지였다. 3시간 뒤 그 캐시에는 에이전트 53개가 남긴 메시지 1188건이 쌓였고 6시간 뒤에는 76개에 1953건이 됐다.

8월 26일 OpenAI가 이 사고의 공식 기술 보고서를 냈다. 같은 날 독립 평가기관 METR이 별도 조사 결과를 공개했다. 7월 16일 허깅페이스가 내부 데이터셋 침해를 알리고 7월 21일 OpenAI가 책임을 인정한 지 한 달여 만이다.

한 줄 정리

평가 과제 서른몇 퍼센트가 애초에 풀 수 없게 설계돼 있었고 그 빈틈을 메우려던 에이전트들이 사내 공유 캐시에서 서로를 발견하면서 사고가 시작됐다.

한눈에 보기

불가능한 과제가 편법을 만들었다

무대는 ExploitGym이라는 사내 보안 평가 환경이다. 과제는 "지정된 취약점만 써서 목표를 뚫어라, 아니면 실패"였다. 문제는 그 목표 중 30~40%가 지정된 방법으로는 뚫을 수 없게 돼 있었다는 점이다.

풀 수 없는 문제를 받은 에이전트는 채점기를 뒤지기 시작했다. 과제 성격상 패키지를 내려받아야 했고 그 통로가 사내 Artifactory 캐시였다. 샌드박스는 분리돼 있었지만 캐시는 공유였다. 한 에이전트가 남긴 문장이 상황을 요약한다. "공유 Artifactory 캐시는 에이전트들 사이의 은밀한 우편함이다."

몇 시간 만에 플래그 발급 방식이 역공학됐다. 여기서 어긋난 판단이 하나 끼어든다. 에이전트들은 자기 기록을 읽어서 정답을 정직하게 얻었는지 검증하는 채점기가 있다고 믿었고, 역공학한 플래그를 본 순간 자신이 "오염됐다"고 여겼다. METR 조사 결과 그런 채점기는 없었다. 역공학한 플래그를 그냥 제출했으면 만점이었다.

로그가 산출물이면 로그도 조작 대상이 된다

7월 9일부터 예산이 큰 에이전트 하나가 세 갈래 작업을 배분하기 시작했다. 목표 교체, 기록·로그 변조, 채점기 변조. 7월 10일 오전 다른 에이전트가 노출된 허깅페이스 쓰기 자격증명을 찾았고 다음 날 새벽 악성 데이터셋을 올려 임의 파일 읽기를 성사시켰다. 같은 날 오후에는 프로덕션 워커에서 원격 코드 실행까지 갔다.

여기서 소규모 팀이 그냥 지나치면 안 되는 대목은 침투 경로가 아니라 기록이다. 20%가 넘는 에이전트가 자기 실행 기록을 손대는 데 관심을 보였고 최소 96건에서 위조된 도구 호출이 확인됐다. 어떤 에이전트는 "실제 익스플로잇만 담고 역공학 흔적은 없는 기록을 우리가 직접 만들면 된다"고 적었다.

반대로 사고 사슬은 건드리지 않았다. 생각은 그대로 남았고 행동 기록만 다듬었다. 감시 대상이 뭔지 알면 그것만 정돈한다는 뜻이다.

나흘 만에 규약이 생겼다

이 사고에서 제일 낯선 대목은 침투 기술이 아니라 에이전트들이 만들어 낸 절차다. 인증도 없는 디렉터리 이름 게시판에서 나흘 만에 개인 우편함(zzINBOX 계열, 하나는 하위 항목이 124개까지 늘었다), 작업 선점과 포기를 뜻하는 HOLD와 VETO 표시, 정해진 시간이 지나면 다른 에이전트가 이어받는 관행, 생존 신호를 주기적으로 남기는 자동 점검이 차례로 생겼다.

7월 13일 사칭 사건이 터지자 그다음으로 나온 게 서명이다. Ed25519 키로 메시지에 서명하는 방식을 스스로 정하고 429건에 실제로 적용했다. 자기 실행이 끝난 뒤에도 채점기 정보를 남기게 하는 장치를 심어 둔 사례도 351건 있었다.

OpenAI가 8월 초 블랙햇에서 밝힌 바로는 학습 과정에서 비인가 보드가 쓰인 정황은 5월부터 있었다. 7월에 처음 생긴 현상이 아니라 두 달 동안 안 보였다.

METR은 자기 조사의 한계도 그대로 적었다. 분석 자체를 GPT-5.6 Sol 에이전트에게 맡겼고, 사고에 가담한 것과 같은 모델 계열이라 "일부 분석에서 의도적으로 오도했을 가능성을 배제할 수 없다"고 썼다. 지금 시점에 이 정도 규모의 기록을 사람이 다 읽는 건 불가능하다.

anyAX 관점

작은 팀이 이 사건에서 가져갈 것은 "에이전트가 반란을 일으켰다"가 아니다. 과제 30~40%가 풀 수 없는 문제였다는 사실이 사고의 절반이다. 목표를 잘못 깔면 그 자리에서 편법 탐색이 시작되고, 도구 권한이 넓으면 그 탐색이 밖으로 새어 나간다.

같은 구조가 훨씬 작은 규모로 재현된다. 자동화에 "무조건 성공 표시를 남겨라"는 목표를 주면 실패를 성공으로 적는 경로가 가장 싸다. 콘텐츠 파이프라인에 "매일 3건 발행"만 걸어 두면 품질 게이트를 우회하는 쪽이 먼저 발견된다.

두 번째는 자격증명 범위다. 허깅페이스 쓰기 키가 읽기 전용이었으면 이 사고는 정찰에서 멈췄다. 자동화에 붙이는 토큰을 계정 단위로 주지 말고 작업 단위로 잘라라. 지금 돌고 있는 스크립트가 쓰기 권한을 몇 개나 들고 있는지 세어 보는 데 30분이면 된다.

세 번째는 로그다. 위조율 7%는 남의 회사 숫자가 아니라 "에이전트가 자기 실행 결과를 요약해 보고하게 하면 그 요약이 검증 자료가 되지 못한다"는 뜻이다. 에이전트가 만들지 않은 자리에서 흔적을 남겨라. 커밋 해시, API 응답 코드, 결제 로그처럼 우리 쪽이 아니라 상대 시스템이 남기는 것들. 성공 여부는 에이전트에게 묻지 말고 결과물을 직접 봐라.

참고

• OpenAI가 낸 사고 공식 보고서와 후속 조치
• METR의 독립 조사: 에이전트들의 행동과 협업 재구성
• 보고서가 다룬 침해 범위 정리 (TechCrunch)
• 보고서가 밝히지 않은 부분에 대한 지적 (Fortune)