AX LABS
← 블로그 에이전트 제품 설계

MCP 권한은 IdP에서 끝난다

도구 권한은 프롬프트가 아니라 권한면에서 결정된다

AX LABS 7분 읽기

AI 에이전트 PoC는 MCP 서버를 붙이는 순간 빨라진다. 그런데 운영 전환 회의에서는 같은 질문이 반복된다. “이 사용자가 이 tool을 호출해도 되는가.” “퇴사·전보가 나면 즉시 막히는가.” “매번 OAuth 동의창을 띄울 것인가.” 이 질문에 답하지 못하면 MCP는 자동화 인터페이스가 아니라 또 하나의 예외 계정 묶음이 된다.

2026년 7월 현재 MCP 쪽 논의도 같은 방향으로 가고 있다. Enterprise-Managed Authorization은 2026년 6월 18일 stable로 공개됐고, 조직이 IdP를 통해 MCP 서버 접근을 중앙 관리하며 사용자는 per-app OAuth 없이 첫 로그인에서 연결되는 모델을 제시한다. MCP 2025-11-25 authorization spec도 OAuth 2.1, Protected Resource Metadata, scope challenge를 전제로 둔다. 결론은 명확하다. MCP 권한은 클라이언트 화면이나 프롬프트가 아니라 기업의 identity plane에서 끝나야 한다.

Zero-touch는 무권한이 아니라 사전 승인이다

Zero-touch를 “사용자 확인 없이 아무 tool이나 실행”으로 해석하면 바로 실패한다. 여기서 zero-touch는 사용자별 반복 동의창을 없애는 것이다. 승인 주체는 사라지지 않는다. 개인의 즉석 consent가 아니라 IdP 정책, 그룹, role, SCIM entitlement가 승인 주체가 된다.

consentless access는 runtime 통제를 없애는 설계가 아니다. per-app OAuth consent를 조직의 사전 승인 정책으로 대체하는 설계다.

따라서 destructive action, 결제, 외부 발송, 권한 변경 같은 tool은 별도 human approval을 남긴다. OAuth consent와 업무 승인 결재를 섞으면 안 된다. 전자는 접근권한이고, 후자는 행위 승인이다.

SCIM entitlement는 scope catalog로 번역된다

핵심 산출물은 “권한 매핑표”가 아니라 scope catalog다. MCP server가 노출하는 tool마다 최소 scope를 정의하고, IdP의 그룹·entitlement를 그 scope로 투영한다.

설계 요소 흔한 PoC 방식 운영 설계
권한 원천 MCP client 설정 파일 IdP 그룹·SCIM entitlement
권한 단위 서버 전체 접근 per-tool, 필요 시 argument 조건
토큰 내용 넓은 read/write scope tool별 최소 OAuth scope
차단 위치 agent prompt 또는 tool 내부 if문 gateway·MCP server pre-dispatch
회수 방식 client별 수동 revoke IdP·SCIM lifecycle로 자동 회수

scope 이름은 사람이 읽을 수 있어야 한다. 예를 들어 mcp:crm.customer.read, mcp:crm.customer.update, mcp:finance.invoice.approve처럼 server, domain, action이 드러나야 한다. 더 중요한 것은 stable identifier다. IdP group displayName은 바뀐다. SCIM externalId, entitlement id, IdP object id를 기준키로 잡아야 운영 중 이름 변경이 권한 사고로 이어지지 않는다.

Okta는 SCIM 2.0 기반으로 role과 entitlement resource type을 발견·할당하는 가이드를 제공한다. Microsoft Entra ID도 SCIM client로 사용자·그룹·그룹 멤버십을 애플리케이션에 provision한다. 이 기반 위에 projection layer를 둔다. projection layer는 “재무승인자 그룹”을 invoice.approve tool scope로 번역하고, “영업조회 entitlement”를 customer.read scope로 번역한다.

권한 판정은 tool 실행 전에 끝난다

MCP tool scope 논의가 어려운 이유는 tool과 scope가 항상 1:1로 맞지 않기 때문이다. 같은 update_record tool도 인자에 따라 고객정보 수정, 가격 변경, 승인 상태 변경이 된다. MCP Tool Scopes Working Group도 2026년 2월 회의에서 scope challenge는 구현 가능하지만 tool scope 정의와 관리 가이드는 아직 구현자에게 크게 의존한다고 정리했다.

그래서 권한 판정은 세 층으로 나눠야 한다.

  1. Catalog: tool별 기본 scope와 argument-sensitive rule을 등록한다.
  2. Projection: IdP 그룹·SCIM entitlement를 사용자별 effective scope로 계산한다.
  3. Enforcement: gateway 또는 MCP server가 JSON-RPC dispatch 전에 token scope와 tool call을 대조한다.

MCP authorization spec의 WWW-Authenticate scope challenge는 부족한 scope를 클라이언트에 알려주는 통로다. 하지만 운영에서는 challenge에 기대기 전에 access token이 올바른 scope로 발급돼야 한다. Enterprise-Managed Authorization의 ID-JAG 흐름처럼 client가 MCP Authorization Server로 사용자를 다시 보내지 않고 enterprise IdP assertion을 교환하는 구조가 이 지점에 맞다. 사용자는 로그인만 한다. scope는 조직 정책이 결정한다.

지금 설계할 것은 connector가 아니라 권한면이다

MCP 도입팀이 먼저 만들 것은 멋진 tool 목록이 아니다. tool catalog, scope catalog, entitlement projection, audit schema다. 이 네 가지가 없으면 agent가 늘어날수록 예외 승인과 수동 revoke가 늘어난다.

실행 순서는 단순하다. 우선 고위험 tool을 분류한다. 다음으로 IdP 그룹과 SCIM entitlement의 stable id를 수집한다. 그다음 per-tool scope를 정의하고, gateway 또는 MCP server에서 pre-dispatch enforcement를 넣는다. 마지막으로 tool call, subject, source entitlement, issued scope, decision, approval id를 같은 audit event로 남긴다.

AX Ops 관점에서 이 작업은 보안팀의 부속 과제가 아니다. agent product 설계의 중심이다. 사용자가 매번 동의하지 않아도 되는 경험은, 뒤에서 권한이 더 엄격하게 계산될 때만 안전하다.

참고

MCP 권한 투영은 한 번의 연동 프로젝트가 아니라 운영 체계 설계다. 이 체계를 AX 도입 사이클 안에서 설계하려면 AX Ops 방법론 →