
Microsoft Entra ID 및 Microsoft Entra Agent ID를 활용한 에이전트형 앱(Agentic Apps)을 위한
요약
AI 에이전트 기반 애플리케이션 구축 시 필수적인 인증(Authentication) 및 인가(Authorization) 전략을 다룹니다. Microsoft Entra ID와 Entra Agent ID를 활용하여 제로 트러스트 아키텍처와 최소 권한 원칙을 적용하는 방법을 제시합니다.
핵심 포인트
- AI 에이전트 설계 시 인증과 인가는 사후 고려 사항이 아닌 핵심 요소임
- 제로 트러스트 및 최소 권한 원칙을 통한 에이전트 보안 강화 필요
- MCP 생태계의 기업 관리형 권한 부여(EMA) 및 새로운 표준 도입 추세
- Microsoft Entra를 활용한 엔터프라이즈급 에이전트 보안 구현
서론
오늘날 AI 에이전트(AI agents)를 사용하여 애플리케이션을 구축할 때는 모든 것이 변했습니다. 처음부터 고려해야 할 가장 중요한 영역 중 하나는 AI 에이전트를 위한 인증 (Authentication) 및 인가 (Authorization)입니다.
배경 설명을 드리겠습니다. 과거에는 우리 모두 애플리케이션에 인증이 어떻게 구현되어야 하는지에 대한 정적인 관점을 가지고 작업했습니다. 또한, AI 에이전트 내부에서 실행되는 모든 것은 신뢰할 수 없는 것으로 취급되어야 하며, 이것이 바로 에이전트가 자체적인 샌드박스 (Sandbox) 내에서 실행되어야 하는 이유입니다. 보안 관점에서는 AI 에이전트에게 작업을 위임할 때마다 최소 권한 원칙 (Principle of Least Privilege)과 제로 트러스트 아키텍처 (Zero Trust Architecture, ZTA)를 적용해야 합니다.
지난 몇 달 동안 저는 현재 재직 중인 회사의 여러 프로젝트를 위해 AI 기반 시스템을 설계하는 데 참여해 왔습니다. 우리가 지속적으로 직면했던 가장 큰 과제 중 하나는 인증 (Authentication)과 인가 (Authorization)이 사후 고려 사항이 아닌 일급 시민 (First-class concerns)으로서 보장되도록 하면서, 이러한 시스템을 어떻게 안전하게 구축할 것인가였습니다.
만약 여러분이 엔터프라이즈 애플리케이션을 위한 MCP가 어떻게 진화하고 있는지 지켜봐 오셨다면, MCP 클라이언트와 서버에게 SSO(Single Sign-On)의 순간을 의미하는 **기업 관리형 권한 부여 (Enterprise-Managed Authorization, EMA)**의 도입을 이미 보셨을 것입니다. EMA와 함께, MCP 생태계는 RFC 8693, RFC 7523, XAA, 그리고 기타 표준들을 기반으로 구축된 ID-JAG와 같은 새로운 표준 및 프로토콜을 도입하고 있습니다.
하지만 저희 회사의 기술 스택은 주로 Microsoft Azure와 Microsoft Entra를 기반으로 구축되어 있습니다. 따라서 저희는 Microsoft 생태계가 에이전트형 AI (Agentic AI)의 인증 및 권한 부여(Authorization) 과제를 어떻게 해결하는지 먼저 탐구해 보기로 했습니다. 이 글은 바로 그 접근 방식에 초점을 맞춥니다.
향후 게시물에서는 **ID-JAG (XAA)**를 Microsoft Entra와 어떻게 통합할 수 있는지, 그리고 두 접근 방식이 엔터프라이즈 환경에서 어떻게 함께 작동할 수 있는지에 대해서도 살펴볼 예정입니다.
이 글은 Microsoft Entra ID를 새롭게 도입된 Microsoft Entra Agent ID와 결합하여 이러한 인증 과제를 해결하는 방법을 보여줍니다.
면책 조항 (Disclaimer): 이 글에서는 인프라 계층에서 RFC 8693 / OAuth 2.0 토큰 교환 (On-Behalf-Of) 흐름을 구성하고 위임하기 위해 Agent Gateway (작성 시점 기준 v1.4.0-beta.1)를 사용합니다. 이는 실제 운영 환경에 대한 권장 사항이라기보다, 순수하게 실험 및 인증 흐름을 시연하기 위한 목적입니다.
간단한 시나리오부터 시작해 보겠습니다.
사용자가 할 일 목록을 관리할 수 있는 Todo 애플리케이션이 있습니다. 예제를 단순하게 유지하기 위해, 다음 두 가지 작업만 있다고 가정합니다:
- 모든 할 일 항목 가져오기 (Get all todo items)
- 새로운 할 일 항목 추가하기 (Add a new todo item): 사용자는 할 일의 이름만 입력하면 되며, 설명은 AI 에이전트 (AI Agent)가 생성합니다.
먼저 모든 할 일 항목 가져오기 (Get All Todo Items) 흐름에 집중해 보겠습니다. 비즈니스 로직에는 특별한 점이 없습니다. 우리는 다음과 같은 구성으로 세 가지 애플리케이션을 설정합니다: todo-api, todo-agent, 그리고 todo-mcp.
- todo-api는 Microsoft Entra ID 앱 등록 (App Registration)을 사용합니다. 이는 우리 대부분이 수년 동안 사용해 온 전통적인 인증 모델입니다.
- todo-agent는 Microsoft Entra Agent ID를 사용합니다. 이는 에이전트형 애플리케이션 (agentic applications)을 위한 Microsoft의 새로운 인증 모델입니다. Microsoft Entra ID를 대체하는 것이 아니라, 에이전트 블루프린트 (Agent Blueprints) 및 **에이전트 ID (Agent Identities)**와 같은 새로운 개념을 도입하여 이를 확장합니다. 이러한 개념이 생소하다면, 이 글을 계속 읽기 전에 https://blog.christianposta.com/entra-agent-id-agw/를 읽어보시기를 강력히 권장합니다.
- todo-mcp 또한 todo-api와 동일한 구성에 따라 Microsoft Entra ID 앱 등록 (App Registration)을 사용합니다.
보시다시피, 이 솔루션은 전통적인 Microsoft Entra ID 앱 등록과 에이전트형 애플리케이션을 위한 Microsoft Entra Agent ID를 결합한 하이브리드 인증 모델을 사용합니다.
- 사용자가 Todo API에 접속합니다.
- 애플리케이션이 사용자를 Microsoft Entra ID 로그인 페이지로 리다이렉트(redirect)합니다.
- 사용자는 PKCE를 사용한 OAuth 2.0 권한 부여 코드 흐름 (Authorization Code Flow)을 통해 인증을 수행하고 동의를 부여합니다.
- Todo API는 앱 등록 (App Registration) (TK01)에 대해 발급된 JWT 액세스 토큰 (access token)을 수신합니다.
- Todo API는 Microsoft Entra ID를 사용하여 TK01을 검증합니다.
- Todo API는 TK01 (앱 등록)에서 TK02 (에이전트형 애플리케이션, Agentic Application)로 On-Behalf-Of (OBO) 토큰 교환을 수행합니다.
- Todo API는 TK02를 todo-agent로 전달합니다.
- Todo Agent는 Microsoft Entra Agent ID를 사용하여 TK02를 검증합니다.
- Todo Agent는 TK02 (에이전트형 애플리케이션)에서 TK03 (앱 등록)으로 또 다른 토큰 교환을 수행합니다.
- Todo Agent는 TK03를 todo-mcp로 전달합니다.
- Todo MCP는 Microsoft Entra ID를 사용하여 TK03를 검증합니다.
소스 코드: agentgateway-entraid-obo
참고: Hop-1과 Hop-2는 근본적으로 다른 토큰 교환 메커니즘입니다.
**Hop-1 (TodoApi → TodoAgent)**은 표준 RFC 7523 JWT Bearer On-Behalf-Of (OBO) 흐름을 사용합니다. Agent Gateway의
backendAuth.oauthTokenExchange는 Agent Gateway 소스 코드(https://github.com/agentgateway/agentgateway)에서 확인된 바와 같이 이 흐름을 직접 지원합니다 (grantType: jwtBearer). 게이트웨이가 토큰 교환을 수행하므로 애플리케이션 코드를 단순하게 유지할 수 있습니다.**Hop-2 (TodoAgent → TodoMcpServer)**는 표준 OBO 흐름이 아닙니다. Microsoft Entra Agent ID는
client_credentials권한 부여(grant)를 기반으로 하는 독자적인 2단계fmi_path토큰 교환 방식을 사용합니다. 에이전트는 로그인한 사용자를 대신하여 동작하는 동시에, 자체 Agent Blueprint 자격 증명(클라이언트 비밀(client secret) 또는 연합 ID 자격 증명(Federated Identity Credential))을 사용하여 인증합니다. 이 교환 유형은 현재 Agent Gateway 구성 스키마에 존재하지 않습니다. 게이트웨이는 Hop-1에서 사용되는 표준jwtBearer교환만 지원합니다. 이는 구성의 한계가 아니라, Microsoft Entra Agent ID에서 사용하는 프로토콜이 다르다는 것을 나타냅니다.
인증 - todo-api, todo-agent 및 todo-mcp를 위한 하이브리드 인증 흐름(Microsoft Entra ID + Microsoft Entra Agent ID) 설정
Azure CLI를 사용하여 로그인합니다:
az login
그 다음 다음 명령을 실행합니다:
./scripts/setup-entra-obo-chain.ps1
끝입니다.
저장소 루트에서 다음 명령을 실행하여 솔루션을 시작합니다:
aspire run
http://localhost:3000/scalar를 열고 다음과 같이 인증합니다:
사용자는 (MS Entra ID 페이지에서) 사용자 이름(Bob)/비밀번호를 입력할 수 있게 됩니다. 입력을 마친 후, http://localhost:3000/scalar로 돌아가세요. 이제 create a new todo를 클릭하면 데이터베이스(db)에 1개의 레코드가 생성되며, Aspire로 돌아가면 트레이스(trace)가 표시됩니다:
그리고 Todo 에이전트(agent)가 수행하는 작업은 다음과 같습니다:
todo-api, todo-agent, 그리고 todo-mcp를 위한 설정
- 1.todo-api
-
2.todo-agent
- Agent BlueSprint
- Agent Identity
- 3.todo-mcp
인가(Authorization) - todo-api, todo-agent, 그리고 todo-mcp를 위한 보안 그룹(security groups) 설정
두 개의 Microsoft Entra 보안 그룹을 생성합니다:
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기






