MCP 서버를 운영 환경에 연결하기 전에 확인할 보안 항목

검증 기준: 2026년 8월 27일

확인한 MCP Stable Specification: 2026-07-28

MCP 서버를 운영 환경에 연결하는 일은 LLM에 API 하나를 더 붙이는 작업이 아니다. 연결된 Tool이 고객 데이터 조회, 파일 변경, 메시지 전송, 권한 수정이나 배포 같은 실제 작업을 수행한다면 MCP는 곧 운영 시스템의 권한 경로가 된다.

따라서 확인해야 할 것은 “MCP가 OAuth를 지원하는가”만이 아니다. 어떤 사용자를 인증했는지, 토큰이 어느 서버를 대상으로 발급됐는지, 어떤 Tool과 Parameter를 허용하는지, 고위험 작업을 누가 승인하는지, Secret과 Tenant를 어디에서 격리하며 권한을 어떻게 회수하는지가 하나의 아키텍처로 연결돼야 한다.

MCP 자체를 안전하거나 위험한 기술로 단정할 수는 없다. MCP는 Host·Client·Server 사이의 통신 형식과 권한 흐름을 표준화하지만 공식 Specification도 Protocol만으로 모든 보안 원칙을 강제할 수는 없다고 밝힌다. 실제 안전성은 Host의 정책, Server의 권한 검사, Downstream 시스템의 자격증명과 운영 통제에서 결정된다.

최신 MCP 버전에서 먼저 달라진 전제

2026년 8월 27일 기준 최신 Stable Revision은 2026-07-28이다. 이 Revision에서 MCP의 Modern Protocol은 요청마다 Version과 Capability를 선언하는 무상태 구조를 사용한다. 과거 Revision에서 사용하던 Mcp-Session-Id는 최신 Streamable HTTP에 포함되지 않으며 Server는 해당 Header를 받아도 무시한다.

이 변화는 “Session 보안을 더 이상 생각하지 않아도 된다”는 뜻이 아니다. Protocol-level Session이 없어졌을 뿐, 장바구니 ID나 Workflow ID 같은 상태 Handle, OAuth Token, 사용자 승인 기록과 Downstream Credential은 여전히 존재한다. 공식 Security Guidance도 Handle 소유만으로 인증했다고 판단하지 말고 검증된 사용자와 Server-side로 묶으며 만료시킬 것을 요구한다.

OAuth 버전 표기도 구분해야 한다. MCP 2026-07-28 Authorization 문서는 OAuth 2.1 Draft-13을 참조하지만 IETF의 현재 OAuth 2.1 Working Draft는 Draft-15다. OAuth 2.1은 아직 최종 RFC가 아니므로 “OAuth 2.1 호환”이라는 문구보다 resource, Audience Validation, PKCE, Issuer Validation, HTTPS가 실제로 구현됐는지를 확인하는 편이 정확하다.

네 개의 Identity를 하나로 취급하지 않는다

운영 MCP 환경에는 최소 네 종류의 주체가 있다.

공식 Architecture에서 Host는 여러 Client를 관리하면서 연결 권한, 보안 정책과 사용자 동의를 통제한다. 각 Client는 하나의 Server와 1:1 관계를 맺고 Server 간 보안 경계를 유지한다. 보호된 MCP Server는 OAuth Resource Server, MCP Client는 사용자 대신 요청하는 OAuth Client로 정의된다.

여기서 인증(Authentication)과 권한 부여(Authorization)를 분리해야 한다.

사용자가 회사 계정으로 로그인했다는 사실은 인증 결과다. 그 사용자가 특정 Tenant의 데이터를 읽을 수 있는지, 특정 Tool로 운영 데이터를 삭제할 수 있는지는 별도의 권한 판단이다. MCP Server는 로그인 여부만 확인하고 Tool을 실행해서는 안 된다. 요청마다 검증된 Principal, Tenant, Scope, Tool, Parameter와 대상 Resource를 함께 평가해야 한다.

MCP Production Trust Boundary Diagram

┌──────────────────────────────────────────────────────────────────────┐
│ 사용자 또는 업무 주체                                                │
│ - 사람, 서비스 계정, 자동화 주체                                     │
└──────────────────────┬───────────────────────────────────────────────┘
│ 로그인·동의
▼
┌──────────────────────────────────────────────────────────────────────┐
│ Identity Provider / Authorization Server                             │
│ - 사용자 인증                                                        │
│ - MCP Server A를 대상으로 한 Token 발급                              │
│ - 최소 Scope·짧은 Lifetime·Step-up                                   │
└──────────────────────┬───────────────────────────────────────────────┘
│ resource / audience = MCP Server A
▼
┌──────────────────────────────────────────────────────────────────────┐
│ MCP Host / Client                                                    │
│ - 허용 Server 목록                                                   │
│ - 사용자·Role별 Tool Allowlist                                       │
│ - Tool과 Parameter 표시                                              │
│ - 고위험 Action 승인                                                 │
│ - Server 간 Credential과 Context 분리                                │
└──────────────────────┬───────────────────────────────────────────────┘
│ MCP Server A 전용 Access Token
═══════════════════════╪════ Trust Boundary 1 ═════════════════════════
▼
┌──────────────────────────────────────────────────────────────────────┐
│ MCP Server A / OAuth Resource Server                                 │
│ - 발급 Authorization Server와 Token Audience 검증                    │
│ - 만료·활성 상태·Scope 확인                                          │
│ - Principal → Tenant Server-side Mapping                             │
│ - Tool + 정규화된 Parameter 권한 검사                                │
│ - Secret Broker·감사·폐기                                            │
└──────────────────────┬───────────────────────────────────────────────┘
│ 별도 Downstream Token 또는 Workload Identity
│ MCP Client Token 전달 금지
═══════════════════════╪════ Trust Boundary 2 ═════════════════════════
▼
┌──────────────────────────────────────────────────────────────────────┐
│ Downstream API / Database / SaaS                                     │
│ - 자체 Resource·Scope·Tenant 권한                                    │
│ - MCP Server를 독립된 Client로 식별                                  │
└──────────────────────────────────────────────────────────────────────┘

[Resource·Prompt·Tool Result 등 신뢰하지 않은 데이터]

│
▼
[LLM Context]
│ 작업 제안
▼
[Policy + Authorization + Approval]
│ 통과한 경우만
▼
[실제 Tool 실행]

이 구조에서 LLM은 작업을 제안하는 주체이지, 권한을 부여하는 주체가 아니다.

Token Audience를 Scope와 혼동하지 않는다

Scope는 “무엇을 할 수 있는가”를 표현한다. Audience 또는 Resource는 “그 토큰을 어디에서 사용할 수 있는가”를 제한한다.

예를 들어 orders:write Scope를 가진 토큰이라고 해서 모든 주문 API와 MCP Server가 그 토큰을 받아서는 안 된다. 토큰은 특정 MCP Server를 대상으로 발급되고 해당 Server에서만 유효해야 한다.

MCP Authorization Specification은 Client가 Authorization Request와 Token Request 모두에 resource Parameter를 포함하고 대상 MCP Server의 Canonical URI를 지정하도록 요구한다. MCP Server는 토큰이 자신을 Intended Audience로 하여 발급됐는지 검증해야 하며 자신에게 발급되지 않은 토큰을 받아들이거나 전달해서는 안 된다.

운영 점검에서는 다음 세 질문에 답할 수 있어야 한다.

Authorization Server는 어떤 resource를 기준으로 토큰을 발급하는가?

MCP Server는 Audience를 어떤 방식으로 검증하는가?

다른 MCP Server나 Downstream API에 같은 토큰을 제시했을 때 확실하게 거부되는가?

마지막 항목은 문서 확인만으로 끝내지 말고 Negative Test로 검증해야 한다.

Token Passthrough는 Proxy 구현의 지름길이 아니다

MCP Client가 가진 Access Token을 MCP Server가 그대로 Downstream API에 전달하는 방식을 Token Passthrough라고 한다. 최신 MCP Authorization과 Security Best Practices는 이를 명시적으로 금지한다.

Passthrough를 허용하면 MCP Server가 Token의 원래 Audience를 무시하게 되고 Downstream 시스템에서는 실제 호출 경로와 Client Identity를 구분하기 어려워진다. 로그에는 MCP Server가 아니라 다른 주체가 직접 호출한 것처럼 남을 수 있으며 토큰 하나가 여러 Resource에서 재사용되면 침해 범위도 커진다.

권장 구조는 토큰을 두 개의 독립된 Credential로 분리하는 것이다.

MCP Client → MCP Server:

MCP Server 전용 Token resource / audience = MCP Server

MCP Server → Downstream API:

MCP Server가 별도로 취득한 Downstream Token resource / audience = Downstream API

사용자가 Third-party 서비스 접근을 승인해야 하는 경우에도 Third-party Credential은 MCP Client를 통과하면 안 된다. 공식 Elicitation Specification은 사용자가 MCP Server를 직접 승인하고 Server가 Downstream Token을 저장·관리하도록 요구한다. Protocol Core는 무상태여도 이러한 외부 연동 Credential Store는 상태를 가져야 한다.

최소 권한은 Scope 하나로 끝나지 않는다

read, write, admin Scope 몇 개를 만든 것만으로 최소 권한이 구현되지는 않는다. 운영 환경에서는 적어도 네 단계의 Gate가 필요하다.

MCP 공식 Security Guidance도 모든 Scope를 처음부터 발급하기보다 낮은 권한으로 시작하고 필요한 작업이 처음 발생했을 때 최소 Scope만 요청하는 Progressive Scope Model을 권고한다. Server는 부족한 Scope에 대해 403과 정확한 Scope Challenge를 반환할 수 있다.

Tool Allowlist는 Server와 사용자에 따라 달라져야 한다

하나의 MCP Server가 노출한 모든 Tool을 모든 사용자와 Agent에 자동으로 제공해서는 안 된다.

Allowlist는 적어도 다음 단위로 관리한다.

허용한 MCP Server

사용자·Role·Tenant별 허용 Tool

Development·Staging·Production 환경별 허용 Tool

조회·변경·삭제·외부 전송 등 Action 유형

대상 Resource와 최대 작업량

자동 실행 또는 승인 필요 여부

Tool 이름도 전역적으로 고유한 Security Identity가 아니다. 공식 Specification은 Tool 이름의 고유성이 Server 내부에만 적용되며 Server 이름 역시 고유성이 보장되지 않는다고 설명한다. 따라서 delete_file이라는 이름이나 Server Display Name이 아니라, 신뢰된 Server Identity와 Tool ID의 조합으로 정책을 관리해야 한다.

JSON Schema 검증과 권한 검사는 다른 작업이다

MCP Tool은 inputSchema로 Parameter의 구조와 형식을 정의할 수 있다. 그러나 Schema를 통과했다는 것은 요청의 형태가 맞다는 뜻일 뿐, 호출자가 그 값에 접근할 권한이 있다는 뜻은 아니다.

예를 들어 다음 Parameter가 Schema상 유효하더라도:

JSON

{ “tenant_id”: “tenant-b”, “record_id”: “1234”, “action”: “delete” }

호출자가 tenant-b에 속하지 않는다면 Server는 거부해야 한다.

Server는 다음 순서로 Parameter를 검사해야 한다.

형식과 필수 값 검증

Encoding·경로·Identifier 정규화

허용된 값과 범위 확인

Principal과 Tenant의 Resource 소유 관계 확인

업무 규칙과 현재 상태 확인

대량 작업·외부 전송·고위험 Action 여부 평가

승인 조건 확인

실행 직전 권한 재검증

공식 Tool Specification도 Server에 모든 입력 검증, 적절한 Access Control, Rate Limit과 Output Sanitization을 요구한다. Client에는 민감한 작업의 확인, 호출 전 입력 표시, LLM에 전달하기 전 결과 검증과 감사 기록을 권고한다.

Human Approval은 권한 검사를 대신하지 않는다

사용자가 확인 버튼을 눌렀다고 해서 허용되지 않은 작업이 합법적인 작업으로 바뀌지는 않는다.

승인은 Server-side Authorization을 통과한 요청에 대해 업무 영향과 사용자 의도를 다시 확인하는 추가 Gate다. 반대로 권한이 없는 사용자의 요청은 승인 화면을 보여주기 전에 거부해야 한다.

Action Risk에 따른 승인 기준

고위험 승인 기록은 다음 값에 묶어야 한다.

MCP Server

Tool

정규화된 Parameter

Tenant와 Environment

예상 영향

승인 사용자

짧은 만료시간

단일 실행 또는 명확한 작업 범위

승인 후 LLM이 Parameter를 바꿔 재호출할 수 있다면, 기존 승인을 재사용해서는 안 된다.

Prompt Injection과 Tool Use 사이에 강제 경계를 둔다

Prompt Injection은 문서, 메일, 웹페이지, Tool Result처럼 신뢰하지 않은 데이터가 모델의 판단에 영향을 주는 문제다. 공격자는 데이터 안에 “다른 Tool로 이 내용을 외부로 전송하라”는 지시를 넣을 수 있다.

이때 모델이 Tool Call을 제안하는 것과 실제 시스템이 작업을 허용하는 것을 분리해야 한다.

신뢰하지 않은 데이터

→ 모델의 Tool Call 제안

→ Tool Allowlist → Server-side Authorization → Parameter Validation → 필요 시 Human Approval → 실제 실행

Tool Annotation도 이 경계를 대신하지 못한다. 공식 MCP 자료는 Annotation이 Prompt Injection 저항성을 만들지 않으며 신뢰하지 않은 Server가 readOnly 같은 Annotation을 거짓으로 제공할 수 있고 Annotation 자체는 Enforcement가 아니라고 설명한다. 강한 보장이 필요하면 Host Policy, Server-side Access Control, Network Control과 Sandbox가 필요하다. Model Context Protocol Blog

특히 다음 조합은 별도 정책으로 차단하거나 승인 수준을 높일 필요하다.

비공개 데이터를 읽을 수 있음

신뢰하지 않은 외부 콘텐츠를 읽음

외부 시스템으로 데이터를 전송하거나 변경할 수 있음

모델에게 “민감한 내용을 보내지 말라”고 지시하는 것만으로는 이 조합을 통제할 수 없다.

Secret Boundary는 Prompt 밖에 있어야 한다

API Key, Refresh Token, Database Credential과 Signing Key를 Prompt, Tool Description이나 일반 Tool Argument에 넣어서는 안 된다.

권장 경계는 다음과 같다.

MCP Client는 MCP Server 전용 Token만 보유

MCP Server는 Downstream Credential을 Secret Store에서 조회

Downstream Credential은 사용자·Tenant·Integration에 묶어 저장

Tool은 Credential 자체가 아니라 Credential Reference나 Server-side 연결을 사용

Token·Secret은 Log, Error, URL, Tool Result에 포함하지 않음

Credential 접근 권한과 Tool 실행 권한을 별도로 관리

Third-party Authorization을 사용할 때도 MCP Server가 Token을 저장·관리하고 MCP Client에는 전달하지 않아야 한다. Elicitation URL에는 Credential이나 개인정보를 넣을 수 없으며 사전 인증된 URL도 전달해서는 안 된다.

Local stdio Server는 별도의 위험 모델을 가진다

MCP Authorization Specification에서 HTTP Authorization은 선택적 기능이며 stdio Transport는 같은 OAuth 흐름을 따르기보다 환경에서 Credential을 가져오도록 정의돼 있다. 그러나 이는 Local Server가 신뢰된다는 뜻이 아니다.

Local MCP Server는 MCP Client와 같은 사용자 권한으로 실행될 수 있다. 따라서 설치 전에 실제 실행 Command를 보여주고 파일시스템·네트워크 접근을 제한하며 Sandbox와 최소 권한 실행을 적용해야 한다. 공식 Guidance도 One-click 설정에서 정확한 Command 표시와 명시적 승인, 파일·네트워크 제한을 요구한다.

Tenant는 모델이 보내는 값으로 결정하지 않는다

멀티테넌트 환경에서 가장 위험한 설계 중 하나는 Tool Parameter의 tenant_id를 그대로 신뢰하는 것이다.

Tenant는 다음 중 검증된 Server-side 근거로 결정해야 한다.

인증된 사용자와 Tenant Membership

Authorization Grant

Server-side Policy Mapping

연결된 Downstream Account

Workload Identity와 배포 환경

Tool Parameter에 Tenant나 Project ID가 들어오더라도 그 값은 대상 선택 값일 뿐이다. Server는 호출자가 해당 대상에 접근할 수 있는지 다시 확인해야 한다.

Cache, 상태 Handle, Downstream Token과 승인 기록에도 같은 원칙을 적용한다. 다음처럼 사용자와 Tenant를 Binding하지 않은 전역 Key는 피해야 한다.

나쁜 상태 Key:

workflow:1234

권장 구조: tenant-a:user-42:workflow:1234

최신 MCP는 Protocol-level Session이 없지만 여러 요청에 걸친 Workflow Handle은 일반 Tool Argument로 전달될 수 있다. 공식 Guidance는 Handle 소유를 인증으로 간주하지 않고 검증된 사용자에게 Server-side로 묶으며 만료시킬 것을 요구한다.

Credential Lifetime과 Revocation을 함께 설계한다

짧은 Token Lifetime은 유출 피해를 줄이지만 Revocation을 대신하지는 않는다. 반대로 Revocation Endpoint가 있더라도 Resource Server가 오래된 권한 결과를 장기간 Cache하면 즉시 차단되지 않을 수 있다.

MCP Authorization Security Considerations는 짧은 Access Token과 Public Client의 Refresh Token Rotation을 요구한다. RFC 7009는 Access·Refresh Token을 폐기하는 표준 Endpoint를, RFC 7662는 Resource Server가 Token의 Active·Expired·Revoked 상태와 권한 Metadata를 조회하는 방식을 정의한다.

사용자 퇴사, Tenant 이동, 외부 서비스 연결 해제나 보안 사고가 발생했을 때는 다음을 한꺼번에 처리할 수 있어야 한다.

사용자와 MCP Server 사이의 Grant 폐기

MCP Refresh·Access Token 무효화

MCP Server가 보관한 Downstream Grant 폐기

Tool과 Tenant Policy 제거

State Handle과 미사용 승인 기록 무효화

해당 Server 연결 또는 Client Registration 비활성화

이미 진행 중인 고위험 작업 취소

“Token이 곧 만료된다”는 이유로 Revocation 경로를 생략하면 안 된다.

Audit은 Prompt 전체를 저장하는 일이 아니다

이 글의 Audit은 Agent Observability와 목적이 다르다. Model Latency, Retrieval 시간, Token 사용량과 Retry 분석은 Topic 020의 범위다. MCP Security Audit은 권한 판단과 실제 Side Effect를 재구성하는 데 초점을 둔다.

최소한 다음 이벤트를 기록한다.

검증된 사용자 또는 Service Principal

Tenant와 Environment

MCP Server Identity와 Authorization Server Issuer

Protocol Version

Tool ID와 Version

정규화된 Parameter의 Redacted Summary 또는 Hash

요청한 Scope와 실제 부여된 Scope

Audience·Token Validation 결과

적용한 Policy Version

Allow·Deny·Step-up 결정

Human Approval 주체·시각·범위

Downstream Resource와 Action

실행 결과와 Error

Credential·Grant·Server 폐기 이벤트

Tool 목록과 권한 설정 변경

반대로 다음 값은 기본 Audit Log에서 제외하거나 별도 보호 저장소로 분리한다.

Access Token과 Refresh Token 원문

API Key와 Secret

전체 Prompt·Completion

민감한 Tool Result 전체

개인정보가 포함된 원문 Parameter

인증된 URL이나 Credential Reference

공식 Tool Specification 역시 Tool Usage를 감사 목적으로 기록하도록 권고하지만 무엇을 기록할지는 별도의 데이터 최소화 정책이 필요하다.

Server Trust는 이름이나 Tool 설명으로 결정하지 않는다

MCP의 clientInfo는 Protocol상 Self-reported 값이며 보안 판단에 사용해서는 안 된다. Tool Annotation도 신뢰한 Server에서 온 경우가 아니라면 신뢰할 수 없다. Server 이름 역시 전역 고유성이 보장되지 않는다.

Server Trust Record에는 최소한 다음을 남긴다.

운영·배포 주체

Remote Endpoint 또는 Local Package의 정확한 식별자

Package Version·Digest·Signature

Authorization Server Issuer

허용 Redirect URI와 Client Registration 방식

노출 Tool·Resource·Prompt 목록

파일시스템·네트워크·Downstream 접근 범위

데이터 저장·보존·삭제 정책

Update Channel과 자동 업데이트 여부

보안 연락처와 Incident 대응 경로

연결 비활성화·제거 절차

Tool 목록이 변경되면 단순 UI 갱신으로 끝내지 말고 새 Tool과 기존 Tool의 권한·Risk 차이를 다시 검토해야 한다.

Third-party MCP는 별도 Trust Domain으로 취급한다

외부 MCP Server를 연결할 때는 “많이 쓰는 Server인가”보다 다음을 확인한다.

Remote Server

Endpoint와 운영 주체가 확인되는가

Authorization Server Issuer가 예상한 값과 일치하는가

Client Credential을 다른 Authorization Server와 공유하지 않는가

OAuth Metadata Discovery URL이 내부 IP·Cloud Metadata·Localhost를 가리킬 수 없는가

Tool과 Scope가 실제 사용 목적보다 넓지 않은가

데이터가 어느 지역과 시스템에 저장되는가

Tool 목록·권한·약관 변경을 탐지할 수 있는가

즉시 비활성화할 Kill Switch가 있는가

MCP Client는 Authorization Server별로 Registration State, Credential과 Token을 분리해야 한다. Metadata Discovery 과정에서는 악성 Server가 내부 주소나 Cloud Metadata Endpoint를 가리키는 SSRF 위험이 있으므로 HTTPS 강제, Private·Reserved IP 차단, Redirect 재검증과 Egress 통제가 필요하다.

Local Server

Package Source와 Publisher를 확인했는가

실제 실행 Command와 Argument를 검토했는가

자동 업데이트로 실행 내용이 바뀌는가

사용자 Home·SSH Key·Browser Profile·환경변수 접근이 필요한가

외부 네트워크 Egress가 필요한가

Sandbox 또는 별도 OS User로 실행할 수 있는가

제거 후 Credential과 State가 남지 않는가

Local Server는 설치 파일이 아니라 사용자의 권한으로 실행되는 코드다. Discovery나 편리한 설치 절차를 Trust Approval로 간주해서는 안 된다.

MCP Production Security Checklist

아래 항목 중 하나라도 명확히 답할 수 없다면, 전체 권한을 한 번에 연결하기보다 Read-only Sandbox나 제한된 Tenant에서 먼저 검증해야 한다.

Version과 Transport

운영 Client와 Server가 지원하는 MCP Revision을 기록했다.

2026-07-28 Modern Protocol과 Legacy Session 기반 Revision을 구분했다.

HTTP 요청마다 Protocol Version을 검사하고 불일치 요청을 거부한다.

Streamable HTTP Server가 Origin을 검증한다.

Local HTTP Server는 기본적으로 Localhost 또는 제한된 IPC에만 Binding한다.

stdio Server가 어떤 환경변수와 OS 권한을 상속하는지 확인했다.

Server Trust

허용 MCP Server Endpoint 또는 Package를 Allowlist로 관리한다.

Display Name이나 Self-reported serverInfo를 Security Identity로 사용하지 않는다.

Remote Server의 운영 주체, Domain, TLS와 Authorization Server Issuer를 확인했다.

Local Server의 정확한 실행 Command·Package Version·Digest를 검토했다.

Server·Tool 목록 변경 시 재승인 또는 Risk Review가 실행된다.

연결을 즉시 차단하는 Kill Switch가 있다.

Authentication과 Authorization

사용자 또는 Service Principal을 검증하는 Authentication Boundary가 있다.

MCP Server가 매 요청의 Token을 검증한다.

사용자 인증과 Tool 실행 권한 검사를 분리한다.

Principal·Role·Tenant Mapping을 Server-side에서 관리한다.

부족한 권한은 401과 403을 구분해 거부한다.

낮은 권한으로 시작하고 필요한 Action에서만 Step-up한다.

Token Audience와 Passthrough

Authorization Request와 Token Request에 MCP Server의 resource를 보낸다.

MCP Server가 자신을 Intended Audience로 한 Token만 수락한다.

다른 API나 MCP Server용 Token을 제시하는 Negative Test가 실패한다.

Token을 Query String이나 Tool Parameter로 전달하지 않는다.

MCP Client Token을 Downstream API로 전달하지 않는다.

Downstream API에는 별도 Token 또는 Workload Identity를 사용한다.

Authorization Server별 Client Credential과 Token Store가 분리돼 있다.

Tool과 Parameter Policy

사용자·Role·Tenant·Environment별 Tool Allowlist가 있다.

Model이 선택했다는 이유만으로 Tool을 실행하지 않는다.

모든 Tool Input을 Schema와 업무 규칙으로 검증한다.

Identifier·Path·URL·수량·날짜를 정규화한 뒤 권한을 검사한다.

Tool Parameter의 Tenant·Project ID를 그대로 신뢰하지 않는다.

대상 Resource가 호출자의 Tenant에 속하는지 확인한다.

대량 작업, 외부 전송과 반복 호출에 별도 Limit를 둔다.

Tool Output을 정제·검증한 뒤 LLM Context에 전달한다.

Tool Annotation은 신뢰한 Server의 Hint로만 사용한다.

Human Approval과 High-impact Action

고위험 Action 목록과 소유자가 정의돼 있다.

승인 화면에 Tool, 대상, Parameter와 예상 영향을 표시한다.

승인 전에 Server-side Authorization을 완료한다.

승인을 정확한 Tool·Parameter·Tenant·Environment에 Binding한다.

승인 후 Parameter가 바뀌면 다시 승인받는다.

삭제·권한 변경·Production 작업·결제·대량 Export는 요청별 승인 대상이다.

필요한 Action에는 재인증, Scope Step-up 또는 이중 승인을 적용한다.

자동 실행 가능한 Action과 사람이 승인해야 하는 Action이 문서화돼 있다.

Prompt Injection Boundary

Resource·Prompt·Tool Result를 기본적으로 신뢰하지 않은 입력으로 취급한다.

LLM의 Tool Call은 실행 명령이 아니라 제안으로 취급한다.

Prompt 안의 지시가 Tool Allowlist나 권한 정책을 바꿀 수 없다.

비공개 데이터 조회 후 외부 전송 Tool 사용 시 승인 수준을 높인다.

모델 지시문이 아니라 Host·Server·Network Policy로 Exfiltration을 통제한다.

신뢰하지 않은 콘텐츠가 포함된 실행 경로를 Audit에서 식별할 수 있다.

Secret과 Tenant Isolation

Secret을 Prompt, Tool Description, URL이나 일반 Argument에 넣지 않는다.

Downstream Token을 MCP Server의 보호된 Secret Store에 보관한다.

Token을 사용자·Tenant·Integration 단위로 분리한다.

한 Tenant의 Cache·State·Credential이 다른 Tenant에서 조회되지 않는다.

State Handle을 인증 수단으로 사용하지 않는다.

State Handle을 사용자·Tenant에 Binding하고 만료시킨다.

Error와 Audit Log에 Token·Secret이 포함되지 않는다.

Lifetime과 Revocation

Access Token이 불필요하게 장기간 유효하지 않다.

Refresh Token을 기밀로 저장하고 필요한 경우 회전한다.

사용자 Grant와 Downstream Grant의 폐기 경로를 각각 보유한다.

Server·Tool·Client Registration을 즉시 비활성화할 수 있다.

사용자 퇴사·Tenant 이동·연결 해제 시 자동 폐기 절차가 있다.

권한 Cache 시간이 목표 Revocation 시간보다 길지 않다.

State Handle과 미사용 Approval도 함께 무효화한다.

진행 중인 고위험 작업을 취소하거나 차단할 수 있다.

Audit과 Incident Response

Allow·Deny·Step-up·Approval·Revocation 결정을 기록한다.

사용자, Tenant, Server, Tool, Policy Version과 결과를 연결할 수 있다.

Parameter는 Redaction 또는 Hash를 적용해 기록한다.

Raw Token·Secret·민감 Prompt 전체를 일반 Log에 남기지 않는다.

Tool과 Scope 변경 이력을 보존한다.

비정상 호출량·반복 실패·Cross-tenant 시도를 탐지한다.

Credential 유출 시 어떤 Grant와 Downstream 연결을 폐기할지 Runbook이 있다.

사고 후 실제 실행된 Side Effect를 재구성할 수 있다.

연결을 보류해야 하는 조건

다음 중 하나라도 존재하면 Production 연결을 보류하는 편이 낫다.

MCP Server가 Token Audience를 검증하지 않는다.

Client Token을 Downstream API로 그대로 전달한다.

모든 Tool을 모든 사용자에게 노출한다.

Tenant를 Prompt나 Tool Argument만으로 결정한다.

고위험 Action을 Model 판단만으로 자동 실행한다.

Secret이 Prompt·Argument·Log에 포함된다.

Third-party Server의 운영 주체와 실행 권한을 확인할 수 없다.

Credential과 연결을 폐기하는 경로가 없다.

실행 결과를 어느 사용자·Tenant·승인과도 연결할 수 없다.

자주 묻는 질문

OAuth를 구현했으면 MCP Server는 안전한가?

아니다. OAuth는 사용자와 Token의 권한 경계를 만드는 중요한 구성요소지만 Tool Allowlist, Parameter-level Authorization, Human Approval, Tenant Isolation과 Downstream Credential 분리는 별도로 구현해야 한다.

Read-only Tool은 자동 승인해도 되는가?

신뢰한 Server가 제공하고 실제로 Side Effect가 없으며 조회 대상과 데이터 민감도가 정책 범위 안에 있을 때만 가능하다. readOnly Annotation만으로 판단해서는 안 된다. 신뢰하지 않은 Server는 Annotation과 다른 동작을 수행할 수 있다.

최신 MCP가 Stateless라면 Session Hijacking은 사라졌는가?

Protocol-level Session ID는 최신 Revision에서 제거됐지만 Workflow ID나 Cart ID 같은 State Handle은 여전히 Tool Argument로 사용될 수 있다. Handle을 사용자와 Tenant에 Binding하지 않으면 다른 사용자의 상태에 접근하는 문제가 남는다.

연결 성공보다 거부 성공을 시험해야 한다

MCP Server가 정상적으로 연결되고 Tool이 호출되는지만 확인하면 보안 검증의 절반도 끝나지 않는다.

운영 전에는 다음 요청이 확실히 실패하는지 시험해야 한다.

다른 Audience용 Token

만료되거나 폐기된 Token

Scope가 부족한 Token

허용되지 않은 Tool

다른 Tenant의 Resource ID

승인 후 Parameter가 변경된 요청

다른 사용자의 State Handle

허용하지 않은 Downstream Destination

비활성화한 Server와 Client Credential

Production 연결 판정 기준은 “Agent가 작업을 수행할 수 있는가”가 아니다.

잘못된 사용자, Token, Tool, Parameter, Tenant와 승인으로는 작업을 수행할 수 없으며 이미 부여한 권한을 신속하게 회수하고 그 과정을 감사 기록으로 재구성할 수 있는가.

여기에 답할 수 있을 때 MCP는 단순한 연결 기능을 넘어 통제 가능한 운영 권한 경로가 된다.

공식 참고자료

• https://modelcontextprotocol.io/specification/2026-07-28
• https://modelcontextprotocol.io/specification/draft/basic/authorization
• https://modelcontextprotocol.io/specification/draft/basic/authorization/security-considerations