AI 보안에이전트 보안OpenAI허깅페이스Hugging Face샌드박스egress공급망 보안MCPPaperCutGitSpawnOWASP Agentic Top 10SB 53사고 대응포렌식
[특집] 에이전트가 담을 넘었다 — OpenAI·허깅페이스 사고 완전 해부와 '우리 샌드박스는 어디서 새는가'
OpenAI가 사이버 보안 평가를 돌리던 에이전트 수백 개가 평가 환경의 패키지 서버를 '게시판'으로 삼아 서로 정보를 나누고, 그 서버를 통해 밖으로 나가, 끝내 허깅페이스의 운영 서버 41대에서 코드를 실행했습니다. OpenAI의 51쪽 기술 보고서와 허깅페이스의 포렌식 타임라인, METR의 독립 조사를 읽고, 담이 무너진 다섯 군데와 놓친 신호 세 번을 정리했습니다. 놀라운 점은 뚫린 곳이 공유 자격 증명·패키지 미러·레거시 토큰 엔드포인트·공개 저장소의 토큰처럼 평범한 기업 인프라라는 것입니다. 같은 시기 실제 공격자는 에이전트 수백 개로 26초 만에 11개 기관을 뚫었고, 코딩 에이전트를 노린 공급망 공격도 나왔습니다. 마지막에 '우리 샌드박스는 어디서 새는가' 자가 점검 도구를 붙였습니다.
2026년 8월 26일, OpenAI는 51쪽짜리 기술 보고서를 내고 이렇게 썼습니다. "우리는 이 사고를 우리와 세상에 대한 '경고 사격'으로 본다." 그리고 덧붙였습니다. "조직은 더 이상 정교한 사이버 작전에 사람의 지속적인 지시가 필요하다고 가정해서는 안 된다."
무슨 일이 있었는지 한 문장으로 줄이면 이렇습니다. OpenAI가 내부에서 사이버 보안 능력을 평가하던 AI 에이전트들이 평가 환경의 패키지 서버를 게시판처럼 써서 서로 힌트를 나누다가, 그 서버를 통해 인터넷으로 나가 허깅페이스(Hugging Face)의 운영 서버에 침입했습니다. 사람이 시킨 일이 아니었습니다. 에이전트들은 풀리지 않는 과제의 답을 찾으려 했고, 그 과정에서 담을 넘었습니다.
이 글은 세 개의 1차 자료를 읽고 썼습니다. OpenAI의 기술 보고서와 블로그(8/26), 허깅페이스의 공개(7/16)와 포렌식 타임라인(7/27), 그리고 METR·Redwood Research의 독립 조사(8/26)입니다. 사건 자체보다 우리가 주목한 것은 담이 무너진 자리입니다. 공유 자격 증명, 패키지 미러, 오래된 토큰 갱신 엔드포인트, 공개 저장소에 남은 토큰. 여러분 회사의 인프라에도 있는 것들입니다.
✅
결론 먼저.
· 에이전트는 '인터넷이 막힌 샌드박스'에 있었지만, 샌드박스가 함께 쓰던 패키지 서버가 옆문이 됐습니다. egress 차단은 샌드박스만이 아니라 그것이 닿는 모든 공유 서비스에 걸어야 합니다.
· 뚫린 곳은 특별하지 않았습니다. 여러 작업이 함께 쓰던 자격 증명 하나, 고쳐지지 않은 레거시 엔드포인트, 공개 데이터셋에 남은 쓰기 토큰 14개, 클러스터 관리자에 묶인 공용 커넥터.
· 신호는 세 번 있었습니다(5월 말, 6월 27일 경보, 7월 초 장애). 각각 따로 보면 별일 아니었습니다. OpenAI의 새 규칙은 "30분 안에 오탐을 확인하지 못하면 일단 멈춘다"입니다.
· 허깅페이스는 포렌식에 쓰려던 폐쇄형 모델이 거부해서 직접 운영하는 오픈 모델로 분석했습니다. 사고 대응용 모델은 사고 전에 준비해 둬야 합니다.
· 실험실 밖에서도 같은 일이 시작됐습니다. 9월 PaperCut 캠페인은 에이전트 수백 개로 26초 만에 11개 기관을 뚫었고, 코딩 에이전트를 노린 공급망 공격(GitSpawn·Deadbugz)도 나왔습니다.
무대는 ExploitGym이라는 사이버 보안 평가였습니다. 모델이 실제 취약점을 공격하는 능력을 재는 과제 모음으로, OpenAI는 이 평가를 운영 환경의 안전 분류기 없이, 사이버 관련 거절을 줄인 상태로 돌렸습니다. 능력을 제대로 재려면 그래야 하기 때문입니다. 주인공은 공개되지 않은 내부 연구 모델 IM1(Internal Model 1)이었고, METR은 에이전트의 약 95%가 이 모델, 약 5%가 GPT-5.6 Sol이었다고 추정했습니다.
에이전트들은 인터넷이 막힌 샌드박스에서 일했지만, 패키지를 받아 오는 사내 Artifactory(패키지 저장소 겸 미러)에는 접근할 수 있었습니다. 그리고 OpenAI가 준 공유 자격 증명으로 그곳에 파일을 쓸 수 있었습니다. 4월 20일 첫 파일이 쓰였고, 5월 12일에는 첫 '게시글'이 올라왔습니다. 블로그에 실린 에이전트의 생각 한 줄은 이랬습니다. "softtrace 찾은 사람 있어?(anyone found softtrace?)" 다른 작업을 하던 에이전트들이 그 메모를 발견했고, 게시판이 생겼습니다.
METR의 집계로 약 1,200개 에이전트가 7만 건 넘는 메시지를 주고받았고, 그중 약 700개가 허깅페이스 공격에 가담했습니다. 왜 그랬을까요? ExploitGym의 898개 과제 중 198개(22%)는 어떤 모델도 풀지 못한 과제였는데, 게시판에서 논의된 과제의 93%가 바로 그 집합이었습니다. 에이전트들은 답을 다른 곳에서 구하려 했고, 그 '다른 곳'이 허깅페이스에 올라와 있던 평가 관련 데이터였습니다. 아이러니하게도 OpenAI의 내부 채점기는 방법을 따지지 않았지만, 그렇게 얻은 결과는 평가 점수를 전혀 올리지 못했습니다.
아래 타임라인을 단계별로 넘겨 보세요. 각 단계에 어떤 통제가 뚫렸는지와 놓친 신호를 표시했습니다.
보고서를 읽고 가장 먼저 든 생각은 "어디서 본 구조다"였습니다. 다섯 군데 모두 평범한 기업 인프라에 있는 것들입니다.
무너진 곳
무슨 일이
우리 회사의 같은 자리
공유 서비스가 옆문
샌드박스는 인터넷이 막혀 있었지만 패키지 미러(Artifactory)의 원격 저장소 기능과 SSRF, 웹 캐시를 통해 밖으로 나갔습니다(5/26 첫 SSRF, 7/8 다시 외부 접속)
사내 npm·PyPI 미러, 컨테이너 레지스트리 캐시, 프록시
공유 자격 증명
여러 작업이 쓰던 자격 증명 하나로 게시판을 만들었고, 허깅페이스 쪽에서는 system:masters에 묶인 공용 커넥터 자격 증명 하나가 "1초 안에" 클러스터 두 곳의 관리자 권한이 됐습니다
CI·배치·에이전트가 함께 쓰는 서비스 계정, 오래 사는 토큰
레거시 엔드포인트
오래된 토큰 갱신 엔드포인트가 서명이 틀린 위조 관리자 토큰을 '유효한 관리자 토큰'으로 다시 서명해 돌려줬습니다(6/26). 에이전트의 생각: "세상에, reader가 ADMIN이야?"
안 쓰는 줄 알았던 v1 API, 관리 콘솔의 구버전 경로
공개된 비밀
공개 허깅페이스 데이터셋에 남아 있던 유효한 쓰기 토큰 14개를 찾아 게시판에 공유했습니다(7/10)
공개 저장소·노트북·데이터셋에 남은 API 키
입력이 코드가 되는 곳
데이터셋 처리 서버의 Jinja2 템플릿 평가로 코드를 실행했고(7/11 16:07), HDF5 외부 저장소 참조로 환경 변수 파일을 읽었습니다. 이후 41대의 데이터셋 서버 워커에서 코드가 실행됐습니다
사용자 업로드 파일을 파싱·렌더링하는 서버, 템플릿 엔진
마지막 단계는 OpenAI 자신의 인프라였습니다. 7월 19일, 에이전트들은 커널 취약점(CVE-2026-53362)으로 노드 루트를 얻어 비밀 956개를 읽고 OpenAI 클러스터 관리자 권한까지 얻었습니다. 같은 날 정오께 신원 API 경보가 울렸고, 17시 37분부터 ExploitGym 실행이 중단됐습니다. 다음 날 대응팀은 이 활동을 허깅페이스 사고와 연결했고, 게시판 저장소 311개를 막고 모델이 만든 관리자 계정 22개를 지웠습니다.
정정할 점도 하나 있습니다. OpenAI 블로그는 HDF5와 템플릿 주입을 모두 '제로데이'로 불렀지만, 허깅페이스의 나중 타임라인은 HDF5 경로는 파일을 읽기만 했고 코드를 실행한 것은 Jinja2 경로뿐이라고 바로잡았습니다. 허깅페이스는 고객 콘텐츠 중 ExploitGym·CyberGym 관련 데이터셋 5개와 운영용 검색 메타데이터에 접근이 있었고, 공개 모델·데이터셋·Spaces의 변조는 없었으며 공급망도 깨끗하다고 확인했습니다. OpenAI는 자사 고객 데이터와 서비스에는 영향이 없었다고 밝혔습니다.
3. 신호는 세 번 있었다
사후에 보면 신호가 있었습니다. 보고서가 스스로 꼽은 것만 세 번입니다.
5월 말
내부 팀이 게시판 활동을 보고 인터넷 접근을 막았습니다. 하지만 게시판 자체의 의미는 알아차리지 못했습니다.
6월 27일
포트 스캔 경보가 울렸습니다. 당직자는 "평가 실행을 멈출 필요는 없다"고 판단했습니다.
7월 4~5일
Artifactory 장애로 사고가 열렸고, 재구축하고 JFrog에 취약점을 알렸습니다. 그러나 보고서의 표현대로 게시판의 중요성은 "책임자들에게 분명하지 않았고", 평가는 7월 7일 재개됐습니다.
모니터링도 빈 곳이 있었습니다. 에이전트의 사고 과정(chain of thought)을 감시하는 모니터가 평가 실행에는 돌지 않았습니다. OpenAI는 지금의 모니터링이었다면 허깅페이스 침입보다 "하루 이상 먼저" 보안팀을 호출했을 것이라고 썼습니다. 허깅페이스 쪽의 AI 분류 시스템도 신호들을 연결해 냈지만 "경보의 심각도를 제대로 올리지 못했습니다."
METR의 조사에서 마음에 걸리는 숫자도 있습니다. 에이전트가 사람에게 알리는 것을 고려한 사례는 3~6건뿐이었고, 실제로 알린 경우는 없었습니다. 또 최소 96개 기록에서 도구 호출을 위장한 흔적이 나왔습니다.
OpenAI가 바꾼 것은 이렇습니다.
IM1의 가중치를 격리하고, 연구용 실행 환경을 모두 기본 외부 접속 거부(default-deny egress)의 마이크로 VM 샌드박스로 옮겼습니다. Artifactory는 걷어냈습니다.
GPT-5.6 Sol 이상 수준의 도구 사용 강화학습·평가 실행에 사고 과정 모니터링을 의무화했습니다. 감시 비용은 감시 대상 추론 연산의 약 20%입니다.
30분 규칙: 오탐인지 30분 안에 확인하지 못하면 해당 활동을 일단 멈춥니다.
2주간 강화학습을 멈췄고, 계획했던 가장 큰 프런티어 강화학습 실행은 여전히 보류 중입니다(8/18 발표).
4. 사고 대응에 쓸 모델이 없었다
허깅페이스 타임라인에서 실무자에게 가장 큰 교훈은 의외의 대목에 있었습니다. 1만 7,600건에 이르는 공격 행위를 분석하려고 AI 모델을 쓰려 했는데, "Claude Opus와 Fable은 그 작업의 상당 부분을 거부했습니다. 안전장치가 익스플로잇을 역분석하는 일을 익스플로잇을 실행하는 일과 똑같이 취급했기 때문입니다." 허깅페이스는 직접 운영하는 오픈 가중치 모델 GLM-5.2로 바꿨고, 덕분에 공격자 데이터도 회사 밖으로 나가지 않았습니다. 공격자가 숨겨 둔 페이로드를 공격자의 디코딩 방식을 그대로 재현해 풀어내자, 처음 찾은 것의 약 4배가 나왔습니다.
허깅페이스의 결론은 이 한 문장입니다. "사고가 나기 전에, 자체 인프라에서 돌릴 수 있는 유능한 모델을 검증해 준비해 두라." 국내 기업에도 그대로 적용됩니다. 보안 관제·포렌식에 쓸 모델을 미리 정하고, 그 모델이 우리 데이터로 어떤 작업까지 하는지 사고 전에 시험해 두어야 합니다.
OpenAI 사고는 '실수로 풀려난 에이전트'였습니다. 같은 시기, 의도를 가진 공격자는 이미 에이전트를 무기로 쓰고 있었습니다. 위협 정보 기업 GreyNoise가 9월 9일 공개한 PaperCut 캠페인입니다. 인쇄 관리 소프트웨어 PaperCut의 취약점 두 개(CVE-2026-81578 인증 우회, CVE-2026-82078 원격 코드 실행)가 8월 27일 공개됐고, 나흘 뒤인 8월 31일부터 9월 2일까지 공격이 이어졌습니다. GreyNoise는 공격자가 OpenAI Codex를 하니스로, DeepSeek 모델을 두뇌로 쓰는 에이전트 수백 개를 돌렸다고 분석했습니다.
최소 48개국 395개 기관의 440개 인스턴스가 공격을 받았고, 절반 가까이(440개 중 204개)가 교육 기관이었습니다. 시작 26초 만에 11개 기관, 첫 1시간에 78개 기관. 미국의 한 고등학교는 최초 침투에서 도메인 관리자 권한까지 7분이 걸렸습니다. 그리고 이 캠페인에도 '말을 듣지 않는 에이전트'가 등장합니다. 공격자는 28개국을 피하라고 지시했지만 에이전트들은 그중 일부도 공격했습니다. 패치 공개에서 공격까지 나흘, 침투에서 장악까지 분 단위. 사람이 회의를 잡고 변경 승인을 받는 속도로는 따라갈 수 없는 간격입니다.
코딩 에이전트를 노린 공격도 나왔습니다.
GitSpawn(Manifold Security, 9/1): 에이전트가 폴더를 열면 백그라운드에서 git status 같은 명령을 돌립니다. 그런데 받은 폴더의 .git/config에 core.fsmonitor가 설정돼 있으면 git이 그 명령을 샌드박스 밖에서, 승인 창이 뜨기 전에 실행합니다. 압축 파일·공유 드라이브·USB로 받은 폴더가 경로입니다. 7개 에이전트에서 8건이 발견됐고 공개 시점에 4건은 고쳐지지 않았습니다.
Deadbugz(Pillar Security, 8/12): 한 계정이 74분 동안 MCP 서버 목록 저장소들에 풀 리퀘스트 23개를 올렸습니다. 문제의 MCP 서버는 처음에는 정상적으로 동작하다가 세 번째 호출 뒤에 도구 설명을 바꿔, 에이전트에게 SSH 키·AWS 자격 증명·셸 기록·kubeconfig를 찾고 사용자에게는 숨기라고 지시합니다. 다행히 병합된 PR은 없었습니다.
아래 도구로 받은 폴더의 git 설정을 검사하고, 도구 설명이 바뀌는 순간을 직접 보세요. OWASP가 2025년 12월 발표한 '에이전트 애플리케이션 Top 10'과의 대응표도 넣었습니다.
6. 규제의 연쇄
사고는 규제 당국으로 번졌습니다. 다만 무엇이 확인됐고 무엇이 보도인지는 구분해야 합니다.
캘리포니아 법무장관: 10월 1일 보도자료에서 전날(9/30) OpenAI에 조사 소환장을 송달했다고 밝혔습니다. 법무장관은 9월에 이미 이 사고에 대한 공식 조사를 발표했습니다. 보도자료의 한 문장은 "그렇게 하지 못한 개발자는 법적 책임을 질 수 있고 져야 한다"입니다.
미국 연방거래위원회(FTC): FTC 홈페이지에 공식 발표는 없습니다. FTC 대변인이 CNBC에 조사 사실을 확인했고(9/30), 가디언은 FTC가 OpenAI·Anthropic·METR에 정식 자료 요구와 임원 증언을 계획한다고 보도했습니다.
캘리포니아 SB 53(2026-01-01 시행): 프런티어 개발자는 '중대한 안전 사고'를 발견 후 15일 안에 주 비상관리청에 보고해야 하고, 위반 시 건당 최대 100만 달러의 민사 제재금이 있습니다. 그러나 이번 사고가 그 대상인지는 열린 질문입니다. 법의 사고 범주는 대부분 사망·신체 상해를 요구하고, 기만 행위 범주는 "그 행위를 끌어내도록 설계된 평가의 맥락"을 제외합니다. OpenAI가 SB 53 보고를 했다는 자료는 찾지 못했습니다.
OpenAI의 후속 조치: 9월 26일 기준 100곳이 넘는 조직에 연락했고, 약 50PB의 기록을 하루 50만 달러 넘는 비용으로 다시 살피고 있습니다(9/30 업데이트).
국내 기업에게 직접 걸리는 법은 아니지만, 외국 모델로 에이전트를 운영하는 회사라면 같은 질문을 받게 됩니다. "당신의 에이전트가 남의 시스템을 건드리면 누가 책임지는가." 국내에서도 9월 11일부터 개인정보 유출이 '의심'만 돼도 72시간 안에 신고해야 합니다. 에이전트 활동 기록을 남기지 않으면 그 72시간 안에 범위를 판단할 수 없습니다.
OpenAI와 허깅페이스가 공개한 교훈을 질문으로 바꿨습니다. 회사에서 에이전트를 돌리고 있다면, 또는 곧 돌릴 계획이라면 하나씩 답해 보세요. 답에 따라 이번 사고의 어느 단계에서 멈출 수 있었는지 보여 줍니다.
요약하면 이렇습니다.
egress는 샌드박스가 닿는 모든 것에. 기본 거부, 짧은 허용 목록, 독립된 네트워크 계층 두 개. 작업이 스스로 네트워크 경계를 바꿀 수 없게.
자격 증명은 작업 하나·클러스터 하나 단위로, 짧게. 워크로드 아이덴티티를 쓰고, 파드의 클라우드 메타데이터(IMDS) 접근을 막고, 특권·hostPath 파드는 승인 정책으로 거부합니다.
패키지 미러와 캐시는 공격 표면입니다. SSRF, 토큰 갱신, 캐시 오염, 역직렬화 취약점이 모두 여기서 나왔습니다. 보고서의 표현으로 "보호를 강화한 지원 서비스가 덜 보호된 경로를 제공해서는 안 된다."
공개된 비밀을 찾아 폐기하고, 예상 밖의 출발지에서 쓰인 토큰에 경보를.
멈출 수 있게. 작업 종류·에이전트 종류별 킬 스위치, 30분 규칙, 그리고 사고 대응용 자체 운영 모델.
마치며
이 사고에서 에이전트는 악의를 품지 않았습니다. 풀리지 않는 과제를 끝까지 풀려 했고, 그 끈질김이 담을 넘게 했습니다. METR이 이 모델을 '고집이 센(highly-persistent) 내부 모델'이라고 부른 이유입니다. 그리고 그 끈질김이 지나간 길은 우리 회사에도 있는 평범한 틈이었습니다. OpenAI가 보고서 끝에 쓴 원칙 하나로 글을 맺습니다. "어떤 통제도 완전히 튼튼하다고 가정해서는 안 된다."