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가 실제로 구현됐는지를 확인하는 편이 정확합니다.^[6][7][8]

네 개의 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를 함께 평가해야 합니다.^[6][7]

MCP Production Trust Boundary Diagram

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

신뢰하지 않은 데이터 → LLM Context → 작업 제안 → Policy + Authorization + Approval → 통과한 경우만 실제 Tool 실행

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

사용자 또는 업무 주체

사람, 서비스 계정, 자동화 주체가 로그인하고 동의합니다.

Identity Provider / Authorization Server

사용자를 인증하고 MCP Server A 전용 Token을 발급합니다. 최소 Scope, 짧은 Lifetime과 Step-up을 적용합니다.

MCP Host / Client

허용 Server와 사용자·Role별 Tool Allowlist를 관리합니다. Tool·Parameter를 표시하고 고위험 Action을 승인하며 Server 간 Credential과 Context를 분리합니다.

Trust Boundary 1: MCP Server A 전용 Access Token

resource / audience = MCP Server A입니다. MCP Server는 Issuer·Audience·만료·활성 상태·Scope를 검증합니다. Principal과 Tenant를 Server-side로 연결하고 Tool·정규화된 Parameter의 권한을 검사합니다. Secret Broker·감사·폐기도 맡습니다.

Trust Boundary 2: 별도 Downstream Credential

별도의 Downstream Token 또는 Workload Identity를 사용합니다. MCP Client Token을 전달하지 않습니다.

Downstream API / Database / SaaS

자체 Resource·Scope·Tenant 권한을 검사하고 MCP Server를 독립된 Client로 식별합니다.

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는 상태를 가져야 합니다.^[7][8]

최소 권한은 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상 유효하더라도:

{ "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에 전달하기 전 결과 검증과 감사 기록을 권고합니다.^[6][7]

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

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

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

Action Risk에 따른 승인 기준

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

MCP Server

Tool

정규화된 Parameter

Tenant와 Environment

예상 영향

승인 사용자

짧은 만료시간

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

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

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도 전달해서는 안 됩니다.^[6]

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 표시와 명시적 승인, 파일·네트워크 제한을 요구합니다.^[7][8]

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로 묶으며 만료시킬 것을 요구합니다.^[8]

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 경로를 생략하면 안 됩니다.^[8]

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를 감사 목적으로 기록하도록 권고하지만 무엇을 기록할지는 별도의 데이터 최소화 정책이 필요합니다.^[6]

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 차이를 다시 검토해야 합니다.^[6]

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로 간주해서는 안 됩니다.^[8]

MCP Production Security Checklist

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

Version과 Transport 1

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

Version과 Transport 2

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

Version과 Transport 3

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

Version과 Transport 4

Streamable HTTP Server가 Origin을 검증합니다.

Version과 Transport 5

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

Version과 Transport 6

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

Server Trust 1

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

Server Trust 2

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

Server Trust 3

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

Server Trust 4

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

Server Trust 5

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

Server Trust 6

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

Authentication과 Authorization 1

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

Authentication과 Authorization 2

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

Authentication과 Authorization 3

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

Authentication과 Authorization 4

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

Authentication과 Authorization 5

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

Authentication과 Authorization 6

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

Token Audience와 Passthrough 1

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

Token Audience와 Passthrough 2

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

Token Audience와 Passthrough 3

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

Token Audience와 Passthrough 4

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

Token Audience와 Passthrough 5

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

Token Audience와 Passthrough 6

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

Token Audience와 Passthrough 7

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

Tool과 Parameter Policy 1

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

Tool과 Parameter Policy 2

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

Tool과 Parameter Policy 3

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

Tool과 Parameter Policy 4

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

Tool과 Parameter Policy 5

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

Tool과 Parameter Policy 6

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

Tool과 Parameter Policy 7

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

Tool과 Parameter Policy 8

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

Tool과 Parameter Policy 9

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

Human Approval과 High-impact Action 1

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

Human Approval과 High-impact Action 2

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

Human Approval과 High-impact Action 3

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

Human Approval과 High-impact Action 4

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

Human Approval과 High-impact Action 5

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

Human Approval과 High-impact Action 6

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

Human Approval과 High-impact Action 7

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

Human Approval과 High-impact Action 8

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

Prompt Injection Boundary 1

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

Prompt Injection Boundary 2

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

Prompt Injection Boundary 3

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

Prompt Injection Boundary 4

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

Prompt Injection Boundary 5

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

Prompt Injection Boundary 6

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

Secret과 Tenant Isolation 1

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

Secret과 Tenant Isolation 2

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

Secret과 Tenant Isolation 3

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

Secret과 Tenant Isolation 4

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

Secret과 Tenant Isolation 5

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

Secret과 Tenant Isolation 6

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

Secret과 Tenant Isolation 7

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

Lifetime과 Revocation 1

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

Lifetime과 Revocation 2

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

Lifetime과 Revocation 3

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

Lifetime과 Revocation 4

Server·Tool·Client Registration을 즉시 비활성화하는 경로가 있습니다.

Lifetime과 Revocation 5

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

Lifetime과 Revocation 6

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

Lifetime과 Revocation 7

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

Lifetime과 Revocation 8

진행 중인 고위험 작업을 취소하거나 차단하는 경로가 있습니다.

Audit과 Incident Response 1

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

Audit과 Incident Response 2

사용자, Tenant, Server, Tool, Policy Version과 결과를 연결하는 기록이 있습니다.

Audit과 Incident Response 3

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

Audit과 Incident Response 4

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

Audit과 Incident Response 5

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

Audit과 Incident Response 6

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

Audit과 Incident Response 7

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

Audit과 Incident Response 8

사고 후 실제 실행된 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·승인과도 연결할 수 없습니다.

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

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는 연결 기능만이 아니라 통제 가능한 운영 권한 경로가 됩니다.