MCP 보안 고려사항
MCP 보안 고려사항 (MCP Security Considerations)
CrewAI 에이전트에 MCP(Model Context Protocol) 서버를 붙일 때, 가장 중요한 건 바로 신뢰입니다. MCP 서버는 노출하는 도구에 따라 코드를 실행하거나 데이터에 접근하고 다른 시스템과 상호작용할 수 있어요. 이 페이지에서는 MCP 통합 시 반드시 알아야 할 보안 베스트프랙티스를 정리합니다.
출처: 공식문서
본문
개요
MCP 보안에서 가장 중요한 측면은 신뢰입니다. 완전히 신뢰하는 MCP 서버에만 CrewAI 에이전트를 연결해야 합니다. MCP 서버가 어떤 위험을 가져올 수 있는지 이해하고 베스트프랙티스를 따르는 것이 애플리케이션과 데이터를 보호하는 핵심이에요.
위험
- 에이전트가 실행되는 머신에서 임의 코드 실행(특히
Stdio트랜스포트를 쓸 때 서버가 실행 명령을 제어할 수 있음). - 에이전트 또는 그 환경의 민감 데이터 노출.
- 내 대신 무단 API 호출을 하는 등 에이전트 동작을 의도치 않게 조작.
- 정교한 프롬프트 인젝션 기법으로 에이전트의 추론 과정 탈취(아래 참조).
1. MCP 서버 신뢰하기
신뢰하는 서버에만 연결하세요. MCPServerAdapter 로 연결을 구성하기 전에 다음을 확인합니다.
- 누가 서버를 운영하는가? 알려지고 평판 있는 서비스인가, 아니면 내가 통제하는 내부 서버인가?
- 어떤 도구를 노출하는가? 그 도구의 능력을 이해하라. 공격자가 통제하거나 서버 자체가 악의적일 때 오용될 수 있지 않은가?
- 어떤 데이터에 접근하거나 처리하는가? MCP 서버로 보내지거나 처리될 민감 정보를 인지하라.
특히 에이전트가 민감한 작업이나 데이터를 다룬다면, 알려지지 않았거나 검증되지 않은 MCP 서버에 연결하지 마세요.
2. 도구 메타데이터를 통한 프롬프트 인젝션: “Model Control Protocol” 위험
미묘하지만 중요한 위험은 도구 메타데이터를 통한 프롬프트 인젝션입니다. 과정은 이렇게 진행돼요.
- CrewAI 에이전트가 MCP 서버에 연결하면 보통 사용 가능한 도구 목록을 요청합니다.
- MCP 서버는 각 도구의 이름, 설명, 파라미터 설명을 담은 메타데이터로 응답합니다.
- 에이전트의 LLM 은 이 메타데이터로 도구를 어떻게·언제 쓸지 파악합니다. 이 메타데이터는 LLM 의 시스템 프롬프트나 컨텍스트에 통합되는 경우가 많습니다.
- 악의적인 MCP 서버는 도구 이름·설명에 숨겨진 또는 노골적인 지시를 심을 수 있습니다. 이 지시는 프롬프트 인젝션으로 작용해, LLM 이 특정 방식으로 행동하거나 민감 정보를 노출하거나 악의적 행동을 하도록 만들 수 있어요.
중요한 점은, 에이전트가 그 도구를 실제로 사용하기로 결정하지 않아도, 악성 서버에 연결해 도구를 나열하는 것만으로 이 공격이 발생할 수 있다는 겁니다. 악성 메타데이터에 노출되는 것만으로도 에이전트 동작이 손상될 수 있어요.
완화: 신뢰하지 않는 서버에는 극도의 주의. 완전히 신뢰하지 않는 MCP 서버에는 연결하지 마세요. 메타데이터 인젝션 위험이 이를 최우선 사항으로 만듭니다.
Stdio 트랜스포트 보안
Stdio(표준 입출력) 트랜스포트는 보통 CrewAI 애플리케이션과 같은 머신에서 도는 로컬 MCP 서버에 사용됩니다.
- 프로세스 격리: 기본적으로 네트워크 노출이 없어 더 안전하지만,
StdioServerParameters가 실행하는 스크립트나 명령이 신뢰 소스에서 왔고 적절한 파일시스템 권한을 갖는지 확인하세요. 악성 Stdio 서버 스크립트도 로컬 시스템을 해칠 수 있습니다. - 입력 정제: Stdio 서버 스크립트가 에이전트 상호작용에서 파생된 복잡한 입력을 받는다면, 스크립트 자체가 명령 인젝션이나 다른 취약점을 막도록 입력을 정제하는지 확인하세요.
- 리소스 한계: 로컬 Stdio 서버 프로세스는 로컬 리소스(CPU, 메모리)를 소비합니다. 잘 동작하고 시스템 리소스를 고갈시키지 않는지 확인하세요.
혼란스러운 대리인(Confused Deputy) 공격
혼란스러운 대리인 문제는 OAuth 2.0 을 쓰는 제3자 서비스(예: Google Calendar, GitHub)의 프록시 역할을 하는 MCP 서버에서 특히 나타날 수 있는 고전적 보안 취약점입니다.
시나리오:
MCP-Proxy라는 MCP 서버가 에이전트가ThirdPartyAPI와 상호작용하도록 해줍니다.MCP-Proxy는ThirdPartyAPI의 인증 서버에 말할 때 자체 단일 정적client_id를 사용합니다.- 사용자가 정당하게
MCP-Proxy가ThirdPartyAPI에 접근하도록 승인합니다. 이때 인증 서버가 브라우저에MCP-Proxy의client_id에 대한 동의 쿠키를 설정할 수 있습니다. - 공격자가 악성 링크를 만들어
MCP-Proxy로 OAuth 흐름을 시작하되,ThirdPartyAPI인증 서버를 속이도록 설계합니다. - 클릭하면 인증 서버가
MCP-Proxy의client_id에 대한 기존 동의 쿠키를 보고 다시 동의를 묻지 않을 수 있습니다. MCP-Proxy는ThirdPartyAPI용 인증 코드를 공격자에게 전달하도록 속거나, 공격자가 나를 사칭할 수 있는 MCP 인증 코드를 전달하도록 속을 수 있습니다.
완화(주로 MCP 서버 개발자 대상): 하위 서비스에 정적 client ID 를 쓰는 MCP 프록시 서버는, 제3자 서비스와 OAuth 흐름을 시작하기 전에 각 클라이언트 애플리케이션 또는 에이전트에 대한 명시적 사용자 동의를 얻어야 합니다. 즉 MCP-Proxy 자체가 동의 화면을 보여줘야 합니다.
CrewAI 사용자 시사점: MCP 서버가 여러 번 OAuth 인증으로 리다이렉트한다면(특히 예상치 못했거나 요청 권한이 과도하게 넓다면) 주의하세요. 자신의 정체성과 프록시하는 제3자 서비스를 명확히 구분하는 MCP 서버를 선호하세요.
원격 트랜스포트 보안(SSE 및 Streamable HTTP)
SSE(Server-Sent Events) 또는 Streamable HTTP 로 원격 MCP 서버에 연결할 때는 표준 웹 보안 관행이 필수입니다.
a. DNS 리바인딩 공격(특히 SSE)
DNS 리바인딩은 공격자가 제어하는 웹사이트가 same-origin policy 를 우회해 사용자 로컬 네트워크(예: localhost)나 인트라넷의 서버에 요청하게 만듭니다. 로컬에서 MCP 서버(예: 개발용)를 돌리고 브라우저류 환경의 에이전트를 쓰거나, MCP 서버가 내부 네트워크에 있을 때 특히 위험합니다.
완화 전략(MCP 서버 구현자):
Origin와Host헤더 검증: MCP 서버(특히 SSE)는Origin/HostHTTP 헤더를 검증해 요청이 예상 도메인/클라이언트에서 왔는지 확인해야 합니다.localhost(127.0.0.1)에 바인딩: 로컬 개발 시0.0.0.0대신127.0.0.1에 바인딩해 네트워크의 다른 머신에서 접근하지 못하게 하세요.- 인증: 공개 익명 접근이 아니라면 모든 연결에 인증을 요구하세요.
b. HTTPS 사용
- 전송 중 데이터 암호화: 원격 MCP 서버 URL 에는 항상 HTTPS 를 사용하세요. CrewAI 애플리케이션과 MCP 서버 간 통신을 암호화해 도청·중간자 공격을 막습니다.
MCPServerAdapter는 URL 에 제공된 scheme(http또는https)을 존중합니다.
c. 토큰 패스스루(안티패턴)
“토큰 패스스루”는 MCP 서버가 CrewAI 에이전트로부터 받은 접근 토큰(다른 서비스, 예: ServiceA 용일 수 있음)을 적절한 검증 없이 다른 하위 API(ServiceB)로 그냥 통과시키는 경우입니다. ServiceB(또는 MCP 서버 자체)는 명시적으로 자기에게 발급된 토큰만(즉 토큰의 audience 클레임이 서버/서비스와 일치하는 토큰) 받아야 합니다.
위험:
- MCP 서버나 하위 API의 보안 제어(rate limiting, 세밀한 권한) 우회.
- 감사 추적·책임성 파괴.
- 도난 토큰의 오용 허용.
완화(MCP 서버 개발자): MCP 서버는 명시적으로 자기에게 발급되지 않은 토큰을 받아서는 안 됩니다. 토큰의 audience 클레임을 검증해야 합니다.
CrewAI 사용자 시사점: 사용자가 직접 통제하긴 어렵지만, 보안 베스트프랙티스를 따르는 잘 설계된 MCP 서버에 연결하는 것의 중요성을 보여줍니다.
인증과 권한 부여
- 신원 검증: MCP 서버가 민감 도구나 사설 데이터에 접근을 제공한다면, 클라이언트(CrewAI 애플리케이션)의 신원을 검증하는 강력한 인증 메커니즘을 구현해야 합니다. API 키, OAuth 토큰 등 표준 방법을 쓸 수 있습니다.
- 최소 권한 원칙:
MCPServerAdapter가 사용하는 자격 증명이 필요한 도구에 접근하는 데 필요한 권한만 갖는지 확인하세요.
d. 입력 검증과 정제
- 입력 검증은 핵심: MCP 서버는 에이전트에서 받은 모든 입력을 처리하거나 도구에 넘기기 전에 엄격히 검증해야 합니다. 흔한 취약점의 1차 방어선입니다.
- 명령 인젝션: 도구가 입력을 기반으로 셸 명령, SQL 쿼리, 다른 해석 언어 문장을 만든다면, 악성 명령이 주입·실행되지 않도록 입력을 꼼꼼히 정제해야 합니다.
- 경로 순회: 도구가 입력 파라미터로 파일에 접근한다면,
../시퀀스를 차단하는 등 경로를 검증·정제해 허가되지 않은 파일·디렉터리 접근을 막아야 합니다. - 데이터 타입·범위 검사: 입력이 기대 타입(string, number, boolean 등)에 맞고 허용 범위 안이며 정의된 형식(URL용 regex 등)을 따르는지 확인해야 합니다.
- JSON 스키마 검증: 모든 도구 파라미터를 정의된 JSON 스키마에 대해 엄격히 검증하세요. 잘못된 요청을 조기에 잡아줍니다.
- 클라이언트 측 인지: 서버 측 검증이 최우선이지만, CrewAI 사용자로서 에이전트가 MCP 도구로 보내도록 구성된 데이터(특히 덜 신뢰되거나 새로운 MCP 서버와 상호작용할 때)에 유의하세요.
e. Rate Limiting과 리소스 관리
- 남용 방지: MCP 서버는 의도적(서비스 거부 공격)이든 비의도적(잘못 구성된 에이전트의 과도한 요청)이든 남용을 막기 위해 rate limiting 을 구현해야 합니다.
- 클라이언트 측 재시도: 일시적 네트워크 문제나 서버 rate limit 이 예상되면 CrewAI 태스크에 합리적인 재시도 로직을 넣되, 서버 부하를 악화시키는 공격적 재시도는 피하세요.
4. 안전한 MCP 서버 구현 조언(개발자용)
CrewAI 에이전트가 연결할 MCP 서버를 개발한다면 위 사항에 더해 다음을 고려하세요.
- 안전한 코딩 관행: 선택한 언어·프레임워크의 표준 보안 코딩 원칙(예: OWASP Top 10)을 따르세요.
- 최소 권한 원칙: MCP 서버를 실행하는 프로세스(특히
Stdio)가 필요한 최소 권한만 갖도록 하세요. 도구 자체도 최소 권한으로 동작해야 합니다. - 의존성 관리: OS 패키지, 언어 런타임, 제3자 라이브러리를 포함한 모든 서버 의존성을 최신으로 유지해 알려진 취약점을 패치하고, 취약한 의존성을 스캔하는 도구를 사용하세요.
- 보안 기본값: 서버와 도구가 기본적으로 안전하도록 설계하세요. 예를 들어 위험할 수 있는 기능은 기본적으로 끄거나 명확한 경고와 함께 명시적 옵트인을 요구하세요.
- 도구 접근 제어: 특히 강력하거나 민감하거나 비용이 드는 도구에 대해, 인증·권한 부여된 에이전트/사용자만 특정 도구에 접근하도록 제어하는 견고한 메커니즘을 구현하세요.
- 안전한 오류 처리: 서버는 상세한 내부 오류 메시지, 스택 트레이스, 디버깅 정보를 클라이언트에 노출하면 안 됩니다. 진단을 위해 서버 측에서 오류를 포괄적으로 로깅하세요.
- 종합 로깅·모니터링: 인증 시도, 도구 호출, 오류, 권한 변경 같은 보안 관련 이벤트의 상세 로그를 구현하고, 의심 활동·남용 패턴을 모니터링하세요.
- MCP 인증 스펙 준수: 인증·권한 부여를 구현한다면 MCP Authorization 스펙과 관련 OAuth 2.0 보안 베스트프랙티스를 엄격히 따르세요.
- 정기 보안 감사: 민감 데이터를 다루거나 중요 작업을 수행하거나 공개 노출된다면 자격 있는 전문가의 주기적 보안 감사를 고려하세요.
5. 더 읽을거리
MCP 보안에 대한 더 자세한 내용은 공식 문서 MCP Transport Security 를 참고하세요.
이러한 보안 고려사항과 베스트프랙티스를 이해하고 구현하면 CrewAI 프로젝트에서 MCP 서버의 힘을 안전하게 활용할 수 있습니다. 이 목록은 빠짐없는 것은 아니지만 가장 흔하고 중요한 보안 우려를 다룹니다. 위협은 계속 진화하므로 정보를 유지하고 보안 조치를 그에 맞게 조정하는 것이 중요합니다.