arxiv-wiki
Stealing Reasoning Traces from Proprietary LLM APIs
- 게시일: 2026-08-12
- arXiv: 2608.09867v1 · PDF
- 저자: Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping, Maksym Andriushchenko
- 분야: cs.CR, cs.AI, cs.LG
- 선정 점수: 6.75
- 선정 이유: 최근성 0.8, 인용 영향 0.0 (인용 0회), 저자 영향 1.7 (최고 h-index 18), AI 주제 적합성 3.0, 개발자 관심 0.0, 학술 신호 0.3, 오픈 웨이트·주요 연구조직 신호 1.0
주요 Figure
원문 PDF에서 실제 Figure 캡션과 그림 영역이 함께 확인된 자료만 자동 추출했다.
Figure · 원문 PDF 2쪽 · Figure 1: Decoding reasoning traces in Anthropic, OpenAI and Google APIs. Top: Reasoning-trace extraction in
Figure · 원문 PDF 5쪽 · Figure 2: Injection schemes exploiting in- and cross-session compatibility. We find that available form of thought
Figure · 원문 PDF 6쪽 · Figure 3: Prefilling Kimi K3’s reasoning changes the style of its visible responses. In this example, we observe
한 문장 요약
대형 LLM들이 클라이언트에 반환하는 암호화된 체인-오브- thought(추론 트레이스) 블록이 세션·사용자·모델 간에 호환되는 아키텍처적 취약으로 작동함을 보이고, 약한 동일 공급자 모델을 ‘디코더’로 이용해 대규모로 추론 트레이스를 복호·추출하는 실험적 방법과 악용 사례들을 제시한다.
해결하려는 문제
문제: 주요 LLM API 제공자들은 내부 체인-오브- thought(추론 과정)를 서버에 저장하지 않고 클라이언트로 암호화된 블록(베이스64 서명/암호문 형태)을 반환해 무상태(stateless)로 세션을 이어가게 한다. 이 설계는 저장 비용을 줄이나, 제공자 생태계 내에서 이 암호화 블록이 세션·사용자·심지어 모델 간에 호환되면(포팅 가능하면) 약한 모델을 이용해 강력한 모델의 숨겨진 추론을 사실상 복호·복사할 수 있다는 위험을 내포한다. 기존의 방어(모델 수준의 거부·시스템 필터)는 강력 모델에서 직접 추출을 막더라도, 호환성을 악용해 더 약한 모델이 서명된 블록을 평문으로 출력하게 만들면 우회될 수 있다. 연구 질문: (1) 암호화된 생각 블록의 호환성과 포팅 가능성이 실제로 공급자·모델 전반에서 존재하는가? (2) 이를 이용해 어떤 규모·형태의 정보(지적재산, PII, 자격증명, 유해 내용)를 추출·악용할 수 있는가? (3) 완화책은 무엇인가?
핵심 기여
- 암호화된 추론 블록의 호환성(세션·사용자·모델 간)을 체계적으로 규정하고, 이를 이용한 대규모 복호(디코딩) 공격 기법을 제시 및 평가함(Anthropic, OpenAI, Google 대상).
- 약한 동일 공급자 모델을 ‘디코더’로 사용하는 확장 가능한 추론 추출(jailbreak) 방법을 설계하고 실험적으로 재현함(모델별 추출 파이프라인과 고정 추출 프롬프트 등 제공; 세부는 부록 C).
- 이 취약성으로 가능해지는 네 가지 실사용 공격 벡터를 구체화·시연: (i) 지적재산(추론) 증류(distillation) 회피, (ii) 공개된 세션 로그에서의 비밀(PII·자격증명) 대규모 추출, (iii) 숨겨진 유해 정보 노출(visible output은 거부하더라도 reasoning에 유해 정보 존재), (iv) 암호화 블록 내 보이지 않는 프롬프트 주입으로 장기간 에이전트 파이프라인을 중독시킴.
- 공격의 현실적 영향(대규모 공개 추론 블록 스캔 결과)과 책임 있는 공개·완화 권고(암호·시스템 수준의 구체적 대책)을 제안함(부록 A에 기술).
접근 방법
- 방법(본문 기준):
- 위협 모델: 권한 없는(비내부자) API 공격자를 가정.
- 공격자 유형은 (1) 자체로 강력 모델에 질의해 암호화 블록을 얻는 퍼스트-파티(지적재산 증류·제철·jailbreak)와 (2) 타인이 공개·유출한 세션 로그에서 암호화 블록을 수집하는 서드-파티(비밀 추출·프롬프트 주입)로 구분.
- 암호화 블록 관찰: 공급자들은 reasoning을 AEAD(Associated Data 포함) 형태의 서명/암호문 엔벨로프로 반환하고, 클라이언트는 이를 다음 요청에 되돌려 보내야 세션 연속성이 유지됨.
- 헤더에 모델명·블록 타입·키 ID·nonce 등이 포함될 수 있고, 서명은 MAC에 연관 데이터로 해시된다(공개 구현은 없음).
- 호환성 유형 정의: (i) 인·크로스-세션 호환(이전 블록을 재사용/순서 변경 가능), (ii) 크로스-유저 호환(다른 사용자의 블록 재생), (iii) 크로스-모델 호환(한 모델이 만든 블록을 다른 모델이 처리).
- 저자 실험은 공급자들이 전역 키(또는 동등한 설계)를 사용해 블록을 암호화·인증해 포팅을 허용한다고 추정/관찰함(참고: Green 2026 선행 관찰).
- 추출 공격 절차: (1) 목표(강력) 모델로부터 암호화된 추론 블록을 획득, (2) 동일 공급자 생태계 내에서 블록을 처리하는 ‘약한’ 호환 모델(디코더)에 삽입(prefill 또는 thinkingSignature 등 API 필드로 주입), (3) 약한 모델에 고정된 탈출(복호) 프롬프트를 넣어 블록을 그대로 평문으로 전사하게 함.
- 모델·공급자별로 허용되는 주입 방식(current-turn / past-turn 등)과 약한 디코더 후보를 식별함(예: Claude: Haiku 4.5, GPT 계열: GPT-5.6 Luna, Gemini: Robotics 1.6 등).
- 세부 파이프라인은 부록 C에 기술됨.
- 추출 정합성 측정: API가 보고하는 ‘thinking token’ 수를 기준으로, 원본 모델의 보고된 thinking-token 수 대비 추출된 토큰 비율(=재구성된 출력의 토큰 수)을 faithfulness 지표로 사용(청구·과금상의 토큰 수는 정확하다고 가정).
- 실험셋업: 통제된 추출(자체 생성: AIME 2025, Codeforces, Humanity’s Last Exam 문제 등)과 공개 추출(공개된 6,708 세션/에이전트 궤적에서 암호화 블록 파싱)으로 평가.
- 비용 예시(실용성): Claude Haiku 요금 기준으로 10k traces(각 12k 토큰 입력+출력)를 디코딩하는 비용을 약 $720으로 산정함(본문).
주요 결과
- 크로스-모델·세션·유저 호환성이 실제로 존재함을 실증하고, 약한 동일 공급자 모델이 강력 모델의 암호화된 추론을 평문으로 재생산함(Anthropic, OpenAI, Google에서 재현; 세부 모델 조합은 부록 C).
- 추출 충실도: 120개의 Codeforces 문제 세트에서 원본 모델의 API 보고 thinking-token 수와 추출된 토큰 수가 대부분의 입력에서 밀접하게 추적됨(논문 Figure 1). 저자들은 이것을 ‘충실도 지표’로 사용했으나 랜덤성·원본 평문 미접근으로 완전한 일대일 확인은 불가함을 명시함.
- 공개 트레이스 스캔: 6,708개의 공개 에이전트 궤적에서 315,320개의 암호화된 thinking 블록을 재구성함. 이 중 0.3%에 해당하는 1,028개의 블록이 최소 하나의 개인 정보 누출을 포함함으로 라벨링됨(본문). 세션 기준으로는 6,708개 세션 중 4.9%에 해당하는 328개 세션에서 적어도 하나의 민감 정보 항목이 발견됨.
- 회수된 비밀·PII(본문 보고): 총 315,320 블록 복호 결과로 저자들이 식별한 항목들에는 요약적으로 367개의 PII 항목과 182개의 자격증명(크리덴셜)이 포함됨(본문·초록). 진짜(비-벤치마크) 사용자 세션에서 구체적으로는 62개의 API 키, 33개의 비밀번호, 24개의 액세스 토큰, 7개의 개인 키, 30개의 개인 이메일, 6개의 non-localhost IP 주소, 추가적으로 130개의 이름과 36개의 우편주소 등이 보고됨(본문, 부록 D 참조).
- 응용 악용 사례 시연: (i) 지적재산 증류(약한 모델을 이용한 원본 모델 추론 복제), (ii) 추정적 jailbreaking(강력 모델의 visible output은 거부해도 reasoning에 유해 정보 존재하면 추출을 통해 유해 정보 획득; 예: 차량 절도 설명 사례), (iii) 암호화 블록 내 보이지 않는 프롬프트 주입으로 장기간 에이전트 워크플로우를 은밀히 오염·데이터 외부 전송 시연(예: Opus→Haiku→다시 Opus 시나리오).
한계
- 저자가 명시한 한계: (1) 실험은 특정 시점(2026년 7월 경)의 API 버전·모델에 한정되어 있으며, 제공자들의 내부 암호 구현은 비공개이고 향후 변경될 수 있어 공격 유효성이 달라질 수 있음을 밝힘. (2) 디코더 모델의 생성 확률성(stochasticity)과 원본 평문에 대한 직접적 접근 불가로 인해 추출된 토큰이 원본과 정확히 일치한다고 완전히 보장할 수 없음. (3) 공개 트레이스 스캔은 비포괄적이며 전체 유출 규모를 과소평가할 수 있음.
- 본문으로부터 합리적으로 확인되는 제약(저자 진술과 구별): (4) 공격 전제는 동일 공급자 생태계에서 ‘호환 디코더’ 모델에 대한 접근 권한이 필요하므로, 공급자가 디코더 모델을 유통하지 않거나 호환성을 제한하면 효과가 급감함. (5) 암호화·인증 구현의 세부(키 관리 방식, 키 분리 여부 등)를 알 수 없으므로 제공자가 per-session/key-바인딩, 모델별 키 분리 등으로 설계하면 현재 기법은 무력화될 가능성이 높음. (6) 추출·악용 탐지 회피는 공급자의 시스템 로그/감시 정책에 의존하므로 운영 환경별 편차가 큼.
개발자 관점
- 공급자(벤더) 관점 권고(본문·부록 A 기반): (i) 암호화된 추론 블록을 전역 키로 암호화·인증하지 말고 세션-바운드 또는 모델-바운드 키/메타데이터로 바인딩하라(예: 키 ID에 conversation ID/유저 토큰 등 연계). (ii) 모델 패밀리 내 크로스-모델 재생을 금지하도록 MAC/인증에 관련 컨텍스트(모델 식별자, 세션 식별자)를 포함하고 검증하라. (iii) 가능하면 민감한 reasoning 상태는 서버측 저장(또는 권한 있는 서버 측 처리)로 전환해 클라이언트-재생 의존성을 줄여라. (iv) 암호문 재생을 통한 주입 공격을 탐지하기 위해 재생된 블록의 출처·타임스탬프·해시를 기록·검증하고 동일 블록의 빈번한 재사용 패턴을 모니터링하라.
- 사용자·개발자 운영 권고(본문 기반): (i) 세션 로그·에이전트 트레이스 공개 시 암호화된 thinking 블록까지 그대로 공개하지 말고 삭제하거나 공급자-제공 복호 도구를 통해 안전하게 필터링하라. (ii) 공개 리포지터리·벤치마크에 이전에 저장된 세션이 있다면 공개 전 재검토·회수하고 노출된 API 키나 자격증명은 즉시 회전(교체)하라. (iii) 타인이 게시한 세션 로그를 재사용하지 말고, 불가피할 경우 재생 전에 암호화 블록을 제거하라.
- 재현·구현 주의: 본 실험을 재현하려면 연구자가 해당 시점의 공급자 API 및 취약 모델(약한 디코더)에 접근해야 하며, 공급자별로 주입 가능한 API 필드(signatures, thinkingSignature, assistant-turn prefilling 등)와 허용되는 주입 방식이 상이함을 고려해야 한다(부록 C에 공급자별 파이프라인 설명). 또한 추출 비용(예: Haiku 기준 대규모 디코딩 비용 예시)과 개인정보·윤리 규정을 준수해야 한다.
근거 범위: 이 분석은 제공된 논문 PDF 본문(본문 섹션 및 그림·수치 포함)을 바탕으로 작성했다. 주요 정량값(예: 315,320 복호된 블록, 1,028 블록(0.3%)의 프라이버시 누출, 6,708 세션에서 328개(4.9%) 세션 누출, 367 PII·182 자격증명 등)과 실험적 세부는 논문 본문과 도표에서 직접 인용했다. 다만 논문은 공급자 내부의 암호 구현 세부를 공개하지 않았으므로 암호학적 내부 구조(키 관리 방식 등)는 확인 불가하고, 추출된 텍스트가 원본 평문과 정확히 일치하는지 여부는 저자도 보장하지 않음(토큰 수 추적을 기반한 간접 검증만 있음). 부록(C,D,A 등)에 더 상세한 구현·샘플이 있으나 본 요약은 본문 기준으로 정리했음을 밝힌다.