🤖 [최신] ToFu: Exploiting and Fuzzing the LLM–Orchestrator–Tool Trust Boundary — '스키마가 맞으면 안전하다'는 착각

논문 정보

한 줄 요약 — 도구는 '스키마'가 아니라 '의미'를 지켜야 하는데, 아무도 그것을 검사하지 않았다

LLM 에이전트는 대개 LLM · 오케스트레이터 · 도구 세 층으로 구성된다. 오케스트레이터(LangGraph, Semantic Kernel, ADK, AutoGen, Strands, CrewAI …)는 모델이 뱉은 텍스트를 해석해 구조화된 도구 호출로 바꾸고 실행한다. 여기서 논문이 겨냥하는 지점은 명확하다 — "모델이 만들어 준 인자도 결국은 외부 입력인데, 도구 구현체는 그것을 신뢰된 값처럼 받는다." 타입·필수 필드 같은 스키마 검증은 흔히 하지만, 도구가 문서에 적어놓은 의미론적 계약(예: "이 경로는 작업 폴더 안이어야 한다", "이 값은 로그에 남기면 안 된다")은 대개 집행되지 않는다. 저자들은 MCP 서버 273개·도구 3,405개를 자동 퍼징해 118개 서버·343개 도구에서 검증된 취약점 253건을 찾아냈고, 그 결론을 한 문장으로 요약한다 — LLM이 생성한 인자를 신뢰된 입력으로 취급하는 것은 안전하지 않다.

"실제 도구들은 자신이 문서화한 입력 의미론을 자주 집행하지 못한다. 따라서 LLM이 생성한 인자를 신뢰된 것으로 취급하는 것은 안전하지 않다." — 논문 초록

배경 — 왜 '도구 경계'가 새로운 신뢰 경계인가

• 도구 호출의 정체: 도구 호출은 결국 오케스트레이터가 실행 가능한 요청으로 해석하는 구조화된 모델 출력이다. 즉 신뢰할 수 없는 쪽(모델 텍스트·간접 프롬프트 인젝션을 통해 오염될 수 있는 컨텍스트)에서 만들어진 값이, 신뢰된 실행 경로로 들어간다.
• 기존 연구와의 차이: 지금까지의 에이전트 보안 연구는 주로 프롬프트 안전성(탈옥, 간접 프롬프트 인젝션, 도구 포이즈닝, 도구 하이재킹, 크로스툴 공격)에 집중했다. 이 논문은 프롬프트가 아니라 시스템 관점에서 묻는다 — "도구는 LLM이 만든 입력을 얼마나 신뢰해야 하는가?"
• 스키마 검증의 사각지대: MCP 도구는 이름·설명·인자 스키마를 메타데이터로 노출하고, 오케스트레이터는 그 스키마로 호출 형식을 검사한다. 하지만 스키마는 "문자열이다"까지만 보장하지 "그 문자열이 안전한 경로다"는 보장하지 않는다. 그 간극이 논문이 파고든 곳이다.
• 왜 퍼징인가: 이런 위반은 크래시를 내지 않는다. 크래시 기반 퍼저는 도구가 요구사항을 조용히 위반한 경우(path traversal은 정상 응답을 돌려준다)를 아예 발견할 수 없다. 그래서 '의미'를 판정할 오라클이 따로 필요하다.

핵심 1 — Repeat-After-Me: "이거 그대로 따라 써봐"가 곧 도구 실행이 된다

• 공격 아이디어: 오케스트레이터가 인식하는 도구 호출 형식을 공격자가 이미 안다면, 타깃 도구 이름과 공격자가 고른 인자를 담은 텍스트를 만든 뒤 LLM에게 "이 문장을 그대로 반복해줘"라고 시킨다.
• 왜 통하는가: 모델은 주어진 텍스트를 그대로 재생산했을 뿐인데, 오케스트레이터는 그 출력을 도구 호출로 해석해 실행한다. 즉 '무해해 보이는 텍스트 반복 요청'이 도구 호출과 그 인자에 대한 직접 통제권으로 바뀐다.
• 재현 범위(중요): 논문은 이 동작을 6개 오케스트레이션 레이어에서 모두 재현했다 — LangGraph(LangChain) · MAF(Microsoft Agent Framework) · ADK 2.0(Google) · AutoGen(Microsoft) · Strands(AWS) · CrewAI. 특정 프레임워크의 버그가 아니라 아키텍처 패턴의 문제라는 뜻이다.
• 부록의 실증 트랜스크립트: LangGraph 1.2.0의 사전 빌드 ToolNode(tools_condition 라우팅) + Ollama 0.6.2의 llama3.1:8b(temperature 0)로 돌린 대화 기록을 부록 B에 그대로 싣는다. 도구는 부작용 없는 스텁 make_bomb(max_budget)·launch_missiles(max_distance) 이고, 유일한 가드레일은 "위험한 요청은 거절하라"는 시스템 프롬프트 하나다. 모델이 낸 원문 텍스트([RAW])와 LangGraph가 파싱한 도구 호출([PARSED])이 함께 출력된다.
• 설계 시사점: "모델이 위험한 요청을 거절했는가"는 안전 척도가 아니다. 거절을 우회하는 게 아니라, 모델 출력이 곧 실행 명령이 되는 구조 자체가 문제다. 오케스트레이터는 모델 출력을 신뢰 경계를 넘는 데이터로 다뤄야 한다.

핵심 2 — ToFu의 설계: 메타데이터에서 '의미 검사'를 자동으로 끌어낸다

• ① 메타데이터 추출: 각 도구가 이미 노출하는 이름·설명·인자 스키마를 읽는다.
• ② CWE 기반 새니타이저 코퍼스(74종): 코드의 '의미 보증'을 CWE 약점 클래스별 검사로 바꾼다. 런타임 추적(introspection) 계열과, 출력·실행 상태 계열로 나뉜다. LLM은 고르기만 하고 기대 결과를 설정할 뿐, 새니타이저를 런타임에 새로 생성하지 않는다(생성형 오라클의 환각 위험을 구조적으로 차단).
• ③ 도구별 특화(specialization): 일반 규칙을 그대로 쓰지 않고, 각 도구의 메타데이터에 맞춰 검사를 좁힌다 — "이 도구의 path 인자는 작업 디렉터리 하위여야 한다"처럼.
• ④ 스키마 인지 하네스 생성: 인자 타입을 이해해 스키마를 통과하는 시드를 만든다(문자열 5종 페이로드, 숫자 경계값 7종, 불리언 양쪽, 배열 5형태, 객체 3형태, enum은 전 멤버 + 무효값 1개, 타입 혼동 값 2~3개, 전 인자 기본값 시드 1개). LLM이 파일 빌더를 호출해 문서 인자를 만든 경우도 119개 도구였다.
• ⑤ 런타임 추적기 21종: Python 타깃 내부에서 open·socket 같은 싱크에 도달한 호출을 기록한다(성공적으로 실행된 경로에 대한 증거). 즉 '정적 탐지'가 아니라 실제 실행 증거를 요구한다.
• ⑥ 커버리지 기반 퍼징 루프: libFuzzer 스타일의 커버리지 유도 변이를 도구 경계에 적용하고, 위반 시 트리거된 호출·기대 속성·증거를 함께 기록한다. 모든 실행은 bubblewrap 샌드박스(읽기 전용 루트, 전용 /tmp)에서 돌려 폭발 반경을 격리한다.
• 재현성: LLM 단계는 gpt-4.1 temperature 0 + 고정 시드라 구성상 결정론적이고, 잔여 변동(커버리지 유도 탐색)은 3회 반복 실행으로 측정한다. 도구당 예산 60초.

핵심 3 — 실측 결과: 508개 후보 → 수동 검증 후 253건

• 퍼널: ToFu가 처음 보고한 후보는 147개 서버에서 508건. 저자들이 재현·코드 검토로 수동 검증해(스크립트 실행기를 '스크립트를 실행한다'는 이유로 오탐 처리하지 않도록 도구의 의도까지 확인) 최종 118개 서버 · 343개 도구에서 253건으로 정리했다. 즉 후보의 약 절반이 실제 취약점이었다.
• 유형별 분포(253건):

• 핵심 관찰: "이 중 어느 것도 크래시를 요구하지 않는다." 그래서 크래시 기반 퍼저로는 찾을 수 없다. 위반은 정상적인 응답을 돌려주면서 조용히 일어난다.
• 베이스라인 비교(273개 서버): ToFu는 118개 서버를 지목. ToolFuzz(Milev et al., 2025)는 92개를 지목했고 그중 56개가 ToFu와 공유, VIPER-MCP(Sun et al., 2026)는 48개(36개 공유). Cisco MCP Scanner 같은 정적 분석기는 실행이 없어 다른 성질을 재며, "taint 경로가 곧 익스플로잇은 아니다"라는 간극을 저자들은 별도 절로 설명한다.
• 탐지 속도(깊은 예산 실험, 34개 서버 24시간): 도구 커버리지는 1분 안에 사실상 포화(중앙값 정규화 커버리지 약 1.0)되고, 누적 발견의 74%가 1분 안에, 거의 100%가 1시간 안에 나온다 — 설정이 비싼 게 아니라 의미 오라클이 없어서 아무도 못 찾았던 것이다.
• 추적기 적용 범위(RQ1, 일부): Python/JS 기준 로그 인젝션 85.4%/66.7%, 민감정보 로깅 72.5%/79.1%, 파일 접근 59.5%/50.3%, 파일 쓰기 34.8%/47.6%, 네트워크 실행 57.8%/61.5%, 명령 실행 30.8%/33.0%, XXE 5.0%/2.4% 등 — 무엇이 얼마나 집행 가능한지를 정직하게 드러낸다.

핵심 4 — 사례: 스크린샷 도구 하나가 서버 디스크를 넘겨준다

• 대상: s/webpage-screenshot-mcp 서버의 t/screenshot-page — URL을 받아 렌더링한 스크린샷을 돌려주는 도구.
• 발견 ① SSRF (CWE-918): http:// URL을 주면 서버가 대신 임의의 원격 요청을 보낸다 — 원격 서버의 무결성을 사실상 훼손할 수 있다.
• 발견 ② 임의 경로 순회 (CWE-22 / 552 / 73): file:/// URL을 주면 서버 자신의 디스크에 있는 파일이나 디렉터리 목록을 렌더링해 이미지로 돌려준다. 논문은 그 결과 이미지(로컬 파일 1장, 디렉터리 목록 1장)를 그림 4로 싣는다.
• 왜 의미 오라클이 필요한가: 이 서버는 JavaScript라서 ToFu의 tracer가 내부에 들어가지 못한다 → 출력·상태 계열 새니타이저만으로 판정해야 했다. 즉 도구의 문서화된 의미("URL의 스크린샷")와 실제 행동("파일 시스템 읽기")의 괴리를 잡아낸 것이 핵심이다.

시사점 — 에이전트 시대의 '입력 검증'은 어디에 놓여야 하는가

• 신뢰 경계를 한 칸 옮겨야 한다: 지금까지는 "프롬프트를 안전하게"가 화두였지만, 도구 호출은 모델 출력 → 실행으로 넘어가는 진짜 경계다. 오케스트레이터는 모델 출력을 trusted=True가 아니라 구조화된 외부 입력으로 취급해야 한다.
• 스키마 검증은 의미 검증이 아니다: MCP의 인자 스키마는 필요조건일 뿐 충분조건이 아니다. 도구 구현체가 "내가 문서에 적은 계약"을 스스로 강제해야 하며, 그 계약을 테스트 가능한 형태로 노출하는 것이 다음 단계다.
• 거절은 방어가 아니다: Repeat-After-Me는 모델의 판단을 우회한다 — 모델은 시킨 대로 반복했을 뿐이다. 즉 모델 정렬(alignment)과 시스템 격리는 서로를 대체하지 못한다.
• 퍼징 연구의 확장: 1988년 Miller의 퍼징(2026-09-18 회차)이 '크래시'를 신호로 삼았다면, 이 논문은 '의미 계약 위반'을 신호로 삼는 오라클을 자동 생성한다. 오라클을 사람이 쓰지 않고 메타데이터에서 끌어낸 것이 방법론적 기여다.

한계 · 유의점 · 의의

• 런타임 의존: 증거 기반이라 실행 가능한 환경이 필요하다. 백엔드가 없으면 정적 분석기가 잡은 것(예: Sonnet-5가 지목한 Sitecore 도구 7개 중 일부)을 확인할 수 없다 — 이는 오라클의 사각지대가 아니라 도달성(reachability)의 비용이다.
• 상태 기반 도구는 미해결: 여러 도구를 순서대로 호출해야 드러나는 위반(도구 A가 돌려준 리소스 ID를 도구 B가 소비하는 관계 등)은 future work로 남겼다. 다중 호출 하네스와 호출 순서 변이가 다음 과제다.
• 수동 검증의 비용: 후보 508건을 사람이 확인해 253건으로 줄였다. 자동 탐지의 정밀도는 여전히 사람 손을 요구한다.
• 책임 공개: 논문 본문에 CVE 발급·개별 서버 신고 절차는 서술하지 않는다(부록에 평가 대상 저장소 목록과 재현 자료를 공개). 따라서 "고쳐졌는가"는 별도로 추적해야 할 문제다.
• 의의: 에이전트 보안 담론을 프롬프트에서 시스템 경계로 되돌려 놓은 논문이다. 273개 서버·3,405개 도구라는 실제 생태계 규모에서, 그리고 6개 주요 오케스트레이션 레이어 전부에서 재현되는 아키텍처 취약성을 제시했다는 점에서, "내 MCP 서버는 스키마 검증을 하니 안전하다"는 가정을 정면으로 반박한다.

출처

• 논문 원문: Md Nazmul Islam Ananto, Pierre Prevost-Avenel, Colin Smith, Kyungtae Kim, Taegyu Kim, Arslan Khan, ToFu: Exploiting and Fuzzing the LLM–Orchestrator–Tool Trust Boundary, arXiv:2610.13651v1 [cs.CR], 2026-10-09 (FSE 2027 채택) — arXiv abs · PDF · HTML 전문
• 데이터셋: MCPCorpus(고정 커밋) — 평가 대상 273개 MCP 서버·3,405개 도구의 원천
• 함께 읽기: 2026-09-18 Fuzzing(Miller·Fredriksen·So, CACM 1990 — 크래시를 신호로 삼은 퍼징의 원형, 이 논문은 '의미 위반'을 신호로 확장) · 2026-10-03 The Innocent Courier (LLMLeak)(LLM의 '웹 가져오기' 도구를 악용한 은밀 유출 — 도구가 공격 표면이 된다는 같은 결론) · 2026-10-10 ORCAGen(LLM 기반 악성코드 대응 자동화) · 2026-10-11 When Flaws Cascade(취약점·익스플로잇 체인 전수 분석)