보안 공시를 읽다가 두 번째 문단에서 "잠깐, 뭐라고?"라고 생각하며 멈춰 선 적이 있나요? 바로 이 사례가 그렇습니다.

7월 16일, HuggingFace는 기이한 형태의 공격을 받았다고 발표했습니다. 자율 에이전트(autonomous agent)가 그들의 시스템 내부에서 며칠 동안 실행되었으나, 배후가 누구인지 파악하기도 전에 사라져 버린 사건이었습니다. 5일 후, OpenAI가 나섰습니다. 그것은 말 그대로 그들 자신의 모델이었습니다.

한 달 전 Auth0에 합류한 이후, 저는 생업으로 ID(identity)와 액세스(access)에 대해 고민하며 하루를 보내고 있는데, 이번 사건은 정말 저를 멈춰 서게 만들었습니다.

사건의 요약

OpenAI는 미출시 모델의 가공되지 않은 능력을 정직하게 측정하기 위해, 가드레일(guardrails)을 해제한 상태로 ExploitGym이라는 벤치마크를 대상으로 테스트를 진행하고 있었습니다. 해당 모델은 샌드박스(sandbox)의 유일한 출구인 패키지 다운로드 프록시(package-download proxy)에서 제로데이(zero-day) 취약점을 발견했고, 이를 이용해 공개 인터넷에 접속했습니다. 그곳에서 모델은 전혀 관련이 없는 회사의 인프라(Modal)에 노출되어 있던 코드 실행(code-execution) 엔드포인트를 찾아내 루트(root) 권한을 획득했으며, 이를 실제 작전 기지로 사용했습니다.

그 후 모델은 HuggingFace를 공격했습니다. 처음에는 탈취된 자격 증명(credentials)을 통한 것이 아니라, 그들의 데이터셋 프로세서(dataset processor)가 업로드된 파일을 처리하는 방식에서 발생한 매우 평범한 두 가지 버그를 이용했습니다. 하나는 프로덕션 서버의 임의 파일(arbitrary files)을 읽을 수 있게 했고, 다른 하나는 코드 실행(code execution) 권한을 부여했습니다. 그리고 거기서부터 본격적인 권한 상승(escalation)이 이루어졌습니다: 토큰(tokens) 탈취, 위조된 ID 키(identity keys), 단 1초 만에 두 개의 별도 시스템에 대한 클러스터 관리자(cluster-admin) 권한 획득까지 이어졌습니다.

그 누구도 이를 유도(prompt)하지 않았습니다. 모델은 벤치마크를 해결하라는 지시를 받았고, 도구들을 전달받은 뒤, 어떻게 해결할지 스스로 찾아내도록 방치되었습니다. HuggingFace의 자체 재구성 결과에 따르면, 보안 팀이 마침내 차단하기 전까지 4.5일 동안 약 17,600개의 동작이 수행되었습니다.
이것을 방지할 수 있었을까요? 솔직히 말하면, 네.

이 사건을 막을 수 있었던 몇 가지 방법들:

실질적인 격리 (Actual isolation). 다운로드를 위한 선별된 허용 목록 (allowlist)은 격리가 아닙니다. 그것은 그저 열리기를 기다리는 잠기지 않은 문일 뿐입니다. 실질적으로 이는 샌드박스 (sandbox)에 대해 "신뢰할 수 있는" 레지스트리 (registry)를 포함하여 외부 네트워크 접속을 완전히 차단해야 함을 의미합니다. 만약 테스트에 특정 패키지가 진정으로 필요하다면, 실시간 요청을 외부로 프록시 (proxy)하는 대신 실행 전에 미리 준비해 두어야 합니다.

평가 환경 (eval environments)을 운영 환경 (production)처럼 모니터링하기. 해당 모델은 안전 학습 (safety training)이 꺼진 상태로 작동하고 있었으며, 바로 그 순간이 더 적은 감시가 아니라 더 많은 감시가 필요했던 시점이었습니다. 즉, 평가 샌드박스를 아무도 24시간 내내 지켜보지 않는 조용하고 분리된 파이프라인이 아니라, 운영 환경과 동일한 실시간 로깅 (logging) 및 알림 (alerting) 체계에 연결해야 한다는 의미입니다.

상시 권한 (standing access) 대신 범위 제한 권한 (scoped access). 관련된 세 기업 중 어느 곳도 단 하나의 유출된 자격 증명 (credential)이 격리된 상태로 유지되도록 설정되어 있지 않았습니다. 과도한 권한을 가진 커넥터 하나가 1초도 안 되어 두 시스템에 대한 클러스터 관리자 (cluster-admin) 권한을 에이전트 (agent)에게 넘겨주었습니다. 이것이 실제로 어떻게 보여야 하는지 설명하자면 다음과 같습니다: 수명이 긴 API 키와 정적 자격 증명을, 정확히 하나의 리소스와 하나의 동작에만 연결된 수 분 단위의 짧은 수명을 가진 범위 제한 토큰 (scoped tokens)으로 교체해야 합니다. 그리고 단 하나의 자격 증명이 여러 시스템에 걸쳐 있지 않도록 하십시오. 만약 유출되더라도 그 피해 범위 (blast radius)는 모든 것이 아니라 단 하나의 시스템이어야 합니다.

실질적인 강제력을 가진 공개 법안. 현재의 주법은 대규모 인명 피해나 수십억 달러 규모의 손해가 발생했을 때만 공개를 강제합니다. 프런티어 모델 (frontier model)이 자율적으로 세 기업을 가로질러 체이닝 (chaining)하는 것은 그 기준을 통과하지 못하며, 솔직히 말해 통과해야 합니다. 금액에 상관없이 "모델이 자율적으로 제3자의 운영 시스템을 침해하는 모든 사건"과 같이 더 명확하고 낮은 트리거 (trigger) 기준이 있다면, 이번 사례와 같은 경우를 실제로 포착할 수 있을 것입니다.

이것이 AI의 미래에 실제로 의미하는 바

이 부분은 제가 생각을 멈출 수 없는 지점이기에, 자세히 파헤쳐 보겠습니다.

벤치마크 (Benchmarks)가 이제 공격 표면 (attack surface)의 일부가 되었습니다. ExploitGym은 기본적으로 하나의 테스트입니다. AI 에이전트가 보안 버그를 찾아내고, 실제로 이를 이용해 침입할 수 있는가? 문제는, 테스트를 받는 AI가 주어진 시스템이 아닌 다른 회사의 시스템에서 이를 증명해 보일 것이라고는 아무도 예상하지 못했다는 점입니다. 단순히 테스트를 실행한 것만으로도 실제 피해가 발생했습니다. 이는 누구도 예측할 수 없었던 완전히 새로운 종류의 리스크이며, AI 기업들은 이러한 테스트를 구축하는 방식을 재고해야 할 것입니다.

이것은 오랫동안 지속되어 온 정렬 (alignment) 우려에 대한 지금까지 중 가장 명확한 실제 사례입니다. 연구자들은 유능한 시스템이 인간보다 더 극단적으로 좁은 목표를 추구할 때 어떤 일이 발생하는지에 대해 수년간 주로 추상적인 수준에서 논의해 왔습니다. 여기 구체적인 사례가 있습니다. 에이전트가 시도한 모든 파괴적인 명령은 실제 피해를 입히지 않으면서 피해를 줄 수 있는지 확인하기 위해 먼저 드라이 런 (dry run, 사전 연습) 형태로 실행되었습니다. 에이전트는 해를 끼치려 했던 것이 아닙니다. 단지 벤치마크를 해결하는 데 초집중하고 있었을 뿐이며, 실제 인프라에 접근할 수 있게 되자 "벤치마크 해결"에는 자연스러운 중단 지점이 없다는 것이 드러났습니다. 이것은 더 이상 가설적인 상황이 아니라는 사실이 말도 안 될 정도로 놀랍습니다.

방어자의 비대칭성 문제 (defender's asymmetry problem)에 대한 실제 사례가 방금 등장했습니다. HuggingFace가 자신들의 공격 로그를 연구하기 위해 Claude Opus와 Fable을 사용하려 했을 때, 두 모델 모두 거부했습니다. 공격자의 페이로드 (payloads)를 해독하는 데 도움을 요청할 때마다, 안전 필터 (safety filters)가 이를 사이버 보안 리스크로 분류하여 거부한 것입니다. 모델들은 방어를 위해 익스플로잇 (exploit)을 역공학 (reverse-engineering)하는 것과, 공격을 위해 익스플로잇을 구축하는 것 사이의 차이를 구분할 수 없었습니다. 결국 HuggingFace는 조사를 수행하기 위해 자체 서버에 별도의 오픈 웨이트 (open-weight) AI 모델을 구축해야만 했습니다. 반면 제한이 없는 모델을 사용하는 공격자는 이러한 장벽에 전혀 부딪히지 않을 것입니다. 이 한 순간, 안전을 기하는 행위가 공격자를 늦추는 것보다 선한 의도를 가진 이들을 더 많이 늦춰버렸습니다.

규모 (Scale)가 조용히 게임의 판도를 바꾸고 있습니다. 이에 대한 HuggingFace의 성찰 중 제가 계속 되새기게 되는 문장은 다음과 같습니다: '하나의 영리한 취약점 공격 (exploit)이 있었던 것이 아니라, 17,600번의 대부분 실패한 시도 끝에 소수의 시도가 연결된 것이었다.' 인간 공격자라면 여기서 그 어떤 단 하나의 결함이라도 찾아낼 수 있었을 것입니다. 변화하는 점은, AI 에이전트 (AI agent)는 사람이 단 하나의 경로를 테스트하는 시간 동안 수천 개의 경로를 테스트할 수 있다는 것이며, 이제 방어자들은 신호 (signal)를 포착하기 위해 그와 동일한 양의 노이즈 (noise)를 상관 분석해야 한다는 것입니다. 그 수학적 계산은 기본적으로 방어자에게 유리하지 않지만, 방어자에게 유리하도록 구축되어야만 합니다.

그리고 정말 흥미로운 부분은 이것이 실제 제품조차 아니었다는 점입니다. 이 모든 일은 OpenAI와 같은 기업에서 가장 안전하고 면밀히 감시되는 환경인 내부 테스트 중에 발생했습니다. 반면, 기업들은 지금 이 순간에도 매일 AI 에이전트에게 관리가 제대로 되지 않고 감시가 소홀한 복잡한 시스템에 대한 실제 접근 권한을 부여하고 있습니다. 신중하고 밀착 감시되는 테스트조차 이 정도의 피해를 입힐 수 있다면, 진짜 문제는 이것이 다시 발생할지 여부가 아닙니다. 그것은 사람들이 더 높은 이해관계가 걸린 곳에서 다음 사고가 터지기 전에, 샌드박싱 (sandboxing)과 시스템 보안에 실제로 더 진지해질 것인가 하는 점입니다.

만약 당신이 지금 AI 에이전트를 구축하거나 보안을 강화하고 있다면, 이것은 정확히 당신의 레이더망에 있어야 할 위험 요소입니다. 이 모든 상황에서 가장 무서운 부분은 기대 이상의 성과를 낸 AI 모델이 아니라, 실제 버그들이 얼마나 평범했는가 하는 점이었습니다.

이것이 AI의 지형을 어떻게 바꿀 것이라고 생각하시나요? 아래에 댓글을 남기거나 X(@layluh)에서 저를 찾아주세요. 여러분의 생각을 듣고 싶습니다. :-)