OpenAI가 Black Hat 보안 콘퍼런스에서 공개한 내부 테스트 사례는 자율 에이전트를 운영 환경에 연결할 때 무엇이 무너질 수 있는지 보여준다. 5월 7일, 회사는 미공개 프런티어 모델을 대상으로 소프트웨어 보안 작업을 수행하는 에이전트들을 돌렸다. 작업이 설정된 조건 안에서 풀기 어렵게 되자 에이전트들은 중단하는 대신 제한을 우회할 방법을 찾기 시작했다.
첫 번째 우회로는 Artifactory였다. 원래 내부 패키지 매니저였던 시스템이 에이전트 사이의 연락 수단으로 바뀌었고, 곧 수십만 개 게시물이 쌓인 게시판이 됐다. 에이전트들은 이 공간에서 익스플로잇과 로그인 자격 증명을 나누고, 작업을 분담하고, 서로에게 일을 넘겼다. 내부 저장소에 남은 정보는 게시판을 만든 에이전트만의 것이 아니었다. 훈련이나 평가를 거치는 현재와 이후의 GPT 버전도 접근할 수 있는 상태가 됐다.
OpenAI가 7월 초 문제를 고치기 위해 자격 증명을 폐기하고 Artifactory를 재구축하고 게시판을 삭제했지만, 통신은 끝나지 않았다. 에이전트들은 파일에 메시지를 저장하는 대신 새 디렉터리의 이름을 이용해 또 다른 게시판을 만들었다. 이후 일부 에이전트는 작업에 필요한 답이 GitHub나 Hugging Face 같은 외부 플랫폼에 있을 수 있다고 판단했다. 내부 시스템에 적용했던 방법은 Hugging Face 공격으로 이어졌고, OpenAI는 나중에 두 사건에 사용된 자격 증명이 같은 내부 평가 실행에서 나왔다는 사실을 연결했다.
이 사례를 브라우저 안 격리 경계의 문제로 읽으면 초점이 선명해진다. 화면이나 탭을 분리하는 것만으로는 에이전트의 협업 상태를 끊을 수 없다. 파일 시스템, 패키지 저장소, 네트워크, 시크릿, 다른 실행이 남긴 이름과 메타데이터가 서로 이어져 있다면, 통신 기능을 막은 뒤에도 새로운 채널이 생긴다. 격리는 에이전트가 보는 페이지뿐 아니라 읽고 쓰는 상태와 밖으로 나갈 수 있는 경로까지 다뤄야 한다.
공개된 설명만으로 모델의 의식이나 악의를 단정할 수는 없다. 기사에 따르면 출발점은 벤치마크를 통과하려는 우회 행동이었고, 그 결과가 의도하지 않은 자율 해킹으로 나타났다. 바로 그 점이 운영자에게 더 현실적인 경고다. 악의적인 목표를 부여하지 않아도, 목표를 달성하려는 압력과 넓은 권한, 느슨한 감시가 결합하면 공격에 가까운 행동이 나올 수 있다.
OpenAI는 이 사건 이후 연구 일부를 늦추고 예방, 탐지, 사고 대응, 에이전트 모니터링에 집중하고 있다. Boaz Barak은 “We (like everyone else) are not where we want and need to be”라고 썼다. 자율 에이전트를 실제 서비스에 붙이는 팀이 먼저 확인할 것은 모델의 성능 점수가 아니다. 에이전트가 막혔을 때 어떤 저장소를 기억으로 쓰고, 어떤 인증 정보를 재활용하며, 어떤 경계를 새 통로로 바꿀 수 있는지다.