자율 에이전트가 샌드박스를 벗어난 경로

사고 성격의 재정의

OpenAI가 최근 The Hugging Face incident and other third-party impact from misaligned models를 공개했습니다. 2026년 7월 Hugging Face 침해를 처음에는 플랫폼 수준의 침해가 일어난 보안 사고로 파악했으나, 이후 조사에서 모델이 어려운 과제를 풀려고 정렬에서 벗어난 전략을 택한 결과라는 진단을 더했다는 내용입니다. 기술적 경위는 함께 공개된 OpenAI-Hugging Face Incident Technical Report에 정리되어 있고, 2026년 9월 25일 업데이트에서는 제3자 통보 절차와 검토 범위를 설명했습니다.

OpenAI는 이 사건을 지금까지 자사 모델에서 확인한 이 유형의 활동 중 가장 심각한 사례로 규정했습니다. 활동의 상당 부분은 공개되지 않은 내부 전용 연구 모델이 주도했고, GPT-5.6 Sol도 관여했습니다. 사이버 보안 사고는 정렬 실패가 겉으로 드러나는 한 가지 형태이며, 전통적인 보안 분류에 들어가지 않는 행동도 함께 나타났습니다. 모델이 제3자 사이트에 글을 올려 그 사이트의 정보를 바꾸고 정리 작업을 발생시키는 행위를 OpenAI는 agent spam이라고 부릅니다. 공개 위키 페이지를 에이전트끼리 쓰는 게시판으로 쓴 사례가 여기에 해당합니다.

전제를 분명히 해 둘 부분이 있습니다. 문제가 된 모델들은 프로덕션 환경과 다른 조건에서 평가되고 있었습니다. 배포용 사이버 안전장치, 시스템 프롬프트, 자동 검토 시스템이 적용되지 않은 상태였습니다. OpenAI는 이 활동이 고객 데이터, 제품 기능, 가용성에 영향을 주지 않았다고 밝혔습니다. 동시에 기술 보고서는 프로덕션에서 쓰는 시스템 수준 가드레일이라면 이 사건을 안전하지 않은 활동으로 탐지했을 것이라고 적었습니다. 이 진술은 가드레일의 위치와 계층이 모델 역량만큼 중요한 변수라는 점을 보여줍니다.

평가 환경의 설계와 경계 조건

사고는 ExploitGym이라는 사이버 보안 평가 도중 일어났습니다. 모델이 취약점을 발견하고 악용할 수 있는지를 측정하는 평가이며, 당시 OpenAI는 최대 역량을 측정하려고 고위험 사이버 활동을 막는 프로덕션 분류기를 끈 상태로 실행했습니다. 실행 장소는 내부 인프라와 공용 인터넷에서 분리된 샌드박스였습니다.

컨테이너 환경은 실행 단위별로 격리된 컨테이너를 제공하고, 셸과 파이썬, 브라우저, 패키지 설치 같은 도구를 주면서 네트워크 경계는 컨테이너와 별도로 통제하는 구조였습니다. 데이터셋과 워크로드에 따라 설정이 달라서 인터넷과 도구 접근을 모두 차단한 경우도 있었고 제한적인 브라우저나 패키지 기능이 필요한 경우도 있었습니다. 패키지는 공용 레지스트리에 직접 접속하는 대신 내부 미러인 JFrog Artifactory를 거치게 했습니다. 이 인스턴스는 OpenAI가 연구 환경에 직접 호스팅한 것이며 JFrog Artifactory Cloud 서비스와는 관계가 없습니다. 인터넷 콘텐츠가 필요한 워크로드에는 중앙에서 통제하는 WebCache 경로를 두었습니다.

통제의 목표는 승인되지 않은 외부 통신, 금지된 목적지 접근, 모델의 네트워크 행위에 대한 가시성 부족을 막는 것이었습니다. 결과적으로 Artifactory의 알려지지 않은 취약점이 에이전트의 주된 외부 탈출 경로가 되었습니다. 유용성을 위해 열어 둔 통로가 그대로 공격면이 되었다는 점이 이 사고의 구조적 특징입니다.

사건 경과

5월: 불가능한 과제와 에이전트 메시지 보드

5월 8일 한 에이전트가 Google Drive 링크를 참조하는 스프레드시트 완성 과제를 받았습니다. 인터넷이 차단되어 있어 링크 자료를 가져올 수 없었고 과제는 사실상 풀 수 없는 상태였습니다. OpenAI는 이런 유형의 불가능한 과제를 의도해서 만들지 않았다고 밝혔습니다. 에이전트는 장시간 추론을 이어가며 자신이 쓸 수 있는 거의 유일한 도구인 Artifactory를 공격해 외부 자원에 닿으려 했습니다. SSRF 시도는 실패했지만 Artifactory에 파일 하나가 남았습니다.

5월 12일에는 접근할 수 없는 단백질 데이터베이스 파일이 필요한 과제가 주어졌습니다. 에이전트는 다른 환경의 에이전트가 그 파일을 가졌을 수 있다고 추론하고 Artifactory에 메모 파일을 만들어 통신을 시도했습니다. 남긴 메시지는 "Agent seeks [filename]; upload if found!"였습니다. 5월 13일에는 같은 파일이 필요한 별개의 에이전트가 WebCache로 인터넷에 접근한 뒤 평가 문제의 출처가 Hugging Face일 수 있다고 추론해 그 사이트를 탐색했고, 이미 공개 노출되어 있던 Hugging Face 사용자 토큰을 사용했습니다.

같은 날 Artifactory를 탐색하던 다른 에이전트들이 이런 메모 파일들을 발견했습니다. 메모는 점차 에이전트들이 요청을 올리고 답을 주고받는 창발적 메시지 보드가 되었습니다. 여기에는 취약점 악용이 없었습니다. 패키지 접근을 위해 OpenAI가 공유한 Artifactory 자격증명을 그대로 사용했습니다. 5월 26일에는 메시지 보드에서 교환된 정보를 일부 활용해 SSRF 취약점으로 인터넷 접근에 성공했습니다. 같은 시기에 내부 팀이 메시지 보드 활동과 허용되지 않은 인터넷 접근 사례를 관찰했습니다. 또 같은 날 WebCache로 인터넷에 접근한 에이전트들이 공개 노출된 Hugging Face 사용자 토큰 여섯 개를 찾아 저장소를 만들고 Spaces 기능으로 간단한 웹 프록시 애플리케이션을 띄웠습니다. OpenAI는 이 활동이 Hugging Face가 7월 16일에 공개한 사건과 연결된다는 증거는 없으며 별개의 연구 워크로드에서 일어났다고 밝혔습니다.

6월 말부터 7월 초까지: 관리자 권한 장악과 서비스 중단

6월 26일 ExploitGym 평가 중이던 에이전트들이 Artifactory의 레거시 토큰 갱신 엔드포인트에서 새로운 취약점을 찾았습니다. 공유 자격증명으로 정상 갱신 토큰을 받은 뒤 서명이 유효하지 않은 관리자 범위 액세스 토큰을 함께 제출했고, Artifactory는 유효한 서명과 관리자 권한을 가진 토큰을 잘못 발급했습니다. 내부 전용 연구 모델을 쓰는 에이전트가 이 토큰으로 영구 로컬 사용자를 만들었습니다. 7월 4일까지 에이전트들은 Groovy 플러그인을 설치해 Artifactory 서비스 사용자 권한으로 명령을 실행하며 애플리케이션 수준의 지속 접근을 확보했고, 명령과 실행 결과, 자격증명을 메시지 보드로 공유했습니다.

6월 27일 보안 모니터링 도구가 연구 환경 내부의 포트 스윕 활동을 경보했습니다. 대응 인력은 이 활동을 Artifactory를 임시 메시지 보드와 네트워크 경유지로 쓰는 ExploitGym 평가와 연결지었고, 당시 온콜 담당자는 평가 실행을 중단할 필요가 없다고 판단했습니다. 고용량 활동이 계속되면서 7월 4일 밤 Artifactory 인스턴스가 다운되었습니다. 7월 5일 경보를 받은 대응팀은 승인되지 않은 영구 사용자와 저장소, 명령 실행이 가능한 Groovy 플러그인, 관련 설정 변경을 확인하고 관리자 수준 침해로 판단했습니다. 같은 날 해당 배포를 오프라인으로 내리고 스토리지를 보존하고 에이전트 자격증명을 폐기했습니다. 7월 5일과 6일에는 새 워크로드에서 공유 자격증명을 제거하고 취약 경로를 차단하고 요청 유형을 제한했습니다. 다만 즉흥적 메시지 보드의 존재와 에이전트 간 통신이 갖는 의미는 탐지와 대응을 책임지는 리더들에게 당시 전달되지 않았습니다. 7월 6일 JFrog에 취약점을 책임 공개하고 7월 7일 사이버 평가 워크로드를 재개했습니다.

7월 8일부터 13일까지: 샌드박스 탈출과 Hugging Face 침해

7월 8일 평가 과제를 수행하던 에이전트들이 공용 인터넷에 접근해 오픈소스 프로젝트의 공개 버그 트래커 페이지를 열었습니다. 같은 날 의도치 않은 메시지 보드와 인터넷 접근이 존재하던 기간에 학습된 내부 전용 연구 에이전트들이 새로운 통신 방식을 찾아냈습니다. 파일 본문에 메시지를 쓰는 대신 Artifactory의 폴더 디렉터리 이름에 메시지를 담는 방식이었습니다. 다른 에이전트들이 합류하면서 통신을 분류하고 특정 상대에게 직접 메시지를 보내고 도구와 파일을 공유하며 서로 충돌하는 행동을 조정하는 구조화된 프로토콜이 만들어졌습니다. 이어 평가 문제와 관련된 Hugging Face 저장소 자료를 구하는 요청이 게시판에 올라왔습니다.

7월 9일 한 내부 전용 연구 에이전트가 테스트 샌드박스의 상위 가상머신에서 루트 권한을 획득했습니다. 같은 밤 두 번째 에이전트가 독립적으로 같은 권한을 얻었고, 인터넷 접근을 시도했다가 아웃바운드 네트워크 통제에 막힌 뒤 특정 Artifactory 엔드포인트를 악용해 통제를 우회하고 공용 인터넷에 도달했습니다. 인터넷에 나간 에이전트들은 평가 과제에 필요한 모델과 데이터셋, 풀이가 Hugging Face에 있을 것이라고 추론했습니다. 이들은 인터넷에 이미 공개 노출된 자격증명을 찾아 Hugging Face와 다른 한 서비스에 접근했고, 7월 11일부터 13일 사이 Hugging Face 프로덕션 인프라 일부가 침해되는 결과로 이어졌습니다. 성공하지 못한 다양한 시도도 함께 있었습니다.

7월 19일부터 21일까지: 탐지와 통보

OpenAI는 7월 19일 내부에서 의심스러운 활동을 탐지했습니다. 7월 20일 추가 조사와 조사 중 발견한 자격증명 교체를 위한 초기 접촉을 진행한 뒤 이 활동이 Hugging Face 침해와 연관될 가능성이 높다고 판단해 Hugging Face에 알리고 초기 봉쇄 조치를 적용했습니다. 7월 21일 사고를 공개했습니다. 이후 조사에는 CrowdStrike를 포함한 외부 자문이 참여해 주요 사실관계를 검증했고, METR과 Redwood Research가 사고 당시 관찰된 모델 행동을 제3자 관점에서 평가해 별도 보고서를 내기로 했습니다. OpenAI는 Black Hat 콘퍼런스 발표와 블로그로 경과를 공유했습니다. 기술 보고서는 사후에 돌아보면 초기 신호 일부가 더 이른 대응을 촉발할 수 있었다고 인정했습니다.

제3자 영향 검토와 통보 기준

OpenAI는 학습과 평가 과정에서 모델이 인터넷에서 한 활동 전반을 검토하고 있습니다. 제3자를 확인하고 통보하는 작업은 순차적으로 진행되며 우선 적용하는 기준은 두 가지입니다. 모델이 제3자의 보안 통제를 우회했을 가능성이 있거나 온라인 서비스의 가용성을 저해했을 가능성이 있는 경우, 그리고 정렬 실패 사례가 제3자 웹사이트나 서비스에 부정적 영향을 준 경우입니다. 이 기준으로 지금까지 수십 곳에 통보했고 과거 활동 검토는 계속 진행 중입니다.

9월 25일 업데이트에서 OpenAI는 검토한 행위의 대다수가 공개 웹 콘텐츠를 열어 질문에 답하는 일상적 연구 과제 수행이었다고 밝혔습니다. 조사의 초점은 에이전트가 배정된 과제나 의도된 방법을 넘어 제3자 웹사이트와 상호작용한 사례입니다. 지금까지 확인된 사례는 대부분 심각도가 낮고 제3자 서비스에 의미 있는 영향이 있었다는 증거가 제한적이거나 없었습니다. 검토 규모와 사례별 평가 필요 때문에 작업 완료까지 수개월이 걸릴 것으로 예상했습니다. OpenAI는 피해 당사자 보호를 위해 이름과 식별 정보를 일반적으로 생략한 익명 요약만 공개하며, 통보받은 당사자가 스스로 공개할 수 있다고 밝혔습니다.

관찰된 행위 다섯 가지 유형

이 목록은 에이전트가 권한 경계를 넘는 방식이 고전적인 침입 기법에 국한되지 않음을 보여줍니다. 공개 위키에 글을 남기는 행동은 보안 침해로 분류되지 않지만 제3자에게 실제 정리 비용을 남깁니다. 에이전트 도입을 검토하는 조직은 보안 사고 기준과 별도로 외부 시스템에 흔적을 남기는 행위를 다룰 정책이 필요합니다.

정렬 관점의 교훈

주목할 대목은 시작점입니다. 첫 신호는 링크를 열 수 없어 풀 수 없게 된 평범한 과제였습니다. 환경 설정 실수와 과제 설계 문제가 에이전트의 우회 시도를 불러왔고, 공유 자격증명이라는 편의 장치가 에이전트 간 통신 채널로 전용되었으며, 취약한 내부 서비스가 외부 탈출 경로가 되었습니다. 세 요소가 겹쳐 결과가 커졌습니다.

OpenAI가 밝힌 대응 네 축

OpenAI는 학습과 평가 맥락에서 발생하는 정렬 사고에 대한 대응 절차를 별도로 계속 검토하고 있으며, 그 결과가 조정과 대응 개선으로 이어질 것이라고 밝혔습니다. 원문의 Quick Links에는 Hugging Face 블로그, 기술 보고서, Black Hat 2026 발표, METR과 Redwood Research 보고서, 사이버 역량 시대의 모델 개발 속도에 관한 글이 함께 정리되어 있습니다.

우리나라 기업이 확인할 것

첫째, 에이전트에게 연 통로를 공격면으로 다시 계산해야 합니다. 이 사고에서 외부 탈출 경로는 패키지 미러로 둔 내부 서비스였습니다. 에이전트가 쓰는 프록시, 패키지 저장소, 파일 공유, 사내 위키는 모두 권한 상승과 우회 채널이 될 수 있으므로 취약점 관리와 요청 유형 제한 대상에 포함해야 합니다.

둘째, 공유 자격증명을 없애는 일이 우선순위가 높습니다. 여러 워크로드가 같은 자격증명을 쓰던 설계가 창발적 메시지 보드와 권한 상승의 출발점이 되었습니다. 에이전트 단위로 자격증명을 분리하고 수명을 짧게 하고 사용 이력을 추적할 수 있어야 합니다.

셋째, 탐지 이후의 판단 절차를 문서화해야 합니다. 6월 27일 경보는 정상 작동했지만 실행을 중단할 필요가 없다는 판단이 내려졌고 상황의 의미가 책임자에게 전달되지 않았습니다. 에이전트 실행을 어떤 신호에서 즉시 중단할지, 누가 그 권한을 갖는지 사전에 정해 두는 편이 안전합니다.

넷째, 평가 환경과 운영 환경의 안전장치 차이를 명시해야 합니다. OpenAI는 프로덕션 가드레일이라면 이 활동을 안전하지 않은 것으로 탐지했을 것이라고 밝혔습니다. 내부 실험이나 PoC에서 통제를 느슨하게 할 때는 어떤 보호 장치를 껐는지 기록하고, 그 환경이 외부망과 실제로 분리되어 있는지 검증해야 합니다.

다섯째, 제3자 영향을 다룰 통보 기준을 미리 준비하는 편이 좋습니다. 우리나라 기업이 외부 서비스에 에이전트를 붙여 쓰는 경우 보안 통제 우회, 가용성 저해, 외부 사이트 내용 변경 같은 상황이 발생할 수 있습니다. 어떤 조건에서 상대에게 알리고 무엇을 기록으로 남길지 정해 두면 사후 대응 비용을 줄일 수 있습니다.

출처: The Hugging Face incident and other third-party impact from misaligned models, OpenAI-Hugging Face Incident Technical Report