Bouncer는 MCP 프록시를 통해 에이전트의 이메일·파일 공유 요청을 검사하고, 목적지가 같은 서버의 신뢰할 수 없는 출력에서 먼저 발견됐다면 전송을 거부한다. 다만 AgentDojo 시험에서 공격자에게 보낸 전송은 막았지만 정당한 이메일 전송·파일 공유 작업도 모두 차단했다. 현재 v0.1.4 초기 버전이며 MCP 호출만 다룬다.
Bouncer는 프롬프트 인젝션을 탐지하지 않는다. 에이전트가 악성 지시를 따를 수 있다고 가정하고, MCP를 통해 실행하는 작업을 제한한다. 판단은 LLM이 아닌 규칙에 따라 결정되며, 허용·거부·사람에게 확인 요청한 모든 결과를 ~/.bouncer/audit.jsonl에 기록한다. bouncer report 명령으로 감사 로그를 바탕으로 한 검토용 문서를 만들 수 있다.
설치와 적용
Python 3.12 이상에서 설치한 뒤 MCP 클라이언트 설정을 백업하고 프록시를 적용한다. init은 변경된 설정을 출력하고 파일에 쓰기 전에 확인을 요청한다. --server <name>을 지정하면 일부 서버에만 적용할 수 있다.
uv tool install bouncer-mcp # or: pipx install bouncer-mcp (Python 3.12+)
cp .mcp.json .mcp.json.bak
bouncer init --config .mcp.json # add --server <name> to wrap only some servers
Claude Code의 .mcp.json, Cursor의 ~/.cursor/mcp.json, macOS의 Claude Desktop 설정처럼 mcpServers 항목이 있는 설정을 사용할 수 있다. 설정을 바꾼 뒤 클라이언트를 다시 시작해야 한다. 데스크톱 앱이 셸의 PATH를 찾지 못하면 설정의 command에 which bouncer가 출력하는 경로를 넣어야 할 수 있다.
목적지를 알 수 없어 사람에게 확인을 요청하는 ask 동작은 클라이언트의 MCP elicitation 지원이 필요하다. 지원하지 않는 클라이언트에서는 ask가 모두 거부로 처리되므로, 자주 쓰는 수신처를 정책의 trusted_destinations에 등록해야 한다. 정책 안내와 60초 빠른 시작에서 설정 방법을 확인할 수 있다.
서버를 시작할 때 도구 목록을 기록하고 이후 호출을 전달하기 전에 도구가 시작 시점에 존재했는지, 호출 예산과 경로·정규식 검사에 걸리지 않는지 등을 확인한다. 서버가 반환한 텍스트와 구조화된 내용은 모두 신뢰할 수 없는 정보로 기록한다. 이후 그 안에 나타난 목적지로 보내려는 요청은 거부한다. 목적지를 추적할 수 없으면 허용하지 않고 사람에게 확인을 요청하며, 승인한 목적지는 해당 세션이 끝날 때까지 기억한다. 차단된 호출은 실제 서버로 전달되지 않는다.
파일 쓰기 경로 제한, 도구별 세션 호출 횟수 제한, 인수 정규식 검사 등의 규칙은 YAML 정책으로 설정할 수 있다. 자체 정책 항목으로 도구 규칙을 덮어쓸 때는 전송 도구의 exfiltrating과 sink_params도 다시 지정해야 목적지 검사가 유지된다. 경로 접두사는 절대 경로를 쓰는 것이 권장된다. 상대 경로는 클라이언트가 프록시를 시작한 디렉터리를 기준으로 해석된다.
시험 결과와 제약
제작자가 AgentDojo workspace 제품군 v1.2.2에서 important_instructions 공격과 openai/gpt-4o-mini 에이전트를 사용해 시험한 결과, 공격자에게 데이터를 보내려 한 공격은 Bouncer 없이 164건 중 48건 성공했고, Bouncer를 적용했을 때는 163건 중 0건이었다. Bouncer 조건의 0건은 95% 신뢰구간 기준 상한이 2.2%다. 다만 이 시험에서는 Bouncer가 전송이나 공유를 한 건도 허용하지 않았으므로, 결과는 정당한 전송과 공격을 구별하는 능력을 보여주지 않는다.
정상 작업 완료율은 40건 중 33건에서 30건으로 떨어졌다. 이메일 전송·파일 공유 작업은 6건 중 4건에서 0건으로 감소했다. 공격이 없는 조건에서도 수신 주소가 도구 출력에 함께 등장한 경우 등이 정상 작업을 막았다. 신뢰 수신처 목록으로 되살아난 것은 해당 목록의 주소를 쓴 두 작업뿐이었다. 공격 조건에서는 전송 작업 완료가 Bouncer 없이 24건 중 8건, 적용 시 24건 중 0건이었다.
시험은 MCP 프록시가 아니라 AgentDojo의 도구 호출 루프 안에서 엔진을 실행했고, 사람 확인 요청은 모두 거부로 처리했다. 고정된 공격 템플릿을 사례별 한 차례 적용했으며, 이메일·파일 공유로 데이터를 보내는 공격만 평가했다. 파일 삭제나 일정 생성 등 다른 공격은 측정하지 않았다. 제작자는 이 결과가 일반적인 방어 능력의 증거가 아니라고 명시한다. 시험 결과와 조건 및 세부 결과를 확인할 수 있다.
적용 범위는 MCP 호출뿐이다. 에이전트가 셸이나 원시 HTTP에 접근할 수 있으면 우회할 수 있다. 내용 자체를 검사하는 데이터 유출 방지 도구도 아니므로, 신뢰된 목적지로 민감한 내용이 전송되는 것은 막지 않는다. 목적지 기록은 프록시 서버와 세션별로 분리되며 재시작하면 지워진다. 다른 서버에서 읽은 목적지로 보내려는 경우는 거부가 아니라 확인 요청으로 이어질 수 있다.
목적지 일치 검사는 대소문자와 공백을 정규화한 뒤 문자열 그대로 비교한다. 인코딩되거나 조합된 주소는 거부 대상이 아니라 확인 요청 대상이며, 6자 미만 목적지는 오염된 것으로 표시하지 않는다. 도구의 목적지 인수 목록이 불완전하면 검사하지 못하는 인수가 생길 수 있다. 파일 경로 검사는 ..을 정리하지만 심볼릭 링크를 해석하지 않는다. 시작 후 도구 스키마가 바뀌어도 이를 감지하지 못한다. 상세 제약은 limits 문서에 정리돼 있다.
감사 로그에는 UTC 시각, 도구, 전체 인수, 판정, 사유와 적용 규칙이 기록된다. 로그는 일반 텍스트이며 이메일 본문을 포함해 에이전트가 전달한 인수가 담길 수 있고, 위변조를 감지하는 장치는 없다. 또한 0.1.0~0.1.2에서는 프록시 모드가 Bouncer 자체 도구를 노출해 감사 로그 밖에서 호출될 수 있었으며, 0.1.3에서 이를 제거했다. 이전 버전을 쓰고 있다면 업그레이드해야 한다. 변경 기록에서 해당 수정 내용을 볼 수 있다.
저장소와 설치 안내는 GitHub 저장소, PyPI 패키지에서 확인할 수 있다. 현재 MCP over stdio 방식으로 한 대의 컴퓨터에서 동작하며, 실시간 Gmail·Slack·GitHub·Google Drive 서버에서 검증되지 않은 정책 묶음이 있다. 제작자가 밝힌 향후 계획에는 이미 고정된 도구의 스키마 변경 감지, mcp 2.x 지원, 해당 서버에서 검증한 정책 묶음이 포함되지만 아직 구현되지 않았다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요