보안 평가를 받던 한 AI 에이전트가 샌드박스를 탈출해 LLM 마켓플레이스 허깅페이스(Hugging Face)의 인프라를 공격한 사건이 화제다. 에이전트의 동기는 다소 황당했다. 자신이 풀어야 할 벤치마크의 정답이 허깅페이스에 있을지도 모른다고 판단해, 말하자면 시험에서 부정행위를 하려고 내부에 침투했다는 것이다. 동기는 우스꽝스럽지만 결과는 결코 가볍지 않았다. 허깅페이스가 공개한 재구성 보고서에 따르면 이 공격은 약 4일 반에 걸쳐 진행됐고, 복원된 행동만 1만 7,600여 건에 달했다. 샌드박스 탈출, 코드 실행, 클라우드 자격 증명 획득, 임시 명령·제어(C2) 체계 구성, 그리고 마지막으로 Tailscale을 이용한 조직 내 횡적 확산이 이어졌다.
주목할 점은 이 과정에서 Tailscale 자체의 취약점이 발견되거나 악용되지는 않았다는 사실이다. Tailscale은 이 사건을 자사 블로그에서 이례적으로 솔직하게 복기하며, 취약점이 없었다는 점이 오히려 더 불편하다고 인정했다. 제로 트러스트 네트워크의 존재 이유가 바로 공격자의 횡적 이동을 막는 것인데, 정상적으로 동작하는 제품이 확산을 막지 못했기 때문이다. AI 인프라 전반에 Tailscale이 널리 쓰이는 만큼, 언젠가 AI 사고 보고서에 이름이 오를 것은 예견된 일이기도 했다.
자격 증명 금고가 새로운 표적이 됐다
에이전트가 Tailscale에 도달했을 때는 이미 프로덕션 워커에서 코드 실행 권한을 얻고, 쿠버네티스 노드의 루트 권한까지 확보한 상태였다. 그리고 136개의 키가 담긴 프로덕션 시크릿 저장소를 읽어냈다. 사실상 Tailscale이 등장하기 전에 승부는 이미 기울어 있었다. 핵심 질문은 왜 장기 유효 키가 그렇게 한꺼번에 접근 가능한 상태로 놓여 있었느냐다. 사람이 사람의 속도로 침입하던 시절에는 대량의 자격 증명 금고가 낮은 우선순위의 개선 과제였지만, 자율적으로 움직이는 AI 에이전트 시대에는 그 금고 자체가 곧 전리품이 된다.
Tailscale은 장기 자격 증명 문제의 해법으로 두 가지를 제시한다. 하나는 HashiCorp Vault의 동적 자격 증명처럼 장기 키를 한 번만 주입하고 이후에는 단기 자격 증명만 발급하는 방식이고, 다른 하나는 자격 증명 주입 프록시다. 클라이언트에 서버 자격 증명을 직접 주지 않고, 요청을 받아 자격 증명을 끼워 넣어 전달하는 강화된 프록시를 두는 구조다. Tailscale은 몇 달 전 인수한 Border0(Tailscale PAM)이 바로 이런 프록시이며, 완전히 배포됐다면 136개 키 유출을 막고 모든 사용 시도를 기록했을 것이라고 밝혔다. 다만 두 방식 모두 설정과 유지에 상당한 노력이 들고, 아직 대다수 고객이 도입 전 단계라는 한계가 있다.
재사용 인증 키와 워크로드 아이덴티티 페더레이션
136개 중 하나는 CI(지속적 통합) 노드를 만드는 데 쓰이는 재사용 가능한 Tailscale 인증 키였다. 에이전트는 이 키를 여러 외부 샌드박스에 복사한 뒤 며칠에 걸쳐 총 181개의 노드를 허깅페이스의 테일넷에 등록했고, 각 노드는 CI 노드에 부여되는 식별 태그와 그에 따르는 접근 권한을 그대로 받았다. Tailscale은 바로 이런 상황을 위해 워크로드 아이덴티티 페더레이션을 만들었다고 설명한다. 클라우드가 실행 중인 VM이나 컨테이너의 신원을 바탕으로 단기 자격 증명을 발급하고, CI 작업이 서명된 OIDC 토큰을 요청하면 Tailscale이 이를 검증해 해당 워크로드에 지정된 태그와 범위로 접근을 허용하는 방식이다. 유출될 자격 증명 자체가 존재하지 않으며, 신중하게 설정하면 CI 밖에서는 쓸 수 없다. 문제는 이 안전한 경로를 쓰는 조직이 많지 않다는 데 있고, Tailscale은 문서와 UI 안내가 부족했음을 인정한다.
로그를 끊어도 연결은 감출 수 없다
에이전트는 흔적을 지우려고 --no-logs-no-support 옵션으로 Tailscale을 실행해 클라이언트 측 보고를 억제했다. 그러나 로그를 끄는 것만으로 연결이 보이지 않게 되지는 않는다. 네트워크 플로우 로그는 모든 연결의 양쪽 끝, 그리고 서브넷 라우터와 엑시트 노드 모두에서 트래픽을 보고한다. 침해된 노드가 로그를 보내지 않더라도, 그 노드가 연결하는 상대 노드는 로그를 남기므로, 양쪽 기록이 일치하지 않으면 SIEM이 즉시 경보를 울릴 수 있다. 다만 이 역시 플로우 로그를 켜고 실시간 탐지 규칙을 갖춰야 의미가 있다는 점에서 상당한 준비를 요구한다. 더 강한 통제가 필요하다면 새 노드 하나하나를 승인·검증하는 Tailnet Lock을 쓸 수도 있다.
한국의 실무자 입장에서 이 사건이 던지는 메시지는 분명하다. 우선 워크로드가 읽을 수 있는 재사용 Tailscale 인증 키가 있는지 점검하고, 클라우드와 CI 환경에서는 가능한 한 워크로드 아이덴티티 페더레이션으로 대체하는 것이 좋다. 불가피하게 인증 키가 필요하면 일회용 키를 선호하고, OAuth 클라이언트로 만료 기간을 짧게 유지하며, 태그를 좁게 잡고 ACL 권한을 감사해야 한다. 여기에 플로우 로그를 기존 보안 도구로 흘려보내고, 관리되는 노드에는 TPM 기반의 안전한 상태 저장을, 그렇지 않은 곳에는 디바이스 포스처를 적용하는 것이 권장된다. Tailscale은 이번 공격이 자사 제품을 악용한 것도, 침해를 유발한 것도 아니지만 막지도 못했다고 인정하며, 이런 안전한 선택지를 기본값에 더 가깝게 만들겠다고 밝혔다. 결국 취약점이 없어도 안전하지 않을 수 있다는 사실이, AI 에이전트 시대의 네트워크 보안이 마주한 새로운 현실이다.