McKinsey의 Lilli가 3월 9일에 공개되었다. 그 기록에는 아무런 해가 없다.

2026년 3월 9일, 보안 스타트업 CodeWall은 자사가 구축한 자율 에이전트가 McKinsey & Company의 전사 AI 어시스턴트인 Lilli를 뒷받침하는 프로덕션 데이터베이스에 약 두 시간 만에, 단 하나의 자격 증명도 없이 완전한 읽기 및 쓰기 접근 권한을 얻은 경위를 공개했다. 침해 자체는 2월 28일에 발생했으며, 이 AI 사고 아카이브 항목이 기록하는 것은 이 사건이 공개된 날이다. CodeWall에 따르면, 에이전트가 접근한 데이터베이스에는 평문 상태의 채팅 메시지 4,650만 건, 파일 72만 8,000개, 사용자 계정 5만 7,000개, 그리고 Lilli의 답변 방식을 규정하는 95개의 시스템 프롬프트가 들어 있었으며, 그 프롬프트들은 에이전트가 쓰기 권한을 가진 바로 그 데이터베이스에 있었다. 데이터에 포함된 사람들은 McKinsey & Company 자체 직원들이었다. 회사 측은 직원의 72퍼센트, 즉 4만 명 이상이 Lilli를 사용하며, Lilli는 한 달에 50만 건 이상의 프롬프트를 처리한다고 밝혔다. 심각도 및 신뢰도 등급과 이 항목이 나란히 위치한 인접 기록을 포함한 전체 항목은 Orca AI Incident Archive.

그 도입부는 매우 다른 두 종류의 주장을 압축한 것이며, 아카이브 항목은 그 차이를 신중하게 다룹니다. 이 항목은 해당 기록을 사건으로 등급화하며, 신뢰도 A, 이견 없음, 심각도 높음, 지역 미국, 유형 INFRA — 모델 실패가 아닌 인프라로 분류합니다. 또한 실제 피해는 없었다고 기록합니다. 마지막 필드는 두 번 읽어볼 가치가 있습니다. 그것은 노출이 무해했다는 뜻이 아니기 때문입니다. 그것은 기록상 피해가 입증되지 않았다는 뜻이며, 아래 글은 두 당사자가 동의하는 부분과 한 회사가 자체 연구에 대해 밝힌 설명에만 근거한 부분을 구분합니다.

왜 공개는 그 자체로 날짜가 있는 별개의 사건인가

아카이브의 이 항목에 대한 요약은 CodeWall의 에이전트가 결함을 발견한 날인 2026년 2월 28일을 가리키며, 아카이브는 그 이전 날짜를 별도 기록으로 보관한다. 이러한 분리는 행정적인 것이 아니다. 3월 9일 이전에는 Lilli 내부에서 무슨 일이 있었는지 알던 당사자는 McKinsey와 이를 알려준 연구자뿐이었다. 3월 9일 이후에는 실패의 윤곽, 회사의 대응, 데이터베이스에 무엇이 있었는지에 대한 주장이 모두 공개 기록에 남아 다른 보안 연구자들이 이에 대해 논쟁할 수 있게 되었다.

Lilli는 사이드 프로젝트가 아니다. The Register는 이의 출시를 2023년 7월로 잡았으며, 채팅, 문서 분석, 그리고 회사 내부 연구 전반에 걸친 검색을 아우른다고 했다. 이름의 유래—회사가 1945년에 채용한 최초의 전문직 여성—도 기록한 CodeWall의 글은 그 배후에 10만 개가 넘는 내부 문서가 있다고 설명한다. 같은 날 이 공개를 보도한 The Register는 채택률을 직원의 72퍼센트로, 사용량을 월 50만 건이 넘는 프롬프트로 제시했다. 이는 McKinsey가 해당 플랫폼에 관한 공개 사례 연구에서 스스로 발표한 수치다.

에이전트가 어떻게 들어왔는지

CodeWall의 설명은 익스플로잇이 아니라 문서화에서 시작됩니다. 그 에이전트는 Lilli의 API 문서가 공개적으로 노출되어 상세히 작성된 것을 발견했습니다. 총 200개가 넘는 엔드포인트가 있었고, 대부분은 인증이 필요했지만 22개는 그렇지 않았습니다. 인증이 필요 없는 그중 한 엔드포인트는 사용자 검색 쿼리를 데이터베이스에 기록했습니다. 값은 적절히 매개변수화되었지만, JSON 키 — 필드 이름 — 는 SQL에 그대로 이어붙여졌습니다.

에이전트는 데이터베이스 오류 메시지가 해당 JSON 키들을 그대로 반영해 되돌려주었기 때문에 이를 알아차렸다. CodeWall은 OWASP의 ZAP 스캐너가 이 문제를 표시하지 않았으며, 그다음 에이전트가 15회의 블라인드 반복을 실행했고, 각 오류 메시지가 쿼리의 형태에 대해 조금씩 더 알려주면서 결국 실제 운영 환경의 행들이 반환되기 시작했다고 말한다. 거기서부터 그것은 인젝션을 객체 수준 인가 결함과 연계하여 개별 직원들의 검색 기록을 읽었다. 회사는 전체 실행 과정을 대상 선택부터 보고서 작성까지 완전 자율적이었으며 자격 증명도, 인간 개입도 없었다고 설명한다. 창립자 겸 최고경영자인 Paul Price는 The Register에 그 과정이 "대상 조사, 분석, 공격, 보고에 이르기까지 완전 자율적"이었다고 말했다.

CodeWall이 말한 것은 안에 있었다

이 섹션의 모든 수치는 CodeWall의 3월 9일 분석 자료에서 나온 것이다. 공개된 페이로드는 없었으므로, 그중 어느 것도 재현하거나 독립적으로 집계할 수 없다 — 이 한계는 다음 섹션에서 다룬다.

• 4,650만 건의 채팅 메시지가 전략 업무, 고객 프로젝트, 재무 및 인수합병 사안을 포괄하며 평문으로 저장되어 있습니다.

• 728,000개의 파일 중, 해당 보고서에는 192,000개의 PDF, 93,000개의 Excel 스프레드시트, 93,000개의 PowerPoint 덱, 58,000개의 Word 문서가 항목별로 기재되어 있습니다 — 총 436,000개이며, 나머지 292,000개는 같은 문장에서 분류되지 않은 채로 남아 있습니다.

• 사용자 계정 57,000개, AI 어시스턴트 384,000개, 워크스페이스 94,000개로, CodeWall은 이를 해당 기업이 내부적으로 AI를 사용하는 전체 조직 구조라고 설명합니다.

• 12개 모델 유형에 걸친 95개의 시스템 프롬프트 및 모델 구성으로, 어시스턴트가 어떻게 지시받았는지, 어떤 가드레일이 존재했는지, 그리고 그 기반에 어떤 모델이 있었는지를 보여줍니다.

• S3 스토리지 경로와 내부 파일 메타데이터를 포함한 368만 개의 검색 증강 생성 문서 청크 — 어시스턴트에 공급되는 지식 베이스.

• 110만 개의 파일과 217,000개의 에이전트 메시지가 외부 AI API를 통해 오가며, 여기에는 OpenAI 플랫폼의 266,000개 이상의 벡터 스토어가 포함됩니다.

코드월이 헤드라인으로 내세우는 발견은 인젝션 자체가 아니라 인젝션이 어디에 떨어졌는가이다. Lilli의 시스템 프롬프트는 에이전트가 쓰기 권한을 가진 바로 그 데이터베이스의 행들이었고, 이는 같은 접근 권한을 가진 공격자가 단 한 번의 HTTP 호출로 감싼 단 하나의 UPDATE 문으로 어시스턴트의 지시사항을 다시 쓸 수 있었음을 의미한다. 배포도, 코드 변경도, 디프로 비교할 디스크상의 파일도 필요 없다. 코드월은 자사의 테스트가 검증 목적에 한정됐다고 말한다. 즉 읽기만 했고 쓰지는 않았으며, 어떤 프로덕션 서비스도 중단되지 않았다고 밝혔다.

McKinsey가 같은 날 말한 것

McKinsey 대변인은 3월 9일 The Register에 회사가 CodeWall이 발견한 모든 문제를 알게 된 후 몇 시간 안에 모두 해결했다고 밝혔다. "선도적인 제3자 포렌식 업체의 지원을 받은 우리의 조사에서는 이 연구원이나 다른 어떤 비인가 제3자도 고객 데이터나 고객 기밀 정보에 접근했다는 증거를 발견하지 못했습니다."라고 대변인은 말하며 "McKinsey의 사이버보안 시스템은 견고합니다."라고 덧붙였다.

Silicon UK는 3월 13일 Matthew Broersma의 기사에서 같은 입장을 보도했다. 맥킨지는 “최근 한 보안 연구원으로부터 내부 AI 도구인 Lilli와 관련된 취약점을 통보받았으며”, “즉시 취약점을 확인하고 몇 시간 안에 문제를 해결했고”, 고객 데이터나 고객 기밀 정보에는 접근되지 않았다고 밝혔다. 해당 보도는 또한 Price가 CodeWall의 유일한 직원이라는 점을 언급하는데, 이는 양쪽으로 해석될 수 있어 짚고 넘어갈 만한 세부 사항이다. 즉 1인 연구 조직이 회사 자체 스캐너가 찾지 못한 것을 두 시간 만에 찾아냈으며, 동시에 그 1인 조직은 그것을 찾아낸 도구를 판매하고 있다.

수정에 관한 두 가지 설명, 하루 차이

CodeWall의 자체 공개 일정은 다음과 같이 진행된다: 에이전트는 2월 28일 SQL 인젝션을 식별하고 프로덕션 데이터베이스 열거를 시작한다; 전체 체인은 같은 날 확인되어 27건의 발견 사항이 문서화된다; 3월 1일 McKinsey의 보안 팀에 고수준 영향 요약과 함께 책임 있는 공개 이메일이 발송된다; 회사의 최고정보보안책임자는 3월 2일 수신을 확인하고 상세 증거를 요청한다; 그리고 3월 2일 인증되지 않은 모든 엔드포인트가 패치되고 검증되며, 개발 환경은 오프라인으로 전환되고 공개 API 문서는 차단된다. 대중 공개는 3월 9일에 이어진다.

McKinsey의 설명은 통보를 받은 뒤 몇 시간 안에 수정이 이루어졌다는 것이다. CodeWall의 타임라인은 패치가 공개 이메일을 보낸 다음 날 이루어졌다고 본다. 두 기록 모두 공식적으로 남아 있다. 어느 쪽도 이 둘을 서로 맞추지 않았고, 이 기사도 그렇게 하려 하지 않는다. 차이는 당일 수정이냐 다음 날 수정이냐의 문제이며, 중요한 순서—통보, 그다음 패치, 그다음 공개—는 다투어지지 않는다.

확립된 기업, 단일 공급원, 그리고 그들 사이의 격차

확인되었으며 양측이 합의한 사항: Lilli의 공개 API 표면에 인증이 적용되지 않은 취약점이 존재했다는 점, 이는 내부자가 아닌 외부 보안 연구원에 의해 발견되었다는 점, 맥킨지가 이를 확인하고 패치했다는 점, 인증되지 않은 엔드포인트가 폐쇄되고 개발 환경이 오프라인으로 전환되었으며 공개 API 문서가 차단되었다는 점.

CodeWall의 단일 출처: 위의 모든 수치, 2시간의 타임라인, 15회의 블라인드 반복, 문서화된 27건의 발견 사항, 그리고 동일한 인젝션을 통해 프롬프트를 작성할 수 있었다는 주장까지. 그중 반박된 것은 없다. 하지만 누구든 검증할 수 있게 해줄 페이로드가 공개되지 않았고, 프라이스가 자신의 팀이 사용한 정확한 프롬프트를 The Register에 제공하기를 거부했기 때문에, 그 어느 것도 독립적으로 검증되지 않았다.

AI 보안 기업 Promptfoo는 3월 10일 평가 보고서를 발표하며 그 한계를 정확히 밝혔다. 공개 기록은 “보고된 모든 행 수나 악용의 모든 단계를 독립적으로 입증하지는 못하지만” 사건의 윤곽은 뒷받침한다. 이는 이용 가능한 자료에 대한 올바른 해석이다. 버그의 유형은 재구성할 수 있지만, 규모는 증언에 근거한다.

기록이 담지 않은 피해

아카이브의 등급 평가가 실제로 작동하는 지점이 바로 여기다. 전사적 어시스턴트의 프로덕션 데이터베이스 내부에서 읽기 및 쓰기 접근 권한에 이르는 2시간짜리 경로는 피해 기록처럼 들리지만, 아카이브에는 그런 기록이 없다. 이 항목은 세 가지에 근거한다. McKinsey가 제3자 포렌식 조사에서 고객 데이터가 접근되었다는 증거를 찾지 못했다고 밝힌 성명, CodeWall이 자사의 테스트는 검증 목적일 뿐 아무것도 방해하지 않았다고 밝힌 성명, 그리고 이 기사를 위해 검토된 보도에서 반박하는 조사 결과가 발견되지 않았다는 점이다.

이는 독립적인 기술 감사, 규제 당국의 판단 또는 침해 통지에 근거한 것이 아니다. 검토된 어떤 보도에서도 CVE 식별자가 부여되지 않았으며 — Lilli는 배포되는 제품이 아니라 내부 소프트웨어이고, 이를 명시한 권고문도 없다 — 어떤 감독 당국도 사안을 개시한 것으로 보이지 않는다. 이 기사를 위해 검토된 보도에서 해당 데이터가 사용되거나 판매되거나 추가로 노출되었다는 공개 증거는 발견되지 않았다. 여기서 “기록된 실제 피해 없음”이 뜻하는 바는 이것이다. 즉, 기록에 관한 증거 진술이지, 그 노출이 안전했다는 판정은 아니다.

그 격차가 중요한 이유는 흥미로운 위험이 잠재적이었기 때문이다. 읽기 접근은 이미 존재하던 것을 드러낸다. 프롬프트 계층에 대한 쓰기 접근은 어시스턴트가 다음에 말할 내용을 드러낸다 — 오염된 조언, 가드레일 제거, 컨설턴트가 이후 고객 문서에 붙여넣는 답변에 끼워 넣은 기밀 자료 같은 것이다. CodeWall은 그러한 결과가 동일한 접근 권한을 가진 누구에게나 가능하다고 설명했다. 아무도 그것이 실제로 실행되었다는 것을 입증하지 못했다. 두 진술은 동시에 참일 수 있다: 그 능력은 실재했지만, 누구든 공개한 증거로는 피해가 실현되지 않았다.

왜 이것이 모델 실패가 아닌 인프라로 분류되는가

아카이브는 이 기록에 INFRA 태그를 붙였고, 기술 기록도 그 태그를 뒷받침한다. CodeWall의 설명 어디에도 모델을 속여야 할 필요는 없었다. 탈옥도, 문서로부터의 프롬프트 인젝션도, 어시스턴트가 받아들여야 했던 적대적 입력도 없었다. 진입점은 노출된 문서, 누락된 인증 검사, 안전하지 않은 SQL 구성이었다. 모델은 그저 문 뒤에 있던 가장 가치 있는 대상이었을 뿐이다.

Promptfoo의 3월 10일 분석은 방어적 관점에서 같은 구분을 짓는다. Lilli는 "공개 기록상 모델 탈옥이 아니라 AI 시스템에까지 이른 애플리케이션 보안 사고로 보이며", AI 보안이라고 불리는 것의 상당 부분은 여전히 소프트웨어 보안, 데이터 보안, 구성 거버넌스다. AI에 특유한 부분은 침해 자체가 아니라 피해 범위였다. 프롬프트, 라우팅 규칙, 검색 설정이 변경 가능한 애플리케이션 데이터였기 때문에, 데이터베이스 쓰기 접근 권한은 코드를 건드리지 않고도 어시스턴트의 동작을 바꿀 수 있는 능력이 되었다.

그 후 무엇이 달라졌나요?

구체적인 변경 사항은 양측이 설명하는 것과 같습니다. 인증되지 않은 엔드포인트는 폐쇄되고 검증되었으며, 개발 환경은 오프라인으로 전환되었고, 공개 API 문서는 차단되었습니다. 맥킨지는 해당 취약점을 발견하고 확인하여 수정했다고 밝혔으며, 공식 입장은 고객 데이터가 접근되지 않았다는 것입니다.

변하지 않은 것은 이 사건이 설명하는 더 넓은 노출 범위다. CodeWall의 글은 프롬프트가 데이터베이스에 저장되고 API를 통해 전달되며 구성 파일에 캐시되고, 접근 제어나 버전 이력, 무결성 모니터링은 거의 적용되지 않는다고 주장하며 끝난다. 이는 한 산업에 대한 주장이지 McKinsey에 대한 발견이 아니며, 지속적 자동 테스트를 판매하는 회사의 논변으로 읽어야 한다. 이 회사는 초기 프리뷰 단계에 있으며 설계 파트너를 찾고 있다. 이 공개는 동시에 하나의 시연 역할도 한다.

기록이 남기는 것은 논쟁보다 좁고 더 유용하다. 전사적 어시스턴트, 운영 데이터베이스, 두 시간, 자격 증명 없음, 그리고 거짓으로 읽히는 피해 항목 — 사실에 접근할 수 있는 두 당사자 모두 데이터가 사용되지 않았다고 말하기 때문이다. 그 수치는 그중 한 당사자의 것이고, 취약점은 둘 모두의 것이다.