기술 요약: 프록시는 너무 많은 것을 알고 있다: 검증된 TEE를 통한 LLM API 라우터 봉인

1. 문제 정의

본 논문은 대규모 언어 모델(LLM) API 라우터의 아키텍처에 존재하는 심각한 보안 취약점을 식별한다. 에이전트가 여러 모델 제공자에게 접근하기 위해 중개자에 점점 더 의존함에 따라, 이 라우터들은 애플리케이션 계층의 중간자(Man-in-the-Middle, MitM) 지점 역할을 하게 된다. 라우터는 클라이언트의 전송 계층 보안(TLS) 세션을 종료하고 별도의 업스트림 세션을 시작함으로써, 요청과 응답의 전체 상호작용을 평문(plaintext) 상태로 보유하게 된다.

이러한 구조적 설계는 라우터 운영자에게 에이전트 데이터에 대한 완전한 가시성과 제어권을 부여하며, 이를 통해 네 가지 유형의 악의적인 공격을 가능하게 한다:

• AC-1 (도구 호출 재작성): 라우터는 클라이언트에 도달하기 전에 도구 호출(예: 셸 명령)을 변경할 수 있다. 이 재작성은 스키마상 유효하므로, 클라이언트는 악의적인 명령을 실행하게 되어 잠재적으로 원격 코드 실행(RCE)으로 이어질 수 있다.
• AC-1.a (타이포스쿼팅): 라우터는 설치 명령에서 종속성을 타이포스쿼팅된 패키지로 교체하여, 도메인 기반 허용 목록을 우회하고 공급망 거점을 확보할 수 있다.
• AC-1.b (트리거 기반 공격): 라우터는 특정 조건(예: 특정 키워드 또는 요청 횟수) 하에서만 재작성을 실행하여, 유한한 프로브 세트를 실행하는 감사자(auditor)의 탐지를 회피할 수 있다.
• AC-2 (수동적 정보 유출): 라우터는 상호작용을 변경하지 않고도 트래픽을 스캔하여 자격 증명 및 비밀 정보를 찾아내어 유출할 수 있다.

기존의 클라이언트 측 방어 기제(정책 게이트, 이상 징후 스크리닝)는 회피 가능하다는 것이 입증되었다. 본 논문은 근본적인 해결책이 제공자의 협조에 의존하지 않고도 클라이언트가 검증할 수 있는 당사자로 신뢰 경계(trust boundary)를 이동해야 한다고 주장한다.

2. 방법론: AEGIS

저자들은 AEGIS를 제안한다. 이는 제공자 투명성을 갖춘 검증된 API 라우터로, 관리 기능은 신뢰할 수 없는 호스트에 남겨두되, 평문 처리를 하드웨어로 격리된 인클레이브(enclave) 내로 한정한다.

핵심 아키텍처

AEGIS는 라우터를 두 개의 뚜렷한 신뢰 도메인으로 분리한다:

1. 신뢰할 수 없는 호스트(Untrusted Host): 인증, 계정 선택, 스케줄링, 과금 및 관리를 담당한다. 호스트는 요청/응답 본문이나 네트워크 주소를 절대 전달하지 않는 좁은 제어 채널을 통해 인클레이브와 통신한다.
2. 검증된 인클레이브(Attested Enclave, TEE): 최소한의 충실한 데이터 경로를 실행한다. 이는 클라이언트의 TLS 세션을 종료하고, 요청 및 응답 바이트를 고정된 제공자에게 그대로 전달하며, 사용량 텔레메트리만을 호스트에 보고한다.

주요 메커니즘

• 충실한 패스스루(Faithful Passthrough): 인클레이브 코드는 어떠한 의미론적 변형도 수행하지 않는다. 요청과 응답을 바이트 단위로 그대로 전달한다. 이를 통해 코드 검증(attestation)이 데이터 흐름의 무결성을 보장하도록 한다.
• 실패 시 폐쇄(Fail-Closed) 검증: 클라이언트가 평문(프롬프트, 도구 호출, 자격 증명 등)을 공개하기 전에, 로컬 사이드카가 인클레이브의 원격 검증을 확인한다. 클라이언트는 인클레이브의 측정값이 고정된 감사 값과 일치하고 현재 세션에 바인딩된 경우에만 데이터를 전송한다.
• 목적지 권한(Destination Authority): 정당한 업스트림 목적지 집합은 인클레이브의 측정된 이미지에 "구워져(baked)" 있다. 호스트는 이름(정책)으로만 경로를 요청할 수 있으며, IP나 URL로는 요청할 수 없다. 인클레이브는 이 이름을 고정된 목적지로 해석하여, 호스트가 트래픽을 악의적인 엔드포인트로 리다이렉트하는 것을 방지한다.
• 앵커드 측정(Anchored Measurement, ARPA): 시스템은 Audit(감사), Reproduce(재현), Pin(고정), Attest(검증) 프로토콜을 사용한다. 운영자는 투명성 로그에 기록되고 서명된 재현 가능한 빌드 매니페스트를 게시한다. 클라이언트는 소스를 감사하고, 측정값을 검증하기 위해 재현 가능한 빌드를 수행하며, 그 결과를 고정(pin)한다. 이를 통해 클라이언트는 중앙 감사자 없이도 코드를 신뢰할 수 있다.

3. 주요 기여

본 논문은 네 가지 주요 기여를 설명한다:

1. 제공자 투명적 설계: 정밀한 악의적 운영자 모델 하에서 네 가지 악의적 라우터 공격 클래스(AC-1, AC-1.a, AC-1.b, AC-2)를 모두 차단하는 라우터 아키텍처를 제공하며, 제공자 측의 변경 없이도 작동한다.
2. 최소 신뢰 기반(Minimal Trusted Base): 충실한 패스스루만이 인클레이브에서 실행되는(851 라인의 신뢰 코드) 기밀성 우선 설계를 통해, 인증과 과금은 신뢰할 수 없는 호스트에 남겨둠으로써 신뢰 컴퓨팅 기반(TCB)을 최소화한다.
3. 측정값 equals 감사된 코드: 재현 가능한 빌드와 투명성 로그를 사용하는 ARPA 프로토콜을 통해, 사용자나 에이전트가 중앙 권한 없이도 신뢰를 고정할 수 있도록 한다.
4. 경험적 평가: AEGIS가 낮은 오버헤드를 유지하면서 네 가지 공격 클래스를 차단함을 보여주는 종합적인 테스트를 수행하였다. 여기에는 적응형 테스트, ProVerif를 통한 형식 검증, 실제 제공자 워크로드 테스트가 포함된다.

4. 결과 및 평가

저자들은 AWS Nitro Enclaves에서 AEGIS를 구현하고 이를 평문 접근 베이스라인과 비교 평가하였다.

• 보안 효과성: 네 가지 공격 클래스(AC-1 ~ AC-2) 모두 평문 베이스라인에는 성공했으나, AEGIS에 의해 완전히 차단되었다. 적응형 테스트를 통해 호스트가 도구 호출을 재작성하거나, 타이포스쿼트를 주입하거나, 조건부 재작성을 트리거하거나, 비밀 정보를 유출할 수 없음을 확인했다.
• 형식 검증: Pro-Verif를 사용한 심볼릭 모델은 프로토콜 순서, 검증된 릴리스, 목적지 권한을 확인하였으며, 개별 체크를 제거했을 때 시스템이 실패함을 입증하였다.
• 감사 가능성: 시드 감사 파일럿 테스트에서 두 개의 범용 코딩 에이전트(Codex 및 Claude Code)가 최소 신뢰 코드 내에 심어진 불변성 위반 사항을 각각 8/10 및 10/10 비율로 성공적으로 식별하여, 작은 코드베이스가 검토 가능하다는 주장을 검증하였다.
• 성능 오버헤드:
  • 지연 시간(Latency): 로컬 릴레이는 작은 페이로드당 요청당 약 6밀리초의 지연을 추가한다.
  • 확장성: 암호화 및 경계 통과로 인해 페이로드 크기에 따라 오버헤드가 증가하지만(4MB 페이로드 시 약 183ms), 모델 호출 자체의 지연 시간보다는 훨씬 낮다.
  • 동시성: 시스템은 중간 정도의 병렬성(최대 16개 동시 요청)을 처리하며, 중앙 지연 시간은 단일 요청 값의 20% 이내를 유지한다.
  • 스트리밍: 시스템은 제공자의 토큰 간격을 보존하며, 토큰 사이의 지터(jitter)를 발생시키지 않는다.

5. 의의 및 주장

본 논문은 AEGIS가 널리 배포된 오픈 소스 라우터 템플릿에 대한 최초의 최소 신뢰 코드, 재현 가능한 인클레이브 리트로핏(retrofit)임을 주장한다. 그 의의는 다음과 같다:

• 신뢰 경계의 이동: 신뢰 경계를 라우터 운영자(완전히 신뢰할 수 없는 대상)로부터 검증 가능한 하드웨어 인클레이브로 이동시켜, 운영자가 사후에 탐지되는 것이 아니라 악의적인 행동을 할 수 없도록 만든다.
• "배포 격차(Deployment Gap)" 해소: 클라이언트가 제공자에게 새로운 API나 인프라를 추가하도록 요구할 수 없는 문제를 해결한다. AEGIS는 기존 제공자와 표준 HTTPS 업스트림과 함께 작동한다.
• 에이전트 의미론 보존: "충실한 패스스루"를 엄격히 강제함으로써, 도구 호출 및 스트리밍 구조가 온전하게 유지되도록 보장한다. 이는 정확한 제공자 응답에 의존하는 코딩 에이전트에게 매우 중요하다.

저자들은 하드웨어 신뢰 루트(root of trust)에 의존하고, 사이드 채널 공격으로부터 보호하지 못하며, 현재 트래픽 크기 및 타이밍에 관한 잔여 누출이 존재한다는 점을 인정하며 한계점에 대해 겸허한 태도를 유지한다. 또한 현재의 프로토타입은 단일 홉(single-hop) 솔루션이지만, 향후 다중 홉 검증된 업스트림으로 확장될 수 있음을 언급한다.