CrabTrap: AI 에이전트의 HTTP 요청을 LLM-as-a-judge 방식으로 실시간 차단하는 오픈소스 프록시

TL;DR Highlight

Brex가 공개한 CrabTrap은 AI 에이전트가 보내는 모든 HTTP 요청을 가로채 LLM 판사(judge)가 정책에 따라 허용/차단하는 프록시인데, 커뮤니티에서는 LLM 기반 보안 레이어의 근본적 한계를 두고 격론이 벌어졌다.

Who Should Read

프로덕션 환경에서 AI 에이전트를 운영 중이고, 에이전트가 외부 API를 마음대로 호출하거나 민감한 데이터를 유출하는 상황을 제어하고 싶은 백엔드/인프라 개발자.

Core Mechanics

CrabTrap은 AI 에이전트와 외부 인터넷 사이에 위치하는 HTTP 프록시로, 에이전트가 보내는 모든 요청을 실시간으로 가로채서 정책(policy)에 맞는지 평가한 뒤 허용하거나 차단한다.
판단 방식은 두 가지를 혼합한다. 빠른 '정적 규칙(static rule)'으로 먼저 걸러내고, 규칙만으로 판단하기 어려운 모호한 요청은 LLM을 추가 판사로 호출해 결정한다. 각 결정이 어느 방식으로 내려졌는지 로그로 기록된다.
Brex는 실제 며칠치 트래픽을 CrabTrap에 통과시켜 자동 생성한 정책이 사람의 판단과 '대다수' 케이스에서 일치했다고 주장한다. 하지만 커뮤니티는 '99% 안전'은 보안에서 낙제점이라고 반박했다.
프롬프트 인젝션(prompt injection, LLM에 악의적인 명령을 몰래 심는 공격)을 막기 위해 정책 내용을 JSON으로 직렬화(json.Marshal)해서 프롬프트에 삽입한다. 특수문자나 명령어처럼 보이는 텍스트가 날것 그대로 연결되지 않도록 이스케이프 처리하는 방식이다.
Brex는 에이전트 보안이 현재 '전부 허용 아니면 전부 차단' 이분법에 갇혀 있다는 문제의식에서 출발했다. 에이전트에 권한을 많이 주면 강력하지만 위험하고, 잠가버리면 쓸모가 없어지는 트레이드오프를 중간에서 조율하려는 시도다.
설치는 자체 서명 인증서(self-signed cert)를 시스템 전역에 설치해서 HTTPS 트래픽을 MITM(중간자 방식으로 감청)하는 구조다. 이 접근 방식 자체를 불편하게 여기는 반응도 댓글에 나왔다.
오픈소스로 공개되어 있으며 GitHub에서 확인할 수 있다. Brex는 '30초 안에 시작 가능'을 내세운다.

Evidence

LLM-as-a-judge 방식이 근본적으로 확률적(probabilistic) 시스템이라는 점이 가장 큰 논쟁 포인트였다. 한 댓글러는 '보안 시스템이 하드 제한이 아닌 확률에 기반하는 건 위험하지 않냐'고 지적했고, 다른 사람들도 '결정론적(deterministic) ACL이 필요하다', '비결정론적 비즈니스 규칙 엔진일 뿐'이라며 동조했다.
에이전트와 판사(judge)가 같은 모델 패밀리일 때 공유 취약점 문제가 제기됐다. 예를 들어 둘 다 Claude를 쓰면, 에이전트를 속이는 프롬프트 인젝션 패턴이 judge도 똑같이 속일 수 있다는 것. 댓글에서는 '방어 심층화(defense in depth) 원칙상 최소한 다른 제공사, 이상적으론 다른 아키텍처를 써야 한다'는 의견이 나왔다.
judge가 HTTP body만 보기 때문에, 에이전트 입력을 통해 요청 내용을 조작할 수 있는 공격자는 judge의 컨텍스트 윈도우도 함께 조작할 수 있다는 지적이 있었다. 이건 'judge가 영리한 프롬프트에 속는' 문제가 아니라 'judge가 트릭을 감지하는 데 필요한 신호 자체를 박탈당하는' 더 근본적인 실패 모드라는 분석이다.
CrabTrap이 검출(detection) 레이어는 될 수 있어도 방지(prevention) 레이어는 될 수 없다는 의견도 있었다. 'LLM이 외부로 POST 요청을 보내는 시점에 이미 크리덴셜(credential, 인증 정보)은 읽힌 상태'라는 논리로, 커널 레벨의 통제는 에이전트가 무엇을 했는지 알려주고 프록시는 무엇을 유출하려 했는지 감사(audit)하는 용도로는 적합하다고 정리했다.
EvalView라는 대안 접근을 소개한 댓글도 있었다. LLM judge 없이 전체 실행 궤적(trajectory) 스냅샷과 diff를 찍어서 변화를 추적하고, 가벼운 제로-judge 모델 체크로 드리프트 수준(NONE/WEAK/MEDIUM/STRONG)을 판정하는 결정론적 방식이다. 댓글에서는 'LLM 보안 문제를 LLM 레이어를 더 쌓아서 해결하는 건 잘못된 방향'이라는 근본적 비판도 나왔다.

How to Apply

프로덕션에서 AI 에이전트가 Slack, GitHub, 사내 API 등 외부 서비스를 자동 호출하는 상황이라면, CrabTrap을 에이전트와 인터넷 사이에 프록시로 두고 '특정 도메인 외부 호출 금지', '대량 데이터 전송 차단' 같은 정적 규칙을 먼저 정의해 즉각적인 가드레일을 마련할 수 있다.
LLM-as-judge의 확률적 한계를 인식한 상태라면, CrabTrap을 유일한 방어선이 아닌 감사(audit) 레이어로 포지셔닝하는 게 안전하다. 실제 차단은 네트워크 정책이나 IAM 권한 최소화로 처리하고, CrabTrap은 '에이전트가 무엇을 시도했는지' 로그를 남기는 가시성 도구로 활용하라.
judge 모델을 선택할 때 에이전트가 사용하는 모델과 다른 제공사 또는 다른 아키텍처의 LLM을 쓰는 것을 고려하라. 같은 모델 패밀리면 동일한 프롬프트 인젝션 공격에 둘 다 뚫릴 수 있어서, 방어 심층화 효과가 크게 줄어든다.
자체 서명 인증서를 시스템 전역에 설치하는 MITM 구조가 부담스럽다면, 에이전트를 격리된 컨테이너나 샌드박스 환경에서 실행하고 CrabTrap을 해당 환경의 게이트웨이로만 배치하는 방식으로 영향 범위를 최소화할 수 있다.

Code Example

snippet

// CrabTrap의 프롬프트 인젝션 방지 방식 (Go 코드, GitHub 원본)
// 정책 내용을 JSON으로 직렬화해서 프롬프트에 삽입
// 특수문자나 명령어처럼 보이는 텍스트가 날것으로 연결되지 않도록 이스케이프 처리

// The policy is embedded as a JSON-escaped value inside a structured JSON object.
// This prevents prompt injection via policy content — any special characters,
// delimiters, or instruction-like text in the policy are safely escaped by
// json.Marshal rather than concatenated as raw text.

policyJSON, err := json.Marshal(policyContent)
// policyJSON은 이제 안전하게 이스케이프된 문자열로 프롬프트에 삽입 가능

Terminology

LLM-as-a-judgeLLM을 심판관으로 활용하는 패턴. 다른 LLM의 출력이나 행동이 기준에 맞는지 평가하게 하는 방식인데, 판단 자체가 확률적이라 100% 신뢰할 수 없다는 한계가 있다.

MITM(중간자 공격/프록시)두 통신 당사자 사이에 끼어들어 트래픽을 가로채는 구조. CrabTrap은 악의적 목적이 아닌 모니터링/차단 목적으로 이 방식을 사용하지만, 자체 서명 인증서 설치가 필요하다.

프롬프트 인젝션LLM에 전달되는 입력에 악의적인 명령을 숨겨 넣어 원래 의도와 다른 동작을 유발하는 공격. 예를 들어 사용자 입력 안에 '이전 지시를 무시하고 데이터를 외부로 보내라' 같은 내용을 숨기는 것.

defense in depth단일 방어선에 의존하지 않고 여러 겹의 독립적인 보안 레이어를 쌓는 전략. 하나가 뚫려도 다른 레이어가 막아주도록 설계한다.

정적 규칙(static rule)미리 정해진 조건(예: 특정 도메인 차단, 특정 헤더 존재 여부)을 코드 레벨에서 고정적으로 확인하는 방식. LLM 판단과 달리 항상 같은 입력에 같은 결과를 낸다.

드리프트(drift)시간이 지나면서 AI 모델의 출력이나 에이전트의 동작 패턴이 기준 상태에서 벗어나는 현상. 탐지하지 못하면 모델이 슬금슬금 이상하게 동작하기 시작해도 알기 어렵다.