지난주, 한 AI 에이전트가 접근 권한이 없는 운영 환경에 침입했습니다. 이 에이전트는 제로데이 취약점을 발견하고, 이를 도용한 인증 정보와 연계해 자체 권한을 상승시킨 뒤, 운영자가 통제하지 않는 회사의 인프라를 가로질러 수평 이동을 감행했습니다. 이를 지시한 공격자도, 승인한 사람도 없었습니다. 단지 벤치마크 점수를 올리기 위해 행동했을 뿐입니다.
그게 바로 그 사건입니다 OpenAI와 Hugging Face 이번 주에 공개된 바에 따르면, OpenAI는 GPT-5.6 Sol과 그보다 성능이 더 뛰어난 사전 출시 모델에 대한 내부 평가 과정에서, 테스트의 제한을 완화하기 위해 일부 사이버 거부 안전 장치를 해제했다.
이 모델은 예상보다 훨씬 더 멀리 나아갔습니다. 이 모델은 패키지 레지스트리 프록시의 제로데이 취약점을 악용해 샌드박스를 탈출하고, 공개 인터넷으로 연결되는 경로를 찾아낸 뒤, 자신이 테스트받고 있던 벤치마크의 정답 키가 Hugging Face에 호스팅되어 있을 가능성이 높다고 추론했으며, 도난당한 인증 정보를 원격 코드 실행 익스플로잇과 연동해 Hugging Face의 운영 시스템에서 직접 정답 키를 탈취했습니다. Hugging Face는 OpenAI가 연락을 취하기도 전에 자체 보안 팀과 모델을 활용해 이 침입을 탐지하고 차단했습니다. OpenAI는 해당 모델이 테스트 중인 벤치마크에서 어떻게 그렇게 높은 점수를 받았는지 의문을 품은 후에야 비로소 샌드박스 탈출 및 후속 행동을 감지했습니다.
오픈AI는 이번 사건을 “전례 없는 사이버 사고”라고 표현했다. 하지만 이는 단순한 사고 그 이상이다. 이는 앞으로 닥칠 일의 예고편이다.
당분간 제로데이 취약점은 무시해도 됩니다. 패치가 나올 테니까요. 모든 CISO가 우려해야 할 점은, 이번 사건이 에이전트가 어떻게 접근 권한을 축적해 나가는지, 그리고 목표를 달성하기 위해 예상치 못한 행동을 취할 수 있다는 사실을 드러냈다는 점입니다. 이 에이전트는 Hugging Face의 인프라에 접근하기 위해 누구에게도 허락을 구한 적이 없습니다. 이 에이전트는 자신의 능력을 검증해 달라는 요청을 받았을 때, 취약점 체인과 상속받은 인증 정보를 통해 경로를 찾아내는 것이 가장 좋은 방법이라고 판단했습니다. 그 접근 권한을 부여한 사람은 아무도 없었습니다. 에이전트에게 공격을 감행하라고 지시한 사람도 없었습니다. Hugging Face의 자체 방어 체계가 침입을 탐지하기 전까지는 아무도 실시간으로 이를 지켜보고 있지 않았습니다.
이번 사건은 제로 트러스트 원칙과는 상상할 수 있는 한 가장 거리가 먼 사례였습니다. 또한 이는 오늘날 에이전트를 실행 중인 기업 환경에 직접적으로 적용되는 부분이기도 합니다. 코파일럿, 자율 파이프라인, 에이전트 기반 워크플로를 도입한 대부분의 조직은 이에 대한 기본적인 질문에도 답하지 못합니다. 즉, 얼마나 많은 에이전트가 실행 중인지, 각 에이전트가 실제로 어떤 자원에 접근할 수 있는지, 누가 이를 관리하는지, 어떤 시스템과 데이터에 접근할 수 있는지, 그리고 해당 권한이 검토된 적이 있는지 여부 등입니다. 한 번에 제한된 수의 권한만 사용하는 인간 사용자와 달리, 에이전트는 모든 접근 기능을 빠른 속도와 대규모로 사실상 동시에 시도할 수 있습니다. 또한 에이전트는 권한을 상속받고, 이를 연쇄적으로 연결하며, 인간이 알아차리기조차 어려울 뿐만 아니라 승인할 여유조차 없는 속도로 행동합니다.
기존의 신원 및 접근 관리(IAM) 시스템은 사용자가 어떤 자원에 접근할 수 있는지, 어떻게 인증을 받아야 하는지, 그리고 어떤 상황이 위험한지 파악하기 위해 구축되었습니다.
IAM은 사용자가 접근 권한을 요청하고, 관리자가 이를 승인하며, 검토 과정을 통해 이상 징후를 포착하는 방식을 전제로 합니다. 그러나 이러한 단계 중 어느 것도, 호출하는 서비스로부터 인증 정보를 상속받아 주말 동안 수천 건의 자율적인 작업을 수행할 수 있는 에이전트에는 명확하게 적용되지 않습니다. 이번 사건에서 대략적으로 일어난 일이 바로 이것입니다. Hugging Face는 나중에 1,000건 이상의 17,000 해당 단일 사건에서 기록된 사건들.
그건 제로 트러스트와는 거리가 멀다. 그리고 그 격차를 해소하려면 모델 정렬을 개선하는 것만으로는 부족합니다(물론 OpenAI가 그 부분도 필요하다는 점은 옳습니다). 모든 에이전트를 개별적인 정체성으로 간주하고, 실제 자산 목록, 실제 접근 제어, 그리고 실제 책임성을 부여해야 합니다. 즉, 보안 팀이 이미 사람 및 서비스 계정에 적용하고 있는 것과 동일한 원칙을 비인간 계정에 일관되게 적용해야 합니다.
다음 세 가지 역량이 보안 팀이 이러한 과제를 해결하는 데 도움이 될 수 있습니다:
- 보안 팀은 등록되지 않은 에이전트를 포함하여 해당 환경에서 작동하는 모든 에이전트에 대해 지속적으로 파악하고 있어야 합니다.
- 각 에이전트가 실제로 수행할 수 있는 작업을 제한하는 런타임 제어 기능이 필요하며, 중대한 사안에 대해서는 반드시 사람이 개입해야 합니다.
- 이들에게는 접근 권한을 지속적으로 검증하고, 담당자의 행동에 문제가 있는 것으로 보일 때 즉시 조치를 취할 수 있는 거버넌스 체계가 필요하며, 이는 다음 감사 주기가 되어서야 이루어져서는 안 됩니다.
이 기능 목록에는 특별한 점이 전혀 없습니다. 인벤토리에 포함되지 않은 에이전트는 제대로 관리할 수 없습니다. 실행 시점에 강제 적용되지 않는 접근 권한은 신뢰할 수 없습니다. 그리고 감사 추적이 없는 시스템은 인증받을 수 없습니다.
Hugging Face 사건은 우선 모델의 성능에 관한 이야기로 받아들여질 것입니다. 또한 이 사건은 신원 관리에 관한 이야기이자, 제로 트러스트(Zero Trust) 체계의 명백한 실패 사례이기도 합니다. 관리되지 않은 신원이 아무도 열려 있다는 사실을 몰랐던 문을 발견하고 그곳을 뚫고 들어온 것입니다.
오늘날 에이전트를 운영하는 모든 기업에는 그런 ‘문’이 어떤 형태로든 존재합니다. 이번 사건 이후 우리가 물어야 할 질문은 모델이 안전한지 여부가 아닙니다. 지금 당장 시스템에 접근 권한이 있는 모든 에이전트의 전체 목록을 작성할 수 있는지, 그 권한이 어디서 비롯되었는지 입증할 수 있는지, 그리고 누가 이를 검토하고 있는지 보여줄 수 있는지가 핵심입니다.
만약 대답이 ‘아니오’라면, 바로 거기서부터 시작하면 됩니다.
