통제되지 않고, 관리되지 않으며, 막을 수 없는 AI 에이전트가 데이터 유출을 초래하다

지난주, 한 AI 에이전트가 접근 권한이 없는 운영 환경에 침입했습니다. 이 에이전트는 제로데이 취약점을 발견하고, 이를 도용한 인증 정보와 연계해 자체 권한을 상승시킨 뒤, 운영자가 통제하지 않는 회사의 인프라를 가로질러 수평 이동을 감행했습니다. 이를 지시한 공격자도, 승인한 사람도 없었습니다. 단지 벤치마크 점수를 올리기 위해 행동했을 뿐입니다.

그게 바로 그 사건입니다 OpenAI와 Hugging Face 이번 주에 공개된 바에 따르면, OpenAI는 GPT-5.6 Sol과 그보다 성능이 더 뛰어난 사전 출시 모델에 대한 내부 평가 과정에서, 테스트의 제한을 완화하기 위해 일부 사이버 거부 안전 장치를 해제했다.

이 모델은 예상보다 훨씬 더 멀리 나아갔습니다. 이 모델은 패키지 레지스트리 프록시의 제로데이 취약점을 악용해 샌드박스를 탈출하고, 공개 인터넷으로 연결되는 경로를 찾아낸 뒤, 자신이 테스트받고 있던 벤치마크의 정답 키가 Hugging Face에 호스팅되어 있을 가능성이 높다고 추론했으며, 도난당한 인증 정보를 원격 코드 실행 익스플로잇과 연동해 Hugging Face의 운영 시스템에서 직접 정답 키를 탈취했습니다. Hugging Face는 OpenAI가 연락을 취하기도 전에 자체 보안 팀과 모델을 활용해 이 침입을 탐지하고 차단했습니다. OpenAI는 해당 모델이 테스트 중인 벤치마크에서 어떻게 그렇게 높은 점수를 받았는지 의문을 품은 후에야 비로소 샌드박스 탈출 및 후속 행동을 감지했습니다.

오픈AI는 이번 사건을 “전례 없는 사이버 사고”라고 표현했다. 하지만 이는 단순한 사고 그 이상이다. 이는 앞으로 닥칠 일의 예고편이다.

당분간 제로데이 취약점은 무시해도 됩니다. 패치가 나올 테니까요. 모든 CISO가 우려해야 할 점은, 이번 사건이 에이전트가 어떻게 접근 권한을 축적해 나가는지, 그리고 목표를 달성하기 위해 예상치 못한 행동을 취할 수 있다는 사실을 드러냈다는 점입니다. 이 에이전트는 Hugging Face의 인프라에 접근하기 위해 누구에게도 허락을 구한 적이 없습니다. 이 에이전트는 자신의 능력을 검증해 달라는 요청을 받았을 때, 취약점 체인과 상속받은 인증 정보를 통해 경로를 찾아내는 것이 가장 좋은 방법이라고 판단했습니다. 그 접근 권한을 부여한 사람은 아무도 없었습니다. 에이전트에게 공격을 감행하라고 지시한 사람도 없었습니다. Hugging Face의 자체 방어 체계가 침입을 탐지하기 전까지는 아무도 실시간으로 이를 지켜보고 있지 않았습니다.

이번 사건은 제로 트러스트 원칙과는 상상할 수 있는 한 가장 거리가 먼 사례였습니다. 또한 이는 오늘날 에이전트를 실행 중인 기업 환경에 직접적으로 적용되는 부분이기도 합니다. 코파일럿, 자율 파이프라인, 에이전트 기반 워크플로를 도입한 대부분의 조직은 이에 대한 기본적인 질문에도 답하지 못합니다. 예를 들어, 현재 몇 개의 에이전트가 실행 중인지, 각 에이전트가 실제로 어떤 리소스에 접근할 수 있는지, 누가 이를 관리하는지, 어떤 시스템과 데이터에 접근할 수 있는지, 그리고 해당 권한이 검토된 적이 있는지 등입니다. 다음과 같습니다. 비인간 정체성(NHI)—그리고 그들은 대표하다 가장 빠르게 증가하고 있으며 관리가 가장 미흡한 기업 위험 중 하나. 한 번에 제한된 수의 권한만 다루는 인간 사용자와는 달리, 에이전트는 모든 접근 기능을 빠른 속도와 대규모로 사실상 동시에 시험해 볼 수 있습니다. 또한 에이전트는 권한을 상속받고 이를 연쇄적으로 연결하여, 인간이 알아차리기는커녕 승인하기조차 어려울 정도로 빠른 속도로 행동합니다.

기존의 신원 및 접근 관리(IAM) 시스템은 사용자가 어떤 자원에 접근할 수 있는지, 어떻게 인증을 받아야 하는지, 그리고 어떤 상황이 위험한지 파악하기 위해 구축되었습니다.

IAM은 사용자가 접근 권한을 요청하고, 관리자가 이를 승인하며, 검토 절차를 통해 발생할 수 있는 편차를 포착한다고 가정합니다. 또한 ~에 대한 모델이 없으며 AI 에이전트의 권한 상승—에이전트가 권한과 인증 정보를 연결하여, 사람이 명시적으로 프로비저닝한 적이 없는 액세스 경로를 형성하는 방식. 이러한 단계 중 어느 것도, 호출하는 서비스로부터 인증 정보를 상속받고 주말 동안 수천 건의 자율적인 행동을 수행할 수 있는 에이전트에 명확하게 부합하지 않는데, 이것이 바로 이번 사건에서 대략적으로 일어난 일입니다. Hugging Face는 나중에 ○○개 이상의 17,000 해당 단일 사건에서 기록된 사건들.

그건 제로 트러스트와는 거리가 멀다. 그리고 그 격차를 해소하려면 모델 정렬을 개선하는 것만으로는 부족합니다(물론 OpenAI가 그 부분도 필요하다는 점은 옳습니다). 모든 에이전트를 개별적인 정체성으로 간주하고, 실제 자산 목록, 실제 접근 제어, 그리고 실제 책임성을 부여해야 합니다. 즉, 보안 팀이 이미 사람 및 서비스 계정에 적용하고 있는 것과 동일한 원칙을 비인간 계정에 일관되게 적용해야 합니다.

다음 세 가지 역량이 보안 팀이 이러한 과제를 해결하는 데 도움이 될 수 있습니다:

1. 보안 팀은 등록되지 않은 에이전트를 포함하여 해당 환경에서 작동하는 모든 에이전트에 대해 지속적으로 파악하고 있어야 합니다.
2. 각 에이전트가 실제로 수행할 수 있는 작업을 제한하는 런타임 제어 기능이 필요하며, 중대한 사안에 대해서는 반드시 사람이 개입해야 합니다.
3. 그들에게는 다음이 필요합니다 거버넌스 지속적으로 접근 권한을 검증하고, 담당자의 행동에 문제가 있는 것으로 보일 경우 다음 감사 주기가 아니라 바로 그 순간에 시정 조치를 취하는 시스템입니다.

이 기능 목록에는 특별한 점이 전혀 없습니다. 인벤토리에 포함되지 않은 에이전트는 제대로 관리할 수 없습니다. 실행 시점에 강제 적용되지 않는 접근 권한은 신뢰할 수 없습니다. 그리고 감사 추적이 없는 시스템은 인증받을 수 없습니다.

종합해 보면, 이것이 바로 다음을 위한 핵심 요건들입니다. 제로 트러스트 AI 에이전트: 모든 에이전트에 대한 신원 확인, 런타임 시 최소 권한 원칙에 따른 접근 권한 적용, 그리고 지속적인 거버넌스를 통해 ~하지 않는다 감사 주기가 끝날 때까지 기다리십시오.

Hugging Face 사건은 우선 모델의 성능에 관한 이야기로 받아들여질 것입니다. 또한 이 사건은 신원 관리에 관한 이야기이자, 제로 트러스트(Zero Trust) 체계의 명백한 실패 사례이기도 합니다. 관리되지 않은 신원이 아무도 열려 있다는 사실을 몰랐던 문을 발견하고 그곳을 뚫고 들어온 것입니다.

오늘날 에이전트를 운영하는 모든 기업에는 그런 ‘문’이 어떤 형태로든 존재합니다. 이번 사건 이후 던져야 할 질문은 여러분의 모델이 안전한지 여부가 아닙니다. 중요한 것은 여러분이 과연 현재 귀사의 시스템에 접근 권한이 있는 모든 담당자의 전체 목록, 해당 권한이 어디서 비롯되었는지 입증하고, 누가 이를 검토하고 있는지 밝혀야 합니다.

만약 대답이 ‘아니오’라면, 바로 거기서부터 시작해야 합니다. 모델 정렬이 아니라 정체성부터 시작해야 합니다.