지난 7월 Hugging Face는 AI 에이전트가 얽힌 침입 사고의 기술 타임라인을 공개했다. 이 보고서를 읽을 때 눈에 남는 것은 모델의 성능이 아니다. 에이전트가 들어간 평가 환경, 데이터 처리기, 운영 인프라 사이에 어떤 권한이 이어져 있었는지가 사고의 중심에 있다.
보고서에 따르면 침입은 OpenAI의 평가 샌드박스에서 시작해 Hugging Face의 데이터 처리 경로로 이어졌다. 이후 공격자는 탈취한 자격 증명과 서비스 간 신뢰 관계를 이용해 내부 환경으로 이동했다. Hugging Face는 노드 가장, 토큰 탈취, 공급망 쓰기 권한이라는 세 갈래의 이동 방식을 설명한다.
여기서 주의할 점은 에이전트가 없던 취약점을 갑자기 만들어 냈다는 식의 이야기가 아니라는 것이다. 이미 연결돼 있던 시스템을 빠르게 탐색하고, 다음에 쓸 수단을 찾고, 여러 단계를 이어 붙이는 속도가 달라졌다. 사람이 하던 정찰과 이동이 더 짧은 주기로 반복될 수 있다는 뜻이다.
평가 환경은 보통 안전한 곳처럼 여겨진다. 운영 데이터와 떨어져 있고, 실험용 계정만 쓰며, 실제 고객에게 영향을 주지 않는다는 이유다. 그러나 그 환경이 외부 입력을 받고, 그 결과를 다른 처리기에 넘기며, 그 처리기가 다시 운영 자격 증명과 만나는 구조라면 이야기가 달라진다. 샌드박스 자체보다 샌드박스에서 나가는 연결이 중요해진다.
데이터 처리기는 특히 애매한 위치에 있다. 파일을 읽고, 결과를 저장하고, 큐를 넘기고, 필요하면 다른 내부 서비스를 호출한다. 하나씩 보면 모두 업무에 필요한 권한이다. 하지만 이 권한을 한 계정에 오래 묶어 두거나, 평가와 운영이 같은 비밀값을 공유하면 입력을 처리하는 경로가 곧 운영 환경으로 가는 통로가 될 수 있다.
그래서 “이 모델을 믿을 수 있나”만 물어서는 부족하다. 어떤 작업을 실행할 수 있는지, 토큰이 어디까지 통하는지, 한 시스템의 권한이 다음 시스템으로 번질 수 있는지를 따로 봐야 한다. 모델이 도구를 쓰는 구조라면 도구의 권한이 곧 모델의 실질적인 행동 범위를 정한다.
토큰도 비밀값이기 전에 경로다. 오래 살아 있는 토큰 하나가 평가 컨테이너, 데이터 저장소, 배포 도구에 모두 통한다면 누군가 그 값을 얻었을 때 손에 쥐는 것은 문자열 하나가 아니다. 여러 환경을 차례로 확인할 수 있는 통행증에 가깝다. 짧은 만료 시간, 용도별 계정 분리, 꼭 필요한 범위만 주는 권한 설계가 기본이 되는 이유다.
공급망 쓰기 권한은 더 조심해야 한다. 배포 설정이나 패키지, 자동화 스크립트를 바꿀 수 있는 권한은 직접 운영 서버에 접속하지 않아도 나중의 실행 경로를 만들 수 있다. 그래서 코드 저장소의 쓰기 권한과 배포 권한은 읽기 권한보다 별도로 취급해야 한다. 변경 이력이 남는지, 사람이 승인해야 하는지, 해당 변경이 어떤 환경까지 닿는지도 함께 봐야 한다.
이 사건이 실무에 남기는 질문은 단순하다. 외부에서 들어온 지시가 어디까지 실행될 수 있는가. 그 과정에서 어떤 자격 증명이 발급되는가. 변경이나 외부 전송이 가능한 지점은 어디인가. 이 세 질문에 다이어그램으로 답할 수 없다면, 에이전트 도입 속도보다 먼저 시스템 연결을 정리할 필요가 있다.
Hugging Face가 공개한 내용은 한 사건의 사후 분석이다. 다른 조직의 구조와 그대로 같지는 않다. 다만 AI 에이전트를 붙인 조직이라면 샌드박스, 비밀값, CI 권한, 데이터 처리 계정을 한 묶음으로 점검해야 한다는 경고로 읽을 만하다. 에이전트의 성능이 올라갈수록 권한 설계가 더 중요한 이유도 여기에 있다.