MCP 보안 아키텍처: 인증·프롬프트 인젝션·에이전트 권한 경계

확산 속도를 따라가지 못한 MCP 보안

배포된 MCP(Model Context Protocol) 서버 가운데 상당수는 기본 인증조차 구현하지 않은 상태로 운영된다. 툴 설명을 겨냥한 프롬프트 인젝션도 활발히 연구되고 있으며, 6주 만에 30개 이상의 MCP 관련 CVE가 공개됐다. 취약한 인스턴스는 최대 20만 건으로 추정된다.

MCP는 LLM이 외부 도구와 데이터에 연결되는 표준 인터페이스로 빠르게 퍼졌다. 2026년 초 기준 공개 접근 가능한 서버는 7,000개 이상이며, 주요 패키지 관리자에서의 다운로드는 1억 5,000만 건을 넘었다. 반면 인증 체계와 에이전트 권한 경계는 프로덕션 도입의 핵심 과제로 남아 있다.

2026년 1~2월, 6주 동안 공개된 대표 사례는 다음과 같다.

CVE	영향 시스템
CVE-2025-49596	MCP Inspector
CVE-2026-22252	LibreChat
CVE-2026-22688	WeKnora
CVE-2025-54136	Cursor
+ 30개 이상	기타 MCP 구현체

특히 MCP 프로토콜의 STDIO 인터페이스는 로컬 서버 프로세스를 띄울 때 악성 명령에 대한 새니타이제이션 경고나 적색 신호 없이 실행될 수 있다. 프로세스 시작 성공 여부와 무관하게 명령 자체는 실행된다.

인증을 나중에 붙일 수 없는 이유

많은 MCP 서버는 인증과 권한 부여를 구현하지 않았거나, 불완전하게 구현했거나, 프로덕션 이후의 수정 항목으로 미룬다. 이 상태에서는 Basic Auth 사용에 따른 크레덴셜 노출, 다운스트림 API로의 토큰 패스스루, 인증과 권한 부여의 혼동, 과도한 스코프 요청이 함께 발생할 수 있다.

클라이언트가 다운스트림 API에 토큰을 직접 전달하면 속도 제한, 요청 검증, 트래픽 모니터링을 우회할 여지가 생긴다. 인증 여부와 해당 요청을 실행할 권한은 별도로 평가해야 한다.

2025년 11월 MCP 사양은 HTTP 전송에서 PKCE를 필수로 하는 OAuth 2.1을 표준으로 채택했다. 기업 환경에서는 Red Hat Keycloak 같은 외부 OAuth/OIDC 제공자에 인증을 위임하는 구성이 권장된다.

⤢✕

이 구조에서는 신뢰 경계를 넘을 때마다 RFC 8693 토큰 교환을 수행해 토큰 패스스루를 피한다. 작업별로 필요한 접근만 요청하는 증분 스코프 동의, 장기 세션의 리프레시 토큰 순환, 모든 토큰 교환을 남기는 감사 로그도 함께 설계 대상이다.

외부 콘텐츠가 지시로 바뀌는 경로

프롬프트 인젝션은 사용자가 UI에 악성 프롬프트를 직접 넣는 직접 인젝션과, LLM이 읽는 외부 소스를 경유하는 간접 인젝션으로 나뉜다.

⤢✕

직접 인젝션은 사용자 입력 레이어에서 확인할 수 있어 상대적으로 탐지가 쉽다. 반대로 간접 인젝션은 웹페이지, MCP 서버 메타데이터, 응답, 이메일, 데이터베이스처럼 모델이 상호작용하는 소스에 적대적 프롬프트를 심는다. 공격 콘텐츠가 사용자 입력 레이어에 도달하지 않으므로 탐지가 더 어렵다.

Tool Poisoning은 MCP 툴 설명에 악성 지시를 포함해 모델이 의도하지 않은 툴 호출을 하도록 유도한다. 보안 통제를 우회하는 주요 공격 벡터다.

트랜스포머 어텐션의 특성상 모델은 컨텍스트 윈도우 안에서 공격자 지시와 오퍼레이터 지시를 아키텍처적으로 구분할 수 없다. 이는 구현 버그가 아니라 트랜스포머의 설계 특성이다.

툴을 설치하기 전에는 설명에 포함된 지시 패턴을 검사하고, 사용자 입력은 LLM 컨텍스트에 도달하기 전에 필터링해야 한다. 에이전트 출력도 다음 단계에 전달하기 전에 검사하며, 외부 콘텐츠와 시스템 지시의 경계를 명확하게 마킹하는 방식이 필요하다.

간접 인젝션 탐지는 하나의 기법만으로 충분하지 않다.

방법	장점	한계
패턴 매칭	빠른 알려진 패턴 탐지	신규 패턴 대응 불가
LLM 의미 분析	신규 변형 탐지 가능	지연 시간·비용 증가
목적 훈련 신경망 분류기	신규 공격 최고 성능	대량 레이블 훈련 데이터 필요

콘텐츠가 LLM 컨텍스트로 들어오기 전, 패턴 매칭을 1차 빠른 필터로 두고 ML 분류기를 2차 신규 패턴 탐지에 사용하는 조합이 권장된다. Microsoft Prompt Shields는 머신러닝과 NLP를 이용해 직접·간접 인젝션을 모두 방어한다.

MCP 프록시가 대리자가 되는 순간

MCP 서버가 요청별 권한 부여 컨텍스트를 검증하지 않으면 Confused Deputy 문제가 발생한다. 공격자는 MCP 프록시 서버를 경유해 정적 클라이언트 ID, 동적 클라이언트 등록, 동의 쿠키의 조합을 악용하고, 적절한 사용자 동의 없이 인증 코드를 얻을 수 있다.

⤢✕

권한 경계는 툴 단위에서 설정해야 한다. 각 툴은 자체 권한 요건을 가져야 하며, 모든 호출마다 이를 평가해야 한다. 보유한 토큰이 있다는 사실만으로 요청을 승인해서는 안 된다.

작업별 최소 접근만 요청하는 증분 스코프 동의, 에이전트 수준 신원 관리에 SPIFFE/SPIRE를 적용하는 워크로드 아이덴티티, 신뢰 경계마다 새 스코프 한정 토큰을 발급하는 RFC 8693 토큰 교환을 함께 적용할 수 있다.

컨텍스트에 넣기 전 통제할 것

모델이 컨텍스트 안에서 지시와 데이터를 구별할 수 없다면, 방어 지점은 콘텐츠가 컨텍스트에 들어가기 전이어야 한다.

툴 출력은 LLM 컨텍스트에 주입하기 전에 모두 스캔하고, 의심 패턴은 격리하거나 새니타이즈한다. 시스템 프롬프트와 툴 출력 사이에는 명확한 경계를 두고 외부 콘텐츠를 마킹한다. 툴 호출의 이상 행동을 추적하고, 비율 제한과 다중 테넌트 환경의 사용자 간 오염 방지도 운영 통제에 포함한다.

시스템 프롬프트만으로 인젝션을 막을 수 없다는 점도 전제해야 한다. 연구에서 반복적으로 입증된 한계이므로 계층화된 방어 전략이 필요하다.

프로덕션 운영에서 함께 닫아야 할 공격면

공급망도 MCP 보안의 일부다. 암호화 검증 없이 서드파티 저장소에서 내려받은 서버, 보안 검토 없이 설치·운영되는 서버, 폐기 뒤에도 동작하는 좀비 서버, 공개 저장소에서 정상 툴로 위장하는 악성 패키지가 모두 위험 요인이다.

영역	권장 조치
인증	OAuth 2.1 + PKCE 필수, 정기 토큰 교체, 크레덴셜 보안 저장
권한 부여	툴 수준 RBAC, 요청별 검증, 신뢰 경계 토큰 교환
모니터링	감사 로그, 속도 제한, 이상 탐지 시스템
공급망	암호화 검증, 설치 전 보안 검토, 수명주기 관리
데이터 보호	시크릿 관리 시스템, 환경 격리, 전송·저장 암호화
인젝션 방어	다층 필터링, Microsoft Prompt Shields 통합, 행동 모니터링

인증과 권한 경계는 사후 보완 기능이 아니라 초기 설계의 일부여야 한다. MCP 생태계의 약한 고리 하나가 전체 에이전트 파이프라인에 침입하는 지점이 될 수 있다.

MCP의 보안 문제는 단일 기술 결함보다 생태계 전반의 설계 성숙도와 관련된다. 인증 부재, 프롬프트 인젝션, 권한 경계 위반은 서로 연결된 공격 표면을 만든다. OAuth 2.1 통합, 툴 수준 RBAC, 다층 인젝션 방어, 컨텍스트 격리를 함께 구성해야 하며, RSAC 2026에서도 MCP 보안이 최대 화두로 떠오른 만큼 프로덕션 도입 전 보안 아키텍처 설계가 선결 과제다.