MCP 게이트웨이와 MCP 보안: 게이트웨이가 다루는 범위
게이트웨이는 수신한 에이전트 요청의 접근 권한을 확인하고 이를 기록합니다. 게이트웨이가 처리하는 MCP 보안 위험과 여전히 다른 통제가 필요한 위험을 알아보세요.
간략한 결정
MCP용 게이트웨이는 AI 클라이언트와 이들이 사용하는 도구 사이의 경로에 놓인 검사 지점입니다. 게이트웨이는 수신한 요청에 대해 누가 요청하는지 확인하고, 접근 규칙을 적용하고, 자격 증명을 분리하고, 검토되지 않은 도구를 보류하고, 민감한 변경 작업을 검토로 보내고, 발생한 일을 기록할 수 있습니다. MCP 보안은 이보다 넓은 영역으로, 프롬프트 인젝션, 각 서버의 코드, 노트북의 로컬 서버, 게이트웨이를 우회하는 모든 경로까지 다룹니다. 대부분의 팀에는 게이트웨이와 이러한 다른 통제가 함께 필요합니다.
간단히 정리하면
Model Context Protocol(MCP)은 Claude Code나 Cursor 같은 AI 클라이언트를 티켓 대기열 검색, 파일 읽기, 고객 레코드 업데이트 같은 도구를 제공하는 서버에 연결합니다. 게이트웨이는 이러한 클라이언트와 서버 사이에 위치합니다. 클라이언트는 관리되는 하나의 엔드포인트에 연결하고, 게이트웨이는 각 요청을 전달하기 전에 확인합니다.
MCP 보안은 더 넓은 개념으로, 에이전트의 도구 사용이 잘못될 수 있는 모든 경우를 다룹니다. 모델이 콘텐츠에 숨겨진 지시를 따르는 경우, 서버의 도구가 표방한 것과 다른 경우, 토큰이 쓰여서는 안 되는 곳에 쓰이는 경우, 에이전트가 작업에 필요한 것보다 많은 접근 권한을 가진 경우, 아무도 존재를 몰랐던 연결이 있는 경우가 모두 해당합니다.
따라서 이 비교는 두 제품을 견주는 문제라기보다 범위의 문제입니다. 게이트웨이는 MCP 보안을 구성하는 통제 중 하나이며, 수신한 요청에 대해서는 강력한 통제입니다. 핵심은 실제 배포 환경에서 게이트웨이가 어떤 위험을 처리하고, 나머지는 누가 담당하는지입니다.
MCP 보안 위험별 대응 지점
위험 목록을 정리할 때 출발점으로 삼기 좋은 자료가 두 가지 있습니다. MCP 보안 모범 사례는 토큰 패스스루(token passthrough), 혼동된 대리인(confused deputy) 문제처럼 이 프로토콜에 특화된 공격을 설명합니다. 이 글을 쓰는 시점에 베타 프로젝트인 OWASP MCP Top 10은 주요 위험을 10개 범주로 분류합니다.
아래 표는 이 10개 범주별로 게이트웨이가 기여할 수 있는 부분과 다른 곳에서 보완해야 하는 부분을 정리한 것입니다. 특정 제품에 대한 설명이 아니라 자체 검토를 위한 출발점이므로, 의존하는 항목은 각각 시연을 요청해 확인하세요.
| 위험 | 게이트웨이가 할 수 있는 일 | 추가로 필요한 것 |
|---|---|---|
| 토큰 관리 부실 및 시크릿 노출 | 업스트림 자격 증명을 기기와 프롬프트에 두지 않음. 단, 그만큼 게이트웨이가 가치 높은 공격 대상이 됨 | 시크릿 저장소와 수명이 짧고 범위가 좁은 토큰 |
| 점진적인 범위 확대를 통한 권한 상승 | 팀별로 도구, 리소스, 작업을 제한하고 새 접근 권한을 검토 | 좁게 설정한 OAuth 범위와 정기적인 접근 권한 검토 |
| 도구 포이즈닝 | 검토 전까지 도구를 차단하고, 정의가 변경되면 새로 검토 | 승인 전 서버 검증, 변경 사항을 알려 주는 클라이언트 |
| 공급망 공격 및 의존성 변조 | 거의 없음: 서버 코드는 검사할 수 없고, 연결할 서버를 제한할 수 있을 뿐임 | 출처 검증, 버전 고정, 소프트웨어 자재 명세서(SBOM) |
| 명령 인젝션 및 실행 | 일부 가능: 검토된 스키마를 벗어나는 인수를 거부할 수 있음 | 서버의 입력 검증과 안전한 명령 처리, 그리고 샌드박싱 |
| 에이전트가 읽는 콘텐츠를 통한 프롬프트 인젝션 | 잘못 유도된 에이전트가 접근할 수 있는 범위를 제한하고, 중대한 변경 작업은 검토를 위해 보류 | 모델 및 클라이언트 방어 기능과 사용자 확인 요청 |
| 불충분한 인증 및 접근 권한 부여 | 수신하는 모든 요청에서 신원과 접근 권한을 확인 | 각 서버도 자체 접근 제어를 계속 적용 |
| 감사 및 텔레메트리 부족 | 라우팅된 요청의 결정과 결과를 기록 | 그 밖의 모든 활동에 대한 클라이언트, 서버, 엔드포인트 로그 |
| 섀도우 MCP 서버 | 수신하지 않는 요청에 대해서는 할 수 있는 일이 없음 | 탐지, 엔드포인트 인벤토리, 네트워크 통제, 쉽게 이용할 수 있는 승인 경로 |
| 컨텍스트 인젝션 및 과잉 공유 | 도구가 읽을 수 있는 범위를 제한하고, 설정된 경우 응답을 검사 | 데이터 분류와 모델 공급자의 데이터 약관 |
게이트웨이가 잘하는 일
게이트웨이의 가치는 어떤 클라이언트가 보냈든 수신한 모든 요청이 같은 확인 절차를 거친다는 데 있습니다. 게이트웨이는 누가 요청하는지, 그 사람이 아직 팀에 속해 있는지, 이 연결과 도구, 리소스를 사용할 수 있는지 확인할 수 있습니다. 이러한 결정이 모든 클라이언트와 서버에서 제각각 반복되지 않고 한곳에서 이루어집니다.
게이트웨이는 자격 증명을 분리할 수 있습니다. 사용자는 게이트웨이에 로그인하고, 게이트웨이는 업스트림 시스템용으로 발급된 자격 증명으로 해당 시스템을 호출합니다. MCP 사양은 클라이언트의 토큰을 그대로 전달하는 것을 금지합니다. 그렇게 하면 업스트림 시스템의 통제를 우회하게 되고, 누가 작업했는지에 대한 명확한 기록도 남지 않기 때문입니다.
게이트웨이는 도구를 검토 대상으로 다룰 수 있습니다. 도구 이름과 설명은 모델이 읽고 그에 따라 행동하는 텍스트입니다. 따라서 검토되지 않은 도구를 보류하고 변경된 정의를 새로운 검토 대상으로 처리하는 게이트웨이는 프로토콜이 열어 둔 빈틈을 메웁니다. 또한 민감한 변경 작업을 검토자에게 보내고, 결정과 결과를 모두 기록할 수 있습니다.
게이트웨이에도 고유한 보안 책임이 따릅니다
게이트웨이에는 접근 권한이 집중되므로, 다른 여러 시스템의 자격 증명을 보관하는 여느 시스템과 마찬가지로 면밀히 검토해야 합니다. MCP 보안 모범 사례에서는 클라이언트를 타사 API에 연결하는 서버를 프록시 서버라고 부르며, 이러한 서버에는 구체적인 의무가 있습니다.
이러한 프록시는 타사 권한 부여 서버로 요청을 전달하기 전에 클라이언트별로 동의를 받고, 리디렉션 주소를 정확히 일치시키고, OAuth state 매개변수를 검증해야 합니다. 이러한 조치가 없으면 공격자가 사용자의 이전 동의를 악용해 사용자가 허락한 적 없는 접근 권한을 얻을 수 있습니다. 사양에서는 이를 혼동된 대리인(confused deputy) 공격이라고 부릅니다.
게이트웨이는 사용자를 대신해 메타데이터를 가져오고 업스트림 서버를 호출하기도 합니다. 사양은 서버에 배포된 클라이언트가 HTTPS 요구, 사설 주소 대역 차단, 리디렉션 확인 등의 방법으로 서버 측 요청 위조(SSRF)를 방어하도록 요구합니다. 게이트웨이가 이러한 흐름을 어떻게 처리하는지, 게이트웨이가 침해되면 저장된 자격 증명은 어떻게 되는지 확인해 보세요.
게이트웨이 바깥에 있는 것
게이트웨이는 요청을 볼 뿐, 그 이면의 추론은 보지 못합니다. 문서가 모델에게 데이터를 어딘가로 보내라고 지시하고 그 요청이 해당 사용자에게 허용된 것이라면, 정책 확인만으로는 그것이 사람의 의도인지 문서의 지시인지 구별할 수 없습니다. Anthropic은 프롬프트 인젝션이 해결된 문제와는 거리가 멀다고 설명합니다. 좁은 권한과 중대한 작업에 대한 검토는 피해를 줄여 주지만, 콘텐츠를 신뢰할 수 있게 만들지는 않습니다.
로컬 서버도 게이트웨이 바깥에 있습니다. 노트북에서 실행된 서버는 사용자의 권한으로 동작하며, 그 트래픽은 원격 게이트웨이에 도달하지 않습니다. MCP 프로젝트의 가이드는 이러한 서버를 엔드포인트 및 소프트웨어 거버넌스가 필요한 일반 소프트웨어로 취급합니다.
도구가 데이터를 읽기만 한다는 힌트 같은 도구 어노테이션도 강제 수단이 아닙니다. MCP 메인테이너들은 안전 보장을 결정론적 통제에 맡기라고 권장합니다. 마지막으로, 같은 자격 증명이 다른 경로로 사용되면 게이트웨이의 규칙은 적용되지 않으며, 게이트웨이는 클라이언트가 모델 공급자에게 보내는 내용을 볼 수 없습니다.
예시: 숨겨진 지시가 담긴 지원 티켓
예시로, 티켓을 읽고 고객 레코드를 조회할 수 있는 지원 에이전트가 있다고 가정해 보겠습니다. 그런데 에이전트에게 전체 고객 목록을 내보내 답장에 첨부하라고 지시하는 텍스트가 담긴 티켓이 들어옵니다.
모델이 이 지시를 따를지 여부는 모델과 클라이언트에 따라 다릅니다. 모델이 지시를 따르려 하면, 게이트웨이는 이 사용자가 해당 리소스에 내보내기 도구를 사용할 수 있는지 확인합니다. 지원팀에 그 도구가 활성화된 적이 없다면 요청은 거부됩니다. 도구가 활성화되어 있고 팀이 내보내기에 검토를 요구한다면, 어떤 작업도 실행되기 전에 검토자가 정확한 요청 내용을 확인합니다.
내보내기가 허용되어 있고 검토도 필요 없다면, 게이트웨이가 문제 삼을 것이 없습니다. 주어진 규칙상 허용된 요청이기 때문입니다. 그래서 검사 지점 자체만큼이나 도구 설계와 접근 권한 선택이 중요합니다.
게이트웨이와 함께 쓰는 MCP 보안 도구
MCP 보안이라는 이름으로 판매되는 제품은 게이트웨이와 다른 역할을 하는 경우가 많습니다. 스캐너는 승인 전에 서버 패키지와 도구 설명에 숨겨진 지시가 있는지 검사합니다. 런타임 모니터는 에이전트가 작업하는 동안 콘텐츠와 동작을 검사합니다. 탐지 도구는 기기에 구성된 MCP 서버를 찾습니다.
이러한 도구는 게이트웨이를 대체하기보다 보완합니다. 스캔 결과는 어떤 서버를 승인할지 판단하는 근거가 되고, 검사는 정책만으로는 제공할 수 없는 콘텐츠 확인을 더하며, 탐지는 어떤 경로가 여전히 통제를 우회하는지 보여 줍니다. 게이트웨이를 평가할 때 다음 질문을 활용하면 실제 배포 환경에서 게이트웨이가 무엇을 적용하는지 확인할 수 있습니다.
- 게이트웨이가 실제로 보게 되는 요청은 무엇이며, 게이트웨이를 우회하는 경로는 무엇입니까?
- 클라이언트 로그인과 업스트림 자격 증명은 어떻게 분리됩니까?
- 도구 정의는 어떻게 검토되며, 정의가 변경되면 어떻게 됩니까?
- 연결 단위뿐 아니라 도구, 리소스, 작업 유형별로 접근 권한을 제한할 수 있습니까?
- 제안된 변경 작업은 어떻게 검토되며, 검토자는 무엇을 보게 됩니까?
- 기록에서 접근 권한 결정과 작업 결과가 구분됩니까?
Durin가 맞는 곳
Durin은 에이전트 요청에 일관된 규칙과 증거가 필요한 팀을 위해 게이트웨이를 통한 MCP 거버넌스를 제공합니다. Durin을 거쳐 라우팅되는 요청의 경우, 각 호출은 현재 신원, 멤버십, 팀, 연결, 자격 증명, 검토된 도구, 리소스에 대한 확인과 콘텐츠 검사를 모두 통과해야 합니다. 도구는 검토될 때까지 차단된 상태로 유지되며, 도구 정의가 변경되면 다시 검토해야 합니다. Durin은 해당 연결의 자격 증명으로 공급자를 호출하며, Durin 자체의 토큰을 업스트림으로 전달하지 않습니다.
이러한 확인을 통과한 검토된 요청은 기본적으로 진행될 수 있습니다. 팀은 기본적으로 접근을 거부하도록 설정하거나, 제안된 변경 작업을 다른 관리자가 검토하도록 요구할 수 있습니다. 이후 요청자가 권한이 만료되기 전에 같은 요청을 다시 보냅니다. Durin은 결정과 결과를 따로 기록하며, 결과 불확실 상태인 요청은 절대 자동으로 반복되지 않습니다.
Durin은 프롬프트 인젝션을 방지하지 않으며, Durin을 우회하는 요청은 관리할 수 없습니다. Durin의 섀도우 MCP 탐지 기능은 등록된 기기에 구성된 MCP 서버를 보고하므로 이러한 우회 경로를 찾는 데 도움이 되지만, 이를 차단하지는 않습니다. 모델, 클라이언트, 엔드포인트, 서버 통제는 여전히 계획의 일부로 필요합니다.