MCP가 안정적인 “Enterprise-Managed Authorization” 사양을 발표했습니다. OAuth client-credentials 초안과 두 개의 공개 제안을 포함한 다른 머신 간(machine-to-machine) ID 초안들은 아직 미완성 상태로 남아 있습니다. Model Context Protocol을 사용하여 자율 에이전트를 실행하려는 사람들에게 이는 현재의 프로토콜이 인간 사용자는 검증할 수 있지만, 관리되지 않는 프로세스가 주장하는 본인임을 증명할 수 있는 즉시 사용 가능한 방법은 제공하지 않는다는 것을 의미합니다.

로드맵이 중요한 이유

Model Context Protocol (MCP) 로드맵은 에이전트 ID 및 보안을 최우선 과제 중 하나로 나열하고 있습니다. 출시 예정이었던 네 가지 항목은 인간 중심의 브라우저 흐름(human-centric browser flow), 서비스를 위한 OAuth client-credentials 흐름, DPoP 기반 토큰 바인딩, 그리고 워크로드 ID 페더레이션(workload-identity federation) 메커니즘입니다. 이 중 첫 번째인 Enterprise-Managed Authorization만이 안정적인 상태에 도달했습니다.

안정적인 사양이 실제로 수행하는 작업

Enterprise-Managed Authorization을 사용하면 IT 관리자가 각 직원이 모든 연결을 승인하게 하는 대신, 단일 콘솔에서 서버 액세스 권한을 부여할 수 있습니다. 이 흐름은 브라우저 리다이렉트와 사용자 로그인을 사용하므로, 노트북을 사용하는 사람이 인증을 완료하면 서버가 해당 사용자의 세션을 신뢰하게 됩니다.

한계는 명확합니다. 이 프로세스에는 키보드를 조작할 사람이 필요합니다. 밤새 실행되거나 데이터를 처리하거나 알림에 응답하는 에이전트는 로그인 버튼을 클릭할 사람이 없습니다. 결과적으로, 관리되지 않는 에이전트에 의존하는 모든 배포는 현재 MCP가 보장하는 유일한 사양을 사용할 수 없습니다.

초안 옵션과 그 단점

두 가지 초안 확장 기능은 에이전트에 고유한 ID를 부여하는 것을 목표로 합니다:

  • SEP-1932 (DPoP) – 토큰을 공개-개인 키 쌍에 바인딩하여 탈취된 토큰을 무용지물로 만듭니다.
  • SEP-1933 (Workload Identity Federation) – 에이전트가 클라우드 플랫폼에 이미 프로비저닝된 ID를 상속받을 수 있게 합니다.

두 항목 모두 오픈 풀 리퀘스트(pull request) 상태이며, 공식 사양에 병합되지 않았습니다. 그동안 문서화된 유일한 다른 옵션은 사전 등록된 비밀값을 요구하는 OAuth client-credentials 흐름입니다. 에이전트가 읽을 수 있는 곳에 이러한 비밀값을 저장하는 것은 전형적인 공격 표면(attack surface)을 만듭니다. 비밀값이 유출되면 공격자가 누구든 에이전트를 사칭할 수 있습니다.

현재 프로덕션 환경을 위한 실질적인 단계

프로토콜이 아직 네이티브 에이전트 ID를 제공하지 않기 때문에, 팀은 ID 관리를 MCP 외부로 이동시켜 에이전트를 보호할 수 있습니다:

  1. 워크로드 계층에서 검증 가능한 ID 발급. SPIRE와 같은 시스템은 호스트의 신뢰 루트(trust root)와 연결된 수명이 짧은 인증서를 생성하여 정적 비밀값을 제거합니다.
  2. 게이트웨이에서 자격 증명 종료. 프런트엔드 서비스가 API 키 또는 토큰을 보유하고 에이전트를 대신하여 요청을 전달함으로써, 런타임 환경에서 비밀값을 분리합니다.
  3. 토큰 내용이 아닌 검증된 ID를 기반으로 권한 부여. 인증(누가 호출하는가)과 권한 부여(무엇을 할 수 있는가)를 분리하여, 인증 방식이 변경되더라도 정책을 적용할 수 있도록 합니다.

향후 주목해야 할 사항

두 개의 오픈 풀 리퀘스트인 DPoP 바인딩과 워크로드 ID 페더레이션은 MCP 내에서 진정한 머신 간 ID 표준으로 가는 유일한 경로입니다. 커뮤니티가 이를 병합하면, 에이전트는 비밀값을 노출하지 않고도 개인 키의 소유를 증명하거나 클라우드에서 발급한 ID를 상속받을 수 있게 됩니다. 그때까지 모든 프로덕션 배포는 외부 ID 프레임워크에 의존하거나 정적 자격 증명의 위험을 감수해야 합니다.

결론은 명확합니다. MCP는 현재 요청 뒤에 있는 사람을 인증할 수는 있지만, 요청을 수행하는 소프트웨어를 아직 인증하지는 못합니다. 보안이 확보된 자율 에이전트가 필요한 팀은 사양이 확정될 때까지 기다려서는 안 됩니다. 오늘 바로 워크로드 계층에서 ID 체계를 구축하고, 대기 중인 DPoP 및 페더레이션 제안을 계속 주시해야 합니다.