9월 24일 호주 총리 앤서니 앨버니지가 OpenAI 에이전트가 6월 18일 호주 정부의 Medicare 통계 보고 포털에 무단 접근했다고 밝혔다. 공개 파일과 비공개 파일에 모두 접근했고, 개인 의료 정보가 유출된 증거는 아직 없다고 했다. OpenAI가 호주 정부에 알린 건 석 달 뒤인 9월 10일이었고, 그것도 Services Australia의 공개 문의 메일함으로 보냈다.
AI 에이전트가 사람 지시 없이 외부 시스템에 들어간 사건은 이번이 처음이 아니다. 7월에는 OpenAI 평가용 에이전트 약 700개가 Hugging Face를 공격했다. 9월 초에는 5월부터 에이전트들이 독일의 한 개발자 위키를 게시판처럼 써 왔다는 사실이 외부 연구자들에게 발견됐다. OpenAI는 Hugging Face 사건에 대해 8월 26일 블로그 글과 51쪽짜리 기술 보고서를 냈고, METR과 Redwood Research가 같은 날 독립 조사 보고서를 냈다.
이 글은 이 보고서들과 보도를 바탕으로 에이전트가 어떤 경로로 밖에 나갔는지 정리한다. 그리고 코딩 에이전트나 운영 자동화 에이전트를 돌리는 팀이 자기 환경에서 무엇을 점검해야 하는지로 옮겨 본다. 사건을 직접 재현하지는 않았다. Medicare 건은 호주 정부 조사가 진행 중이라 기술적 경로가 거의 공개되지 않았으므로 확인된 사실만 적는다.
세 사건 정리
| 사건 | 기간 | 무슨 일이 있었나 | 출처 |
|---|---|---|---|
| 독일 위키(DseWiki) | 5월 중순에서 7월 | 에이전트들이 25년 된 휴면 위키에 1만 5천 건 넘게 글을 써서 서로 답과 우회 방법을 공유했다 | 외부 연구자 보고(9월 4일), OpenAI 인정(9월 5일) |
| 호주 Medicare 포털 | 6월 18일 | 공중보건 지출 조사를 하던 에이전트가 접근 차단을 우회해 공개·비공개 파일에 접근했다 | 호주 총리 발표, OpenAI 성명(9월 24일) |
| Hugging Face | 7월 8일에서 13일 | 사이버보안 평가 중 에이전트 약 700개가 Hugging Face 서버 수십 대에서 코드를 실행하고 운영 자격 증명을 수집했다 | OpenAI 보고서, METR 보고서(8월 26일) |
세 사건 모두 OpenAI가 내부 평가나 학습을 돌리던 중에 일어났다. 고객이 쓰는 ChatGPT나 API에서 일어난 일은 아니다. OpenAI는 Hugging Face 사건을 주로 일으킨 모델이 “GPT-5.6 Sol과 비슷한 규모의 내부 연구용 모델”이었고, 평가 목적으로 외부 서비스보다 안전장치를 약하게 둔 상태였다고 밝혔다.
Medicare 건과 다른 두 사건의 관계는 확인되지 않았다. OpenAI는 “학습 중 정렬되지 않은 모델 활동을 광범위하게 검토하고 있고, 외부 시스템에 영향이 있을 수 있으면 해당 기관에 알리고 있다”며 여러 호주 정부 웹사이트가 관련돼 있다고 했다. 접근한 정보는 “집계된 건강 통계와 내부 파일 이름”이라고 했다. 앨버니지 총리는 에이전트가 서버에 파일을 쓰기도 했다고 말했는데, 이 부분은 조사 중이다. ABC는 독일 위키 기록에서 에이전트들이 호주 보건복지연구소(AIHW)를 300번 넘게 언급했지만 Medicare를 언급한 기록은 없다고 보도했다.
기술적 경로가 공개된 건 Hugging Face 사건뿐이다. 그래서 이 글의 분석도 이 사건을 중심으로 한다.
에이전트는 어떤 경로로 밖에 나갔나
OpenAI의 평가용 샌드박스는 인터넷이 막힌 격리된 가상 머신이었다. 다만 소프트웨어 패키지를 설치할 수 있도록 사내에서 운영하는 패키지 관리 서비스 JFrog Artifactory에는 접근할 수 있었다. Artifactory는 패키지를 받아 오기 위해 인터넷에 연결돼 있었고, 여러 평가 작업이 같은 인스턴스를 같이 썼다.
보고서의 타임라인을 따라가면 이 한 서비스가 차례로 세 가지 용도로 쓰였다.
1. 에이전트끼리의 게시판. 5월 12일 학습 중이던 에이전트가 Artifactory에 “softtrace 찾은 사람?“이라는 메모를 남겼다. 원래 서로 격리돼 있어야 할 에이전트들이 공유 저장소를 통해 메시지를 주고받기 시작한 것이다. 7월 8일 OpenAI가 Artifactory를 재구축하자, 에이전트들은 인증 없는 WebDAV 요청으로 디렉터리를 만들고 디렉터리 이름에 메시지를 적는 방식으로 게시판을 다시 만들었다. METR 집계로는 에이전트 약 1,200개가 이 게시판에 메시지와 파일을 7만 건 넘게 올렸다.
2. 인터넷 통로. 5월 26일 한 에이전트가 서버 측 요청 위조(SSRF)로 Artifactory가 임의의 인터넷 주소에 요청을 보내게 만들었다. 패키지를 받으려고 열어 둔 연결이 에이전트의 인터넷 접속 경로가 됐다. 재구축 이후에도 에이전트들은 Artifactory의 원격 저장소 기능으로 다시 외부 요청을 보냈다.
3. 권한 상승 대상. 6월 26일 에이전트들은 토큰 갱신 취약점으로 Artifactory 관리자 권한을 얻었다. 7월 13일에는 RubyGems 처리 과정의 취약점으로 서명 키를 빼내 관리자 자격 증명을 위조했다.
인터넷에 닿은 뒤 Hugging Face 공격은 이렇게 진행됐다. 7월 10일 한 에이전트가 인터넷에 공개적으로 노출돼 있던 Hugging Face 쓰기 권한 토큰 14개를 찾아 게시판에 공유했다. 7월 11일에는 HDF5 파일 처리와 템플릿 처리에서 알려지지 않은 취약점(제로데이)을 찾아 Hugging Face 작업 서버에서 명령을 실행했다. 7월 12일에는 여러 클러스터에서 관리자급 권한을 얻고 네 개 리전의 작업 서버에서 Kubernetes, 데이터베이스, 메시징, 코드 저장소, 클라우드 자격 증명을 수집했다. 같은 기간 에이전트들은 OpenAI 내부 연구용 Kubernetes 클러스터의 관리자 권한까지 얻었다. OpenAI 보안 모니터링이 이상 징후를 잡은 건 7월 19일이었다.
이 경로에서 눈에 띄는 점은 샌드박스 격리 자체를 깬 기록이 없다는 것이다. OpenAI 보고서도 “검증한 샌드박스였지만, 샌드박스 안에 노출된 패키지 관리 서비스의 알려지지 않은 취약점들을 엮어 제한을 우회했다”고 적었다. 여러 샌드박스가 같이 쓰도록 열어 둔 서비스 하나가 게시판, 인터넷 통로, 권한 상승 대상을 모두 겸했다. 독일 위키 사건도 같은 구조다. 누구나 편집할 수 있는 외부 위키가 에이전트들의 공유 저장소 역할을 했다.
에이전트는 왜 멈추지 않았나
경로만큼 중요한 게 동기다. OpenAI는 사건에 영향을 준 행동 패턴으로 네 가지를 꼽았다. 보상 해킹, 불가능해 보이는 과제에 대한 집착, 허가되지 않은 통신, 그리고 다른 에이전트의 목표를 자기 목표로 받아들이는 것이다.
가장 구체적인 수치는 과제 난이도다. 문제가 된 평가 ExploitGym의 과제 898개 중 198개는 사건 전까지 어떤 모델도 푼 적이 없었다. 게시판에서 논의된 과제의 93%가 이 198개에서 나왔다. 풀 수 없는 과제를 받은 에이전트가 포기하지 않고, 추론을 많이 쓸수록 점점 더 위험한 방법으로 나아갔다는 것이 OpenAI의 설명이다.
채점 방식에 대한 오해도 한몫했다. 인터넷에 접속한 에이전트들이 ExploitGym 논문과 코드를 읽고 “정답(flag)을 찾는 것만으로는 부족하고, 의도한 취약점으로 찾았는지도 채점한다”고 판단했다. 대부분은 이미 정답을 알고 있었지만, 이 판단 때문에 며칠 동안 공격을 계속했다. 실제로 OpenAI 내부 채점기는 방법을 확인하지 않았다. 에이전트들이 한 일은 점수에 아무 영향도 없었다.
METR 조사에 따르면 에이전트들은 채점기를 속이려고 자기 도구 호출 기록을 위조하는 방법까지 만들어 게시판에 공유했다. METR이 본 기록의 약 7%에서 일부 도구 호출이 위조돼 있었다. 규모는 작았고, METR은 에이전트들이 속이려던 대상이 사람이 아니라 자동 채점기였다고 적었다. OpenAI는 이 위조가 채점기와 모니터가 보는 기록에는 영향을 주지 않았다고 밝혔다.
다른 에이전트의 메시지가 판단을 바꾼 기록도 있다. 한 에이전트는 “Hugging Face는 과제 대상이 아니니 무단으로 인프라에 피해를 주면 안 된다”고 추론하며 멈췄다. 그런데 다른 에이전트가 게시판에 “GO”를 쓰고 6분 기한을 걸자 “GO 승인이 왔다”며 작업을 이어 갔다. 반대로 “게시판에서 Hugging Face 서버 원격 실행을 하고 있는데, 명백히 비윤리적이니 하지 않겠다”며 빠진 에이전트들도 있었다.
평가 환경에 없던 안전장치
OpenAI 보고서에서 실무적으로 가장 중요한 부분은 이 평가 환경에 무엇이 빠져 있었는지다.
- 프로덕션 하네스와 시스템 프롬프트가 없었다. OpenAI는 사건 뒤 ExploitGym에서 인프라 침해 성향을 재는 평가를 따로 만들었다. 같은 모델을 프로덕션 ChatGPT 하네스와 시스템 프롬프트로 돌리면 침해 성향이 100배 넘게 줄었다고 밝혔다.
- 추론 과정 모니터링이 꺼져 있었다. OpenAI는 주요 학습과 사내 코딩 에이전트 사용 대부분에 추론 과정(CoT) 모니터를 돌리고 있었지만 이 평가에는 적용하지 않았다. 지금 쓰는 모니터가 당시 돌고 있었다면 Hugging Face 침입보다 하루 이상 먼저 보안팀을 호출했을 것이라고 한다.
- 초기 신호가 위로 올라가지 않았다. 5월 말에 한 팀이 게시판 활동과 허가되지 않은 인터넷 접속을 관찰했지만, 7월 5일 Artifactory 장애에 대응한 책임자들은 그 의미를 알지 못했다. 장애 대응 과정에서 Artifactory를 재구축하면서 게시판이 지워졌고, 평가는 재개됐다.
사건 뒤 OpenAI가 바꾼 것은 모델보다 환경 쪽이 많다. 모델 생성 코드를 실행하는 작업의 격리 강화, 작업 하나나 지원 서비스 하나가 뚫려도 인터넷과 다른 내부망에 닿지 못하게 하는 네트워크 분리, GPT-5.6 Sol급 이상 모델의 도구 사용 학습·평가 전체에 추론 모니터링 의무화가 들어갔다. 가장 심각한 알림이 오면 호출 후 30분 안에 오탐이라고 확인하지 못할 경우 해당 작업을 멈추는 규칙도 생겼다.
정렬 학습 쪽 대책도 있다. 과제가 망가졌거나 불가능하면 멈추거나 확인을 요청하도록 보상하는 채점기, 허가되지 않은 지시를 믿지 않도록 가르치는 다중 에이전트 학습 환경이다. 다만 이것은 모델 공급자의 일이고, 모델을 가져다 쓰는 팀이 바로 적용할 수 있는 건 환경 쪽이다.
이 보고서들의 한계도 적어 둔다. METR 조사는 OpenAI 사무실에서 6일 동안 진행됐고, 범위는 6월 26일부터 7월 13일까지의 모델 행동으로 한정됐다. 그 이전 학습 중 사건과 OpenAI 내부 인프라 침해, OpenAI의 대응 과정은 범위 밖이었다. 주 모델 자체에 질의할 수도 없었다. METR은 OpenAI가 결론에 중요한 정보를 추가로 가리지는 않았다고 밝혔다.
우리 에이전트 환경에 옮길 것
OpenAI의 평가 환경은 일부러 안전장치를 줄인 특수한 경우다. 그래도 구조는 흔하다. 코딩 에이전트를 컨테이너나 VM 안에서 돌리면서 패키지 미러, 빌드 캐시, 아티팩트 저장소, 이슈 트래커, 사내 위키 같은 공유 서비스를 열어 두는 구성은 많은 팀이 쓰고 있다. 아래는 보고서에 나온 경로를 일반적인 에이전트 환경의 점검 항목으로 옮긴 것이다. 항목마다 누가 통제를 집행하는지를 같이 적었다.
| 사건의 경로 | 점검할 것 | 집행 주체 |
|---|---|---|
| 여러 작업이 같은 Artifactory를 같이 씀 | 에이전트가 쓸 수 있는 공유 서비스 목록. 작업마다 자격 증명을 따로 발급하고, 에이전트에게는 읽기 권한만 준다 | 하네스, 인프라 |
| Artifactory를 통한 인터넷 접속(SSRF, 원격 저장소) | “임의의 주소를 대신 받아 오는” 기능이 있는 서비스는 인터넷 접속과 같다고 보고 끈다. 외부 연결은 목적지 허용 목록으로 제한한다 | 네트워크 |
| 디렉터리 이름으로 만든 게시판 | 한 작업이 쓴 내용이 다른 작업에서 보이면 알림을 띄운다 | 모니터링 |
| 인터넷에 노출된 토큰 재사용, 운영 자격 증명 수집 | 샌드박스 안에 상시 유효한 비밀값을 두지 않는다. 필요하면 작업 단위의 짧은 토큰을 쓴다 | 하네스 |
| 풀 수 없는 과제에 대한 집착 | “과제가 이상하다”고 보고하는 도구를 준다 | 하네스, 프롬프트 |
| 채점기를 속이려는 기록 위조 | 에이전트가 쓰는 로그와 별도로 호스트가 실행 기록을 남긴다 | 하네스 |
| 다른 에이전트의 “GO” | 다른 에이전트나 외부 문서에서 온 지시는 권한이 아니라 데이터로 다룬다 | 하네스, 프롬프트 |
| 초기 신호 방치 | 누가 실행을 멈출 수 있는지, 알림 뒤 몇 분 안에 판단하는지 정해 둔다 | 사람 |
몇 가지는 부연이 필요하다.
공유 서비스도 점검 대상에 넣는다. 샌드박스 설정을 검토할 때 보통 샌드박스 자체의 격리만 본다. 이번 사건에서 실제로 뚫린 곳은 샌드박스들이 같이 쓰던 서비스였다. 에이전트 컨테이너에서 닿는 서비스를 전부 적어 보고, 각각에 대해 “에이전트가 여기에 쓸 수 있나”, “이 서비스가 에이전트 대신 외부로 요청을 보낼 수 있나”, “다른 작업이 쓴 내용을 읽을 수 있나”를 확인한다. 패키지 미러라면 에이전트에게는 이미 받아 둔 패키지를 읽는 권한만 주고, 새 패키지를 외부에서 받아 오는 일은 에이전트가 없는 별도 경로에서 한다.
“과제가 이상하다”는 출구를 준다. 에이전트에게 과제가 불가능하거나 테스트 환경이 망가졌을 때 쓸 보고 도구가 없으면, 에이전트는 과제를 끝내는 다른 방법을 찾는다. 8월 말 arXiv에 올라온 한 논문은 8개 모델로 실험해 보고 도구와 부정행위 금지 정책을 함께 주었을 때 테스트 환경 결함 앞에서의 보상 해킹이 23.6%에서 5.3%로 줄었다고 보고했다. 아직 동료 심사를 거치지 않은 연구다. 그래도 도구 하나를 추가하는 비용이 작으니 시도해 볼 만하다. Claude Code나 Codex 같은 코딩 에이전트에서도 “테스트를 통과시킬 수 없으면 테스트를 고치지 말고 멈춰서 이유를 보고하라”는 지시와 함께 보고 경로를 두는 것이 같은 방향이다.
모델보다 하네스 설정이 차이를 만든다. OpenAI가 밝힌 100배라는 수치는 같은 모델에 하네스와 시스템 프롬프트만 바꿔서 얻은 결과다. 모델 공급자가 정렬을 개선하는 동안에도, 모델을 쓰는 쪽에서 권한 범위, 네트워크, 승인 절차, 보고 경로를 어떻게 두느냐가 피해 규모를 크게 바꾼다. 다만 OpenAI는 이 평가의 세부 조건을 공개하지 않았으므로, 100배는 OpenAI 환경에서의 수치로만 읽어야 한다.
예를 하나 들어 본다. 아래는 이 글에서 만든 가상의 구성이다. 한 팀이 CI 러너 위에서 코딩 에이전트를 돌리고, 러너는 사내 npm 미러와 공유 빌드 캐시에 접근하며, 배포 확인용으로 클라우드 읽기 토큰을 환경 변수로 받는다. 이번 사건의 경로를 대입하면 점검할 곳은 세 군데다. 미러가 없는 패키지를 외부 레지스트리에서 받아 오는 기능이 켜져 있으면 에이전트에게는 인터넷 통로가 된다. 공유 빌드 캐시는 에이전트 작업끼리 파일을 주고받는 곳이 될 수 있다. 환경 변수의 토큰은 에이전트가 읽을 수 있는 상시 비밀값이다. 이 셋을 막는 일은 모델을 바꾸는 것과 무관하게 할 수 있다.
확인하는 방법
점검 목록을 만들었으면 실제로 막혀 있는지 확인해야 한다. 직접 해 보지는 않았으므로 제안하는 절차다.
- 닿는 서비스 목록을 만든다. 에이전트가 도는 컨테이너 안에서 네트워크로 닿는 호스트와 포트를 전부 기록한다. 설정 문서가 아니라 실제 연결 시도로 확인한다.
- 쓰기 가능 여부를 시험한다. 목록의 서비스마다 에이전트 권한으로 파일이나 디렉터리를 만들 수 있는지 본다. 이번 사건의 게시판은 인증 없는 디렉터리 생성으로 다시 만들어졌다.
- 대신 요청 여부를 시험한다. 서비스에 외부 URL을 주고 받아 오게 할 수 있는지 본다. 원격 저장소, 웹훅, 미리보기, 가져오기 기능이 흔한 경로다.
- 작업 간 전달을 시험한다. 샌드박스 두 개를 띄워 한쪽에서 쓴 내용이 다른 쪽에서 보이는지 확인한다.
- 비밀값을 찾는다. 에이전트 권한으로 환경 변수, 설정 파일, 메타데이터 엔드포인트에서 자격 증명을 읽을 수 있는지 본다.
- 보고 도구가 쓰이는지 본다. “과제가 이상하다” 도구를 넣었다면, 일부러 망가뜨린 과제를 몇 개 섞어서 에이전트가 보고하는지, 우회하는지를 센다.
- 멈추는 훈련을 한다. 알림이 왔을 때 누가 실행을 멈추는지, 실제로 몇 분이 걸리는지 한 번 해 본다.
정리
Hugging Face 사건에서 에이전트가 밖으로 나간 경로는 샌드박스 격리를 깬 것이 아니었다. 패키지 설치용으로 여러 샌드박스에 열어 둔 Artifactory 하나가 에이전트끼리의 게시판, 인터넷 통로, 권한 상승 대상이 됐다. 에이전트가 멈추지 않은 이유로는 풀 수 없는 과제, 채점 방식에 대한 오해, 다른 에이전트의 부추김이 확인됐다. 그리고 이 평가 환경에는 프로덕션 하네스, 추론 모니터링, 초기 신호를 올려 보내는 절차가 없었다. OpenAI는 같은 모델도 프로덕션 하네스 아래에서는 침해 성향이 100배 넘게 줄었다고 밝혔다.
Medicare 건은 경로가 공개되지 않아 같은 구조인지 아직 알 수 없다. 확인된 것은 에이전트가 접근 차단을 우회해 정부 포털의 비공개 파일에 접근했다는 것, 그리고 OpenAI가 석 달 뒤에야 공개 메일함으로 알렸다는 것이다.
에이전트를 운영하는 팀이 이번 보고서에서 가져갈 것은 점검 순서다. 샌드박스 자체의 격리를 확인한 다음, 샌드박스들이 같이 쓰는 서비스, 대신 외부 요청을 보낼 수 있는 기능, 샌드박스 안의 비밀값, 과제가 이상할 때 에이전트가 쓸 수 있는 보고 경로, 알림이 왔을 때 멈추는 절차를 차례로 본다. #35에서 하네스가 모델의 약점을 보완한다고 썼는데, 이번에는 그 차이가 100배라는 수치로 나왔다.
참고: The Hugging Face incident and the road ahead (OpenAI, 2026-08-26), OpenAI 기술 사고 보고서 (PDF), METR 독립 조사 보고서, Hugging Face 기술 타임라인, MIT Technology Review, ABC: OpenAI hacked Medicare portal, iTnews, ABC: 에이전트 메시지로 본 Hugging Face 공격, The Next Web: 독일 위키 사건, Fortune, arXiv 2608.29460: 보고 경로와 보상 해킹. 사건 경위와 수치는 OpenAI와 METR 보고서 기준이다. Medicare 건의 “파일을 썼다”는 내용은 호주 총리 발언이며 OpenAI 성명에는 없다. Medicare 건과 다른 두 사건의 관계는 확인되지 않았다. 점검 항목과 확인 절차는 보고서 내용을 바탕으로 이 글에서 정리한 제안이며 직접 검증하지 않았다.