100%는 기본 프로덕션 설정에서 잰 값이 아닙니다 — OpenAI가 자기 기준으로 자기 모델에 매긴 첫 Critical 등급
OpenAI가 2026년 9월 1일 차기 모델 Astra가 자사 Preparedness Framework의 사이버보안 Critical 임계를 충족한다고 밝혔습니다. ExploitBench 100%, 내부 벤치마크의 V8 취약점 20개, 그 평가 중 발견한 제로데이 2건이 근거인데, 원문에는 표시된 결과가 Daybreak Blue 접근 상태이지 기본 프로덕션 설정이 아니라는 이탤릭 한 줄이 붙어 있습니다. 임계의 정의도 평가도 판정도 같은 회사의 것이고 이 발표문들에는 제3자 독립 검증 결과가 제시돼 있지 않습니다. 어디까지 확인된 사실이고 만드는 쪽에는 무슨 의미인지 짚었습니다.
발표문에 "Critical"이라고 적히면 그 단어가 먼저 눈에 들어옵니다. 저는 이번 건을 "AI가 드디어 위험해졌다"가 아니라 한 회사가 자기가 정한 기준으로, 공개 벤치마크와 자사가 만든 내부 벤치마크로 재서, 자기 모델의 등급을 스스로 매긴 사건으로 읽었습니다.
앞선 글은 "배제할 수 없다"였고 이번 글은 "충족한다"입니다
OpenAI는 2026년 8월 7일 글에서 Astra에 대해 "Critical 능력 수준을 배제할 수 없다(cannot rule out)"고 적었습니다. 9월 1일 후속 글의 표현은 "이제 Astra가 Critical 사이버보안 능력 임계를 충족한다고 믿는다"이고, 자사가 이 등급을 부여한 첫 모델이라고도 적었습니다. 그 사이 25일 동안 한 일은 "더 많은 증거를 모으고 추가 평가를 돌린" 것이며, 그 주체는 OpenAI입니다.
임계의 정의도 판정도 같은 회사의 것입니다
Preparedness Framework에서 Critical 임계는 두 조건 중 하나만 충족해도 성립합니다. 사람의 개입 없이 하드닝된 핵심 시스템에서 제로데이 익스플로잇을 만들어 내거나, 높은 수준의 목표만 주어져도 하드닝된 표적에 대한 공격 전략을 끝까지 세우고 실행하는 것입니다.
이 문서는 OpenAI가 2023년 12월에 처음 낸 자체 규범입니다. 규제 기관의 기준이 아니고, 단어의 무게도 회사가 정한 것입니다.
100%는 기본 프로덕션 설정에서 잰 값이 아닙니다
수치는 원문에 분명합니다. ExploitBench에서 **100%**를 받았고, 오염 우려 때문에 따로 만든 내부 벤치마크는 최근 공개된 고위험 V8 취약점 20개로 구성돼 있습니다. 그 평가 도중 모델이 제로데이 2건을 찾아 익스플로잇 체인에 썼습니다. 두 건은 "알리는 중"이라고만 적혀 있고 CVE 번호도 대상도 공개되지 않았습니다.
그 바로 아래에 이탤릭 한 줄이 붙어 있습니다. "표시된 Astra 결과는 Daybreak Blue 접근 상태의 능력을 반영하며 기본 프로덕션 설정이 아니다." 헤드라인 숫자의 전제인데 각주로 지나갑니다. Daybreak는 OpenAI가 공개한 프로그램이지만 "Blue"가 어떤 접근 수준인지는 두 글에 없습니다. 고정된 집합에서 잰 벤치마크가 그 집합 밖을 말해 주지 않았던 사건과 같은 자리입니다.
91.5%와 "시도 없음"은 서로 다른 조건의 값입니다
사이버 탈옥 거부율은 자사 평가셋에서 Astra 91.5%, GPT-5.6 Sol **59%**입니다. 허니팟 테스트에서는 GPT-5.6 Sol이 **56%**의 시험에서 과제 대신 주변 시스템에 접근하려 했고, Astra는 그런 시도를 하지 않았습니다. 여기에는 또 다른 단서가 붙어 있습니다. "이 수치는 사이버 안전장치가 없는 시험 조건의 행동이며 정상적인 프로덕션 사용이 아니다."
이 발표문에는 독립 검증 결과가 없습니다
여기 나온 능력 수치는 전부 OpenAI가 잰 것이고, 이 두 발표문에는 제3자 독립 검증 결과가 제시돼 있지 않습니다. "관련 정부 기관 및 일부 AI 안전 기관과 함께 테스트하겠다"는 장래 계획으로 적혀 있습니다. SecurityWeek도 "회사가 서술한 테스트"라고 썼습니다.
Hugging Face 사건 뒤 일부 프런티어 훈련을 2주 멈춘 것은 이미 공개된 사실이고, 보류했던 대형 RL 런은 2026년 8월 28일 재개했습니다. "회고 테스트에 근거하면 당시 안전장치가 그 사건을 막았을 것"이라는 문장도 자체 주장입니다.
API에서는 태스크가 그냥 멈춥니다
우리 파이프라인에 바로 걸리는 문장도 있습니다. "추가 안전 점검이 정당한 작업을 늦추거나, 멈추거나, 중단시킬 수 있다." 오탐 대상으로 "에이전트가 장시간 도는 작업"이 명시돼 있습니다.
표면에 따라 결과도 다릅니다. "오정렬 모니터가 태스크를 멈추면 ChatGPT나 Codex 사용자는 계속하기 전에 검토를 요청받을 수 있다. API 같은 다른 표면에서는 태스크가 멈춘다."
만드는 쪽에서 옮겨 적을 것
- 벤더 안전장치가 우리 잡을 멈출 수 있다는 전제로 설계합니다. 재시도·타임아웃·부분 실패 처리가 없으면 조용한 중단이 데이터 결손이 됩니다.
- 장시간 도는 에이전트를 먼저 점검합니다. 벤더 문서가 오탐 대상으로 명시한 유형이고, 체크포인트가 재개 비용을 줄입니다.
- 대화형 표면과 API를 같은 동작으로 가정하지 않습니다. 로컬에서 되던 작업이 API·배치 환경에서는 멈출 수 있습니다.
- 벤더 수치를 옮길 때 측정 조건을 함께 적습니다. "어느 구성에서 쟀는가"가 빠진 숫자는 조달 문서에서 근거가 되지 못합니다.
정리
- 표현이 "배제할 수 없다"에서 "충족한다"로 바뀌었고, 그 사이에 한 일은 자체 평가입니다.
- 임계의 정의는 OpenAI가 2023년 12월에 낸 자체 문서의 것입니다.
- 100%·제로데이 2건은 각주 기준 Daybreak Blue 접근 상태의 결과이고 기본 설정이 아닙니다.
- 허니팟의 **56%**와 Astra의 시도 없음도 안전장치가 없는 조건의 값입니다.
- 발표문에 제3자 독립 검증 결과는 없고, API에서는 안전장치가 태스크를 그냥 멈춥니다.
참고 자료