Brex가 공개한 CrabTrap은 프로덕션 환경의 에이전트를 보호하기 위한 HTTP 프록시로, 핵심 아이디어는 "LLM을 심판으로 세워" 요청과 응답을 중간에서 검사하는 것입니다.1 단순한 신기능 소개로 볼 수도 있지만, 이 발표가 중요한 이유는 에이전트 보안의 무게중심이 이제 모델 자체가 아니라 실행 경로 전체로 이동하고 있음을 보여주기 때문입니다.
지금 이 시점이 특히 중요한 건, 에이전트가 더 이상 채팅창 안에 머물지 않기 때문입니다. 최근 흐름은 장시간 추론, 다중 도구 호출, 외부 웹 접근, 내부 시스템 연동으로 이어지고 있고, 이때 문제는 "틀린 답"이 아니라 "잘못된 행동"이 됩니다.2 CrabTrap은 바로 그 행동 경로를 통제하려는 시도라는 점에서 봐야 합니다.
왜 'LLM 프록시'가 갑자기 핵심 인프라가 됐나
전통적인 API 프록시는 인증, 라우팅, 속도 제한에 강합니다. 하지만 에이전트 트래픽은 다릅니다. 프롬프트 안에 지시가 숨어 있고, 도구 호출이 연쇄적으로 일어나며, 출력 자체가 민감정보 유출이나 정책 위반이 될 수 있습니다. 그래서 최근 프록시는 단순 네트워크 중계기가 아니라, 입력 검증·출력 검사·정책 집행·감사 로깅을 수행하는 실행 통제 지점으로 재정의되고 있습니다.3
CrabTrap의 "LLM-as-a-judge"도 이 맥락에 있습니다. 룰 기반 필터만으로는 잡기 어려운 우회 표현, 장문 컨텍스트 속 지시 오염, 도구 사용 맥락을 모델이 해석하게 만드는 방식입니다. 이 접근은 에이전트 보안이 정적 규칙만으로 해결되지 않는다는 현실 인식에 가깝습니다.
실무적으로 중요한 포인트는 하나입니다. 애플리케이션마다 가드레일을 흩어놓는 방식은 오래 못 갑니다. 모델 제공자도 섞이고, 프레임워크도 LangGraph, CrewAI, 자체 오케스트레이터 등으로 분산되기 때문입니다. AWS가 AgentCore에서 런타임, 게이트웨이, 정책, 평가, 관측성을 별도 기능으로 묶는 것도 같은 방향입니다.4 통제는 점점 "앱 내부"가 아니라 "공통 진입점"으로 이동하고 있습니다.
에이전트 보안의 진짜 문제는 프롬프트가 아니라 실행 환경이다
이 문제를 과소평가하면 안 되는 이유는 이미 여러 사례가 보여줍니다. Vitalik Buterin은 에이전트가 웹페이지 같은 외부 입력을 파싱하는 순간 프롬프트 인젝션, 데이터 유출, 악성 도구 실행 위험이 현실화된다고 지적했습니다.2 이건 철학적 우려가 아니라, 에이전트가 파일·네트워크·지갑·브라우저에 손을 대기 시작한 구조적 변화입니다.
더 강한 경고는 벤치마크 연구에서도 나옵니다. UC Berkeley 연구진은 주요 에이전트 벤치마크 8종이 평가 환경 자체를 조작해 높은 점수를 낼 수 있었다고 밝혔습니다.5 이 사례는 "모델이 똑똑한가"보다 "시스템이 얼마나 쉽게 속는가"가 더 중요한 질문이 됐다는 뜻입니다.
CrabTrap 같은 프록시는 여기서 의미가 있습니다. 에이전트가 무엇을 생각하는지는 완전히 통제하기 어렵지만, 어떤 HTTP 요청을 보내고 어떤 응답을 받는지는 훨씬 더 다루기 쉽습니다. 즉, 보안의 단위를 모델 내부에서 찾지 말고, 관측 가능하고 차단 가능한 경계면에서 찾자는 접근입니다.
하지만 LLM 심판이 만능은 아니다
여기서 반론도 분명합니다. LLM에게 보안을 맡기면, 결국 또 다른 LLM 판단 오류에 기대는 것 아니냐는 질문입니다. 이 우려는 타당합니다. LLM 심판은 규칙 기반 필터보다 유연하지만, 일관성과 재현성은 약할 수 있습니다. 비용과 지연도 늘어납니다. 특히 고빈도 에이전트 호출에서는 프록시 단계의 추가 판단이 체감 성능에 مباشرة 영향을 줍니다.
그래서 현실적인 설계는 "LLM만"이 아니라 계층형이어야 합니다. 먼저 고정 정책으로 명백한 금지 행위를 막고, 그다음 애매한 케이스만 LLM 심판으로 넘기는 식입니다. 일부 오픈소스 프록시들이 라우팅, 세션 압축, 도구 출력 축약, 보안 제어를 함께 넣는 것도 같은 이유입니다.6 프록시는 보안장비이면서 비용 제어 장치이기도 합니다.
또 하나의 한계는 HTTP 프록시가 잡을 수 없는 영역입니다. 로컬 파일 시스템, 샌드박스 탈출, 평가 하네스 조작, OS 수준 권한 상승은 프록시만으로 막기 어렵습니다. 그래서 로컬 모델, 샌드박싱, 권한 분리, 네트워크 제한 같은 하부 통제가 여전히 필요합니다.2 CrabTrap은 중요한 조각이지만 전체 답은 아닙니다.
도입 판단 기준: 누구에게 지금 필요한가
CrabTrap류의 프록시가 당장 필요한 팀은 분명합니다. 브라우저·코드 실행·사내 API 호출 같은 도구를 붙인 에이전트를 이미 운영 중이거나, 곧 외부 사용자에게 개방할 팀입니다. 이런 경우는 모델 품질보다 "무슨 요청이 나가고, 누가 승인했고, 무엇이 차단됐는가"가 더 중요합니다.
반대로 단순 질의응답 챗봇이라면 과한 투자일 수 있습니다. 이 경우는 프록시보다 데이터 경계, 로깅, 키 관리, 기본적인 출력 필터가 우선입니다.
앞으로의 판단 기준은 명확합니다. 에이전트 보안을 모델 선택 문제로만 보지 말고, 프록시에서 무엇을 검사하는지, 어떤 정책이 중앙에서 집행되는지, 차단·승인·감사 기록이 남는지 봐야 합니다. CrabTrap이 던진 신호는 이것입니다. 에이전트의 위험은 이제 프롬프트 안이 아니라, 프로덕션 트래픽 위에서 관리해야 합니다.1
참고
1CrabTrap: An LLM-as-a-judge HTTP proxy to secure agents in production
2My self-sovereign / local / private / secure LLM setup, April 2026
3What Is an LLM Proxy and How Proxies Help Secure AI Models - Security Boulevard
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.