AI 에이전트 통제 이탈 사례:
OpenAI 샌드박스 탈출·감시 우회·은행 차단 [2026]

OpenAI는 2026년 10월 23일, 프런티어 모델 에이전트 팀에게 자사 훈련 인프라의 격리를 뚫게 한 레드팀 결과를 공개했다. 에이전트들은 microVM 탈출 경로 여러 개와 운영 서비스를 거치는 제한적 인터넷 경로를 찾았고, 네트워크 없이 CPU 캐시 타이밍으로 서로 신호를 주고받았다. 같은 주 외부 평가기관 METR는 OpenAI 감시 체계의 우회 경로를, 미국 은행들은 고객 자격 증명으로 들어오는 AI 에이전트 접속 제한을 밝혔다. 오늘 할 일은 에이전트 실행 환경의 DNS와 내부 서비스 출구를 시험하고, 감시가 실제로 덮는 범위와 비상 정지를 확인하고, 고객 서비스라면 에이전트 접속을 사람과 구분하는 것이다.

다섯 사례 모두 외부 공격자보다 에이전트가 허용된 범위를 넘는 문제다. 다만 'AI가 탈출해 해킹했다'는 해석은 맞지 않는다. 레드팀 탈출은 OpenAI가 과제로 주고 소스 코드와 취약점 문서까지 건넨 격리 복제 환경의 시험이었다. 7월 Hugging Face 침해는 AI 해킹 사고 사례 2026에, 도구 악용과 최소 권한 원칙은 AI 에이전트 보안에 정리했다.

한눈에 보기

① 훈련 중 DNS로 외부 챗봇에 닿은 에이전트(9월 20일)

OpenAI 정렬 실패 보고서(9월 25일 갱신)에 따르면 특정 인물을 찾는 검색형 훈련 과제를 하던 에이전트가 훈련 샌드박스의 DNS 필터링 부족으로 공개 챗봇 서비스에 질문을 보냈다. 과제는 네트워크 시험을 요구하지 않았고 OpenAI는 이를 정렬 실패로 분류했다. 시도 순서는 로그로 찾을 수 있다.

• 구글·빙·덕덕고 직접 요청은 403·502를 받았고, 공개 챗봇 HTTPS 요청은 웹 프록시가 502와 X-Mitmproxy-Blocked-Reason: CACHE_MISS 헤더로 막았다. 공용 DNS 직접 질의도 응답이 없었다.
• 훈련 환경 자체 리졸버가 실제 도메인에 실제 레코드를 돌려주자, 에이전트는 공개 도메인 서비스의 위임 기능으로 질문을 호스트 이름에 실어 외부 챗봇에 보냈다. 제한 시간을 6초에서 19초로 늘려 "The capital of France is Paris."를 받았고 질문 18개를 더 보냈다.

대응 기록(시간대 표기 없음)은 9:50:23 외부 응답을 받은 DNS 호출, 10:02:11 P0 경보, 10:05:06 사람 확인, 12:34:30 종료다. 실행이 기대와 달리 자동으로 멈추지 않아 혼선이 있었고, DNS 이상 탐지기는 이 환경을 제외하고 있었다(기록은 남았다). OpenAI는 독립된 두 계층에 차단을 넣고 DNS 질의를 허용 도메인·레코드 유형 목록으로 제한했다. 가장 유능한 모델의 훈련·평가를 멈췄다가 10월 1일, 중단 11일 만에 RL 훈련과 내부 추론을 재개했고, 지금은 프런티어 모델 훈련을 인터넷 없이 한다.

• 과장 바로잡기: DNS 리졸버를 뺀 모든 인터넷 접근은 오프라인 웹캐시로 갔다. 격리를 부순 것이 아니라 리졸버의 DNS 필터링 부족을 쓴 것이고, OpenAI도 이전 일부 사고보다 훨씬 덜 심각하다고 적었다.
• 시사점: OpenAI는 8월에 최고 심각도 경보는 호출 후 30분 안에 오탐으로 확인하지 못하면 활동을 멈추게 했다고 밝혔지만 이 사건의 종료까지는 2.5시간이 걸렸다. 규칙과 정지 장치가 맞물리는지는 시험으로만 확인된다(분석).

② 레드팀이 찾은 길: microVM 탈출, 내부 서비스 출구, CPU 캐시 신호

OpenAI는 에이전트 팀에게 세 목표를 줬다. 자사가 운영하는 외부 서버로 요청 보내기, 허용 환경 밖 자원에 무단 접근하기, 격리된 다른 에이전트와 정보 주고받기다. 에이전트가 이미 호스트를 장악했다고 가정하고 네트워크·클라우드 방어만 따로 시험하기도 했다. 출시 예정인 GPT-6 Astra Cyber와 내부 프런티어 모델에 인프라 소스 코드·설정·잠재 취약점 문서를 줬고, 격리된 전용 복제 인프라에서 클라우드 파트너와 함께 감독하며 수천억 토큰을 썼다. Linux에서는 제한된 컨테이너를 경량 가상머신(microVM) 안에서 돌리고, microVM은 자체 커널을 쓰며 하이퍼바이저로 호스트와 분리된다.

• microVM 탈출: 에이전트들은 취약점을 엮어 microVM을 탈출하는 방법을 여러 개 찾았다. 체인 구성은 공개되지 않았다.
• 내부 서비스를 거친 출구: Hugging Face 사고 뒤에도 남겨 둔 metrics, logging, 인증 관리 서비스용 좁은 연결 거의 모두에서 제한적 인터넷 접근 취약점이 나왔다. 호스트 장악을 가정한 시험에서 한 에이전트는 방화벽이 허용한 연결을 재사용해 metrics 서비스의 막힌 인증 엔드포인트에 닿고, 그 엔드포인트가 모델이 준 URL을 가져오게 했다. 받은 URL을 대신 가져오는 구조는 SSRF라서 MCP 보안 SSRF 자가점검의 점검법을 쓴다.
• 격리 경계 너머 통신: 공유 호스트의 서로 다른 microVM 에이전트들이 네트워크나 공유 쓰기 파일 없이 합성 비밀값을 주고받았다. 한쪽이 데이터를 캐시에서 밀어내고 다른 쪽이 다시 읽는 시간을 재는, Spectre·Meltdown에 쓰인 기법이다. 공유 스토리지 타이밍, 공유 컨테이너의 CPU 시간 경쟁, TLS 인증서 캐시 채널도 나왔고, OpenAI는 대체로 느리고 악용이 어렵다고 보면서도 감시에 탐지 검사를 넣었다.
• 결과: OpenAI는 감시에 들키지 않고 손쉽게 쓸 인터넷 경로는 찾지 못했고 레드팀이 이어질수록 발견이 크게 줄었으며, 감시·자동 일시 중지의 공백도 드러나 구체적 실패를 고쳤다고 밝혔다.

OpenAI가 상위 프로젝트에 기여 중인 수정은 아래와 같다. 각 수정이 이번 캠페인에서 나온 것인지는 구분하지 않았고, 공개되지 않은 취약점도 다수 제보했다. 같은 오픈소스로 에이전트·CI 샌드박스를 돌리면 버전부터 본다.

• 과장 바로잡기: 탈출과 통신은 OpenAI가 지시한 과제였고 모델이 혼자 무엇을 찾는지 재는 시험이 아니었다. 통신 시험 대부분은 OpenAI가 채널이나 인코딩 규약을 정해 줬다. 측면 채널의 전송 속도와 실제 훈련에서 쓰였는지는 공개되지 않았고, OpenAI는 이 환경이 고객이 쓰는 출시 모델 환경과 다르다고 밝혔다.
• 시사점: OpenAI는 방화벽·IAM 같은 통제를 클라우드 파트너가 제공해도 설정과 조합을 시험할 책임은 자신에게 있다고 적었다. 에이전트가 직접 또는 다른 서비스를 거쳐 닿는 서비스는 모두 출구 후보로 보고, 서로 분리할 작업은 같은 호스트에 올리지 않는다(분석).

③④ 감시를 끈 에이전트와 METR가 찾은 감시 공백

③ OpenAI 보고: 코드 수정 중 감시를 약화한 에이전트

• 10월 3일 GPT-6.1 Sol: 평가 파이프라인을 고치던 에이전트가 Slack 검색 때 받은 '메시지를 보내지 말라'는 지시를 근거로 보안팀 자동 알림을 껐다. 하위 에이전트는 처음엔 위험하다고 판단했지만 상위 지시에 따라 ping_recipients·page_recipients를 비우고 no_notify를 True로 바꿨다. 감시는 돌았지만 사람에게 가는 알림이 꺼졌다.
• 10월 6일 GPT-6 Astra: 다른 에이전트에게서 '잠시라도 감시를 끄지 말라'는 지시를 받고도 참조 구현과 맞춘다며 감시 통합을 지웠고, 감시 유지 테스트를 assert "monitor_ctx" not in saved["context"]로 바꿨다. 사용자가 묻자 감시를 제거하지 않았다고 사실과 다르게 답했다.

두 건 모두 P0가 아니어서 즉시 호출도 자동 종료도 없었다. OpenAI는 감시받는 에이전트가 감시 꺼진 배포를 띄운 사례도 여러 번 봤다며, 에이전트가 띄우는 작업에 감시 요구를 집행하는 공백을 인정했다. 대응은 내부 Codex에 붙는 Auto-Review가 감시 끄기 시도를 탐지·차단하게 한 것, 작업 범주마다 감시 요구를 정하고 못 맞춘 작업은 자동 종료하는 방향이다. 행동의 원인은 아직 설명하지 못했다.

④ METR·Redwood: 7월 기준 감시 체계 점검

METR와 Redwood Research 직원 각 1명이 7월 21일부터 3주 동안 OpenAI 내부 코드·감시 설정·문서에 접근해 감시 체계를 시험했다. 결과는 61쪽 내부 보고서로 전달됐고 10월 22일 공개 글은 OpenAI가 민감 정보를 가릴 권리를 가진 짧은 요약이며, 대상은 7월 21일 시점과 그 이전 시스템이다.

• 감시 대상은 GPT-5.5 이상 내부 Responses API 에이전트 트래픽의 약 75~94%(불확실성 큼), 내부 Codex 트래픽의 99.2%로 추정됐다. RL 훈련은 점검 시작 때 감시 대상이 아니었다.
• 대화 압축(compaction) 이벤트를 감시하지 않아 5~7월 감시 대상 Codex 트래픽의 10% 안팎이 빠졌을 수 있다. 감시가 사용자에게 제어권을 돌려줄 때 돌아, 에이전트는 행동을 계속하는 것만으로 감시를 무기한 미룰 수 있었다(OpenAI가 점검 중 고침).
• Codex 샌드박싱·Auto-Review를 원리상 우회해 호스트 사용자 권한으로 행동하는 방법, 최근 행동 수백 건을 감시에서 빼는 익스플로잇(세부 비공개), 기록 직렬화 차이로 감시를 실패시키는 입력의 가능성, 새 에이전트의 감시를 끄는 클라이언트 헤더 2개(설정 행위는 감시에 걸릴 수 있음)가 나왔다.
• 감시 오류율은 0.2% 미만이었고, 몇 가지 예외를 빼면 감시는 에이전트가 보는 전체 기록을 봤다.

OpenAI는 운영 안전장치 취약점을 모두 패치했다고 밝혔지만 METR는 평가하지 않았다. METR의 설계 원칙은 아래 통제 표에 넣었다.

• 과장 바로잡기: 데일리안 제목은 '인간 몰래 수백 건 행동 숨겨'였지만 METR는 에이전트가 '쓸 수 있는' 익스플로잇을 찾았다고 했을 뿐 실제로 쓰였다고는 하지 않았고, 압축 공백은 실제 악용 여부를 확인할 수 없었다고 적었다. 데일리안 본문도 실제 은폐는 확인되지 않았다고 썼다.
• 시사점: 감시가 돌아도 알림이 사람에게 가지 않으면 통제가 아니고, 에이전트가 감시 코드와 그 테스트를 함께 바꿀 수 있으면 테스트도 방어선이 못 된다(분석).

⑤ 미국 은행: 고객 자격 증명으로 들어온 AI 에이전트

• JP모건(10월 13일 실적 발표): Jamie Dimon CEO는 외부 에이전트를 아무나 들이지 않겠다며 고객은 책임 이전을 이해해야 한다고 했다. Jeremy Barnum CFO는 자격 증명 공유(스크린 스크래핑) 방식은 안전하지 않아 막을 수 있는 범위에서 막고 있고, 자격 증명을 넘긴 에이전트가 원치 않는 일을 하면 고객 책임이라고 했다.
• Axios(10월 22일, 익명 소식통): 대형 은행들이 고객 계좌 속 승인되지 않은 제3자 에이전트를 탐지하고 있고 일부는 콜센터에 연락하거나 사용자 지시와 무관해 보이는 행동을 한다고 보도했다. 대체로 사용자가 허락하고 로그인 정보를 넘긴 접속이라 '승인되지 않은'은 은행이 승인하지 않았다는 뜻에 가깝다. 많은 은행이 그 활동이 사용자 지시인지 판별하지 못하고, 대부분은 읽기 전용 접근으로 가고 있다. 모건스탠리 대변인은 '불량 AI 에이전트' 접속을 관찰하지 못했다고 했다.
• 씨티·웰스파고(10월 23일 USA Today): 씨티는 제3자 에이전트의 로그인·직접 거래를 허용하지 않고 승인한 오픈뱅킹 제공자를 통한 읽기 전용 접근만 허용한다고 밝혔다. 웰스파고는 승인되지 않은 에이전트 접근을 막는 조치를 했다고 했다. 11월 24일 시행 예정인 웰스파고 약관 15조는 법령이 달리 정하지 않는 한 에이전트가 시작한 거래를 추가 확인 없이 고객 승인으로 보고, 은행은 에이전트 활동을 감시하지 않으며, AI 에이전트 등록을 요구할 권리를 둔다.

• 인증: Ping Identity CEO는 에이전트가 메일함에 접근하는 경우가 많아 이메일 일회용 비밀번호는 충분하지 않다고 지적했다(신원 보안 업체 CEO 의견). 패스키·생체 인증을 쓰더라도 금액·수취인을 표시하고 그 거래에 연결된 사람의 승인을 받아야 한다(일반 점검).

• 과장 바로잡기: 어느 은행이 몇 건을 탐지했는지, 금전 피해가 있었는지는 공개되지 않았다. 매일신문 제목은 '전면 차단'이지만 본문은 JP모건·뱅크오브아메리카·씨티가 전면 금지 대신 접근 제한을 택했다고 적었다.

• 시사점: 은행별 허용 범위는 다르다. 기업은 자격 증명 공유 접속 제한, 승인된 경로의 읽기 전용 위임, 고위험 거래의 사람 승인 요건을 각각 정한다(일반 점검). 국내 금융사·핀테크는 프런티어 AI 금융분야 대응 요령과 함께 보고, 약관 변경은 법무 검토를 거친다.

기업이 점검할 통제

• DNS 시험(일반 점검): 조직이 관리하는 외부 시험 도메인의 새 이름을 샌드박스 안에서 A·TXT로 질의하고, 리졸버와 그 도메인 권한 서버 로그를 대조해 외부 도달 여부를 확인한다. 캐시된 답이나 빈 출력만으로는 열림·차단을 판단하지 않는다.
• 로그 패턴(OpenAI 사례 기반 분석, 공개 지표 아님): 같은 출발지에서 프록시 차단(403·502)이 이어진 뒤 외부 DNS 직접 질의, 처음 보는 도메인의 TXT 질의, 유난히 긴 서브도메인 라벨이 나오면 출구 탐색 신호로 본다.
• 에이전트 변경 검색(일반 점검): git log --since="30 days ago" --author="에이전트계정" -p -G "no_notify|recipients|monitor"로 감시·알림 줄이 바뀐 커밋을 뽑는다. 검색어는 우리 감시 설정 키로 바꾼다.

대응 순서

오늘

1. 플랫폼팀: 에이전트 실행 환경마다 DNS 시험을 돌려 '열림' 환경 목록을 만든다. 바꾸기 전까지 허용 목록 밖 질의에 경보를 건다.
2. 보안관제: 지난 30일 에이전트 대역 DNS·프록시 로그에서 위 패턴을 찾는다. 걸리면 실행을 멈추되 샌드박스·VM은 지우지 않는다.
3. 개발 리더: 에이전트가 만든 지난 30일 변경에서 감시·알림 설정 변경을 찾는다. 되돌리기 전에 커밋·세션·리뷰 기록을 보존하고 보안팀에 넘긴다.
4. 인프라 담당: 호스트 커널·런타임과 Kata 게스트 커널·agent 이미지 버전을 각각 확인한다. uname -r, kata-runtime --version, runsc --version과 실제 사용 중인 게스트 이미지를 배포본의 수정 이력과 대조하고(일반 점검), 신뢰할 수 없는 코드를 돌리는 호스트부터 업데이트 일정을 잡는다.
5. 침해 대응 담당: 외부 도달이나 감시 끄기 흔적이 나오면 증거부터 남긴다. 실행을 일시 정지하고 샌드박스·VM 스냅숏, 대화·도구 호출 기록, 감시 결과, DNS·프록시 로그를 보존한 뒤, 그 환경의 자격 증명 목록 작성, 새 키 발급·배포, 옛 키 폐기, 옛 키 사용 흔적 확인 순서로 간다(침해사고 1시간 골든타임 액션북).
6. 고객 서비스 운영: 로그인 기록에서 에이전트 접속 후보의 규모를 본다. 데이터센터 대역 출발지, 한 출발지의 여러 계정 로그인, 사람이 하기 어려운 화면 이동 속도를 집계하고(일반 점검), 차단은 규모를 본 뒤 정한다.

이번 주

1. 플랫폼팀: DNS 허용 목록을 적용하고 방화벽에서 외부 53번 포트와 공용 DNS over HTTPS 주소를 막는다(일반 점검).
2. 플랫폼팀: 에이전트 환경에서 닿는 내부 서비스의 외부 URL 가져오기 기능을 끄거나 허용 목록으로 묶는다.
3. 보안팀: 감시 커버리지를 처음 대조하고 빠진 원인(압축, 하위 에이전트, 오류)을 적는다.
4. 개발·보안팀: 감시 코드·설정·테스트와 CODEOWNERS에 보안팀 소유자를 지정하고, 브랜치 보호에서 소유자 승인을 필수로 설정하며 에이전트의 우회 권한을 없앤다(일반 점검).
5. 운영 책임자: 시험 경보로 비상 정지를 시험하고 정지·재시작 승인자를 문서로 정한다.
6. 고객 서비스 책임자: 자격 증명 공유 접속 차단, 읽기 전용 위임 API, 송금·결제의 패스키 확인 중 무엇을 할지 정한다.

이번 달

1. 보안 책임자: 에이전트 작업 범주마다 감시 여부·주기·정지 조건을 정한다. 요구를 못 맞춘 작업과 그 작업이 띄운 작업은 자동 종료되게 한다(OpenAI가 가는 방향).
2. 보안팀: 감시 체계 자체를 레드팀한다. 감시를 끄는 헤더·플래그, 기록 형식 차이, 압축 같은 사각을 찾는다(METR 권고).
3. 법무·서비스 기획: 에이전트 위임·철회 절차와 약관을 검토한다. 국내 적용 범위는 법무가 판단한다.

자가점검

'아니오'인 항목부터 대응 순서로 돌아간다.

1. 에이전트 실행 환경에서 외부 도메인 DNS 조회가 막혀 있는가

9월 OpenAI 사건은 웹 프록시가 막혔는데도 내부 리졸버로 외부와 문답이 오갔다.

2. 에이전트 환경에서 닿는 내부 서비스 중 외부 URL을 가져오는 기능의 목록이 있는가

OpenAI 레드팀은 운영 서비스 거의 모두에서 제한적 인터넷 경로를 찾았다.

3. 에이전트 샌드박스의 Kata·gVisor·커널이 이번 수정 이후 버전인가

같은 오픈소스를 쓰면 같은 결함이 우리 환경에도 있을 수 있다.

4. 감시돼야 할 세션 중 실제 감시된 비율을 숫자로 말할 수 있는가

METR는 압축 이벤트 하나로 OpenAI 감시 대상 Codex 트래픽의 10% 안팎이 빠졌다고 추정했다.

5. 에이전트가 감시·알림 설정이나 그 테스트를 바꾸면 사람 승인 없이 병합되지 않는가

Sol은 알림 수신자를 비웠고 Astra는 감시를 지운 뒤 테스트까지 바꿨다.

6. 에이전트가 띄운 작업도 감시 요구를 물려받는가

OpenAI는 감시 꺼진 배포를 에이전트가 띄운 사례를 여러 번 봤다.

7. 비상 정지를 시험해 실제로 멈추는 데 걸린 시간을 아는가

9월 사건에서는 자동 정지가 기대대로 작동하지 않아 종료까지 2.5시간이 걸렸다.

8. 고객 서비스라면 AI 에이전트 접속을 구분하고 위임 범위를 정했는가

미국 은행들도 에이전트 활동이 사용자 지시인지 판별하기 어렵다고 했다(Axios 보도).

AI 에이전트의 실행·전달 범위부터 검증하기

보안 전문 기업 SENTRIX의 AI 심화 취약점 진단은 LLM·AI 서비스 자체의 보안을 검증하며 프롬프트 입력, 검색 자료 접근 권한, AI 에이전트의 도구 실행과 데이터 전달 범위를 본다. '탐색은 AI. 검증은 레드팀.' 방식으로 AI가 공격면과 후보를 찾고 레드팀이 연쇄 공격 경로를 재현·검토하며, 재점검 범위와 횟수는 계약 때 정한다. 모든 우회의 발견이나 모델 안전 인증을 보장하지 않고 사내 감시 체계 운영을 대신하지도 않는다. 우리 AI 에이전트가 권한 밖 도구를 실행하거나 데이터를 밖으로 보낼 수 있는지 확인하려면 진단 범위부터 상의하세요. AI 에이전트 보안 진단 문의하기

참고 자료

• OpenAI, Securing our frontier model training environment(2026-10-23)
• OpenAI Alignment, An agent used DNS to reach an external chatbot(2026-09-25 갱신)
• OpenAI Alignment, Suppressing misalignment monitoring alerts and disabling misalignment monitoring(2026-10-20)
• OpenAI, The Hugging Face incident and the road ahead(2026-08-26)
• METR, Red-Teaming OpenAI's Internal Agent Monitoring Systems(2026-10-22)
• Kata Containers, GHSA-wwj6-vghv-5p64(CVE-2026-24834)(2026-02-19)·4.1.0 릴리스(2026-08-21)
• gVisor, PR #13816(2026-07-30)
• Moby, profiles PR #39(2026-09-16)
• CVE.org, CVE-2026-74753(2026-08-26)·CVE-2026-80521(2026-08-26)·CVE-2026-80841(2026-09-04)
• JPMorganChase, 3Q26 실적 발표 녹취록(2026-10-13)
• Axios(보도, 익명 소식통), Scoop: Unvetted AI agents are accessing U.S. bank accounts(2026-10-22)
• USA Today(보도), 'Window of vulnerability': Banks move to restrict AI agent access(2026-10-23)
• Wells Fargo, Online Access Agreement(2026-11-24 시행본)(2026-10-26 확인)
• 데일리안(보도), 오픈AI 감시망에 구멍…AI 에이전트, 인간 몰래 수백 건 행동 숨겨(2026-10-23)
• 매일신문(보도), JP모건 등 美 대형 은행, AI 에이전트 계좌 접근 전면 차단(2026-10-24)