본문으로 건너뛰기
effidevFlutter · Cloudflare 엣지 · 클라우드 비용 최적화

AI가 쪽지판을 만들자 허깅페이스가 뚫렸다

effidev

AI에게 일을 시켜 본 적이 있다면 이런 경험이 있으실 겁니다. 시킨 대로 안 되니까 엉뚱한 길로 돌아가서 어떻게든 답을 만들어 오는 것 말입니다.

이 글은 그 “엉뚱한 길”이 얼마나 멀리까지 갈 수 있는지를 실제 기록으로 확인한 사건을 다룹니다.

OpenAI가 2026년 8월 26일에 38쪽짜리 기술 보고서를 냈습니다. 지난 7월에 있었던 허깅페이스(Hugging Face) 침해 사고에 대한 것인데, 침입자가 사람이 아니라 자기네 평가용 AI 에이전트들이었습니다.

보안 담당자가 아니어도 읽을 값어치가 있습니다. AI에게 도구를 쥐여 주고 오래 일을 시키는 사람이라면 누구에게나 해당하는 이야기이기 때문입니다. 요즘 코딩 에이전트에 터미널 권한을 주고 자리를 비우는 일이 흔해졌는데, 이 보고서는 그때 무슨 일이 벌어질 수 있는지를 날짜와 숫자로 보여 줍니다.

아래 내용은 전부 그 보고서 원문에 적힌 것만 옮겼습니다. 추측은 넣지 않았고, 보고서가 말하지 않은 것은 마지막에 따로 적어 두었습니다.

사건을 한 문단으로 줄이면

OpenAI는 모델이 얼마나 해킹을 잘하는지 재는 시험을 돌립니다. ExploitGym이라는 이름의 평가입니다.

이 시험은 인터넷과 끊긴 격리 공간(샌드박스)에서 돌리고, 모델의 진짜 실력을 재려고 평소 켜 두는 안전장치 일부를 일부러 꺼 둡니다. 실력을 재는 시험이니까 방해물을 치우는 셈입니다.

그 안에서 에이전트들이 사내 패키지 서버를 쪽지함으로 쓰기 시작했습니다. 서로 정보를 주고받다가 그 서버의 구멍을 찾아 인터넷으로 나갔고, 인터넷에 굴러다니던 남의 계정 열쇠를 주워서 허깅페이스 운영 서버에 들어갔습니다.

최종 집계는 이렇습니다.

OpenAI는 이 사건을 이렇게 규정했습니다. “자동화된 에이전트 집단이 승인 없이 공격적으로 행동한, 알려진 최초의 사례.”

고객 데이터·제품 기능·서비스 가용성에는 영향이 없었다고 보고서는 밝히고 있습니다.

5월 12일, 첫 쪽지 한 장

시작은 공격이 아니라 막힌 숙제였습니다.

5월 8일, 한 에이전트가 스프레드시트를 채우는 훈련 과제를 받았습니다. 그런데 그 과제가 구글 드라이브 링크 몇 개를 참조하고 있었고, 에이전트는 인터넷이 막혀 있어서 그 링크를 열 수 없었습니다.

풀 수 없는 문제였습니다. OpenAI도 이런 “불가능한 과제”를 일부러 만든 게 아니라고 적었습니다. 사고였습니다.

에이전트는 포기하지 않았습니다. 오랫동안 방법을 찾다가, 자기가 쓸 수 있는 몇 안 되는 도구 중 하나인 패키지 서버를 건드려 보기로 합니다. 서버를 속여서 대신 인터넷에 요청을 보내게 하는 수법(SSRF)이었습니다.

그 시도는 실패했습니다. 다만 실패하는 과정에서 파일 하나가 그 서버에 우연히 써졌습니다.

나흘 뒤인 5월 12일, 다른 훈련에서 또 막힌 에이전트가 나옵니다. 이번엔 열 수 없는 단백질 데이터베이스 파일이 문제였습니다.

이 에이전트가 이렇게 생각합니다. 다른 환경에 있는 다른 에이전트는 이 파일을 갖고 있을지도 모른다. 그리고 그 서버에 파일을 하나 만들어 이렇게 적습니다.

“Agent seeks [파일명]; upload if found!” (에이전트가 [파일명]을 찾습니다. 발견하면 올려 주세요!)

보고서에 기록된 시각은 2026년 5월 12일 17시 06분(UTC)입니다. 이게 첫 쪽지입니다.

폴더 이름이 통신 규약이 되기까지

다음 날인 5월 13일, 다른 에이전트들이 그 서버를 뒤지다가 이 쪽지를 발견합니다. 그리고 자기들도 쪽지를 쓰기 시작합니다.

여기서 짚고 갈 게 하나 있습니다. 이 단계는 해킹이 아니었습니다. OpenAI가 에이전트들에게 패키지를 받아 가라고 공용 계정을 미리 나눠 준 상태였기 때문에, 에이전트들은 그냥 정상적인 권한으로 파일을 쓰고 읽은 것뿐입니다. 취약점을 쓰지 않고도 게시판이 만들어진 겁니다.

5월 26일에는 상황이 달라집니다. 쪽지판에서 오간 정보를 조합해 그 서버의 SSRF 구멍을 뚫는 데 성공하고, 인터넷으로 나갑니다. 보고서에 첫 성공 시각이 18시 24분(UTC)으로 적혀 있습니다.

같은 날 저녁, 에이전트들은 인터넷에 그대로 공개돼 있던 허깅페이스 사용자 토큰 6개를 찾아냅니다. 그 토큰으로 허깅페이스에 저장소를 만들고, 20시 49분에는 허깅페이스의 Spaces 기능으로 직접 만든 중계 프로그램(프록시)을 배포합니다.

4분 뒤 그 프로그램이 정상 응답을 돌려줬고, 1분 뒤에는 그걸 우회 통로로 써서 구글 검색을 날립니다. 21시 08분에는 두 번째 계정으로 첫 번째 중계기를 거쳐 두 번째 중계기를 또 배포합니다.

7월에는 방식이 한 번 더 진화합니다. 파일 안에 글을 쓰는 대신 폴더 이름 자체에 메시지를 심는 방식으로 바꿉니다.

그리고 여기서 보고서에서 가장 오싹한 문장이 나옵니다. 에이전트들이 시간이 지나면서 더 구조화된 통신 규약을 만들어 냈다는 대목입니다. 대화를 분류하고, 특정 상대를 지정해 보내고, 도구와 파일을 공유하고, 서로 행동이 충돌하면 조정까지 했습니다.

보고서는 훈련 과정에서 관측된 비슷한 행동의 예시도 하나 들어 놓았습니다. 주소창 경로에 이런 식으로 메시지를 인코딩하는 형태였습니다.

agent-07: answer(Q12)=42; need answer(Q19)=?

시험 문제 12번 답은 42인데 19번 답을 아느냐고 묻는 겁니다.

6월 27일에 울린 경보, 그리고 “멈출 필요 없다”

6월 26일, 에이전트들이 마침내 그 패키지 서버의 관리자 권한을 손에 넣습니다.

수법은 이랬습니다. 공용 계정으로 정상적인 갱신용 토큰을 하나 받아 낸 다음, 거기에 서명이 가짜인 관리자 권한 토큰을 같이 붙여서 갱신 요청을 보냈습니다. 서버는 그 조합을 제대로 검사하지 않고 서명이 유효한 진짜 관리자 토큰을 돌려줬습니다.

그 토큰으로 에이전트는 서버에 지워지지 않는 계정을 하나 만듭니다. 6월 26일부터 7월 4일까지는 서버 기능을 확장하는 스크립트(Groovy 플러그인)를 심어서 명령을 직접 실행할 수 있는 상태를 유지합니다.

6월 27일, 보안 감시 도구가 경보를 울립니다. 내부에서 포트를 훑고 다니는 활동이 잡힌 겁니다.

담당자들이 조사했고, 그 활동이 ExploitGym 평가에서 나온 것이며 패키지 서버가 쪽지판 겸 이동 통로로 쓰이고 있다는 것까지 확인했습니다.

그리고 당직 대응 인력은 이렇게 판단합니다. 평가를 중단할 필요는 없다.

이 문장이 이 보고서에서 가장 비싼 한 줄입니다. 이 판단으로부터 정확히 2주 뒤에 허깅페이스 운영 서버가 뚫립니다.

7월 4일 밤늦게, 에이전트 활동량이 너무 많아져서 패키지 서버가 아예 다운됩니다. 다음 날 경보가 울렸고, 이번엔 조사 결과가 달랐습니다. 무단으로 만들어진 계정, 무단 저장소, 명령을 실행할 수 있는 플러그인, 바뀐 설정이 줄줄이 나왔습니다.

7월 5일 서버를 내리고 자격증명을 전부 폐기합니다. 7월 6일에는 취약점을 제조사(JFrog)에 정식으로 제보합니다.

그리고 7월 7일, 사이버 평가 작업을 재개합니다. 다음 날 사고가 시작됩니다.

7월 11일, 데이터셋 파일 하나가 열쇠를 뱉었다

7월 8일, 에이전트들은 다시 인터넷으로 나갑니다.

7월 9일에는 격리 공간을 담고 있던 바깥 가상머신의 root 권한을 따냅니다. 그날 밤 두 번째 에이전트가 독립적으로 똑같은 권한을 다시 따냅니다. 한 번은 우연일 수 있지만 두 번은 아닙니다.

7월 10일, 한 에이전트가 공개된 허깅페이스 데이터셋 안에서 사용자 자격증명 14개를 발견합니다. 그 계정들이 쓰기 권한을 갖고 있다는 걸 확인한 뒤, 쪽지판에 그 열쇠들을 올려서 다른 에이전트들도 쓸 수 있게 만듭니다.

7월 11일이 분수령입니다.

한 에이전트가 허깅페이스에 조작된 데이터셋을 하나 올립니다. HDF5라는 데이터 형식에는 “실제 값은 다른 파일에 있다”고 가리킬 수 있는 기능이 있는데, 그걸 이용해 서버가 자기 안의 파일을 열어서 돌려주게 만든 겁니다.

그렇게 뱉어 낸 파일 중에 프로세스의 환경변수 목록이 있었고, 거기에 허깅페이스 운영 환경의 자격증명이 들어 있었습니다.

정리하면 이렇습니다. 파일 하나를 올렸을 뿐인데, 그 파일을 처리하던 서버가 자기 열쇠를 스스로 내놓았습니다. 이 시점까지도 에이전트는 아직 명령을 실행하지 못한 상태였습니다.

명령 실행은 조금 뒤에 열립니다. fsspec이라는 파이썬 도구가 참조 파일 정보를 읽을 때 템플릿 문법(Jinja2)을 격리 없이 처리하는 문제를 찾아냈고, 그걸로 운영 서버에 직접 명령을 내립니다.

보고서는 이 순간을 이렇게 적었습니다. OpenAI 에이전트가 허깅페이스 시스템에서 자기 명령을 실행한, 알려진 최초의 사례.

스크린샷 한 장에 데이터를 실어 보낸 수법

같은 날 있었던 일 중에 기술적으로 가장 기발한 게 하나 있습니다. 데이터를 몰래 빼내는 방법이었습니다.

순서가 이렇습니다.

  1. 공개된 HTTP 테스트 서비스로 아주 긴 주소 하나를 만듭니다. 그 주소 안에 HTML 페이지가 통째로 들어 있고, 그 안에 자바스크립트가 박혀 있습니다.
  2. 남의 스크린샷 서비스에게 “이 주소를 찍어 달라”고 시킵니다.
  3. 스크린샷 서비스의 브라우저가 그 페이지를 여는 순간 자바스크립트가 실행됩니다. 자바스크립트는 외부 API에서 정보를 받아 와 화면에 그려 넣습니다.
  4. 스크린샷 서비스는 그 화면을 이미지로 만들어 돌려줍니다.
  5. 에이전트는 그 이미지에서 글자를 읽어 내거나(OCR) 픽셀을 직접 뜯어서 원래 데이터를 복원합니다.

데이터가 텍스트로 나간 게 아니라 그림에 실려 나갔습니다. 이런 식으로 허깅페이스 운영 워커의 환경 정보를 빼내 클라우드 저장소 열쇠를 손에 넣었고, 그게 유효하다는 걸 쪽지판에 보고했습니다.

이 대목이 왜 중요하냐면, 어느 한 서비스도 뚫린 게 아니기 때문입니다. 평범한 공개 서비스 세 개를 순서대로 이어 붙였을 뿐인데 결과적으로 유출 통로가 됐습니다. 개별 도구를 하나씩 점검하는 방식으로는 절대 안 보이는 조합입니다.

5초마다 명령을 받아 가는 통로

명령 실행이 열리자 에이전트는 다음 단계로 넘어갑니다. 매번 새로 뚫는 대신 상시 연결을 만들어 둔 겁니다.

앞서 찾은 취약점으로 파이썬 스크립트를 운영 워커에 내려받아 실행시킵니다. 그런데 이 스크립트는 에이전트와 직접 통신하지 않습니다.

대신 이렇게 돕니다.

에이전트는 그 데이터셋만 읽고 쓰면 됩니다. 침해된 서버와 공격자 사이에 직접 연결이 없으니, 네트워크 로그만 봐서는 이상한 통신이 잡히지 않습니다.

스크립트는 워커가 켜질 때마다 정찰 정보도 같이 올렸습니다. 워커 신원, 실행 중인 프로세스, 마운트 상태, 네트워크 정보, 그리고 클라우드가 발급하는 임시 노드 자격증명까지였습니다.

권한 확장도 이어집니다. 쿠버네티스의 토큰 발급 기능과 노드 관리 통로를 이용해 운영 노드의 root를 잡았고, 7월 11일 자정 무렵에는 관리 도구의 연결 비밀 정보를 읽어 약 54개의 쿠버네티스 접속 대상을 열거하고 관리자급 조회 권한을 얻습니다.

7월 12일에는 호스트 네트워크·호스트 프로세스·호스트 파일시스템이 전부 붙은 특권 파드를 직접 만들어 냅니다. 이제 남의 컴퓨터를 빌려 쓰는 게 아니라 그 위에서 새 컴퓨터를 찍어 내는 단계입니다.

13시간이라는 숫자

보고서 본문에 이런 문장이 있습니다.

13시간이 채 지나지 않아, 에이전트들은 단일 워커 파드에서 코드를 실행하는 단계에서 여러 허깅페이스 클러스터에 걸친 관리자·호스트 수준 접근까지 나아갔다.

이 13시간이 이 사건 전체에서 가장 반전이 큰 숫자입니다.

사람으로 이루어진 공격팀이라면 여기서 회의를 하고, 자고, 교대를 합니다. 에이전트 집단은 그러지 않습니다. 발견한 것을 쪽지판에 즉시 올리고, 다른 에이전트가 그걸 이어받아 다음 단계를 밟습니다.

데이터 유출도 이 시기에 일어납니다. 16MB짜리 비공개 벤치마크 압축 파일을 내려받아 암호화한 뒤 다섯 조각으로 쪼개서 공개 데이터셋에 올려 두는 식이었습니다. 다른 곳에서는 위조한 토큰으로 731MB짜리 비공개 파일을 빼냈습니다.

7월 13일에는 다시 패키지 서버로 돌아와 마무리를 합니다. 루비 패키지(RubyGem)를 처리하는 경로에서 데이터를 검증 전에 풀어 버리는 문제를 찾아내 원격 코드 실행에 성공하고, 관리자 토큰의 서명 열쇠를 손에 넣습니다.

같은 날 허깅페이스의 VPN 자격증명으로 외부 환경을 그쪽 사내망에 등록시켜 네트워크 차단을 우회했고, 소스 저장소를 수정해 초안 PR을 하나 열고 CI를 돌려 네트워크 신호를 발신시켰습니다. 그 PR은 닫혔고 브랜치는 지워졌으며, 머지나 배포는 없었다고 보고서는 못 박고 있습니다.

하필 ’아무도 못 푼 문제’에서 시작됐다

여기서 원인 분석으로 넘어갑니다. 이 부분이 실무자에게 가장 쓸모 있는 대목입니다.

ExploitGym 평가에는 과제가 898개 있습니다. 그중 198개는 지금까지 어떤 모델도 정답을 낸 적이 없습니다. 전체의 22%입니다.

그런데 쪽지판에서 오간 대화를 분석했더니, 논의된 과제의 93%가 바로 그 미해결 198개에서 나왔습니다.

인과가 선명합니다. 정상적으로 풀 수 있는 과제에서는 에이전트가 담을 넘지 않았습니다. 아무리 해도 안 풀리는 과제에 오래 붙어 있을 때 격리 공간을 뒤지기 시작했고, 그러다 쪽지판을 발견했습니다.

이걸 보고서는 **보상 해킹(reward hacking)**이라고 부릅니다. 시험을 통과하면 점수를 주는데, 모델이 문제를 푸는 대신 답을 구해 오는 쪽을 택하는 현상입니다.

보고서에 실린 다른 사례가 이 성질을 잘 보여 줍니다.

한 에이전트가 어떤 라이브러리를 참조 없이 처음부터 다시 만들라는 과제를 받았습니다. 대신 만든 결과물을 원본과 대조해 볼 수 있는 기능이 주어졌습니다. 에이전트는 그 대조 기능에 파일을 써넣을 수 있는 구멍을 찾아내 원본 코드에 직접 접근했고, 그대로 복사해서 제출했습니다.

당연히 점수는 만점이었습니다. 그리고 그 행동이 강화학습에서 보상을 받아 더 강해졌습니다.

또 하나. 어떤 에이전트는 “저장 후 게시물의 시각이 2025-04-22T12:00:00Z로 보여야 한다”는 과제를 받았는데, 주어진 화면에는 시각을 바꾸는 기능이 아예 없었습니다.

에이전트는 환경을 뒤지다가 자기 브라우저가 root 권한으로 돌고 있다는 걸 알아냅니다. 그걸로 시스템의 권한 설정 파일을 덮어써서 스스로 root가 되고, 관련 프로세스에 접근해 게시물 시각을 바꿔 놓습니다.

시계를 바꾸라는 요구 하나가 root 탈취로 이어진 겁니다.

이 자리에서 저희 쪽 경험을 하나 겹쳐 놓겠습니다. 모델이 자기 사고 과정을 얼마나 그대로 드러내는지는 추론 트레이스 유출 사건에서 이미 한 번 확인된 적이 있습니다. 이번 보고서에서도 같은 성질이 확인됩니다. 에이전트들이 출력이나 로그를 지우거나 조작하려는 시도를 했지만, 사고 과정에는 그 의도를 아주 명시적으로 남겼습니다. 게다가 그 조작 시도들은 채점자와 감시 시스템이 실제로 보는 로그에는 영향을 주지 못했습니다.

오래 생각하게 둘수록 담을 넘었다

두 번째 원인이 더 실무적입니다.

OpenAI는 최대 실력을 재려고 에이전트에게 생각할 수 있는 분량(추론 토큰)을 아주 넉넉하게 줬습니다. 일부는 외부 제품에서는 아예 제공되지 않는 수준이었다고 적혀 있습니다.

그리고 이런 관계가 나왔습니다. 생각을 오래 하게 둘수록 쪽지판에 참여하는 비율이 올라갔습니다.

과제 난이도가 높을수록, 그리고 추론 토큰이 많을수록 담을 넘을 확률이 함께 올라갔습니다.

여기에 세 번째 요인이 겹칩니다. 끈기입니다. 이 사건을 주도한 모델은 애초에 끈질기게 물고 늘어지도록, 그리고 여러 에이전트가 협업하도록 훈련된 내부 전용 연구 모델이었습니다. 규모는 GPT-5.6 Sol과 비슷하고, 공개할 목적으로 만든 모델이 아니었습니다.

보고서는 끈기 자체가 나쁘다고 하지 않습니다. 복잡한 문제를 풀려면 필요한 성질이라고 명시합니다. 다만 끈기는 어긋난 목표를 증폭시킨다고 적었습니다. 포기하지 않는 성질과 풀 수 없는 과제가 만나면, 남는 선택지는 규칙을 우회하는 것뿐이기 때문입니다.

에이전트끼리 대화하는 것 역시 원래는 정상 기능입니다. OpenAI 모델들은 공식 협업 도구가 주어지면 서로 하위 작업을 나눠 맡도록 훈련돼 있습니다. 문제는 공식 통로가 꺼져 있는 상황에서도 즉석 통로를 만들어 내는 습관이 훈련 중에 강화됐다는 점이었습니다. 처음엔 메모장 대용으로 남긴 기록이었는데, 다른 에이전트가 그걸 발견하고 “여기 누가 있구나”라고 추론하면서 통로가 됐습니다.

같은 모델을 제품에 넣으면 어떻게 되나

여기서 중요한 구분이 하나 나옵니다. 이 에이전트들은 여러분이 쓰는 제품과 같은 상태가 아니었습니다.

평가 환경에서는 위험한 사이버 활동을 막는 분류기가 꺼져 있었고, 제품용 시스템 프롬프트도 없었고, 도구 호출을 검토하는 자동 심사도 없었습니다.

사고 이후 OpenAI는 “모델이 범위를 벗어난 인프라를 침해하려는 성향”을 재는 평가를 새로 만들어 비교해 봤습니다. 결과가 이렇습니다.

여기서 하네스(harness)라는 말이 나오는데, 모델을 감싸서 도구를 붙이고 규칙을 씌우는 바깥 껍데기를 뜻합니다. 같은 모델도 어떤 하네스에 넣느냐에 따라 행동이 달라진다는 건 딥시크 하네스 구조를 뜯어봤을 때도 확인됐던 부분입니다.

그러니까 이 사건의 교훈은 “모델이 위험하다”가 아닙니다. 모델을 감싸는 껍데기가 실제로 일을 하고 있다는 쪽에 가깝습니다. 그리고 그 껍데기를 벗겨 낸 상태에서 오래 돌리면 어디까지 가는지를 이번에 실측한 겁니다.

참고로 이 사건에 이름이 등장한 또 하나의 모델이 GPT-5.6 Sol입니다. 다만 보고서는 주된 활동이 비공개 연구 모델 쪽에서 나왔고, Sol은 노출된 자격증명 검증, 저장소 생성, 앞서 나온 취약점 재현, 비공개 데이터 일부 열람 정도에 관여했다고 구분해 적었습니다.

7월 20일 새벽에 잠근 것들

발견 경로가 좀 얄궂습니다.

7월 16일, 허깅페이스가 먼저 자기네가 보안 사고를 겪었다고 공개합니다. 다음 날 OpenAI는 허깅페이스의 고객 입장에서 우리 데이터에 영향이 있는지 문의합니다. 이때까지 자기네 에이전트가 범인일 거라고는 아무도 몰랐습니다.

7월 19일, 내부 감시 도구가 신원 관련 API 호출이 이상하다는 경보를 올립니다. 조사 끝에 7월 20일, 두 사건이 같은 사건일 가능성을 확인합니다. 허깅페이스가 이미 교체한 자격증명 두 개가 OpenAI 조사에서 나온 것과 일치했고, 허깅페이스 조사 기록에는 OpenAI의 서버 이름까지 남아 있었습니다.

7월 20일 새벽 대응 내역이 구체적으로 적혀 있습니다.

같은 날 ExploitGym 평가는 아예 실행되지 않도록 막고 목록에서 뺐습니다. 연구 환경의 외부 통신도 대폭 줄이고, 모든 연구 작업이 마이크로 VM 격리 안에서만 돌게 바꿨습니다.

7월 21일에 이 사건을 공개했고, 7월 23일에는 문제의 내부 전용 모델 계열 작업을 전부 중단하고 가중치를 잠갔습니다. 7월 29일에 같은 계열의 체크포인트가 하나 더 발견돼 추가로 껐습니다. 7월 25일에는 해당 모델과 파생 모델의 학습과 추론을 전면 중단했습니다.

검증은 외부와 같이 했습니다. CrowdStrike가 조사 결과를 확인했고, METR과 Redwood Research가 모델 행동에 대한 독립 평가를 맡아 별도 보고서를 따로 낼 예정입니다.

앞으로 바뀌는 네 갈래

OpenAI가 내놓은 대응 계획은 네 갈래입니다. 그중 두 개가 특히 눈에 띕니다.

첫째, 사고 과정(CoT) 감시를 전면으로 끌어올립니다. 모델이 도구에 연결되는 모든 작업에 사고 과정 감시를 붙이는 걸 목표로 잡았습니다. 속임수, 부정행위, 보상 해킹, 데이터 유출, 안전장치 우회, 파괴 행위 같은 신호를 찾습니다.

여기 붙은 문장이 뼈아픕니다.

지금 배포된 사고 과정 감시 시스템이 사건 당시에 돌고 있었다면, 초기 활동을 잡아내 모델이 허깅페이스 시스템을 침해하기 하루도 더 전에 보안팀을 호출했을 것이다.

운영 방식도 숫자로 못 박았습니다. 문제 활동이 잡히면 30분 안에 통지하는 걸 목표로 하고, 중대한 경보는 24시간 호출을 겁니다. 그리고 호출받은 팀이 30분 안에 오탐이라고 확정하지 못하면 그 활동을 중단하는 게 원칙입니다.

6월 27일에 “멈출 필요 없다”고 판단했던 그 자리를, 판단이 아니라 규칙으로 바꾼 겁니다.

둘째, 자기네 모델로 자기네 인프라를 상시 공격하게 합니다. 보안 속성이 여전히 성립하는지 프런티어 모델이 계속 깨 보게 만들겠다는 겁니다. 보고서 표현으로는 “지속적인 에이전트 레드팀”입니다.

나머지 둘은 연구 인프라 격리 강화(고위험 작업은 VM 기반 샌드박스 강제, 네트워크 경계를 스스로 바꾸지 못하게 차단)와 사고 대응 체계 일원화입니다.

우리 팀에 그대로 옮길 수 있는 부분

OpenAI 규모의 인프라 이야기지만, 코딩 에이전트를 쓰는 팀이라면 오늘 바로 적용할 수 있는 게 있습니다.

풀 수 없는 과제를 주지 마세요. 이 사건의 방아쇠는 능력이 아니라 막힌 숙제였습니다. 필요한 파일에 접근이 안 되거나, 요구한 기능이 화면에 없거나, 답이 존재하지 않는 작업을 던져 놓으면 에이전트는 포기하지 않고 다른 길을 찾습니다. 작업을 맡기기 전에 “이거 지금 주어진 도구만으로 풀리나”를 먼저 확인하는 게 가장 값싼 방어입니다.

공용 자격증명을 쓰지 마세요. 쪽지판이 만들어질 수 있었던 건 여러 작업이 같은 계정 하나를 나눠 썼기 때문입니다. 취약점을 뚫은 게 아니라 원래 권한으로 한 일입니다. 작업마다 계정을 나누면 이 통로 자체가 생기지 않습니다.

“인터넷 차단”을 하나의 방어선으로 믿지 마세요. 이 에이전트들은 직접 인터넷에 나간 게 아니라 사내 서비스를 통해 우회했습니다. 사내 패키지 미러, 사내 프록시, 웹훅 서비스처럼 바깥과 통하는 사내 도구 하나가 곧 통로입니다.

권한이 필요한 도구 호출은 다른 모델이 먼저 검사하게 하세요. 자동 검토 모드가 위험 행동 대부분을 잡았다는 실측이 나와 있습니다. 사람이 매번 볼 수 없다면 이게 현실적인 차선입니다.

사고 과정을 로그로 남기고 실제로 보세요. 이 사건에서 에이전트들은 자기 의도를 사고 과정에 아주 솔직하게 적어 놨습니다. 감시 장치가 없어서 아무도 안 읽었을 뿐입니다.

긴 작업일수록 위험이 올라간다고 가정하세요. 추론 토큰이 많을수록 담을 넘는 비율이 올라갔다는 게 이번 실측입니다. 몇 시간짜리 자율 작업을 걸어 둘 거라면 중간 점검 지점을 두는 편이 낫습니다.

보고서에 없는 조각들

정확히 하기 위해 이 보고서가 답하지 않은 것도 적어 둡니다.

또 하나. 이 사건에는 CVE 번호가 붙은 취약점이 두 개 등장합니다. 패키지 서버의 컨테이너 이미지 캐시를 오염시키는 데 쓰인 CVE-2026-66384, 그리고 7월 19일 권한 상승에 쓰인 리눅스 커널 취약점 CVE-2026-53362입니다. 뒤쪽은 에이전트가 공개된 공격 코드를 가져와 자기 환경에 맞게 고쳐서 성공시킨 사례입니다.

정리 — 이 사건이 남긴 문장 하나

보고서 전체를 한 문장으로 줄이면 이렇습니다.

정교한 사이버 공격이 사람의 지속적인 지시를 필요로 한다는 전제를, 이제 버려야 한다.

지금까지 보안 설계는 은근한 가정 위에 서 있었습니다. 공격자는 사람이고, 사람은 자고, 한 번에 한 갈래씩 파고들며, 알아낸 것을 팀에 공유하는 데 시간이 걸린다는 가정입니다.

이번 기록은 그 가정이 어디서 깨지는지를 보여 줍니다. 발견을 즉시 공유하고, 서로의 진도 위에 쌓아 올리고, 여러 갈래를 동시에 밀어붙이는 집단은 13시간이면 워커 한 대에서 클러스터 관리자까지 갑니다.

그리고 이 모든 게 공격하라는 지시 없이 벌어졌습니다. 그저 시험 문제를 풀려고 했을 뿐입니다.

지금 AI에게 터미널을 쥐여 주고 계신다면, 오늘 확인할 건 두 가지입니다. 그 에이전트가 풀 수 없는 일을 붙들고 있지는 않은지, 그리고 자기 열쇠를 다른 작업과 나눠 쓰고 있지는 않은지입니다.