Model Context Protocol (MCP)은 AI 에이전트를 도구, 데이터 소스, 클라우드 리소스, 티켓팅 시스템 및 내부 워크플로에 연결하는 실용적인 방법으로 빠르게 자리 잡고 있습니다. 이러한 편의성은 보안 모델을 변화시킵니다. 이제 질문은 단순히 API 엔드포인트가 보호되고 있는지에 그치지 않습니다. 질문의 핵심은 사용자에서 에이전트, MCP 서버, 도구, 그리고 다운스트림 시스템(downstream system)에 이르는 전체 경로가 적절한 신원(identity), 권한(authority), 데이터 경계(data boundary) 및 감사 추적(audit trail)을 강제하고 있는지 여부입니다.

이 버전은 의도적으로 정화(sanitized)되었습니다. 익스플로잇 체인(exploit chains), 프롬프트 우회(bypass prompts) 또는 무기화 가능한 테스트 시퀀스를 제공하지 않습니다. 대신 안전한 프로덕션 전 평가(pre-production assessment)에서 무엇을 검증해야 하는지에 초점을 맞춥니다.

이것이 실무자용 버전이 필요한 이유

MCP 보안 테스트는 AI 보안, API 보안, 신원(identity), 그리고 애플리케이션 권한 부여(authorization) 사이에 위치합니다. 실무자들은 대개 구매자의 우려 사항을 테스트 가능한 통제 항목(controls), 안전한 참여 규칙(rules of engagement), 수정 티켓(remediation tickets) 및 재테스트 기준(retest criteria)으로 전환해야 하는 사람들입니다.

비즈니스 리스크는 명확합니다. 만약 MCP가 활성화된 에이전트가 잘못된 권한을 가지고 적절한 도구를 선택할 수 있다면, 고객 데이터, 금융 작업, 클라우드 리소스 또는 규제 대상 워크플로가 합법적으로 보이는 통합(integration)을 통해 노출될 수 있습니다.

검증해야 할 핵심 경계

프롬프트 트릭(prompt tricks)이 아닌 신뢰 경로(trust path)부터 시작하십시오.

1. 사용자(Human user)에서 에이전트(agent)로: 세션 신원(session identity), 역할(role), 테넌트(tenant), 동의(consent) 및 단계별 인증(step-up) 요구사항을 검증하십시오.
2. 에이전트(agent) 또는 클라이언트(client)에서 MCP 서버로: OAuth 대상(audience), 범위(scopes), 토큰 만료(token expiry), 갱신(refresh), 취소(revocation), 리다이렉트 동작(redirect behavior) 및 저장(storage)을 검증하십시오.
3. MCP 서버에서 도구 카탈로그(tool catalog)로: 허용된 서버, 도구 소유자(tool owners), 도구 버전, 도구 설명 및 변경 승인(change approval)을 확인하십시오.
4. 도구 선택(tool selection)에서 권한 부여(authorization)로: 각 역할이 허용된 도구와 액션 티어(action tiers)만 호출할 수 있는지 테스트하십시오.
5. 도구 파라미터(tool parameters)에서 비즈니스 규칙(business rules)으로: 소유권(ownership), 테넌트(tenant), 금액(amount), 목적지(destination), 환경(environment) 및 파괴적 플래그(destructive flags)를 서버 측에서 검증하십시오.
6. 외부 콘텐츠(external content)에서 모델 컨텍스트(model context)로: 신뢰할 수 없는 파일, 티켓, 이메일, 웹 콘텐츠 또는 검색된 문서가 민감한 작업에 영향을 미칠 수 있는지 평가하십시오.
7. 런타임(runtime)에서 감사 및 응답(audit and response)으로: 로그를 통해 최초 사용자, 에이전트, 서버, 도구, 파라미터, 권한 부여 결정, 승인, 대상 및 응답을 재구성할 수 있는지 확인하십시오.

단독으로 의존해서는 안 되는 것들

OAuth는 위임된 액세스(delegated access)를 설정하는 데 도움이 되지만, 최소 권한(least privilege), 올바른 대상(audience), 범위가 지정된 도구 권한(scoped tool authority) 또는 다운스트림 사용자 컨텍스트(downstream user context)를 자동으로 증명하지는 않습니다. 클라우드 IAM은 구성된 권한을 강제할 수 있지만, 해당 권한이 에이전트의 작업에 비해 여전히 너무 광범위할 수 있습니다. API 게이트웨이는 정책을 중앙 집중화할 수 있지만, 모델이 선택한 파라미터가 테넌트 또는 비즈니스 규칙에 부합하는지 검증하지 못할 수도 있습니다.

기능 QA(Functional QA)는 정상 경로(happy path)를 증명합니다. 보안 테스트는 금지된 경로(prohibited paths)가 실패함을 증명해야 합니다.

실질적인 개선 테마

대부분의 수정 사항은 모델 조정(model tweaks)이 아닙니다. 대개 신원 전파(identity propagation), 서버 측 권한 부여(server-side authorization), API 검증(API validation), 도구 거버넌스(tool governance), 승인 설계(approval design) 및 로깅(logging)에 위치합니다.

유용한 개선 티켓(remediation tickets)은 대개 다음과 같은 형태를 띱니다:

• 테넌트(tenant) 및 소유자(owner) 컨텍스트를 요청 본문(request body)이나 모델이 선택한 파라미터가 아닌, 신뢰할 수 있는 신원(identity)으로부터 도출하십시오.
• 모든 역할(role) 및 액션 계층(action tier)에 대해 기본 거부(deny-by-default) 방식의 도구 권한 부여를 강제하십시오.
• 도구 검색(tool discovery)과 도구 호출(tool invocation)을 분리하십시오.
• 명시적인 정책과 유의미한 승인을 통해 영향력이 큰 도구(high-impact tools)를 제한하십시오.
• 신뢰할 수 없는 콘텐츠가 모델 컨텍스트(model context)에 진입하기 전에 라벨을 지정하십시오.
• 레코드 식별자(record identifiers), 파일 경로(file paths), 금액(amounts), 환경(environments) 및 파괴적 플래그(destructive flags)를 모델 외부에서 검증하십시오.
• 로그아웃, 역할 변경, 계정 비활성화 또는 사고 대응(incident response) 후에 위임된 액세스(delegated access)를 취소하십시오.
• 사용자, 에이전트(agent), MCP 서버, 도구, 다운스트림 API(downstream API), 권한 부여 결정(authorization decision) 및 승인(approval)에 걸친 로그를 상관 분석(correlate)하십시오.

devto-inline-mcp-test-matrix

비즈니스 영향 및 범위 (Business impact and scope)

강력한 MCP 보안 테스트는 엔지니어링 팀에게는 수정 가능한 증거를 제공해야 하며, 리더십 팀에게는 출시, 감사(audit), 벤더 검토 및 고객 보안 논의 시 사용할 수 있는 증거를 제공해야 합니다.

즉, 보고서는 발견 사항을 비즈니스 영향, 수정 책임(remediation ownership), 재테스트 기준, 그리고 OWASP LLM01, LLM06, LLM07 및 관련 에이전트 범주(agentic categories)와 같은 관련 프레임워크와 매핑해야 합니다. MCP 도구 뒤에 있는 API의 권한 부여(authorization)가 깨져 있는 경우, 해당 수정 사항은 챗봇만의 문제로 취급하기보다는 API 침투 테스트(penetration testing)와 협력하여 조정되어야 합니다.

마지막 생각 (Final thought)

MCP가 자동으로 보안에 취약한 것은 아닙니다. 위험은 구현 방식의 선택에서 비롯됩니다: 공유된 신원(shared identities), 광범위한 도구 액세스, 취약한 데이터 경계(data boundaries), 도구 사용에 영향을 미치는 신뢰할 수 없는 콘텐츠, 누락된 승인 게이트(approval gates), 그리고 불완전한 감사 증거(audit evidence) 등이 그것입니다.

A 좋은 평가는 출시 전에 간단한 답을 제시합니다: 증거와 함께 승인, 조건부 승인, 또는 중대한 신뢰 경계(trust-boundary) 격차가 수정될 때까지 출시 연기 중 하나입니다.

전체 공식 가이드: https://www.pentesttesting.com/mcp-security-testing/