Mercor의 4TB AI 데이터 유출: LiteLLM 공급망 공격이 어떻게 LLM 채용 플랫폼을 무너뜨렸나

CoreProse KB-incidents에 최초 게시됨. 현재 LLM 앱은 모델 제공업체(model providers), 라우터(routers), RAG 저장소(RAG stores), 에이전트(agents), 그리고 그 사이의 수많은 라이브러리 등 취약하고 빠르게 변화하는 공급망(supply chain)에 의존하고 있습니다.[1][7] 중앙 연결 고리 중 어느 하나라도 실패하면, 상류(upstream)의 모든 것이 노출됩니다. AI 기반 채용 스타트업인 Mercor에서 보고된 4TB 규모의 데이터 유출은 구체적인 사례입니다.[7] 분석 결과, 이는 Meta 모델 통합을 포함하여 Mercor와 제공업체 사이의 LiteLLM 기반 라우팅 계층(routing layer)이 침해된 것과 연관이 있는 것으로 밝혀졌습니다.[6][7] 해당 라우터는 프록시된 모든 요청에 대한 프롬프트(prompts), 트랜스크립트(transcripts), 메타데이터(metadata)를 평문(cleartext) 상태로 확인했습니다. 채용 플랫폼의 특성상, 이는 다음과 같은 정보들을 노출했을 가능성이 높습니다:[5][7]

• 이력서 및 LinkedIn 스타일의 프로필
• 코딩 인터뷰 트랜스크립트 및 평가 노트
• 희망 연봉 및 오퍼(offer) 세부 사항
• 내부 검토자 순위 및 휴리스틱(heuristics)

LLM 보안 가이드라인은 이를 매우 민감하고 영향력이 큰 데이터로 분류합니다.[1][5]

📊 Gartner 인용 연구:

운영 환경에서 ML을 사용하는 조직의 65% 이상이 ML 파이프라인 및 LLM 구성 요소에 대한 전담 보안이 부족합니다.[2][8]

편의성을 위한 라우터들이 스택 내에서 가장 위험한 시스템 중 하나로 조용히 변모하고 있습니다. 이 기사는 Mercor–LiteLLM 사례를 사용하여 운영 환경의 LLM 라우터, RAG 파이프라인, 그리고 에이전트 워크플로(agentic workflows)를 위한 위협 모델(threat model)과 강화 플레이북(hardening playbook)을 구축합니다.[7]

1. Mercor–LiteLLM 공급망 유출에서 발생한 일
   Mercor는 Meta 관련 모델을 포함하여 여러 제공업체 간의 호출을 오케스트레이션(orchestrate)하기 위해 LiteLLM을 LLM 라우팅 계층으로 사용한 것으로 보고되었습니다.[6][7] 해당 라우터가 침해되었을 때, 공격자는 흐르는 데이터 중 약 4TB에 접근할 수 있었습니다.[7] LLM 라우터는 TLS를 종료(terminate)하고 외부 호출을 전달하기 때문에 다음과 같은 정보를 볼 수 있습니다:[6][7]

• 원시 프롬프트 (candidate questions, evaluator instructions)
• 완료 문구 (Completions) (생성된 인터뷰 질문, 피드백 텍스트)
• 도구 입력/출력 (Tool inputs/outputs) (코드 러너, 검색, 스코어링)
• 제공업체 자격 증명(credentials) 및 라우팅 메타데이터

⚠️ LLM 공격 표면(attack surface) vs.

classic web apps [1] LLM 앱은 통상적으로 다음과 같은 데이터를 처리합니다:

• 자유 형식의 사용자 프롬프트 (Free-form user prompts)
• 업로드된 문서 (이력서, PDF, 계약서 등)
• 에이전트 도구 결과 (DB 쿼리, 코드 실행 로그)

이 과정에서 침해된 모든 중간 매개체 — 특히 라우터 (router) — 는 이러한 흐름 전체에 대한 완전한 가시성을 확보하게 됩니다.[1][7] 제3자 LLM 라우터 (LLM routers)를 연구하는 연구자들은 수십 개의 라우터가 은밀하게 도구 호출 (tool calls)을 주입하거나, 자격 증명 (credentials)을 탈취하거나, 응답을 조작하고 있음을 발견했으며, 이는 라우터가 주요 공급망 공격 대상 (supply-chain target)임을 확인시켜 줍니다.[6][4]

💡 공급망 관점 (Supply-chain framing)
이러한 사건들은 대개 OpenAI, Anthropic 또는 Meta가 해킹당한 것이 아닙니다. 이는 다음과 같은 상황을 의미합니다:[6][7]

• 하이퍼스케일러 (hyperscaler) 엔드포인트는 정상적으로 작동하는 동안, 사용자과 모델 사이의 모든 요소 — SDK, 라우터, 플러그인, RAG 저장소 — 가 조작되는 상황.

채용 맥락에서 데이터 유출은 다음과 같은 문제를 야기합니다:[5][7]

• 지원자의 개인정보 (PII)에 대한 프라이버시 및 규제 노출
• 인터뷰 내용 및 스코어링 로직 (scoring logic)에 대한 IP(지식재산권) 손실
• Meta 관련 프롬프트나 평가 결과물 (evaluation artifacts)이 노출될 경우 발생하는 파트너 리스크

설문 조사에 따르면 많은 조직이 앱과 인프라는 보안을 유지하지만, 학습 데이터 (training data), 피처 스토어 (feature stores), 그리고 AI 미들웨어 (AI middleware)는 방치하고 있습니다.[2][8]

소결론: Mercor 사례는 예외적인 경우가 아닙니다. 이는 LLM 라우터가 고권한 인프라 (high-privilege infrastructure)가 아닌 단순한 글루 코드 (glue code)로 취급될 때 발생하는 현상입니다.[7]

LiteLLM과 같은 LLM 라우터(Router)가 어떻게 단일 장애점(Single Point of Failure)이 되는가

LiteLLM과 같은 라우터는 투명한 중개자(transparent intermediaries)로 설계되었습니다.[6][7] 일반적인 흐름은 다음과 같습니다:

1. 클라이언트가 라우터로 프롬프트(prompt) + 선택적 문서 전송
2. 라우터가 시스템/정책 프롬프트(system/policy prompts) 추가
3. 라우터가 제공자/모델(예: Meta, OpenAI) 선택
4. 라우터가 API 키 / 토큰 부착
5. 라우터가 전달, 응답 언래핑(unwraps), 로그 기록 및 반환

설계상 라우터는 다음과 같은 역할을 수행합니다:[6][7]

• 모든 요청/응답 콘텐츠를 평문(plaintext)으로 확인
• 제공자 비밀 정보(provider secrets) 관리
• 도구(tools), RAG 호출, 함수 호출(function calling) 오케스트레이션

📊 LLM 중개자에 대한 학술 연구에 따르면, 26개의 제3자 라우터가 도구 호출(tool calls)을 비밀리에 주입하고, 미끼용 암호화폐 지갑을 비우는 것을 포함하여 자격 증명(credentials)을 유출하는 것이 발견되었습니다. 이는 Mercor의 라우터가 가졌던 것과 동일한 신뢰 위치입니다.[6]

💼 라우터에 대한 주요 공격 벡터(attack vectors) [1][4][6][7]

• 악성 / 침해된 라우터 바이너리 또는 컨테이너
• 라우팅 로직 또는 플러그인에 대한 코드 주입(Code injection)
• 제공자가 프롬프트를 보기 전에 추가되는 숨겨진 도구 호출(Hidden tool calls)
• 응답 변조(Response tampering) (안전 점검 제거, 페이로드 추가)
• 환경 변수(env vars) 또는 설정(config)으로부터의 자격 증명 탈취

OWASP는 도구, 플러그인 및 외부 통합을 직접적인 LLM 엔드포인트와 동일한 정밀 조사가 필요한 고위험 구성 요소로 취급합니다.[1][7]

⚡ ML 공급망 연쇄 위험 (ML supply-chain cascading risk)

라우터는 종종 다음과 연결됩니다:[2][8]

• 학습 데이터 파이프라인 및 미세 조정(fine-tuned)된 모델
• 모델 레지스트리(Model registries) 및 아티팩트(artifacts)
• 후보자 순위 산정에 사용되는 피처 스토어(Feature stores)

침해 시 다음과 같은 상황이 발생할 수 있습니다:[2][8]

• 데이터 탈취 (프롬프트, 문서, 피처)
• 학습 데이터 및 피처 오염(poisoning)
• 평가 및 분석 파이프라인 조작

라우터가 Meta가 호스팅하거나 Meta의 정렬(aligned)을 따르는 모델로 가는 관문일 때, 침해 사고는 다음과 같은 정보를 유출할 수 있습니다:[5][7]

• Meta API와 관련된 프롬프트 및 상호작용 패턴
• 평가 로그 및 스코어링 스크립트
• Meta와 계약적 또는 규제적 통제 하에 있는 데이터

라우터는 종종 핵심 API에 적용되는 세분화(segmentation)나 검토 없이 "헬퍼(helper)" 서비스로 배포됩니다.[1][7]

소결론: LLM 라우터는 사실상 권한이 부여된 역방향 프록시(reverse proxy) + API 게이트웨이(API gateway) + 키 관리 시스템(key management system)입니다.

이를 저위험군 배관 작업(plumbing)으로 취급하는 것은 범주 오류(category error)입니다. 3. Mercor 사건으로 드러난 LLM 특화 위협 (LLM-Specific Threats Exposed by the Mercor Incident) Mercor 사건은 LLM 데이터가 기존 애플리케이션 데이터와 질적으로 다르다는 점을 보여줍니다. LLM 트래픽은 깔끔한 필드(fields)가 아니라 산문 형태의 프롬프트(prompts), 완성문(completions), 그리고 문서에 내장되어 있습니다.[1][5] 단 하나의 전사 데이터(transcript)에도 다음과 같은 정보가 포함될 수 있습니다: 개인 정보(이름, 연락처, 위치), 경력 사항, 희망 연봉, 면접관의 코멘트 및 도구 스택 추적(tool stack traces). 데이터 유출은 직접적인 탈취(exfiltration)를 통해 발생하거나, 해당 데이터가 학습에 사용될 경우 나중에 다시 나타나는 방식으로 발생할 수 있습니다.[5]

⚠️ 승수 효과를 내는 프롬프트 인젝션 (Prompt injection as a force multiplier)
프롬프트 인젝션(Prompt injection)은 이제 LLM의 주요 리스크입니다: 시스템 프롬프트(system prompts)를 무력화하거나, 비밀 정보를 탈취하거나, 도구(tools)를 오용하는 입력값입니다.[1][4] 공격자가 라우터(router)나 RAG 저장소(RAG store)를 제어할 수 있다면 다음과 같은 행위가 가능합니다:[3][4][7]

• 검색된 문서에 숨겨진 지침(hidden instructions) 삽입
• 모델에 도달하기 전 시스템 프롬프트 수정
• 모델이 설정(config), 키(keys) 또는 로그(logs)를 덤프(dump)하도록 유도
  셀프 호스팅 LLM 사례: QA 프롬프트로 인해 모델이 숨겨진 시스템 프롬프트를 출력하여 내부 정책과 템플릿이 노출된 사례가 있었습니다. WAF(웹 애플리케이션 방화벽)는 이를 탐지하지 못했습니다. 모델은 그저 지침을 따랐을 뿐입니다.[3][1]

💡 학습 및 미세 조정 오염 (Training and fine‑tuning poisoning)
머신러닝(ML) 공급망 가이드라인은 학습(training)과 미세 조정(fine-tuning)이 추론(inference)만큼이나 취약하다고 경고합니다.[2][8] 침해된 라우터나 데이터 수집 경로(ingestion path)는 다음과 같은 행위를 할 수 있습니다:[2][8]

• 미세 조정 세트에 오염된 예시(tainted examples) 주입
• 점수 산정 모델 왜곡 (예: 특정 기술에 대한 편향 발생)
• 나중에 특정 동작을 유발하는 백도어 프롬프트(backdoor prompts) 설치
  보안 팀은 이제 LLM을 기존의 OWASP 위협을 넘어 코퍼스 오염(corpus poisoning), 과도한 권한을 가진 에이전트(over-permissioned agents), 모델 추출(model extraction)과 같은 리스크를 가진 별개의 공격 표면(surface)으로 취급합니다.[4][7] Mercor 스타일의 침해 사고에서 라우터가 침해되면 다음과 같은 일이 동시에 발생할 수 있습니다:[5][7]
• 후보자 및 파트너 데이터 탈취
• 평가를 위한 프롬프트 및 도구 출력값 조작
• 라우터 로그에 의존하는 분석 모델 오염

소결론: 공격자가 귀하의 라우터를 장악한다면, 그들은 귀하의 LLM 데이터, 프롬프트, 그리고 향후 모델 동작의 상당 부분을 장악하는 것입니다. 4.

Mercor 스타일의 침해를 방지하기 위한 안전한 LLM 아키텍처 패턴 (Secure LLM Architecture Patterns)

예방은 단순히 개별 서비스를 패치하는 것이 아니라 아키텍처에서 시작됩니다. 4.

4.1 라우터 분할 및 강화 (Segment and harden routers)
라우터는 엄격하게 제어되는 엔클레이브 (Enclaves) 내에서 실행되어야 합니다:[2][7]

• 알려진 LLM 엔드포인트로의 외부 송출 (Egress)을 최소화한 프라이빗 서브넷 (Private subnets)
• 엄격한 방화벽 규칙 및 상호 서비스 인증 (Mutual service authentication)
• 평문 설정 파일이 아닌 전용 볼트 (Vaults) 내의 비밀 정보 (Secrets)
  가이드라인은 ML 구성 요소를 데이터베이스나 핵심 API와 같이 일급 인프라 자산 (First-class infra assets)으로 취급할 것을 권장합니다.[2][8]

⚠️ 제어 평면과 데이터 평면의 분리 (Separate control and data planes) [1][7]
제어 평면 (Control plane: 경로 선택, 과금, 제공자 설정)은 데이터 평면 (Data plane: 전체 프롬프트 및 문서)을 볼 필요가 없습니다. 다음과 같은 조치를 취할 수 있습니다:

• 모델/제공자 선택을 위한 얇은 API (Thin API) 노출
• 별도로 감사된 경로를 통해 민감한 콘텐츠 전송
• 전체 프롬프트가 평문으로 노출되는 지점 최소화 [1]

4.2 비밀 정보 및 로깅 규율 (Secrets and logging discipline)
제공자 키 (Provider keys) 및 Meta 액세스 토큰은 다음과 같아야 합니다:[5][6]

• 중앙 집중식 비밀 관리자 (예: Vault, AWS Secrets Manager)에 저장
• RBAC (역할 기반 액세스 제어) 및 로테이션 (Rotation)을 통해 적시 (Just-in-time)에 가져오기
• 이미지나 설정 파일에 포함(Bake)되지 않도록 관리

📊 사후 분석 (Post-mortems) 결과, 유출의 원인은 원시 프롬프트/완성본 (Raw prompts/completions)을 포함하는 과도한 로그인 경우가 많습니다.[5][7]
더 안전한 로깅 방법:[5][7]

• 요청 ID를 해싱(Hash)하고 메타데이터 (테넌트, 경로, 토큰 수, 오류)를 로깅
• 명시적이고 암호화된 감사 채널(Audit channels) 하에서만 전체 콘텐츠를 영구 저장
• 모든 콘텐츠 로그에 대해 짧은 보관 주기 유지

💡 RAG 및 피처 스토어를 일급 자산으로 취급 (RAG and feature stores as first-class assets) [2][8][7]
코퍼스 (Corpora), 피처 스토어 (Feature stores), 레지스트리 (Registries)를 핵심 자산으로 취급하십시오:

• 코퍼스 및 임베딩 (Embeddings)의 버전 관리
• 데이터 수집 작업 (Ingestion jobs)에 서명 및 검증 수행
• 쓰기 권한 제한 및 비정상적인 문서 모니터링

프레임워크는 지시 사항 (Instructions)을 데이터로부터 격리하고, 최소 권한 원칙 (Least privilege)을 강제하며, 모든 제3자 통합을 신뢰할 수 없는 경계 (Untrusted boundaries)로 취급할 것을 강조합니다.[1][7]

소결론: 좋은 아키텍처는 폭발 반경 (Blast radius)을 줄입니다. 라우터가 침해되더라도 세분화 (Segmentation), 비밀 정보 위생 (Secret hygiene), 그리고 최소한의 로깅을 통해 4TB 규모의 재앙을 제한적인 사고로 전환할 수 있습니다. 5.

구현 가이드: 코드 내에서 LiteLLM 스타일의 라우터(Router) 강화하기

아키텍처가 마련되었다면, 이제 구체적인 코딩 패턴이 필요합니다. 5.1 라우터를 API 게이트웨이(API gateway)로 감싸기

라우터 앞에 게이트웨이 또는 서비스 메시(Service mesh)를 배치하여 다음 사항을 강제하십시오:[4][7]

• 강력한 인증 (mTLS, OAuth2, 스코프가 지정된 API 키)
• 테넌트(Tenant)별 속도 제한(Rate limits) 및 동시성 제한(Concurrency caps)
• 페이로드(Payload) 크기 제한 및 구조적 검증(Structural validation)

이를 통해 LiteLLM이 프롬프트(Prompt)를 받기 전에 집행 계층(Enforcement layer)을 제공할 수 있습니다.[7] ⚡ 예시 (FastAPI + 게이트웨이 스타일 검사)

from fastapi import FastAPI, Request, HTTPException
from pydantic import BaseModel, Field

class LLMRequest(BaseModel):
    tenant_id: str = Field(..., min_length=3, max_length=64)
    prompt: str = Field(..., max_length=8000)
    tools: list[str] = []

ALLOWED_TOOLS = {"search", "code_runner"}

app = FastAPI()

@app.post("/router/proxy")
async def proxy(req: Request, body: LLMRequest):
    api_key = req.headers.get("x-api-key")
    if not validate_api_key(api_key, body.tenant_id):
        raise HTTPException(status_code=401, detail="unauthorized")
    
    if any(t not in ALLOWED_TOOLS for t in body.tools):
        raise HTTPException(status_code=400, detail="invalid tool")
    
    if contains_secret_pattern(body.

prompt ): raise HTTPException ( status_code = 400 , detail = " potential secret in prompt " ) return await forward_to_litellm ( body ) 이 방식은 라우터 (router)가 실행되기 전에 인증 (auth), 페이로드 제한 (payload limits), 허용 목록 도구 (allow-listed tools), 그리고 기본적인 비밀 정보 탐지 (secret detection)를 결합합니다.[3][6]

5.2 입력 유효성 검사 (Input validation), 콘텐츠 필터링 (content filtering), 그리고 구조화된 도구 호출 (structured tool calls)
단순한 정화 (sanitization)만으로는 정교하게 설계된 프롬프트 인젝션 (prompt injection)을 막을 수 없습니다.[3]
권장되는 통제 수단:[1][4]

• 도구 및 함수 스키마 (function schemas)에 대한 명시적 허용 목록 (allow-lists)
• 도구 인자 (tool arguments)에 대한 JSON 스키마 검증 (JSON Schema validation)
• 자격 증명 패턴 (AWS keys, JWTs)에 대한 정규 표현식(Regex) 또는 머신러닝(ML) 기반 탐지

💼 콘텐츠 유출 없는 구조화된 로깅 (Structured logging)
기본 로그에는 다음 내용이 포함되어야 합니다:[5][7]

• tenant_id, 경로 (route), 제공자/모델 (provider/model)
• 지연 시간 (latency), 토큰 수 (token counts), 비용 추정치 (cost estimates)
• 보안 플래그 (예: secret_pattern_detected, tool_denied)
  원문 텍스트 (raw text)는 통제된 디버그 모드에서만 로깅되어야 하며, 암호화된 격리 저장소에 짧은 보관 기간을 설정하여 저장해야 합니다.[5]

📊 멀티 테넌트 (multi-tenant) 또는 파트너 전용 경로 (예: Meta)의 경우, 하나의 침해가 연쇄적으로 확산되는 것을 방지하기 위해 테넌트별 키 (per-tenant keys)와 스코프 (scopes)를 사용하십시오.[6][2]

5.3 CI/CD 및 ML SecOps 통합
ML 및 라우터 코드의 CI/CD에 보안 검사를 포함시키십시오:[2][8]

• 안전하지 않은 eval, 역직렬화 (deserialization), 셸 호출 (shell calls)에 대한 정적 분석 (Static analysis)
• 취약하거나 악성인 패키지에 대한 의존성 스캔 (Dependency scanning)
• 라우터 컨테이너 및 설정에 대한 아티팩트 서명 (Artifact signing)

엔드 투 엔드 관측성 (End-to-end observability)은 클라이언트에서 라우터, LLM 제공자, RAG 저장소, 그리고 다시 돌아오는 요청을 추적하여 비정상적인 동작 (대량 내보내기, 반복적인 도구 오용)을 탐지할 수 있어야 합니다.[1][7]

💡 실제 사례
30명 규모의 SaaS 스타트업은 자사의 로그 저장소에

거버넌스 (Governance), 레드팀 (Red-Teaming), 그리고 지속적인 ML SecOps

Mercor의 사례만으로는 다음 Mercor 사태를 방지할 수 없습니다. 거버넌스 (Governance)와 운영 (Operations)이 핵심입니다.

6.1 LLM 보안을 공식적인 프로그램으로 취급하십시오
배포된 모든 LLM 시스템에 대해 조직은 다음을 수행해야 합니다:[5][7]

• AI 리스크 및 LLM 보안에 대한 명시적인 책임(Ownership) 할당
• 제3자 라우터 (Third-party routers) 및 h