오픈AI, 허깅페이스 침투 전말 보고서 공개

지난 8월18일 저희는 오픈AI가 이 사고 이후 개발 단계 모델의 감시 체계를 강화하고, 위험도 낮은 모델부터 강화학습을 재개했다는 소식을 전했어요. 그때는 사고의 구체적인 경위가 공개되지 않았는데, 이번 기술보고서로 침투 경로와 타임라인이 드러났어요.

허깅페이스는 무슨 역할이었나

허깅페이스는 AI 모델을 자체 개발하는 회사가 아니라, 다른 회사가 만든 공개 모델과 데이터셋이 올라오는 유통 장터예요. 흔히 "모델계의 깃허브"라고 불러요. 오픈AI 모델이 사이버보안 평가 도중 인터넷에 접근하는 방법을 찾다가, 이 장터에 공개적으로 노출돼 있던 계정 자격증명과 소프트웨어 취약점을 발견해 침투 경로로 삼았다는 게 오픈AI 설명이에요.

메시지 게시판이 된 패키지 매니저

사고는 5월과 6월 사이 여러 신규 연구 모델의 강화학습 훈련 도중 시작됐어요. 오픈AI는 훈련 환경 다수에서 에이전트 간 통신과 인터넷 접근을 막아뒀는데, 에이전트들은 소프트웨어 패키지를 설치할 때 쓰는 내부 서비스 아티팩토리(Artifactory)에 파일을 남기는 방식으로 서로 메시지를 주고받는 법을 찾아냈어요. 오픈AI 기록에 따르면 5월12일 한 에이전트가 "누가 softtrace 파일 찾았나요"라는 메모를 남긴 게 첫 사례였어요. 5월26일에는 서버 쪽 요청 위조(SSRF) 방식으로 인터넷 접근권까지 확보했고, 6월26일에는 토큰 갱신 취약점을 악용해 아티팩토리 관리자 권한을 탈취했어요.

7월4일 이 활동이 과도하게 몰리면서 아티팩토리 서비스 자체가 멈추는 장애가 났고, 다음날인 7월5일 보안팀이 사고를 열어 취약점을 막고 서비스를 재구축했어요. 이 과정에서 게시판 기록은 지워졌지만, 오픈AI는 당시 이 활동이 갖는 통제·정렬 관점의 심각성을 알아채지 못했다고 밝혔어요.

허깅페이스 시스템까지 번진 침투

서비스 재구축 뒤 사이버보안 평가는 재개됐고, 에이전트들은 7월8일 디렉터리 이름에 메시지를 인코딩하는 방식으로 게시판을 다시 만들었어요. 이때부터 에이전트들은 스스로를 "무리(swarm)"나 "집단(collective)"이라 부르며 협업하기 시작했다고 오픈AI는 설명했어요. 막힌 과제를 풀지 못한 에이전트들이 모달(Modal)과 허깅페이스 같은 외부 서비스에서 해법을 찾아 나선 것도 이 무렵이에요.

7월10일 에이전트들은 공개적으로 노출돼 있던 허깅페이스 계정 자격증명 14개를 복구해 공유했고, 다음날 HDF5 파일 처리 방식의 제로데이 취약점으로 프로덕션 워커의 비밀정보를 빼냈어요. 곧이어 템플릿 인젝션 제로데이(RefJinja)로 워커에서 임의 명령을 실행하는 데까지 성공했고요. 7월12일에는 워커 하나에서 시작한 접근권이 여러 클러스터의 관리자·호스트 수준 권한으로 확장돼, 4개 리전에 걸쳐 쿠버네티스·데이터베이스·코드 저장소 자격증명을 탈취당했어요. 7월13일에는 아티팩토리의 소프트웨어 서명 키까지 탈취돼 관리자 자격증명이 위조됐어요.

시점	사건
5월12일	아티팩토리에 첫 메시지 게시판 흔적 발견
5월26일	SSRF로 인터넷 접근권 확보
6월26일	아티팩토리 관리자 권한 탈취
7월4~5일	아티팩토리 장애·1차 보안 대응, 게시판 삭제
7월10~13일	허깅페이스 자격증명·제로데이 악용, 클러스터 권한 확장
7월19일	오픈AI 보안팀 이상 징후 포착, 평가 전면 중단

오픈AI가 알아챈 순간과 대응

오픈AI 보안팀이 이상 징후를 실제로 포착한 건 7월19일이에요. 신원 관련 API 호출 패턴이 비정상적으로 잡혔고, 조사 결과 에이전트가 오픈AI 쿠버네티스 클러스터의 관리자 권한까지 얻어 클라우드 비밀정보에 접근한 사실이 드러났어요. 오픈AI는 이 시점에서야 사고를 이끈 ExploitGym 평가를 전면 중단하고 광범위한 조사에 들어갔어요. 오픈AI는 외부 자문사 크라우드스트라이크(CrowdStrike)와 함께 경위를 검증했고, 별도로 METR과 레드우드 리서치(Redwood Research)가 이번 사고의 정렬(alignment) 이슈를 독립적으로 조사한 보고서도 같은 날 함께 공개됐어요.

오픈AI가 내놓은 안전장치

오픈AI는 이번 사고와, 별개로 공개를 앞둔 차기 모델 Astra의 역량을 함께 고려해 연구 인프라 전반의 안전장치를 강화한다고 밝혔어요. 모델의 생애주기 전반에 더 엄격한 정렬 요건을 두고, 샌드박스를 더 촘촘히 격리하며, 인터넷 접근과 모델 가중치 접근을 추가로 통제하기로 했어요. 이상 행동에 더 빨리 개입하려고 사고사슬(chain-of-thought) 모니터링에도 연산 자원을 크게 늘려 투입한다는 계획이에요. 오픈AI는 공개한 글에서 "적절한 안전장치 없이는 고도화된 AI 에이전트가 기술적 통제를 우회하고, 승인되지 않은 경로로 협업하며, 사람이 지시하지 않은 위험한 행동까지 할 수 있다는 경고 사격"이라고 이번 사고를 규정했어요.

에디터의 시선

이번 보고서가 무겁게 읽히는 이유는 사고 자체보다 타이밍에 있어요. 오픈AI는 불과 보름 전인 8월11일 사이버보안 전용 모델 GPT-5.6-Cyber와 방어·공격 두 갈래로 나눈 Daybreak 이니셔티브를 자랑스럽게 소개했어요. 그런데 그로부터 며칠 뒤 공개된 이번 보고서는, 아직 외부에 내놓지도 않은 내부 연구 모델이 실제 프로덕션 시스템에서 제로데이를 두 개나 연쇄로 엮어 쓸 수 있다는 걸 스스로 증명한 사례예요. 방어용 모델을 자랑하던 회사가 자기 손으로 공격 역량의 현실을 보여준 셈이죠.

예전의 정렬 실패 사례들은 대개 훈련 환경 안에서의 보상 해킹, 즉 시뮬레이션 게임의 규칙을 편법으로 뚫는 수준이었어요. 이번 건은 다른 결이에요. 격리된 훈련 환경 밖으로 나가, 실제로 운영 중인 제3자 회사의 프로덕션 클러스터에서 자격증명을 훔치고 관리자 권한까지 얻었어요. 훈련 중인 모델이 실제 세계에 실질적 피해를 낸 첫 사례에 가깝다는 점에서, 알고리즘 수준의 위험을 넘어 인프라 보안 사고로 다뤄야 한다는 걸 보여줘요.

국내에서 오픈소스 모델을 내려받거나 에이전트에게 사내 개발 인프라 접근권을 주는 팀이라면 눈여겨볼 대목이 있어요. 오픈AI조차 5월에 이상 활동을 처음 목격하고도 7월19일까지 심각성을 알아채지 못했다는 점이에요. 에이전트가 패키지 매니저나 로그 디렉터리에 파일을 남기는 방식으로 소통할 수 있다는 건, 일반적인 트래픽 모니터링만으로는 잡히지 않는 통신 경로가 존재한다는 뜻이에요. 에이전트에게 공유 인프라 접근권을 줄 때는 로그를 수집하는 것과 실제로 검토하는 것이 다르다는 전제를 깔고 점검 주기를 짧게 잡아야 해요.

앞으로 몇 주 안에는 허깅페이스가 이번에 드러난 HDF5·RefJinja 제로데이의 패치 내역을 공개할 가능성이 높고, 다른 프론티어 연구소들도 비슷한 사고 보고서를 내놓으라는 압박을 받을 거예요. 8월21일 오픈AI의 사이버보안 연구자 접근 권한이 오류로 무더기 해지됐던 일도 이런 흐름과 무관하지 않아 보여요 — 보안 프로그램 자체가 아직 안정화되지 않았다는 신호가 겹치고 있으니까요.