Databricks Genie의 채팅 렌더링 기능이 악성 Skill에 의해 데이터 유출 통로로 바뀌었다. 2026년 10월 5일, 보안 업체 PromptArmor는 Databricks의 에이전트형 어시스턴트 Genie Code가 악성 Skill을 실행한 뒤, 사용자가 분석 결과를 여는 순간 피싱 창을 띄우고 사용자 본인의 브라우저를 통해 테넌트 데이터를 공격자 서버로 보낸다는 내용의 공개 보고서를 발표했다. 기업이 최후의 방어선으로 믿었던 네 가지 통제는 단 하나도 이를 막지 못했다. 먼저 성격부터 분명히 하자. 이것은 책임 있는 공개 절차를 거쳐 발표된 공격 시연과 분석이지, 실제로 확인된 데이터 유출 사고가 아니다.
공격은 어떻게 끝까지 실행되는가
Genie Code는 기업 데이터 팀을 위한 Databricks의 에이전트형 어시스턴트로, 사용자가 자연어만으로 테넌트 안의 데이터를 다룰 수 있게 한다. Databricks의 확장 속도는 가파르다. 새 모델이 나온 날 Databricks가 전 직원 12000명에게 테스트를 시킨 적도 있다. PromptArmor가 시연한 공격 체인은 네 단계다.
- 사용자가 업로드한 Skill을 이용해 Genie에 데이터 분석을 시킨다. Skill은 각종 온라인 마켓플레이스를 통해 유통되는데, 그 생태계는 이미 악성 Skill로 오염돼 있다. 게다가 Genie가 불러오는 것은 조직이 거버넌스를 적용한 카탈로그가 아니라 사용자의 개인 워크스페이스에 있는 Skill이다.
- Genie가 Skill의 코드를 실행한다. 실행 전 가드레일 에이전트가 명령을 심사해 "제3자에게 데이터 전송" 같은 동작에 표시를 하지만, 이번에는 코드를 승인했고 안에 숨은 악성 기능을 잡아내지 못했다.
- Genie가 사용자에게 전체 분석 결과를 열라고 안내한다.
- 결과가 렌더링되는 순간 공격이 동시에 터진다. Skill 코드는 테넌트에서 수집한 데이터셋 같은 민감 정보를 HTML 화면에 미리 심어 두었고, 그 화면 속 스크립트가 사용자의 브라우저로 하여금 공격자 서버에 요청을 보내 데이터를 실어 나르게 한다. 동시에 공격자 사이트를 본뜬 피싱 화면이 겹쳐 표시돼 사용자의 자격 증명을 속여 빼낸다. 전 과정에서 사람의 승인은 개입하지 않는다.
네 가지 통제는 왜 모두 뚫렸는가
- 조직 차원의 Skill 거버넌스: Databricks에는 거버넌스 카탈로그 체계가 있지만, Genie가 실제로 불러오는 것은 개인 워크스페이스의 Skill이라 거버넌스가 닿지 않는다.
- 가드레일 에이전트: Databricks의 설명에 따르면 자동 허용(auto-allow)은 보안 경계가 아니라, 신뢰할 수 없는 입력이 자동으로 실행되는 것을 막기 위한 통제 수단일 뿐이다. 그런데도 문서에서 기본값이자 권장 명령 승인 모드로 안내된다. 여기에 보안 심사를 기대하는 것 자체가 역할을 잘못 기대한 셈이다.
- 코딩 환경의 네트워크 송신 통제: 코딩 환경에서 신뢰할 수 없는 외부 주소로의 통신은 실제로 금지돼 있고, 이 규칙은 깨지지 않았다. 문제는 요청을 실제로 보낸 주체가 사용자의 브라우저라, 그 출구가 코딩 환경의 통제 범위 밖에 있었다는 점이다.
- 채팅 화면의 샌드박스 규칙: 화면이 테넌트 데이터를 조회해서는 안 된다는 규칙 역시 기술적으로는 지켜졌다. 화면은 아무것도 조회하지 않았다. Skill 코드가 미리 심어 둔 데이터를 렌더링해 그대로 내보냈을 뿐이다.
PromptArmor의 판단은 이렇다. 두 가지 보장이 기술적으로는 지켜졌는데도, 그 보장들이 막기 위해 존재했던 결과, 즉 데이터 유출 자체가 발생했다. 이는 Databricks의 위협 모델에 빈틈이 있다는 뜻이다.
Databricks의 답변, 그리고 답변이 없었던 한 가지
시간표는 분명하다. PromptArmor는 2026년 8월 16일 Databricks에 보고했고, 양측은 9월 15일까지 조율을 이어 갔다. 9월 16일 PromptArmor는 공개 방침을 통보했다. Databricks의 핵심 답변은 "업로드하는 Skill에 악성 내용이 없도록 보장하는 것은 궁극적으로 사용자의 책임"이라는 것이었다. Genie가 조직의 거버넌스 카탈로그가 아닌 개인 워크스페이스에서 Skill을 불러온다는 점에 대해서는 Databricks의 설명이 없었다.
지금 Genie를 쓰는 팀이 먼저 할 네 가지
첫째, 개인 워크스페이스의 Skill을 코드로 취급하라. 출처가 불분명한 Skill은 설치하지 말고, 설치 전에 검토하라. 둘째, 운영 데이터 환경에서는 자동 허용을 끄거나 조이고, 승인 중단이 잦아지는 것을 감수하라. 셋째, 브라우저 쪽 송신도 모니터링 범위에 넣어라. 이번 교훈은 데이터가 서버로만 나가는 것이 아니라 직원의 브라우저로도 나갈 수 있다는 점이다. 넷째, 이미 설치된 Skill과 그 출처를 전수 점검하라. 이 위험은 Databricks만의 것이 아니다. 에이전트가 채팅에서 HTML을 렌더링할 수 있고 타사 Skill이 업무 데이터에 닿을 수 있는 제품이라면, 같은 공격 체인으로 스스로를 점검해야 한다.
