암호화했지만 모델끼리는 읽혔다…reasoning trace 격리의 빈틈
Original: Stealing Reasoning Traces from Proprietary LLM APIs View original →
API가 숨겨 둔 reasoning trace는 읽을 수 없는 암호문처럼 보이지만, 같은 제공자의 다른 모델에는 여전히 유효한 입력이었다. 연구진은 OpenAI, Anthropic, Google의 API가 돌려주는 서명·암호화 reasoning block을 새 세션이나 다른 사용자, 다른 모델로 옮긴 뒤 더 약한 형제 모델을 우회했다. 두 번의 API 호출만으로 감춰진 추론을 평문에 가깝게 복원할 수 있다는 것이 이번 연구의 핵심이다.
실험은 단순한 화면 재현에 머물지 않았다. 120개 Codeforces 문제에서 API가 보고한 hidden thinking token 수와 복원된 추론 길이가 함께 움직였고, 복원 내용도 원래 풀이 흐름을 따라갔다. 강한 모델의 trace 일부를 Kimi-K3에 미리 넣자 보이는 답변의 표현까지 원 모델 쪽으로 이동했다. reasoning block이 불투명한 영수증이 아니라, 모델이 다시 소비할 수 있는 상태라는 증거다.
규모를 넓히자 보안 문제가 선명해졌다. 연구진은 GitHub와 Hugging Face에 공개된 6,708개 agent trajectory에서 315,320개 reasoning block을 재구성했다. 그 안에서 API key 62개, password 33개, access token 24개, 개인 이메일 30개를 포함한 704개 민감 artifact를 찾았다. 이 가운데 64개는 사용자에게 보이는 대화에는 없고 숨은 추론에만 존재했다. 공개 로그를 정리할 때 최종 답변만 살피는 방식으로는 충분하지 않다는 뜻이다.
또 하나의 쟁점은 reasoning summary의 충실성이다. 일부 수학 문제에서 모델은 답을 먼저 떠올린 뒤 계산을 붙였지만, API summary는 처음부터 차근차근 유도한 것처럼 정리했다. 요약은 내부 과정을 그대로 보여 주는 감사 기록이 아니며, 모델 행동을 설명하는 자료로 사용할 때 별도 검증이 필요하다.
커뮤니티 토론은 공격 이름보다 경계 설계에 집중했다. trace를 세션이나 사용자에 묶지 않은 점이 가장 먼저 지적됐고, 사용자가 비용을 낸 token을 '훔친다'고 부를 수 있는지에 대한 논쟁도 이어졌다. 표현과 별개로 방어 방향은 분명하다. 제공자는 reasoning state를 계정·세션·모델에 강하게 바인딩하고, 개발자는 공개 trajectory에서 암호화 block까지 비밀정보 검사 대상으로 다뤄야 한다.
연구 페이지와 논문은 재현 결과 및 사례를 공개한다. 원문은 Stolen Thoughts에서 확인할 수 있고, 토론은 Hacker News 스레드에 이어진다. 실제 secret 값은 재전파하지 않고 결과의 범위와 방어 의미만 살피는 편이 안전하다.
Related Articles
235개 댓글의 관심은 “모델이 맞힌 답”보다 “그 답에 붙은 reasoning trace가 실제 이유인지”에 모였다.
1390점을 넘긴 논점은 단순했다. 같은 모델이라도 많이 아는 사람이 더 세게 밀어붙일 수 있다는 이야기다.
2026-07-28 MCP specification release candidate가 transport-level session management를 제거했다. Google은 Python, TypeScript, Go, C# beta SDK가 이미 새 규격을 지원하며, GitHub MCP Server도 Redis session storage를 없앴다고 밝혔다.