에이전트를 배포하기 전, 신뢰 경계를 테스트한 팀이 얼마나 되나요?
솔직히 말해봅시다. 대부분의 팀은 MCP 서버를 연결하고, 툴 호출을 붙이고, 에이전트를 CI/CD에 묶은 다음—보안 테스트 없이 프로덕션에 올립니다. 오케스트레이션 프레임워크가 잘 돌아가면 '된 것'처럼 느껴지기 때문입니다. 하지만 오케스트레이션과 신뢰 경계(Trust Boundary)는 전혀 다른 문제입니다.
최근 세 건의 실증 데이터가 이 간극을 정량적으로 드러냈습니다. 팀 리드라면 배포 전에 반드시 읽어야 할 내용입니다.
핵심 이슈: 신뢰 경계가 무너지는 세 가지 구조적 지점
① 툴 디스크립션은 무방비 인젝션 면(Injection Surface)이다
dev.to에 공개된 332개 보안 테스트 하네스 실험(「Agent Systems Are Failing at Trust Boundaries」)에서 가장 일관되게 실패한 패턴은 MCP 툴 설명 필드를 통한 인젝션이었습니다. LLM은 툴 디스크립션을 컨텍스트 윈도우 안의 '신뢰할 수 있는 지시'로 처리합니다. 개발자가 작성한 시스템 프롬프트와 공격자가 삽입한 툴 설명을 구분하는 메커니즘이 없습니다.
이 취약점은 이론이 아닙니다. 또 다른 실험(「I Poisoned My Own MCP Server in 5 Minutes」)에서는 read_file 툴 디스크립션에 단 한 줄을 추가하는 것만으로 Claude가 ~/.ssh/id_rsa를 사용자 모르게 응답에 포함시켰습니다. 설정 변경 없이, 익스플로잇 없이—그냥 텍스트만으로. CVE-2026-25253(CVSS 8.8)은 이 벡터를 공식 문서화했고, 공개 MCP 레지스트리의 약 12%에서 악용 가능한 디스크립션 패턴이 발견됐습니다.
② 위임 체인(Delegation Chain)에는 신뢰 경계가 없다
멀티 에이전트 아키텍처에서 Agent A가 Agent B에게 작업을 위임할 때, 그 핸드오프는 암호학적 검증 없이 이루어집니다. 332건 테스트에서 에이전트 카드 스푸핑(Agent Card Spoofing)—즉 신뢰된 에이전트인 척하는 악성 에이전트 등록—이 AutoGen, CrewAI, LangGraph 모두에서 기본 설정 그대로 성공했습니다. 더 심각한 건 컨텍스트 누수입니다. 기본 설정으로 실행되는 멀티 에이전트 위임 시나리오의 과반수에서 이전 인터랙션 컨텍스트가 경계를 넘어 흘러들어갔습니다.
프레임워크 버그가 아닙니다. 오케스트레이션 프리미티브를 격리 경계로 착각하는 배포 패턴의 문제입니다.
③ Anthropic 참조 서버도 행동 테스트를 통과하지 못했다
가장 충격적인 데이터는 Fidensa의 독립 보안 감사(「Anthropic's Reference MCP Server Fails Security Audit」)에서 나왔습니다. @modelcontextprotocol/server-filesystem—개발자들이 가장 많이 참조하고 포크하는 공식 구현체—가 행동 보안 인증에서 60점(F 등급)을 받았습니다. 더블 인코딩(%252e%252e%252f) 및 URL 인코딩 경로 우회 공격에 edit_file이 자격증명을 노출했고, read_multiple_files는 AWS 자격증명, SSH 설정, DB 설정 파일 경로를 제한 없이 읽었습니다.
정적 분석 도구는 이 서버에 99~100점을 줬습니다. 유효성 검사 코드가 '존재'하기 때문입니다. 하지만 실제로 공격 페이로드를 던졌을 때 그 가드는 작동하지 않았습니다. 정적 분석은 가드의 존재를 확인하고, 행동 테스트는 가드가 실제로 막히는지를 확인합니다. 두 가지는 다른 질문입니다.
맥락 해석: 왜 지금 이 문제가 터지는가
MCP 에코시스템이 17,000개 이상의 서버로 폭발적으로 성장하는 동안, 검증 인프라는 사실상 부재했습니다. 개발자들은 참조 구현을 복사해서 확장합니다. 참조 구현의 취약점은 에코시스템 전체로 복제됩니다. Fidensa 감사에서 50개 AI 기능 중 7개(14%)에서 치명적 취약점이 발견됐는데, 이 중에는 6개 API 제공업체 자격증명을 수집하고 외부 서비스에 무단 네트워크 연결을 만드는 개발 보조 도구도 있었습니다.
AI-First 팀에게 이 맥락은 특히 중요합니다. 우리는 에이전트를 CI/CD에 통합하고, 외부 MCP 서버를 워크플로우에 연결하고, 멀티 에이전트 오케스트레이션을 프로덕션에 올리는 속도를 높이고 있습니다. 그 속도만큼 공격 면도 확장됩니다.
시사점: 배포 전 최소 방어선 체크리스트
세 건의 실증 데이터를 종합해 팀 리드가 내일 당장 적용할 수 있는 최소 기준을 뽑으면 다음과 같습니다.
[ MCP 툴 보안 ]
- 툴 디스크립션 샌드박싱: 서드파티 MCP 서버의 툴 디스크립션을 LLM 컨텍스트에 그대로 주입하지 마십시오. <IMPORTANT>, 외부 URL, 자격증명 파일 경로, Base64 인코딩 패턴을 필터링하는 레이어를 추가하십시오. Unicode NFKC 정규화를 빠뜨리면 키릴 문자 우회가 통과됩니다.
- 툴 정의 해시 피닝: 최초 승인 시점에 툴 이름 + 디스크립션 + 스키마를 SHA-256으로 해시하고, 이후 로드마다 검증하십시오. 브라우저 SRI와 동일한 원리입니다. 변경 감지 없이는 '러그풀' 공격—승인 후 디스크립션을 조용히 교체하는 방식—을 탐지할 수 없습니다.
- 행동 테스트 필수화: 정적 분석만으로는 부족합니다. 실제로 더블 인코딩, URL 인코딩, 자격증명 경로 직접 요청 페이로드를 던져보십시오. Anthropic 참조 서버도 이 테스트를 통과하지 못했습니다.
[ 멀티 에이전트 위임 ]
- 핸드오프 지점을 공격 면으로 취급: Agent A→B 위임은 신뢰 경계입니다. 암호학적 신원 검증 없는 에이전트 카드는 스푸핑 가능합니다. 위임 체인의 각 핸드오프에서 신원을 검증하십시오.
- 컨텍스트 범위 명시적 제어: LangGraph처럼 상태를 명시적으로 관리하는 프레임워크를 선택하더라도, 기본 설정은 컨텍스트 누수를 막지 않습니다. 에이전트 간 전달 컨텍스트의 범위를 코드 레벨에서 명시적으로 제한하십시오.
- 오픈소스 하네스 활용: pip install agent-security-harness로 설치해 332개 테스트를 직접 실행할 수 있습니다. 독립 연구자가 프로덕션 MCP 엔드포인트에 실행해 재현 가능한 결과를 얻었습니다.
[ 결제·권한 프로토콜 ] - 결제 검증은 상태 기반으로: 에이전트가 금융 트랜잭션을 처리한다면, 수신 영수증을 특정 트랜잭션에 바인딩하고 원장과 대조하십시오. 무상태 검증은 리플레이 공격을 허용합니다.
[ 서드파티 플러그인·훅 ] - 설치된 훅의 로깅 동작 감사: 직접 작성하지 않은 훅이 툴 입출력을 디스크에 기록하고 있는지 확인하십시오. 모든 자격증명이 평문 로그로 지속 캡처될 수 있습니다. - 출처 검증 없는 플러그인 차단: 공개 레지스트리의 12%에서 악용 가능한 디스크립션 패턴이 발견됐습니다. 행동 인증이 없는 서드파티 플러그인은 프로덕션 워크플로우에서 격리하십시오.
전망: AI-First 팀의 다음 과제는 '보안 검증 파이프라인'
세 건의 데이터가 공통으로 지목하는 것은 하나입니다. 보안은 프레임워크가 보장하는 게 아니라 배포 방식이 결정합니다. Fidensa의 7단계 인증 파이프라인—소프트웨어 BOM 생성, 공급망 취약점 스캔, 적대적 레드팀 테스트, 행동 핑거프린팅, 서명된 인증 아티팩트 발행—이 보여주듯, 이제 AI 기능에도 제품 안전 인증에 준하는 검증 프로세스가 필요합니다.
AI-First 팀 리드로서 제가 다음 분기에 우선순위를 두는 건 이겁니다: 에이전트를 CI/CD에 통합하는 속도만큼, 보안 검증을 그 파이프라인에 함께 심는 것. 툴 디스크립션 스캔과 해시 피닝은 당장 이번 주 PR에 넣을 수 있습니다. 행동 테스트 하네스를 CI에 묶는 건 그 다음 스프린트입니다. 에이전트가 실제 돈을 다루기 시작하면—그때는 이미 늦습니다.