facts
이번에 공개된 CrabTrap은 AI 에이전트가 외부 API나 인터넷에 요청을 보낼 때 이를 가로채 승인 여부를 결정하는 오픈소스 HTTP/HTTPS 프록시 플랫폼이다. Brex는 OpenClaw와 같은 에이전트 프레임워크를 엔터프라이즈 규모로 확장하는 과정에서 기존의 SDK 수준 권한 관리나 모델 가드레일만으로는 에이전트의 실제 동작을 완전히 제어할 수 없다는 점을 확인하고 이 도구를 구축했다.
CrabTrap의 핵심 기술 사양은 다음과 같다. 우선 프레임워크, 언어, API에 구속되지 않는(Agnostic) 구조를 가진다. 에이전트 환경 변수에 `HTTP_PROXY`와 `HTTPS_PROXY`를 설정하는 것만으로 모든 아웃바운드 요청을 라우팅할 수 있다. 정책 결정 프로세스는 결정론적인 '정적 규칙(Static Rules)'과 비결정론적인 'LLM-as-a-judge(판별기 모델)'의 하이브리드 방식으로 작동한다.
판별기 모델로는 응답 속도가 빠른 Claude Haiku를 사용한다. 모든 요청을 모델이 검토하는 것이 아니라, 이미 정의된 정적 규칙에 해당하지 않는 '롱테일(Long-tail)' 영역의 생소한 엔드포인트나 특이한 요청 형태에 대해서만 LLM 판별기가 작동한다. 실제 운영 데이터 기준, LLM 판별기가 호출되는 비중은 전체 요청의 3% 미만이다. 모든 감사 추적(Audit trail) 데이터는 PostgreSQL에 저장되며, 관리자 API와 대시보드를 통해 쿼리할 수 있다.
how-it-works
CrabTrap은 전송 계층(Transport Layer)을 핵심 아키텍처 구성 요소로 활용한다. 에이전트가 API 키나 OAuth 토큰을 사용해 네트워크 요청을 보내면, 프록시가 이를 가로채 정책 규칙과 대조한다. 이때 가장 먼저 정적 규칙을 적용해 빠르게 처리하고, 규칙 외의 요청에 대해서만 LLM 판별기가 개입해 승인 또는 거부 결정을 내린다.
정책을 수립하는 방식은 '사전 정의'가 아닌 '관찰 기반의 부트스트래핑(Bootstrapping)'이다. Brex는 정책을 처음부터 작성하는 대신, 실제 에이전트의 동작을 관찰해 정책을 도출하는 파이프라인을 구축했다. 구체적인 단계는 다음과 같다.
1. 섀도 모드(Shadow Mode): 에이전트를 실제 환경에서 실행하되, 정책 결정이 실제 트래픽에 영향을 주지 않는 상태로 네트워크 트래픽을 수집한다.
2. 분석 및 샘플링: 수집된 과거 네트워크 트래픽을 분석하고 대표적인 호출 사례를 샘플링한다.
3. 정책 초안 작성: 자체적인 에이전트 루프(Policy Builder)가 샘플링된 데이터를 바탕으로 에이전트의 실제 동작과 일치하는 자연어 정책 초안을 작성한다.
4. 검증(Eval): 작성된 초안을 과거 감사 로그와 대조해 승인/거부 결과가 어떻게 변하는지 리포트로 출력한다. 사용자는 메서드, URL, 원래 결정, 일치 여부별로 결과를 슬라이싱해 검토할 수 있다.
보안 측면에서는 LLM 판별기를 대상으로 한 프롬프트 인젝션(Prompt Injection) 공격을 차단하는 메커니즘을 적용했다. 판별기가 받는 HTTP 요청의 모든 내용은 사용자가 제어할 수 있으므로, 이를 단순 텍스트로 삽입(Interpolation)하지 않고 JSON 객체 구조로 구성해 전송한다. 이를 통해 사용자 제어 콘텐츠가 모델 내에서 실행 코드가 아닌 '이스케이프(Escaped)'된 데이터로 처리되도록 강제했다.
implementation-impact
개발자와 인프라 운영자가 CrabTrap과 같은 네트워크 제어 평면을 도입할 때 고려해야 할 핵심은 제어 지점의 이동이다. 기존의 MCP(Model Context Protocol) 게이트웨이가 프로토콜 계층에서 정책을 강제하고, Nvidia OpenShell이 샌드박스 기반의 이그레스(Egress) 제어를 제공한다면, CrabTrap은 모든 네트워크 요청이 통과하는 전송 계층에서 제어권을 갖는다.
실무적으로 가장 큰 변화는 지연시간(Latency) 관리 방식이다. 모든 요청에 LLM을 배치하면 시스템 전체가 느려질 위험이 크지만, Brex는 두 가지 전략으로 이를 해결했다. 첫째, 고빈도 트래픽 패턴을 빠르게 정적 규칙으로 전환해 LLM 호출 빈도를 3% 미만으로 낮췄다. 둘째, Claude Haiku와 같은 소형 모델을 사용해 판별기가 작동할 때의 추가 지연시간을 무시할 수 있는 수준으로 억제했다. 향후 로컬 모델 도입과 프롬프트 캐싱을 통해 이를 더 낮출 수 있다.
또한, 운영자는 감사 로그를 통해 에이전트가 생성하는 '노이즈'를 가시화할 수 있다. 거부 로그와 트래픽 분석을 통해 불필요한 도구 호출을 제거하거나, 에이전트 자체의 프롬프트를 수정해 요청 카테고리를 최적화하는 피드백 루프를 구축할 수 있다. 이는 단순한 보안 강화를 넘어, 에이전트의 토큰 비용 절감과 실행 효율성 향상으로 이어진다.
결과적으로 개발자는 '에이전트에게 어떤 권한을 줄 것인가'라는 정적인 고민에서 '에이전트가 실제로 어떻게 행동하고 있으며, 이를 어떻게 정교하게 깎아낼 것인가'라는 동적인 운영 관점으로 전환해야 한다. 이는 에이전트의 기능성(Capability)과 안전성(Safety) 사이의 트레이드오프를 해결하는 실질적인 구현 경로가 된다.
