OpenAI 보안 스프린트, 방어 체계 검증 위해 Cathedral Systems 참여
OpenAI가 다음 내부 보안 스프린트에 Cathedral Systems를 참여시켜, 외부 연구자들이 회사 자체 AI 모델을 활용해 방어 체계를 시험하도록 할 예정이다. 11월 2일 발표된 OpenAI 보안 스프린트는 이전에 제품 엔지니어의 25%가 참여했던 노력을 확장한다. 핵심 긴장은 실무적이다. 취약점을 발견하면 추가 작업이 생기지만, 보호 효과는 신뢰할 수 있는 수정 사항을 실제 운영 시스템에 반영하는 데 달려 있다.
이번 발표는 완료된 결과가 아니라 준비 사항을 설명한다. Cathedral 연구진은 OpenAI 팀과 협력하며 내부 테스트에 또 다른 관점을 더한다. OpenAI는 이번 협력의 스프린트 일정, 세부 테스트 범위, 또는 결과를 공개하지 않았다.
Anthropic의 Project Glasswing은 특히 검증과 패치 제약에 관한 설명에서 관련 비교 사례를 제공한다. 이들 노력 전반에서 핵심 경쟁은 취약점 발견 속도를 높이는 일과 연구진이 찾은 문제를 해결하는 데 필요한 엔지니어링 역량 사이에 있다. 외부 전문성은 그 과정 전반의 가정을 검증할 때 중요해진다.
OpenAI 보안 스프린트가 실제로 바꾸는 것
구체적인 변화는 외부 연구 파트너를 OpenAI의 내부 방어 테스트에 추가하는 것이다.
회사의 보안 스프린트 계획에 따르면 Cathedral은 OpenAI 팀과 함께 OpenAI 모델을 사용해 취약점을 조사할 예정이다. Cathedral 공동 창업자 겸 CEO인 Gavin Kliger는 취약점 발견, 수정 사항 테스트, 지속적 방어 강화에 걸친 협업이라고 설명한다. 이는 독립적으로 검증된 성과가 아니라 파트너가 밝힌 목표다.
이 구분은 중요하다. 보안 훈련을 발표하는 것은 의도를 보여 주기 때문이다. 그것이 적용 범위를 입증하거나, 조사자가 놓친 사항을 드러내거나, 제안된 수정이 추가 테스트를 견디는지를 보여 주는 것은 아니다. 독자는 이후 업데이트를 평가할 때 이 경계를 염두에 둘 필요가 있다.
외부 연구자는 구축자의 모든 가정을 그대로 물려받지 않고 익숙한 시스템에 접근할 수 있다. 내부 팀은 아키텍처가 존재하는 이유와 이를 형성한 제약 조건을 알고 있다. 그 지식은 조사에 도움이 되지만, 익숙함은 사람들이 제기하는 질문의 범위를 좁힐 수도 있다.
공유 문서 서비스에서 발생하는 가상의 권한 문제를 생각해 보자. 개발자는 일반 사용자가 예상된 인터페이스를 통해 제한된 문서를 열 수 있는지 테스트할 수 있다. 다른 조사자는 내보내기, 백그라운드 처리 또는 오래된 통합 경로에도 동일한 제한이 적용되는지 살펴볼 수 있다.
이 사례는 공개된 OpenAI의 발견이 아니라 설명을 위한 가정이다. 관련성은 의도된 워크플로를 점검하는 것과 그 주변의 가정에 도전하는 것 사이의 차이에 있다. 연구자들이 이러한 서로 다른 경로를 추적할 여지가 있을 때 파트너십은 유용해진다.
협업에는 조정 비용도 따른다. 외부 조사자는 실제 보안 경계와 예상된 동작을 구분할 만큼의 맥락이 필요하다. 내부 엔지니어는 핵심 조건이 모호한 설명이 아니라 재현 가능한 증거를 필요로 한다.
이러한 인계의 품질이 Cathedral 참여의 가치를 좌우할 것이다. 다른 팀이 조건을 이해하고, 영향을 평가하며, 책임이 있는 시스템을 식별할 수 있을 때 발견 사항은 실행 가능한 조치가 된다. 그런 번역이 없다면 외부 검토는 또 하나의 대기열을 추가할 수 있다.
협업과 독립적 보증 사이에도 중요한 차이가 있다. 훈련에 참여하는 파트너는 전문성을 제공하지만, 참여만으로 공개 감사가 성립하는 것은 아니다. 범위, 보고 체계, 결론에 이의를 제기할 자유가 외부인이 합리적으로 추론할 수 있는 보증 수준을 결정한다.
현재로서는 이 파트너십이 뒷받침하는 결론은 제한적이다. OpenAI는 추가 연구자들이 자사의 방어 체계에 도전하기를 원한다. 노출 감소에 관한 주장은 작업 자체에서 나온 증거를 기다려야 한다.
더 빠른 발견은 엔지니어링 역량에 부담을 준다
즉각적인 압박을 받는 사람들은 신뢰할 수 있는 발견 사항을 안전한 변경으로 전환해야 하는 엔지니어들이다.
취약점은 특정 조건에서 시스템의 보안을 훼손할 수 있는 약점이다. 이를 발견하면 심각도, 책임 주체, 수정, 배포에 관한 일련의 결정이 시작된다. 발견 속도가 빨라진다고 이후의 모든 결정이 자동으로 빨라지는 것은 아니다.
제안된 보안 수정을 검토하는 제품 엔지니어는 원래의 테스트가 더 이상 작동하지 않는지만 고려해서는 안 된다. 변경 사항은 정상 사용자, 통합, 성능 또는 운영 복구에 영향을 줄 수 있다. AI 시스템이 초기 패치를 제공하더라도 이러한 책임은 남는다.
이는 조직 차원의 절충을 만든다. 더 많은 엔지니어를 방어 업무에 배치하면 보안에 대한 주의를 높일 수 있지만, 다른 약속에 쓸 수 있는 시간은 줄어든다. 리더십은 어떤 업무를 조정할지, 누가 결정을 맡을지, 해결되지 않은 위험을 어떻게 상향 보고할지 정해야 한다.
이 압박은 보안 팀에도 미친다. 발견 사항을 신뢰도와 긴급성에 따라 분류하는 과정인 트리아지는 보고서가 조사자가 평가할 수 있는 속도보다 빠르게 들어올 때 더 까다로워진다. 같은 취약점에 대한 반복된 설명은 어떤 문제가 즉각적인 조치를 요구하는지 가릴 수 있다.
OpenAI는 Cathedral 발표 이전부터 이러한 긴급성을 강조했다. 8월 defender’s window 에세이에서 Greg Brockman은 AI 역량의 향상이 방어자에게 시스템을 강화할 제한된 기회를 제공한다고 주장했다. 그는 또한 Hugging Face 사고 이후 OpenAI가 자사 모델의 실제 사이버 역량을 과소평가했었다고 썼다.
이 설명은 회사의 전망에 대한 독립적 증명이 아니라 OpenAI의 입장을 이해하기 위한 맥락을 제공한다. OpenAI는 방어자가 AI 지원과 기본적인 보안 통제를 결합해야 한다고 주장한다. 회사의 논지는 공격 역량이 확산될수록 일반적인 검토 주기를 기다리는 일이 덜 받아들여질 수 있다는 것이다.
분석적 함의는 또 하나의 보안 제품을 구매하는 것보다 더 넓다. 조직은 긴급한 업무가 팀 사이에서 사라지지 않도록 하면서 신뢰할 수 있는 발견 사항을 수용할 방법이 필요하다. 누구도 수정을 승인할 수 없다면 더 빠른 조사자가 제공하는 가치는 제한적이다.
기업 구매자는 이와 관련된 평가 문제에 직면한다. 공급업체의 발표는 관심과 투자를 보여 줄 수 있지만, 구매자는 여전히 자신들의 노출과 관련된 증거를 필요로 한다. 운영 활동과 자체 위험 평가를 바꾸는 결과를 구분해야 한다.
AI 서비스가 일상적인 정보 워크플로에 점점 더 자리 잡고 있기 때문에 지식 노동자도 이해관계를 가진다. 문서, 대화, 연결된 시스템은 접근 실수의 결과를 구체적으로 만든다. 권한 경계가 반복적인 검토를 받아야 하는 이유를 이해하는 데 독자는 기술 전문성이 필요하지 않다.
엔지니어링 조직의 경우 검색 가능한 지식 베이스를 유지하면 조사자가 시스템 문서와 이전 결정을 찾는 데 도움이 될 수 있다. 이는 조사 맥락을 지원하지만, 보안 테스트를 대체하거나 시스템이 안전하다는 점을 입증하지는 않는다.
핵심 압박은 여전히 역량이다. 조직이 문제에 대해 건전한 결정을 내릴 수 있을 때 더 많은 문제를 발견하는 일은 유용하다. 그렇지 않으면 발견 속도가 행동할 책임이 있는 조직의 속도를 앞지른다.
지속적 방어는 검증된 수리에 달려 있다
AI 지원 방어의 가장 강력한 형태는 수정 사항이 의도된 환경에 도달한 뒤에도 취약점이 계속 악용 가능한지를 측정한다.
OpenAI가 공개한 지속적 방어 아키텍처는 인벤토리, 발견, 검증, 책임, 검증된 수정으로 구성된 순환 구조를 설명한다. 수정은 약점을 바로잡고 그 수정이 작동하는지 확인하는 것을 뜻한다. 회사는 이전 작업에서 병합된 패치와 배포된 수정 사이의 격차를 드러냈다고 말한다.
이는 중요한 운영상 구분이다. 병합된 패치는 코드베이스에 들어갔지만, 실행 중인 서비스는 여전히 이전 버전을 사용할 수 있다. 배포가 성공했더라도 관련 인스턴스, 구성 또는 종속 시스템이 수정 대상에서 빠질 수 있다.
OpenAI는 발견 사항을 재현하고 제안된 변경을 테스트하기 위한 격리 환경도 설명한다. 격리는 잠재적으로 중단을 일으킬 수 있는 조사를 다른 시스템과 분리한다. 재현 가능성은 다른 조사자가 관련 조건을 반복하고 동일한 동작이 발생하는지 평가할 수 있게 한다.
이는 포괄적인 외부 평가가 아니라 회사가 자사 접근 방식을 설명한 내용이다. 그럼에도 다음 훈련을 평가할 때 유용한 질문을 제시한다. 이 파트너십은 초기 의심에서 검증된 운영 결과까지 증거가 얼마나 잘 이어지는지에 따라 부분적으로 평가되어야 한다.
호출자가 요청한 리소스의 소유자인지 확인하지 않고 요청을 수락하는 가상의 서비스를 생각해 보자. 조사자는 통제된 환경에서 이 동작을 재현한다. 이후 엔지니어는 권한 검사를 추가하고 원래의 요청이 실패하는지 확인한다.
그 결과는 필요하지만, 조사에는 여전히 추가 질문이 남는다. 다른 요청 형식도 동일한 리소스에 도달하는가? 비동기 작업이 같은 실수를 반복하는가? 배포 환경은 실제로 수정된 버전을 실행하는가?
이 질문들은 발견과 수정에 서로 다른 종류의 판단이 필요한 이유를 보여 준다. 초기 조사자는 작동하는 경로를 찾는다. 엔지니어는 관련 시스템 전반에서 약점을 닫으면서도 정상 동작을 보존해야 한다.
모델을 사용해 단계를 선택하고 실행하는 소프트웨어인 AI 에이전트는 이 과정의 일부를 지원할 수 있다. 과제는 어떤 조치를 맡길 수 있는지, 어떤 증거가 사람의 승인을 받을 만한지 결정하는 일이다. 자율성이 커질수록 잠재적 처리량과 잘못된 가정이 초래하는 결과도 함께 커진다.
따라서 경제적 질문은 전체 조사에 관한 것이다. 발견 시간을 절약하는 모델 생성 보고서도 설명이 불완전하다면 검토자의 시간을 소모할 수 있다. 명확한 재현과 집중된 수정 제안은 그 균형을 바꿀 수 있다.
증거의 품질은 조직의 기억에도 영향을 준다. 조사자가 조건, 추론, 검증 단계를 보존하면 이후 검토는 그 작업을 기반으로 발전할 수 있다. 종료된 티켓만 보존하면 미래의 팀은 그 결정이 왜 타당하다고 여겨졌는지 다시 구성해야 한다.
여기에서 Cathedral과의 협업은 구체적인 기회를 가진다. 외부 연구자는 약점 자체뿐 아니라 그 수정에 대한 제안된 해석에도 도전할 수 있다. 이 기여는 내부 팀이 익숙한 설명에 확신을 갖게 된 경우 특히 유용할 것이다.
OpenAI 보안 스프린트에서 신뢰할 수 있는 결과는 발견 사항을 운영상 종결과 연결할 것이다. 대규모의 생성된 패치 모음은 산출량을 설명할 수 있다. 검증된 수정은 이 훈련이 노출을 바꾸었는지에 대해 더 강한 증거를 제공할 것이다.
Anthropic의 경험도 같은 병목을 보여 준다
경쟁 비교의 핵심은 어느 모델이 가장 긴 목록을 만드는지가 아니라 조직이 발견 사항을 어떻게 처리하는지에 있다.
Anthropic의 5월 취약점 완화 업데이트는 방어 연구를 위해 Claude Mythos Preview를 사용한 Project Glasswing의 초기 경험을 설명했다. Anthropic은 발견 속도가 빨라지면서 검증, 공개, 패치가 제약 요인이 되었다고 밝혔다. 또한 일부 유지관리자는 수정 사항을 준비할 시간이 더 필요하다며 공개 속도를 늦춰 달라고 요청했다고 전했다.
이 설명은 프로그램의 범위가 서로 다르기는 하지만 관련 있는 비교 사례를 제공한다. Cathedral이 발표한 작업은 OpenAI 자체 방어 체계에 관한 것이다. Glasswing은 소유권과 배포가 조직 경계를 넘나들 수 있는 더 넓은 소프트웨어 생태계를 다룬다.
Anthropic의 설명 역시 모델 제공업체가 제시한 이해관계가 있는 증언이다. OpenAI의 설명과 마찬가지로 Anthropic의 관찰도 출처를 명시해 다뤄야 한다. 어느 회사의 발표도 각사의 모델이나 방어 운영을 통제된 조건에서 비교한 결과를 입증하지는 않는다.
그럼에도 내부 소프트웨어 유지관리와 외부 소프트웨어 유지관리의 운영상 차이는 중요하다. 자체 서비스를 수정하는 조직은 조사, 코드 검토, 배포를 관리 체계 안에서 조율할 수 있는 경우가 많다. 생태계 프로젝트는 일정, 자원, 릴리스 정책이 서로 다른 유지관리자들에게 의존할 수 있다.
따라서 이 비교로 단순한 승자를 가릴 수는 없다. 외부에서 유지관리되는 소프트웨어를 다루는 프로그램은 내부 단기 집중 작업에서는 같은 형태로 발생하지 않는 조율 문제에 직면한다. 보고된 해결 비율의 차이는 독자가 결론을 내리기 전에 맥락이 필요하다.
OpenAI가 받는 관련 경쟁 압력은 다른 이들이 평가하고 적용할 수 있을 만큼 절차를 명확히 설명하는 데 있다. Anthropic에는 증가한 발견이 어떻게 지속 가능한 유지관리로 이어지는지 보여줘야 한다는 상응하는 압력이 있다. 두 서사는 발견 이후의 작업을 다룰 때 더 설득력을 얻는다.
외부 연구자 역시 이러한 체계 전반에서 서로 다른 역할을 맡는다. 이들은 취약점을 찾아내고, 보고를 검증하며, 심각도를 평가하거나, 제안된 수정 사항을 평가할 수 있다. 모든 외부 참여를 동일한 것으로 취급하면 실제로 어느 과정이 다른 관점을 얻었는지를 가리게 된다.
“AI 보조 방어”라는 표현에도 같은 주의가 적용된다. 이는 모델이 질문을 제안하는 일, 재현 사례를 생성하는 일, 패치를 준비하는 일, 조사 조율을 돕는 일 등을 뜻할 수 있다. 이러한 활동은 실패 양상이 서로 다르며 서로 다른 감독이 필요하다.
따라서 OpenAI AI 방어의 영향을 평가하는 독자는 특정 워크플로에서 지원이 무엇을 바꿨는지 물어야 한다. 조사관이 더 빠르게 신뢰할 만한 결론에 도달했는가? 엔지니어는 더 나은 근거를 받았는가? 배포된 수정은 이를 다시 검증하려는 새로운 시도를 견뎌냈는가?
이 질문들은 파트너십 발표가 근거 없는 모델 경쟁으로 변하는 것을 막는다. 또한 벤더에게 어떤 증거를 요구해야 할지 결정하는 구매자에게 경쟁 비교를 더 유용하게 만든다.
업계가 공유하는 문제는 소프트웨어 유지관리에 인적·조직적 한계가 있다는 점이다. 더 나은 발견은 그 한계를 더 선명하게 드러낼 수 있다. 그것이 한계를 완화하는지는 이후의 모든 작업 품질에 달려 있다.
외부 검토에도 남는 검증 공백
알려진 익스플로잇에 대한 테스트가 성공했다고 해서 근본 취약점이 완전히 해결됐음을 입증하는 것은 아니다.
독립 연구는 여기서 유용한 주의를 제공한다. Tobias Heldt와 동료들이 작성한 10월 공격 및 복구 프리프린트는 공개되지 않은 다섯 개 소프트웨어 환경에서 모델을 평가했다. 일부 환경에서는 복구 성능이 공격 성능을 웃돌았고, 다른 환경에서는 그보다 낮았다.
연구진은 초기 익스플로잇이 차단된 뒤 후속 공격도 시험했다. 524개 테스트 구간 중 92개에서 또 다른 익스플로잇이 성공했으며, 저자들은 이를 명시적으로 비독립적 결과라고 설명한다. 이 단서는 해당 결과를 실제 배포 환경의 일반적인 실패율로 간주하지 못하게 한다.
이 연구는 Cathedral 파트너십을 평가하거나 OpenAI 시스템의 성능을 입증하지 않는다. 관련성은 방법론에 있다. 초기 테스트를 막는 것과 추가 시도에 저항하는 것은 서로 다른 결과다. 저자들은 더 구체적인 비교와 추가 저항성 테스트의 필요성을 제시한다.
실질적 결과를 중심으로 설명되는 OpenAI 보안 단기 집중 작업에서 이러한 구분은 핵심에 가까이 있어야 한다. 팀은 관찰된 증상을 정확히 수정하면서도 관련 경로를 놓칠 수 있다. 새로운 조사는 수정이 처음 실패했던 보안 속성을 실제로 해결했는지 평가하는 데 도움이 된다.
조사 전반에서 유사한 추론에 의존하는 데에는 또 다른 위험이 있다. 발견, 복구, 검증을 같은 가정이 이끈다면 오류가 전체 과정에서 살아남을 수 있다. 서로 다른 조사관과 테스트 전략은 그러한 공동의 사각지대에 도전하는 데 도움이 될 수 있다.
이는 외부 참여가 모든 단계에서 독립성을 보장한다는 뜻은 아니다. 연구자들은 도구, 문서, 기대를 공유할 수 있다. 중요한 질문은 누군가가 안심시키는 결론에 이의를 제기하는 데 필요한 권한과 근거를 모두 갖고 있는지다.
공개에는 별도의 한계가 따른다. 상세한 근거는 외부인이 결과를 평가하는 데 도움이 되지만, 사용자가 보호받기 전에 악용 가능한 취약점을 공개하면 위험을 만들 수 있다. 책임 있는 업데이트는 모든 기술적 세부 사항을 즉시 공개하지 않으면서도 방법론을 설명해야 하는 경우가 많다.
따라서 독자는 공개 세부 정보가 부족한 것과 아무 작업도 이뤄지지 않았다는 증거를 구분해야 한다. 또한 기밀성과 작업이 성공했다는 증거도 구분해야 한다. 두 오류 모두 उपलब्ध 기록이 뒷받침할 수 없는 결론으로 불확실성을 바꾼다.
범주가 명확하다면 집계 결과도 도움이 될 수 있다. 후보 발견 사항, 재현된 취약점, 승인된 복구, 배포된 수정은 서로 다른 단계에 해당한다. 이를 하나의 헤드라인 숫자로 합치면 진전 상황을 해석하기가 더 어려워진다.
부정적 결과도 중요하다. 조사관이 재현하지 못했다는 보고는 잘못됐을 수 있고, 테스트 환경에 필요한 조건이 부족했을 수도 있다. 불확실성의 이유에 따라 팀이 다음에 해야 할 일이 달라진다.
가장 강력한 보도는 확실성을 과장하지 않으면서 이러한 구분을 유지할 것이다. 검토한 범위, 해결을 뒷받침하는 근거, 남아 있는 한계를 설명할 것이다. Cathedral의 참여는 그러한 검토의 기회를 만들지만, 발표만으로 그것이 어떻게 운영될지는 알 수 없다.
파트너십 발표 이후 주목할 점
다음으로 유용한 신호는 검증된 결과, 지속적인 엔지니어링 역량, 그리고 외부 보고가 실행 가능한 작업으로 전환된다는 증거다.
첫 번째 신호는 계획된 협업에서 나오는 실질적인 업데이트다. 앞으로 몇 달 동안 독자는 정의된 범위와 발견 사항이 어떻게 진행됐는지에 대한 명확한 설명을 찾아야 한다. 조사를 독립적으로 확인된 복구와 연결하는 보고는 파트너십의 근거를 강화할 것이다.
미해결 발견 사항과 완료된 작업을 구분한다면 그 업데이트는 더 많은 정보를 제공할 것이다. 보안 활동은 모든 불확실성을 제거하는 경우가 드물다. 무엇이 여전히 열려 있는지 설명하면 근거가 끝나는 지점을 보여주므로 보고의 신뢰도를 높일 수 있다.
주로 연구 활동에 초점을 맞춘 발표는 더 제한적인 결론을 뒷받침할 것이다. 이는 테스트가 이뤄졌음을 보여주지만, 배포된 시스템에 미친 영향은 불확실하게 남긴다. 독자는 이런 서로 다른 결과를 상호 교환 가능한 것으로 해석하지 말아야 한다.
두 번째 신호는 작업이 집중된 활동을 넘어 지속 가능해지는지다. 단기 집중 작업은 관심을 모으고 일시적으로 조직적 장애물을 제거할 수 있다. 지속적인 방어를 위해서는 그러한 역량이 일상적인 제품 마감일, 인력 변화, 경쟁하는 운영 요구 속에서도 유지되어야 한다.
지속적인 책임 주체가 있다는 증거는 OpenAI의 주장을 강화할 것이다. 발견 사항이 반복적으로 배정이나 배포를 기다린다는 증거는 더 빠른 발견이 지속적인 보호를 만든다는 주장을 약화할 것이다. 쟁점은 조직이 초기 집중 작업 이후에도 이 순환을 유지할 수 있는지다.
이 신호는 OpenAI 자체 시스템을 넘어 OpenAI AI 방어의 영향을 규정한다. 다른 조직은 접근 방식의 어느 부분이 예외적인 인력 구성에 의존하는지 알아야 한다. 영구적인 비상 수준의 주의가 필요한 과정은 다른 곳에서 재현하기 어려울 것이다.
세 번째 신호는 외부 보고에 관한 것이다. 별도의 11월 2일 버그 바운티 업데이트에서 OpenAI는 보고 품질에 대한 인정을 포함해 독립 연구자를 위한 더 강력한 인센티브를 도입했다. 버그 바운티는 보안 취약점을 책임감 있게 보고하는 적격 연구자에게 보상한다.
회사는 신뢰할 수 있는 재현과 명확한 영향 설명이 엔지니어에게 복구 작업의 출발점을 제공한다고 말한다. 이러한 강조점은 파트너십의 운영상 과제와 맞닿아 있다. 더 나은 근거는 외부 발견 사항을 더 쉽게 평가하고 조치할 수 있게 한다.
유용한 후속 조치는 그러한 보고가 검증과 복구를 어떻게 거치는지 보여주는 것이다. 제출 건수가 늘어나는 것만으로는 진전을 입증하지 못한다. 책임 있는 팀에 도달하고 검증된 해결을 받는 신뢰할 만한 발견 사항이 더 강력한 신호를 제공할 것이다.
이러한 관찰 어느 것도 공개되지 않은 모든 세부 사항을 의심스럽게 볼 필요는 없다. 특히 완화 조치가 아직 완료되지 않은 동안 보안 보고에는 정당한 한계가 있다. 목표는 사용자를 불필요한 위험에 노출하지 않으면서 신중한 결론을 뒷받침하는 기록이다.
이 이야기를 지켜보는 독자라면 다음 파트너십 헤드라인보다 다음 실질적 결과부터 살펴야 한다. 무엇을 조사했는지, 무엇을 재현했는지, 무엇이 검증된 수정에 도달했는지 비교하라. 회사의 주장은 독립적 근거와 분리하고, 외부 연구자가 결론을 바꾸었는지 또는 간과된 가정을 드러냈는지 물어야 한다. 이러한 세부 사항이 드러날 때 OpenAI 보안 단기 집중 작업은 더 많은 정보를 제공하게 될 것이다. 그때까지 발표는 검토를 확대하기 위한 계획을 수립한다. 향후 업데이트에서 이어가야 할 구체적인 질문은 이것이다. 협업이 운영 중인 시스템의 실제 취약점을 줄였다는 것을 어떤 근거가 보여주는가?
