게이트는 작동했다. 그래도 털렸다.

Sysdig이 최초의 LLM 에이전트 침해를 기록했습니다. 4번의 피벗, 모든 게이트 통과, 데이터베이스 탈취까지, 기존 어떤 통제도 커버하지 못하는 레이어에서 벌어진 일입니다.

2026년 6월 24일

인증 신호와 함께 작동한 게이트, 그 옆으로 통제 없이 빠져나가는 데이터. 로그인과 실행 사이의 공백.

Sysdig이 최초의 LLM 에이전트 침해를 기록했습니다. 4번의 피벗, 모든 접근 게이트 통과, 데이터베이스 탈취. 공격당한 환경에는 배스천 호스트와 자격증명 볼트가 있었지만, 이 레이어만큼은 어느 쪽도 막지 못했습니다.

공격당한 환경에는 배스천 호스트가 있었고 AWS Secrets Manager도 있었습니다. 둘 다 설계대로 정확하게 작동했습니다. 배스천은 세션을 인증했고 볼트는 요청받은 시크릿을 반환했습니다. 그럼에도 데이터베이스가 2분도 안 되어 털리는 것은 막지 못했습니다. 게이트는 입장을 통제할 뿐, 실행은 통제하지 않습니다.

저희가 말해왔던 핵심이 바로 이것입니다. 그리고 이제 처음으로 이를 뒷받침하는 실제 증거가 나왔습니다.

무슨 일이 있었나

TL;DR: LLM 에이전트 하나가 노출된 노트북 엔드포인트에서 시작해 단 한 번의 침해로 전체 데이터베이스 덤프까지 도달했습니다. 실패는 로그인이나 시크릿 조회 단계에서 일어난 게 아닙니다. 에이전트가 내부에 들어온 뒤 무엇을 실행하도록 허용했느냐, 거기에 문제가 있었습니다.

2026년 5월 10일, Sysdig 위협 리서치 팀이 LLM 에이전트가 구동한 최초의 공개 확인 침해 사례를 기록했습니다. 진입점은 CVE-2026-39987 (CVSS 9.8 CRITICAL), marimo의 /terminal/ws WebSocket 엔드포인트에서 인증 검사가 빠진 것이었습니다. marimo는 "에이전트를 위한 환경"으로 마케팅되는 오픈소스 반응형 Python 노트북입니다. 인증되지 않은 WebSocket 요청 하나면 전체 PTY 셸을 얻기에 충분했습니다.

CVE-2026-39987은 CISA의 Known Exploited Vulnerabilities Catalog에 5월 7일이 패치 기한으로 등재돼 있었습니다. 연방 기관에게 KEV 등재는 가정이 아니라 의무 패치, 즉 실제 컴플라이언스 사안입니다.

이 사건을 Sysdig이 보고한 기존 공격들과 차별화하는 건 그다음에 벌어진 일입니다. 에이전트는 미리 짜인 플레이북을 실행하지 않았습니다. 스스로 추론하고 즉흥적으로 움직였으며, 인간 작업자는 남기지 않을 흔적을 남겼습니다. 19:31:40 UTC, 실행된 명령 스트림 안에 중국어 계획 메모가 기록되었습니다. 看还能做什么, "우리가 또 뭘 할 수 있는지 봐라." Sysdig는 이렇게 분석했습니다: "미리 짜여진 스크립트라면 이런 혼잣말은 있을 수 없다."

Sysdig의 인시던트 보고서는 4번의 피벗에 걸친 전체 체인을 추적합니다. 타임스탬프를 보면 더 정밀한 그림이 나옵니다. 18:23:44 UTC 최초 셸 획득, 약 19:32:23 UTC 데이터베이스 덤프 완료. 68분을 조금 넘는 시간입니다. 하지만 핵심은 시간이 아니라 그 안에서 벌어진 일입니다. 약 30초간 자격증명을 수집한 뒤 에이전트가 Secrets Manager 피벗을 시작하기까지 약 62분이 비어 있는데, 보고서는 이 공백을 설명하지 않습니다. 그 후 2단계부터 4단계까지는 6분도 채 걸리지 않았고, 데이터베이스 덤프 자체는 2분 안에 끝났습니다.

4번의 피벗, 단계별 정리

피벗 1: marimo RCE에서 AWS 자격증명 수집으로

에이전트는 인증되지 않은 marimo 터미널로 진입해 PTY 셸을 획득한 뒤, 환경 파일 전체를 훑어 자격증명 grep을 즉각 실행했습니다. /app/.env*, ~/.aws/credentials, /proc/*/environ. AWS 액세스 키가 30초 안에 손에 들어왔습니다.

Alpacon이 개입하는 지점: 이 피벗은 Alpacon의 범위 밖입니다. 설령 Alpacon이 보호하는 서버에서 같은 공격이 일어났더라도 결과는 다르지 않습니다. marimo CVE는 WebSocket 엔드포인트에 인증 검사가 없는 애플리케이션 취약점이고, Alpacon은 marimo 프로세스에 관여하지 않습니다. 이 피벗이 PAM 레이어 바깥의 문제라는 건 명백한 사실이며, 그렇지 않다고 주장할 수 없습니다. 진입점은 인터넷에 노출된 개발자 도구였지, 특권 접근 실패가 아닙니다. CVE-2026-39987 패치와 외부 노출 노트북 인스턴스 점검은 CISO가 지금 당장 챙겨야 할 별개의 기본 보안 관리입니다.

피벗 2: AWS 자격증명에서 Secrets Manager의 SSH 키로

수집한 AWS 키로 에이전트는 22초 동안 11개 IP에서 12번의 API 호출을 뿌렸습니다. IP 평판 피드가 업데이트되는 속도보다 빠른 분산이라 IP 기반 레이트 리밋은 방어선이 되지 못합니다. 이어 secretsmanager:GetSecretValue를 호출해 AWS Secrets Manager에 저장된 SSH 개인 키를 조회했습니다.

Alpacon이 개입하는 지점: Alpacon이 관리하는 환경에서는 JIT(Just-in-Time) 자동 만료 세션 덕분에 Secrets Manager에 상시 SSH 키가 남지 않습니다. 에이전트가 조회하려는 자격증명이 애초에 없으니, 조회할 것도 없습니다. 탐지도 룰 매칭도 아닙니다. 키가 처음부터 없는 겁니다.

피벗 3: SSH 키에서 배스천 접근으로

에이전트는 조회한 개인 키로 내부 SSH 배스천에 인증했습니다. 배스천 입장에서는 정상적인 세션이었습니다. 유효한 키, 유효한 사용자. 게이트는 통과시켰습니다.

Alpacon이 개입하는 지점: Alpacon은 아웃바운드 전용 아키텍처라 배스천이 인바운드 포트를 아예 노출하지 않습니다. 유효한 SSH 키를 손에 넣었더라도 에이전트는 인바운드 세션을 열 수 없습니다. 연결할 포트가 없기 때문입니다. 이건 시그니처 매칭이 아니라 아키텍처 차원의 이야기입니다. 배스천이 우회당하는 게 아니라, 에이전트가 오는 방향에서는 애초에 닿을 수 없습니다.

피벗 4: 배스천에서 데이터베이스 덤프로

6개의 Cloudflare Workers IP에서 8개의 병렬 SSH 세션이 열렸습니다. 에이전트는 스키마를 열거하고 덤프할 것을 즉흥으로 골랐습니다. 자격증명이 있을 법한 위치를 일반 지식으로 추론해 credential 테이블을 먼저 노렸지만, 테이블이 스키마에 없다는 걸 확인하자 전체 데이터베이스 덤프로 방향을 틀었습니다. 전체 PostgreSQL 데이터베이스는 기계에 최적화된 HEREDOC 구문으로 탈취됐습니다. 인용된 EOF 블록에 출력을 분리해 담는 방식으로, 터미널이 아니라 에이전트 자신의 컨텍스트 윈도우를 위한 포맷이었습니다. 인간 작업자는 명령을 이렇게 짜지 않습니다. 에이전트는 지도 없이 스스로 추론했고, 찾던 것을 손에 넣었습니다. 스키마를 몰라도 문제없었습니다. 덤프는 2분 안에 끝났습니다.

Alpacon이 개입하는 지점: 런타임 개입이 가능했던 유일한 단계이자, 이 킬 체인의 다른 모든 제어를 에이전트가 이미 통과한 단계입니다.

실시간 명령 검증과 인-세션 킬 체인 탐지는 실행 레이어에서 작동하는 유일한 제어입니다. 인증 이후, 명령 자체를 상대로 작동하지요. 에이전트가 보인 패턴, 곧 래터럴 이동과 스키마 열거, 8개 병렬 세션에 걸친 대량 데이터 읽기는 킬 체인 탐지가 반응하는 다단계 시퀀스 그 자체입니다. 단일 명령이 아니라 패턴입니다.

Alpacon의 실행 제어 레이어는 이 단계에서 개입하기에 알맞은 위치입니다. 특정 개입이 이 특정 덤프를 막았을지는 어떻게 룰과 정책을 구성했느냐에 달린 문제이고, 이 글이 독자를 대신해 단언할 영역이 아닙니다. 이 글이 단언하는 것은 구조적인 사실입니다. 개입이 가능했던 레이어는 이 하나뿐이었습니다. 이전의 모든 제어는 각자의 역할을 제대로 해냈지만, 결과를 막지는 못했습니다.

진짜 공백이 있었던 곳

TL;DR: 공격당한 환경에는 접근 제어와 탐지가 갖춰져 있었지만, 에이전트가 내부에서 벌인 행동은 어느 것도 막지 못했습니다. 진짜 공백은 인증이 아니라 '세션 열림'과 '데이터 탈취' 사이, 실행 레이어 제어가 비어 있었다는 데 있었습니다.

4번의 피벗에서 잠깐 물러나 살펴보면, 이 환경은 배스천 호스트, 자격증명 볼트 둘 다 갖추고 있었고 둘 다 작동하고 있었습니다. 그리고 둘 다 결과와는 무관했습니다.

이것이 이 인시던트가 드러낸 구조적 실패입니다. 모든 제어는 로그인 레이어에 몰려 있었습니다. 정작 실행 레이어, 에이전트가 유효해 보이는 자격증명으로 내부에 들어온 뒤 런타임 개입이 가능한 유일한 그 레이어에는 아무것도 없었습니다.

이 인시던트를 가시화하고 기록으로 남긴 건 Sysdig의 런타임 탐지, 곧 CVE별 탐지 규칙 없이 패턴에 반응하는 시스템 콜 레벨 행동 텔레메트리였습니다. 정말 인상적인 역량이고, 이게 아니었다면 이 글도 나오지 못했습니다. 하지만 탐지와 예방은 다른 레이어입니다. 텔레메트리가 만들어낸 것은 벌어진 일에 대한 완전하고 타임스탬프가 찍힌 기록이지, 그 이상은 아닙니다. 어떤 탐지 시스템도 이미 끝난 탈취를 되돌리지는 못합니다. 탐지는 무슨 일이 있었는지를 알려주고, 실행 제어는 무슨 일이 일어나도 되는지를 결정합니다.

이 공백은 marimo 인시던트에만 국한되지 않습니다. Bessemer는 "targeted in-flight intervention(표적형 인-플라이트 개입)"을 AI 에이전트 보안에서 가장 미개발된 영역으로 지목했습니다. 같은 공백을 제3자가 확인해준 셈입니다. "인증됨"과 "탈취됨" 사이의 레이어에는 선점자가 없습니다. 레거시 PAM 벤더들은 세션의 의도된 범위 안에서 움직이는, 믿을 수 있는 인간 운영자를 전제로 아키텍처를 짰습니다. 기계 속도로 작동하고 타겟을 즉흥적으로 찾아내며 병렬 세션으로 흩어지는 LLM 에이전트는 전혀 다른 종류의 문제입니다.

PAM이 늘 해오던 일을 했습니다. 누가 들어오는지를 통제했지요. 다만 들어온 뒤 무엇을 실행하는지는 아무도 통제하지 않았습니다.

여러분의 PAM이 답하지 못하는 질문

Sysdig 위협 리서치 팀 수석 이사 Michael Clark은 직설적으로 말했습니다: "우리는 AI가 공격자를 대체하는 것을 보고 있지 않습니다. 공격자들이 자신의 스크립트를 AI로 교체하는 것을 보고 있습니다."

Sysdig / marimo 인시던트는 이 현상이 문서로 남고 타임스탬프가 찍힌 킬 체인으로 이어진 최초의 실제 사례입니다. 4번의 피벗, 68분 만에 시작부터 끝까지. 2단계에서 4단계는 6분도 걸리지 않았습니다. 배스천과 자격증명 볼트가 만반의 준비를 갖춘 채 대기하는 동안 데이터베이스는 털렸습니다.

다음 PAM 평가에서 던져야 할 진짜 질문은 제품이 세션을 인증하느냐가 아닙니다. 그건 시장의 모든 PAM이 합니다. 물어야 할 것은 이것입니다. 인증이 끝나고, 세션이 열리고, 에이전트가 모든 게이트를 통과한 자격증명으로 내부에 들어온 뒤, 그 에이전트의 실행을 무엇이 통제합니까?

답이 "아무것도 없다"라면, 여러분의 환경에는 5월 10일의 타겟과 똑같은 공백이 있습니다.

Sysdig 인시던트 보고서에서 전체 타임라인을 확인하세요.