MCP Zero-Touch OAuth: 에이전트 Auth가 제품 기능이 되다

에이전트를 배포하는 개발자들이 공통으로 부딪히는 순간이 있다. 에이전트가 실제 회사 시스템에 닿는 순간 — GitHub, Google Workspace, Slack, 사내 데이터베이스. 여기서 auth는 더 이상 개발자가 환경변수에 키를 박아넣는 문제가 아니다.

MCP(Model Context Protocol)가 **엔터프라이즈 관리 인증(Enterprise Managed Auth)**을 공식 지원하기 시작하면서, 이 문제를 다루는 방식이 바뀌고 있다. (출처)

Zero-Touch OAuth란 무엇인가

Zero-Touch OAuth는 에이전트가 엔터프라이즈 ID 제공자(Okta, Azure AD, Google Workspace 등)와 직접 OAuth 핸드셰이크를 완료하는 방식이다. 사람이 직접 API 키를 복사해서 넣거나, 개발자가 토큰을 하드코딩할 필요가 없다.

핵심은 세 가지다:

테넌트 정책 준수: 기업의 접근 제어 정책이 에이전트에도 자동으로 적용된다. 특정 사용자 그룹만 접근 가능한 리소스라면, 에이전트도 같은 제약을 받는다.
비밀 핸들링 분리: 개발자 코드에 credential이 노출되지 않는다. 인증 흐름은 MCP 레이어에서 처리된다.
세션 범위 제한: 에이전트가 받는 권한은 실제 필요한 범위로 자동 좁혀진다.

MCP Zero-Touch OAuth 인증 흐름

지금까지 에이전트 인증은 배포 담당자가 처리하는 인프라 문제였다. CI/CD에서 시크릿 주입하고, 환경변수 관리하고, 만료된 토큰을 수동으로 교체하는 식으로.

Zero-Touch OAuth가 바꾸는 건 이 문제가 제품 레벨로 올라온다는 점이다.

예를 들어:

이제 에이전트의 “할 수 있는 것”과 “할 수 없는 것”이 코드가 아니라 기업 정책과 사용자 동의로 결정된다. 이건 UX 설계 문제고, 신뢰 아키텍처 문제다.

현재 대부분의 한국 에이전트 프로젝트는 두 가지 인증 패턴 중 하나를 쓴다: (a) 개발자가 고정 API 키를 환경변수에 넣거나, (b) 사용자가 로그인하면 토큰을 세션에 저장하거나.

MCP 엔터프라이즈 auth가 표준화되면 세 번째 선택지가 생긴다: (c) 에이전트가 기업 IdP와 직접 조율하고, 범위 제한된 토큰을 자동 갱신한다.

이게 특히 중요한 시나리오:

사내 업무 자동화 에이전트: Jira, Confluence, Slack에 접근하는 에이전트가 HR 정책 변경과 자동 연동되려면 IdP 연결이 필수다.
외부 고객 대면 AI 제품: 사용자가 “이 에이전트가 내 Google Drive에 어디까지 접근하나?”를 알 수 있어야 신뢰가 생긴다.
멀티테넌트 SaaS: 고객사마다 다른 권한 범위를 코드 변경 없이 정책으로 제어할 수 있다.

에이전트 인증 비교: API 키 vs 세션 토큰 vs Zero-Touch OAuth

MCP 엔터프라이즈 auth는 아직 모든 MCP 서버가 구현한 상태가 아니다. 하지만 방향은 명확하다. 몇 가지 준비 포인트:

1. MCP 서버 선택 시 auth 지원 확인
앞으로 프로덕션 에이전트를 배포할 때, 해당 MCP 서버가 OAuth 2.0 / OIDC를 지원하는지 체크리스트에 넣어야 한다.

2. 권한 범위를 최소화하는 설계 습관
Zero-Touch OAuth의 장점은 범위 제한(scope limiting)이 자동화된다는 것이다. 코드 레벨에서부터 에이전트가 필요로 하는 최소 권한을 명시적으로 정의해두면, IdP 연동 시 훨씬 깔끔하다.

3. 사용자 투명성 UI 준비
에이전트가 어떤 권한으로 무엇에 접근하는지 사용자가 볼 수 있는 UI를 지금부터 설계해두면, 나중에 auth 업그레이드가 훨씬 수월하다. 법적 리스크도 줄어든다.

에이전트 auth는 이제 “보안 팀이 나중에 알아서 해줄 것”이 아니다. 제품 설계 단계에서 함께 정의해야 할 기능이 됐다.