신뢰할 수 없는 LLM 프록시가 코딩 에이전트에 미치는 실험적 위험 분석

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

에이전트가 모델 응답에 포함된 도구 호출을 자동 실행하는 특성 때문에 응답을 변조할 수 있는 프록시는 단순히 메시지를 읽는 수준을 넘는 공격자가 될 수 있다; 와이어 포맷을 통해 첫 응답에 '.env' 읽기 호출을 주입하자 세 가지 서로 다른 에이전트 구현에서 기밀이 승인 절차 없이 유출되었고 일부 런타임에서는 악의적 명령이 무단 실행되었다. 이러한 결과는 네트워크·쓰기 차단만으로는 충분하지 않음을 보여주며 에이전트 안전성은 모델이 아니라 런타임 하니스와 그 기본 설정에 의해 좌우된다는 점이 확인되었다. 따라서 신뢰할 수 없는 엔드포인트를 사용하지 않는 것이 기본 방어이며 추가로 런타임 격리, 자격증명 분리, 최소 권한 및 egress 정책 같은 실행 시점의 강제 규칙이 필요하다.

주요 논점

01찬성다수

프록시가 에이전트 응답에 도구 호출을 주입하면 에이전트의 자동 실행 루프가 기밀 유출과 명령 실행을 초래할 수 있다고 주장되며 이 주장은 세 에이전트를 대상으로 한 재현 실험으로 뒷받침되었다.

02찬성다수

에이전트의 안전성은 모델 자체가 아니라 런타임 하니스의 구성에 좌우되므로 격리와 최소 권한, 런타임 정책 집행이 실무적 해결책으로 제시되었다.

합의점 vs 논쟁점

합의점

에이전트가 모델 응답을 신뢰하여 도구 호출을 실행하는 설계가 존재하며 이 설계가 공격 표면을 제공한다.
네트워크 차단이나 쓰기 제한 같은 전통적 샌드박스는 작업 공간 내부 읽기 데이터의 유출을 막지 못하는 경우가 잦다.
런타임 수준에서의 정책 집행과 자격증명 분리는 실무적으로 필요한 방어 수단이다.

논쟁점

편의성 때문에 권한 프롬프트를 비활성화하거나 허용리스트를 넓히는 설정을 사용할 때 보안 리스크를 수용할 것인지 여부가 논쟁적이다.
어떤 수준의 자동화와 무인 실행(CI·headless)이 허용 가능한지에 대한 운영적 기준이 분열되어 있다.

실용적 조언

신뢰할 수 없는 모델 공급자를 통해 에이전트 트래픽을 라우팅하지 말고 공급자 도메인과 엔드포인트를 사전에 검증할 것.
런타임에서 도구 호출별 권한을 강제하는 정책을 적용하고 작업 공간 파일 접근, 네트워크 egress, 외부 쓰기 권한을 분리해서 최소 권한 원칙을 구현할 것.
CI나 무인(headless) 실행 환경에서는 권한 프롬프트를 허용하지 않거나 별도의 검증 계층을 추가해 자동 실행을 차단할 것.
민감한 자격증명이나 비밀은 에이전트가 접근 가능한 작업 디렉토리에 두지 않고 별도 비밀 관리 시스템을 통해 런타임 시 안전하게 주입할 것.

섹션별 상세

에이전트-모델 상호작용의 구조는 모델 응답에 도구 호출이 포함되면 에이전트가 이를 실행하고 결과를 다시 모델에 전달하는 자동화 루프이다. 이 구조에서 와이어 포맷은 요청과 응답의 필드 배치와 도구 호출 표기를 규정하므로 중간에 위치한 프록시는 응답 필드에 임의의 도구 호출을 삽입할 수 있다. 글쓴이는 세 가지 실제 에이전트를 대상으로 프록시가 첫 응답에서 도구 호출을 주입하는 실험을 수행했고 모든 에이전트가 주입된 호출을 처리하는 동작을 보였다고 보고했다. 이 결과는 에이전트의 설계상 응답을 신뢰해 실행하는 특성이 공격 표면으로 악용될 수 있음을 의미한다.

여러 터미널 창을 띄워 프록시·에이전트 실험 환경을 동시에 보여주는 스크린샷이다. — Screenshot이미지는 실험이 로컬 환경의 여러 런타임 인스턴스에서 병렬로 수행되었음을 시각적으로 확인시켜 주며 각 창이 에이전트 세션을 나타낸다. 하단 캡션은 'Step 1: Run modified LLM providers'로 프록시를 띄우는 단계임을 나타내며 실험 절차의 초기 단계를 시사한다. 이 이미지는 실험 재현을 위한 환경 구성을 간접적으로 뒷받침하는 증거로 활용될 수 있다.

프록시와 에이전트를 동시에 띄운 데스크톱 화면의 다른 크롭 이미지로 실험 환경을 보여준다. — Screenshot두 번째 이미지는 첫 번째 이미지와 동일한 실험 구성의 다른 포착으로, 다수의 에이전트 인스턴스와 터미널 레이아웃을 재확인하게 한다. 캡션과 화면 구성은 프록시 실행이 실험의 출발점이며 모의 공급자 실행이 여러 에이전트에 어떻게 영향을 미쳤는지를 보여줄 준비 단계였음을 뒷받침한다. 이미지 자체에는 구체적 로그나 명령 출력이 보이지 않아 세부 수치나 명령 행 증거로는 제한적이다.

파일 읽기가 에이전트 작업의 일상적 기능이라는 점에서 기밀 정보 유출이 매우 쉬웠다; 프록시는 첫 응답에 '.env'를 읽는 도구 호출을 집어넣었고 세 에이전트 모두 승인 절차 없이 파일 내용을 반환했다. Claude Code는 읽기 전용 툴(Read/Grep/Glob)을 자동 승인했고 Codex CLI는 non-interactive exec 모드에서 승인 정책이 'never'로 기본 설정되어 있어 cat .env가 승인 없이 실행되었으며 OpenCode는 read 툴에 대한 방어를 우회하기 위해 bash 툴을 통해 같은 파일을 읽게 했다. 이 관찰은 네트워크 차단이나 쓰기 방지 같은 샌드박스 조치만으로는 기밀성 손실을 막을 수 없다는 점을 분명히 했다.

명령 실행 통제는 에이전트 자체가 아니라 각 에이전트를 둘러싼 하니스(harness)와 그 기본 설정에 의해 결정되었다. Claude Code는 기본적으로 Bash 실행 전에 프롬프트를 요구하는 반면 해당 프롬프트를 비활성화하는 플래그(--dangerously-skip-permissions) 또는 허용 리스트를 켜면 그 장애가 사라졌다. Codex는 Seatbelt 샌드박스에서 시스템 호출 수준으로 탈출을 방어했지만 작업 공간 내의 읽기·편집에는 제약을 가하지 않았고 OpenCode의 headless run 모드는 샌드박스나 프롬프트 없이 bash를 자동 실행했다. 이 차이는 동일한 워크플로를 다른 런타임으로 옮기거나 CI에서 무인 실행하면 공격 가능성이 크게 달라진다는 사실을 보여주었다.

권고적 교훈은 엔드포인트가 에이전트를 실질적으로 통제한다는 점이며 따라서 신뢰할 수 없는 제공자를 통한 요청 라우팅을 피하는 것이 첫 방어선이다. 그럼에도 불구하고 어떤 엔드포인트든 악성 동작을 할 수 있으므로 런타임 격리, 자격증명 분리, 최소 권한 정책, 네트워크·출력 경로에 대한 엄격한 egress 제어 같은 다층 방어가 필요하다고 보고자는 주장했다. 글쓴이는 이런 권고를 구현한 오픈소스 런타임(Agyn)을 공개 연구와 함께 제시했고 추가 세부사항을 본문과 링크에서 제공했다.

용어 해설

Wire Format: — 에이전트와 모델 프로바이더 간에 주고받는 메시지의 직렬화 규격으로, 요청과 응답에서 도구 호출, 도구 결과, 메타데이터가 어떤 필드에 들어가는지와 승인 흐름을 규정한다. 와이어 포맷은 중간자(프록시)가 응답을 조작하거나 도구 호출을 주입할 수 있는 지점을 제공하며 에이전트의 자동 실행 루프에 직접 영향을 준다.
Coding Agent: — 모델의 응답을 바탕으로 파일 읽기, 쉘 실행 같은 도구를 자동으로 호출하고 그 결과를 다시 모델에 피드백하는 루프를 수행하는 실행 엔진으로, 응답에 포함된 도구 호출을 신뢰하고 자동으로 실행하도록 설계되어 있다. 에이전트의 자동화 특성 때문에 외부 엔드포인트가 반환하는 내용이 곧바로 권한 있는 작업으로 이어질 수 있다.
Seatbelt Sandbox: — 작업 실행을 제한하기 위해 프로세스 수준에서 시스템 호출을 제어하는 런타임 격리 계층으로, 네트워크 접근·파일 쓰기 등 특정 소콜 호출을 차단하여 탈출 시도를 막는다. 샌드박스는 탈출에 대한 방어에는 유효하지만 에이전트가 합법적으로 접근 가능한 파일을 읽어 모델 채널로 유출하는 문제는 차단하지 못하는 경우가 있다.

언급된 도구

Claude Code중립

코딩 에이전트 런타임

Codex CLI중립

명령형 코딩 에이전트로 작업 실행과 샌드박스 기반 제어 제공

OpenCode중립

채팅/코드 에이전트 런타임

Agyn추천링크

에이전트 격리와 런타임 정책 집행을 목표로 한 오픈소스 런타임

언급된 리소스

문서Untrusted LLM proxy agent risk