오픈AI, 250명 투입해 사내 취약점 훑었다

그래도 방어 쪽에 아직 시간이 남아 있다는 게 회사의 주장이에요. 오픈AI는 방어자의 구조적 이점을 두고 "에이전트가 자사 코드에 직접 액세스할 수 있도록 하고, 프런티어 모델을 활용해 널리 이용 가능한 오픈 웨이트 모델을 악용하는 공격자보다 먼저 앞서 나갈 수 있습니다"라고 적었어요. 자기 코드를 통째로 열어 줄 수 있는 쪽도, 최신 모델을 먼저 쓸 수 있는 쪽도 방어자뿐이라는 거예요. 회사는 이 시차를 방어자에게 열린 기회라고 부르면서 지금 움직이지 않으면 닫힌다고 못 박았어요.

스프린트는 실제 사고가 난 것처럼 굴러갔어요. 보안과 응용, 연구 조직을 한자리에 모아 수백 개 시스템을 한꺼번에 걸었어요. 오픈AI 코어 제품·플랫폼 총괄 티보는 "OpenAI는 인시던트에 대응할 때와 같은 긴박감을 가지고 방어 체계를 강화하고 있습니다"라고 말했어요. 그는 이 작업이 핵심 사업 운영을 뺀 다른 모든 업무보다 앞서는 전사 과제이며 스프린트가 끝난 뒤에도 같은 긴박감을 유지하겠다고 덧붙였어요. 첫날에만 긴급 또는 높은 우선순위 이슈 53건을 처리했어요.

메탈이 확인한 공개 문서에는 잘 굴러가지 않았던 대목의 숫자도 그대로 적혀 있어요. 처음에는 심각도 분류의 범주가 너무 넓어서 에이전트에 준 지침에 따라 결과가 흔들렸어요. 회사는 평가 기준과 프롬프트에 버전을 매기고 검토자가 기대한 우선순위와 판단 근거를 기록한 뒤에야 일괄 처리로 넘어갔어요. 그 과정에서 발견 사항의 37%가 중복으로 확인됐고, 중복 제거 성능이 나아질 때까지 담당자 배정을 아예 멈춰 뒀어요.

검증 단계의 숫자는 더 구체적이에요. 에이전트가 코드를 실제로 돌려 볼 수 있는 격리 환경을 만든 뒤 발견 사항의 19.5%가 런타임에서 재현됐고, 이 동적 검증을 거친 다음의 오탐률은 0.81%였어요. 담당 팀을 찾아 넘긴 결과가 받아들여진 비율은 90.6%까지 올라갔어요. 패치를 만든 쪽도 사람이 아니라 Codex였고, 배포한 뒤 되돌려진 수정 사항은 0.53%에 그쳤어요.

회사가 인정한 한계도 함께 실려 있어요. 격리 환경을 갖추는 일 자체가 검증의 병목이어서 반복 실행이 가능한 일부 서비스부터 시작할 수밖에 없었어요. 병합된 패치와 실제로 전체 서버에 배포된 수정 사항 사이에 차이가 있다는 점은 뒤늦게 발견했고, 배포 지연을 어떻게 셈할지 정하지 못해 자동 재오픈 기능은 꺼 둔 상태예요. 자율성도 한 번에 준 게 아니라 소규모 배치와 사람 검토로 시작해 신뢰가 쌓인 만큼만 넓혔어요.

법률의 눈으로 보면 이 문서에서 가장 중요한 대목은 성능 수치가 아니라 통제 구조예요. 오픈AI는 에이전트가 할 수 있는 일의 범위와 실제로 바꿔도 되는 범위를 따로 떼어 관리했다고 밝혔어요. 감사 흔적도 설계 안에 들어가 있어서 호스트 활동과 인프라 보안, 에이전트 감사를 각각 남겨요. 사고가 났을 때 누가 무엇을 언제 승인했는지 되짚을 수 있어야 책임 소재가 정리되는데, 그 요구를 도구가 아니라 조직 설계 층에서 먼저 풀어 둔 구조예요.

이번 발표는 오픈AI가 최근 밀고 있는 방어 사업의 안쪽 기록이기도 해요. 메탈은 오픈AI가 취약한 방어 조직에 10억달러 규모의 Daybreak 접근권을 내놓기로 한 일을 보도한 바 있으며, 이번 문서는 그 도구를 자기 회사에 먼저 걸어 본 결과에 가까워요. 공개 문서에는 Cloudflare와 Ramp, 구글의 팀도 같은 방식을 살펴보고 있다고 적혀 있어요. 회사는 스킬과 보안 워크플로를 다룬 기술 블로그 게시글을 곧 공개하겠다고 예고했어요.

정리하면 오픈AI는 자기 시스템을 상대로 사고 대응 수준의 보안 스프린트를 돌렸고, 거기서 나온 수치와 실패까지 적어 참조 아키텍처로 내놨어요. 방어를 한 번의 점검이 아니라 계속 도는 루프로 바꾸자는 제안이고, 그 루프의 대부분을 에이전트가 돌리되 경계와 예외는 사람이 쥔다는 게 설계의 뼈대예요. 앞으로 볼 것은 두 가지예요. 예고한 기술 블로그가 스킬과 워크플로를 어디까지 공개하는지, 그리고 같은 방식을 따라 한 조직에서 오탐률과 롤백률이 비슷하게 나오는지예요.