💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 2026년 IAM 지형의 세 가지 지각변동

IAM(Identity and Access Management)은 보수적인 분야입니다. 십수 년 묵은 프로토콜이 현역이고, 변화는 느립니다. 그런데 2025~2026년에 걸쳐 세 개의 지각판이 동시에 움직였습니다.

1. **Passwordless의 기본값화**: passkey가 "옵션"에서 "디폴트"가 되었습니다. 신규 서비스는 비밀번호 없이 시작하는 것이 더 자연스러운 설계가 되었고, identity-first 보안 — 네트워크 경계가 아니라 신원이 보안의 1차 경계라는 Zero Trust의 핵심 명제 — 이 실무 표준으로 자리잡았습니다.

2. **Non-human identity의 폭증**: 사람 계정보다 기계 계정이 많아진 지는 오래지만, AI 에이전트의 등장으로 그 비율이 한 자릿수 배가 아니라 수십 배로 벌어지고 있습니다. 더 심각한 것은 양이 아니라 성질입니다 — 에이전트는 자율적으로 행동하고, 권한을 위임받고, 다른 에이전트를 호출합니다.

3. **에이전트-도구 연결의 표준화**: MCP(Model Context Protocol)가 AI 에이전트와 도구/데이터 소스를 잇는 사실상의 표준이 되면서, "에이전트가 내 API에 어떻게 인증하는가"라는 질문에 OAuth 2.1 기반의 공식 답안이 생겼습니다.

이 글은 이 세 흐름을 관통하며, AI 에이전트 인증의 난제, [MCP authorization 스펙](https://modelcontextprotocol.io/specification/draft/basic/authorization)의 상세, Keycloak 26.6의 CIMD 실험 지원이 갖는 의미, token exchange와 transaction token을 통한 위임 체인 구현, 그리고 verifiable credentials까지 — 2026년 IAM 실무자의 지도를 그립니다.

Non-human Identity — 서비스 계정에서 AI 에이전트로

전통적인 non-human identity(NHI)는 다루기 쉬운 편이었습니다. 서비스 계정, API 키, 워크로드 인증서는 **행동이 결정적(deterministic)** 이었기 때문입니다. 배치 잡은 정해진 시간에 정해진 API만 호출합니다. SPIFFE/SPIRE 같은 워크로드 아이덴티티 표준이 이 영역을 잘 정리해 왔습니다.

AI 에이전트는 이 전제를 무너뜨립니다.

| 구분 | 전통적 NHI (서비스 계정) | AI 에이전트 |

| --- | --- | --- |

| 행동 패턴 | 결정적, 예측 가능 | 비결정적, 프롬프트에 따라 변화 |

| 권한 범위 | 고정된 좁은 scope | 작업에 따라 동적으로 필요 |

| 위임 구조 | 거의 없음 (자기 권한으로 동작) | 사용자 대신 행동 (on-behalf-of) |

| 수명 | 길다 (수개월~수년) | 짧다 (세션/태스크 단위) |

| 감사 단위 | 서비스 단위 | 사용자 x 에이전트 x 태스크 단위 |

| 공격 표면 | 키 유출 | 키 유출 + prompt injection + 도구 오용 |

워크로드 영역에서는 [SPIFFE/SPIRE](https://spiffe.io/docs/)가 "비밀 없는 신원 부트스트랩"이라는 모범 답안을 만들어 왔습니다. 워크로드는 배포 시 비밀을 주입받는 대신, 런타임 속성(쿠버네티스 ServiceAccount, 노드 신원 등)으로 attestation을 거쳐 짧은 수명의 SVID(X.509 또는 JWT)를 발급받습니다.

SPIFFE ID 예시:

spiffe://example.com/ns/payments/sa/payment-processor

발급 흐름:

워크로드 ──(attestation: k8s SA, node)──> SPIRE Agent ──> SPIRE Server

^ │

└────────── 짧은 수명 SVID (자동 갱신) ────────────────────┘

에이전트 아이덴티티도 같은 원칙 위에 세워야 합니다 — **장수명 정적 비밀(static secret) 대신, 검증 가능한 속성 기반의 단기 크리덴셜**. 다만 에이전트는 워크로드와 달리 "누구를 대신해 행동하는가"라는 위임 차원이 추가되므로, SPIFFE만으로는 부족하고 OAuth의 위임 메커니즘과 결합해야 합니다.

여기서 세 가지 난제가 나옵니다.

난제 1 — on-behalf-of 위임 체인

"사용자 jane이 에이전트 A에게 시켰고, A가 도구 서버 B를 호출했고, B가 내부 API C를 호출했다"는 체인에서, C는 누구의 권한으로 판단해야 할까요? jane? A? 둘 다?

정답은 "둘 다"입니다. **행위자(actor)와 위임자(subject)를 모두 추적**해야 합니다. 에이전트가 jane의 모든 권한을 그대로 상속하면 과잉 권한이고, 에이전트 자신의 권한만 쓰면 감사 추적이 끊깁니다. 이를 위한 표준 장치가 뒤에서 다룰 token exchange(RFC 8693)의 act 클레임입니다.

난제 2 — 최소 권한의 동적 적용

에이전트의 작업은 동적이므로 "이 에이전트에 필요한 권한 목록"을 미리 고정하기 어렵습니다. 그렇다고 광범위한 scope를 주면 prompt injection 한 방에 전체 권한이 탈취됩니다. 실무 방향은 **태스크 단위의 짧은 수명 토큰 + 세밀한 인가(ReBAC/ABAC) 실시간 평가 + human-in-the-loop 승인**의 조합입니다.

난제 3 — 감사와 귀속(attribution)

규제 관점에서 "누가 이 작업을 했는가"에 "에이전트가요"라는 답은 통하지 않습니다. 모든 에이전트 행위는 (위임한 인간, 에이전트 식별자, 태스크 컨텍스트, 사용된 토큰 체인)으로 귀속 가능해야 합니다. 로그 스키마를 지금 설계해 두지 않으면 나중에 소급할 수 없습니다.

MCP Authorization — OAuth 2.1 기반의 표준 상세

[MCP(Model Context Protocol)](https://modelcontextprotocol.io/)는 AI 애플리케이션과 도구/데이터 소스를 연결하는 개방형 프로토콜입니다. 2025년을 거치며 MCP의 authorization 스펙이 OAuth 2.1 기반으로 정비되었고, 이것이 에이전트 인증의 사실상 표준 궤도가 되었습니다.

핵심 구조: **MCP 서버는 OAuth 2.1의 resource server(RS)이고, MCP 클라이언트는 OAuth 클라이언트이며, 토큰 발급은 별도의 authorization server(AS)가 담당**합니다. MCP 서버가 직접 토큰을 발급하지 않고 기존 IdP(예: Keycloak)에 위임할 수 있다는 점이 엔터프라이즈 통합의 핵심입니다.

전체 흐름은 다음과 같습니다.

MCP Client MCP Server (RS) Authorization Server

| | |

| 1. MCP 요청 (토큰 없음) | |

|------------------------->| |

| 2. 401 + WWW-Authenticate| |

| (resource_metadata URL) |

|<-------------------------| |

| 3. GET /.well-known/oauth-protected-resource |

|------------------------->| |

| (authorization_servers 목록 반환) |

| 4. GET /.well-known/oauth-authorization-server |

|---------------------------------------------------->|

| (AS 메타데이터: endpoints, PKCE 지원 등) |

| 5. Authorization Code + PKCE 플로우 |

|---------------------------------------------------->|

| (resource 파라미터로 대상 MCP 서버 명시) |

| 6. access_token (aud = MCP 서버) |

|<----------------------------------------------------|

| 7. MCP 요청 + Bearer 토큰| |

|------------------------->| |

| 토큰 검증 (aud, 서명) | |

구성 요소를 하나씩 뜯어봅니다.

Authorization Server Discovery

MCP 클라이언트는 어떤 AS를 써야 하는지 사전 지식이 없습니다. 그래서 두 단계의 디스커버리를 거칩니다.

1. **Protected Resource Metadata ([RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728))**: MCP 서버가 401 응답의 WWW-Authenticate 헤더로 자신의 리소스 메타데이터 URL을 알려주면, 클라이언트가 이를 조회해 해당 리소스를 보호하는 AS 목록을 얻습니다.

{

"resource": "https://mcp.example.com",

"authorization_servers": ["https://sso.example.com/realms/agents"],

"bearer_methods_supported": ["header"],

"scopes_supported": ["mcp:tools:read", "mcp:tools:execute"]

}

2. **Authorization Server Metadata (RFC 8414)**: 이어서 AS의 well-known 엔드포인트에서 인가/토큰 엔드포인트, 지원 기능(PKCE, DCR 등)을 얻습니다.

Resource Indicators — 토큰 오용 방지

MCP 스펙은 [RFC 8707 Resource Indicators](https://datatracker.ietf.org/doc/html/rfc8707)를 필수로 요구합니다. 클라이언트가 토큰을 요청할 때 resource 파라미터로 "이 토큰은 이 MCP 서버용"임을 명시하고, AS는 토큰의 aud(audience)를 그 서버로 한정합니다.

POST /realms/agents/protocol/openid-connect/token HTTP/1.1

Host: sso.example.com

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code

&code=AUTH-CODE-VALUE

&code_verifier=PKCE-VERIFIER-VALUE

&client_id=my-agent

&resource=https://mcp.example.com

이것이 막는 공격이 **confused deputy / 토큰 재사용**입니다. resource 한정이 없으면, 악성 MCP 서버가 받은 토큰을 다른 MCP 서버에 재제출하는 공격이 가능해집니다. MCP 서버 측도 반드시 **자신을 aud로 하지 않는 토큰을 거부**해야 하며, 받은 토큰을 업스트림 API에 그대로 전달(passthrough)하는 것은 명시적으로 금지됩니다.

OAuth 2.1이라는 토대

MCP가 OAuth 2.0이 아니라 [OAuth 2.1 draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)를 토대로 삼은 것은 의미가 큽니다. OAuth 2.1은 RFC 6749 + PKCE(RFC 7636) + Security BCP(RFC 9700)를 통합하면서 Implicit/ROPC 그랜트를 제거하고 **모든 클라이언트에 PKCE를 의무화**했습니다. 에이전트처럼 자동화된 클라이언트가 대량 등장하는 환경에서 안전하지 않은 옵션 자체를 없앤 것입니다.

CIMD — Client ID Metadata Document와 Keycloak 26.6

MCP 생태계에는 OAuth의 고전적 가정과 충돌하는 지점이 하나 있습니다. **클라이언트 사전 등록**입니다. 수만 개의 MCP 클라이언트(에이전트, IDE, 데스크톱 앱)가 임의의 MCP 서버/AS와 처음 만나는 상황에서, 관리자가 일일이 클라이언트를 등록하는 모델은 확장이 불가능합니다. Dynamic Client Registration(RFC 7591)이 있지만, 익명 등록을 열어두면 쓰레기 클라이언트 등록이 쌓이는 운영 부담이 있습니다.

이에 대한 새로운 답이 **CIMD(OAuth Client ID Metadata Document)** 입니다. 아이디어는 단순합니다 — **클라이언트 ID로 HTTPS URL을 사용**하고, 그 URL에서 클라이언트 메타데이터 문서를 호스팅합니다.

{

"client_id": "https://agent.example.dev/oauth/client-metadata.json",

"client_name": "Example Coding Agent",

"client_uri": "https://agent.example.dev",

"redirect_uris": ["https://agent.example.dev/oauth/callback"],

"grant_types": ["authorization_code"],

"response_types": ["code"],

"token_endpoint_auth_method": "none"

}

AS는 처음 보는 client_id(URL)를 만나면 해당 URL에서 메타데이터를 가져와 검증/캐시합니다. 사전 등록 없이도 클라이언트의 신원(도메인 소유 기반)과 redirect URI의 무결성을 확보할 수 있습니다.

[Keycloak 26.6](https://www.keycloak.org/docs/latest/release_notes/index.html)이 이 CIMD를 실험적으로 지원하기 시작했다는 것은 큰 신호입니다. 의미를 풀면:

- Keycloak이 **MCP 생태계의 authorization server 역할**을 공식적으로 겨냥하기 시작했습니다. 기업은 이미 운영 중인 Keycloak realm을 그대로 에이전트/MCP 인증 기반으로 확장할 수 있습니다.

- 26.6의 다른 기능들 — JWT Authorization Grant, Federated client authentication, FAPI 2.0 final 지원 — 과 묶어 보면, "사람 로그인용 IdP"에서 "사람 + 워크로드 + 에이전트의 통합 신뢰 앵커"로의 방향 전환이 읽힙니다.

- 실험(preview) 기능이므로 운영 적용 전 기능 플래그와 한계(메타데이터 캐싱 정책, 신뢰 정책 설정)를 반드시 검토해야 합니다.

Keycloak 26.6에서 preview 기능 활성화 예시

/opt/keycloak/bin/kc.sh start \

--features=preview \

--hostname=sso.example.com

실전 — MCP 서버를 Keycloak으로 보호하기

개념을 코드로 옮겨 봅니다. 사내 MCP 서버(예: 사내 위키 검색 도구 서버)를 Keycloak realm으로 보호하는 최소 구성입니다.

먼저 MCP 서버용 client scope와 audience를 준비합니다.

1. MCP 서버를 나타내는 client scope 생성

/opt/keycloak/bin/kcadm.sh create client-scopes -r agents \

-s name=mcp-wiki \

-s protocol=openid-connect

2. audience 매퍼 추가 — 토큰의 aud를 MCP 서버로 한정

/opt/keycloak/bin/kcadm.sh create \

client-scopes/SCOPE-ID/protocol-mappers/models -r agents \

-s name=mcp-wiki-audience \

-s protocol=openid-connect \

-s protocolMapper=oidc-audience-mapper \

-s 'config."included.custom.audience"=https://mcp-wiki.internal.example.com' \

-s 'config."access.token.claim"=true'

MCP 서버 쪽은 일반적인 OAuth resource server입니다. Spring 기반이라면 설정은 익숙한 모양입니다.

application.yaml — MCP 서버의 리소스 서버 설정

spring:

security:

oauth2:

resourceserver:

jwt:

issuer-uri: https://sso.example.com/realms/agents

audiences:

- https://mcp-wiki.internal.example.com

// aud 검증 + 토큰 passthrough 금지를 명시한 보안 설정

@Configuration

@EnableWebSecurity

public class McpSecurityConfig {

@Bean

SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

http

.authorizeHttpRequests(auth -> auth

.requestMatchers("/.well-known/**").permitAll() // RFC 9728 메타데이터

.anyRequest().authenticated())

.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));

return http.build();

}

// 중요: 이 서버가 받은 Bearer 토큰을 업스트림 API 호출에

// 그대로 전달하지 않는다. 업스트림 권한이 필요하면

// token exchange로 별도의 aud 한정 토큰을 발급받는다.

}

그리고 401 응답에 RFC 9728 디스커버리를 위한 헤더를 붙입니다.

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Bearer resource_metadata=

"https://mcp-wiki.internal.example.com/.well-known/oauth-protected-resource"

이 네 조각 — audience 한정 발급, issuer/aud 검증, 메타데이터 공개, passthrough 금지 — 이 MCP 서버 보안의 뼈대입니다.

Token Exchange와 Transaction Tokens — 위임 체인의 구현

에이전트 위임 체인을 표준 토큰으로 구현하는 도구가 [RFC 8693 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)입니다. 에이전트가 사용자 토큰을 받아서, 다운스트림 API용의 **권한 축소(scope-down) + 행위자 명시(act 클레임)** 토큰으로 교환합니다.

POST /realms/agents/protocol/openid-connect/token HTTP/1.1

Host: sso.example.com

Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange

&subject_token=USER-ACCESS-TOKEN

&subject_token_type=urn:ietf:params:oauth:token-type:access_token

&requested_token_type=urn:ietf:params:oauth:token-type:access_token

&audience=internal-api

&scope=tickets:read

교환된 토큰의 페이로드에는 위임 구조가 명시됩니다.

{

"iss": "https://sso.example.com/realms/agents",

"sub": "user:jane",

"aud": "internal-api",

"scope": "tickets:read",

"act": {

"sub": "agent:support-bot"

"exp": 1781234567

}

sub는 여전히 jane(위임자)이고, act.sub가 실제 행위자(에이전트)입니다. 체인이 깊어지면 act가 중첩되어 전체 위임 경로가 토큰 안에 보존됩니다. 감사 로그는 이 두 값을 모두 기록하면 됩니다. Keycloak은 26.2부터 표준 token exchange(V2)를 정식 지원합니다.

한 걸음 더 나아간 것이 IETF OAuth WG에서 논의 중인 **Transaction Tokens(draft)** 입니다. 외부 진입 시점의 토큰을 게이트웨이에서 **단일 트랜잭션 범위의 짧은 수명(분 단위) 내부 토큰**으로 바꿔, 마이크로서비스 체인 내부에서 외부 토큰이 돌아다니는 것을 막고 호출 경로 전체에 사용자/에이전트 컨텍스트를 불변으로 전파합니다. 에이전트가 여러 내부 서비스를 연쇄 호출하는 아키텍처에서 특히 주목할 만합니다.

외부 게이트웨이 내부 서비스들

user/agent token ──────> Token Service에서 교환 ──> txn-token (수명 5분,

(수명 1시간, 광범위) (RFC 8693 스타일) 트랜잭션 한정, 위임

체인 클레임 포함)

transaction token의 페이로드 개념 예시입니다. 트랜잭션 식별자(txn)와 요청 컨텍스트, 위임 체인이 불변으로 박제됩니다.

{

"iss": "https://txn-token-service.internal.example.com",

"aud": "internal-services.example.com",

"txn": "97f2dbd1-2275-4f4c-a8b3-1e9d2c4f5a6b",

"sub": "user:jane",

"exp": 1781234867,

"purp": "ticket-escalation",

"azd": {

"actor_chain": ["agent:support-bot", "svc:ticket-api"],

"client_ip": "203.0.113.10"

}

Verifiable Credentials — 신원의 탈중앙화

또 하나의 큰 흐름은 **검증 가능한 자격증명(Verifiable Credentials, VC)** 입니다. [W3C VC Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/)이 2025년 공식 권고안이 되었고, EU의 [eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) 규정은 모든 회원국에 EU Digital Identity Wallet 제공을 의무화하며 거대한 실사용 사례를 만들고 있습니다.

VC 모델의 삼각형은 다음과 같습니다.

Issuer (발급자) Verifier (검증자)

예: 정부, 대학, 고용주 예: 은행, 서비스 제공자

\ /

\ VC 발급 (서명) VP 제시 /

\ /

v v

Holder (보유자) — 지갑 앱

자격증명을 보관, 선택적으로 제시

OIDC와의 결정적 차이는 **제시(presentation) 시점에 발급자가 온라인일 필요가 없고, 발급자가 사용 내역을 추적할 수 없다**는 점입니다. selective disclosure(SD-JWT VC)를 쓰면 "성인임"만 증명하고 생년월일은 숨기는 식의 최소 공개도 가능합니다. SD-JWT의 개념을 단순화한 예시입니다.

{

"iss": "https://issuer.gov.example",

"vct": "https://credentials.example/identity_credential",

"cnf": {

"jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }

"_sd": [

"hash-of-given-name-disclosure",

"hash-of-family-name-disclosure",

"hash-of-birthdate-disclosure",

"hash-of-age-over-18-disclosure"

"_sd_alg": "sha-256"

}

자격증명 본문에는 각 속성의 해시만 들어 있고, 보유자는 제시 시점에 공개할 속성의 disclosure(원문 + salt)만 골라서 동봉합니다. 검증자는 해시 대조로 무결성을 확인하되, 동봉되지 않은 속성은 알 수 없습니다. cnf 클레임의 키로 보유자 바인딩(holder binding)까지 증명되므로, 훔친 자격증명의 재사용도 차단됩니다.

OpenID Foundation의 OID4VCI/OID4VP 프로토콜이 발급/제시 플로우를 표준화하고 있고, Keycloak도 OID4VCI 발급자 기능을 실험적으로 키워가고 있습니다.

엔터프라이즈 관점의 단기 활용처는 B2C 신원증명(KYC 재사용), 직원 온보딩(학위/경력 검증), 그리고 B2B 파트너 자격 증명입니다.

딥페이크 시대의 Identity Proofing

passkey가 인증(authentication)을 지켜도, **신원 증명(identity proofing)** — 계정 개설이나 계정 복구 시 "이 사람이 실제 그 사람인가"의 확인 — 이 약하면 전체가 무너집니다. 그리고 2026년의 신원 증명은 생성형 AI와의 군비 경쟁 한복판에 있습니다.

- 화상 통화 기반 확인은 실시간 딥페이크로 우회된 사례가 다수 보고되었습니다. 헬프데스크를 속여 MFA를 리셋시키는 소셜 엔지니어링(2023년 MGM 사건의 패턴)은 이제 음성/영상 합성으로 무장했습니다.

- 대응 방향: 문서 + 생체 + **액티브 라이브니스 검증**(지시 반응형), 디바이스 시그널과의 교차 검증, NIST SP 800-63A의 IAL 수준에 따른 차등 절차, 그리고 고위험 작업(복구, 권한 상승)에 대한 다채널 확인.

- 구조적 해법은 위에서 다룬 VC입니다. 정부 발급 디지털 신분증명을 지갑에서 제시받으면, 영상 기반 확인 자체를 줄일 수 있습니다.

헬프데스크의 계정 복구 절차를 딥페이크 가정 하에 재설계하는 것 — 이것이 2026년에 가장 저평가된 보안 과제일 수 있습니다.

에이전트 IAM 안티패턴 — 지금 막아야 할 것들

새 영역일수록 나쁜 관행이 빠르게 굳습니다. 현장에서 이미 관찰되는 안티패턴들입니다.

1. **사람 계정 공유**: 에이전트에게 직원의 아이디/비밀번호 또는 개인 API 토큰을 그대로 쥐여주는 방식입니다. 감사 추적이 사라지고, 직원 퇴사 시 에이전트가 멈추며, 토큰 유출 시 사람의 전체 권한이 노출됩니다. 에이전트는 반드시 독립 신원 + 위임 토큰으로.

2. **만능 service account**: 에이전트 플랫폼 전체가 하나의 슈퍼 서비스 계정으로 모든 다운스트림을 호출하는 구조. 어느 에이전트의 어느 태스크였는지 구분이 불가능하고, 최소 권한이 원천적으로 깨집니다.

3. **장수명 정적 API 키**: 에이전트 설정 파일에 박힌 만료 없는 키는 prompt injection으로 유출되는 순간 게임 오버입니다. 단기 토큰 + 자동 회전이 기본입니다.

4. **scope 없는 광역 토큰**: "일단 되게 하자"며 admin scope 토큰을 에이전트에 부여하는 것. 에이전트의 오동작/오용이 곧바로 전체 시스템 손상으로 이어집니다.

5. **도구 응답을 신뢰 경계 안으로**: MCP 도구가 반환한 콘텐츠에 포함된 지시문을 에이전트가 그대로 따르는 indirect prompt injection은 인가 우회의 새 경로입니다. 도구 응답은 외부 입력으로 취급하고, 권한 변경류 행위에는 별도 승인 게이트를 두십시오.

6. **MCP 토큰 passthrough**: MCP 서버가 받은 토큰을 그대로 업스트림에 전달하는 것은 스펙 위반이자 confused deputy의 지름길입니다. 반드시 token exchange로 재발급하십시오.

실무자가 지금 준비할 것 — 체크리스트

마지막으로, 위의 흐름을 실행 가능한 체크리스트로 정리합니다.

**인벤토리와 거버넌스**

1. NHI 인벤토리를 만드십시오 — 서비스 계정, API 키, 워크로드 인증서, 그리고 에이전트. "우리 조직에 에이전트 아이덴티티가 몇 개인가"에 답할 수 없다면 그것이 첫 과제입니다.

2. 에이전트 아이덴티티의 수명 주기(생성/권한 부여/만료/폐기) 정책을 사람 계정과 분리해 정의하십시오.

3. 감사 로그 스키마에 위임 체인 필드(subject, actor, task context)를 추가하십시오.

**프로토콜과 인프라**

4. OAuth 2.1 기준으로 기존 클라이언트를 점검하십시오 — Implicit/ROPC 잔존 여부, PKCE 미적용 클라이언트.

5. IdP(Keycloak 등)의 token exchange 지원을 검증하고, scope-down 교환 패턴을 표준 라이브러리로 만드십시오.

6. MCP 서버를 운영한다면 RFC 9728 메타데이터, aud 검증, 토큰 passthrough 금지를 구현하십시오.

7. Keycloak 26.6의 CIMD 같은 실험 기능을 스테이징에서 평가하고, 에이전트 클라이언트 온보딩 모델(DCR vs CIMD)을 결정하십시오.

**보안 운영**

8. 에이전트용 토큰의 수명을 태스크 단위(분)로 짧게 하고, refresh 정책을 보수적으로 설정하십시오.

9. 고위험 도구 호출에 human-in-the-loop 승인 게이트를 넣으십시오.

10. 계정 복구/헬프데스크 절차를 딥페이크 시나리오로 위협 모델링하십시오.

11. VC/디지털 지갑 규제 동향(eIDAS 2.0, 국내 디지털 신분증)을 분기 단위로 추적하고, KYC 흐름의 VC 수용 가능성을 평가하십시오.

마치며

2026년의 IAM은 "사람이 비밀번호로 로그인하는 시스템"에서 "사람, 워크로드, 에이전트가 검증 가능한 신원과 위임 체인으로 상호작용하는 시스템"으로 이동하는 중입니다. 다행인 것은 이 전환이 전혀 새로운 기술 위가 아니라, OAuth 2.1, token exchange, WebAuthn, VC라는 **기존 표준의 연장선** 위에서 일어나고 있다는 점입니다.

그래서 가장 좋은 준비는 화려한 신기술 도입이 아니라 기본기입니다. 토큰에 aud를 한정하고, 위임을 act로 명시하고, 권한을 짧고 좁게 발급하고, 모든 결정을 감사 가능하게 남기는 것. 에이전트의 시대에도 좋은 IAM의 원칙은 변하지 않습니다 — 적용 대상이 폭발적으로 늘어날 뿐입니다.

참고 자료

- [MCP Authorization Specification](https://modelcontextprotocol.io/specification/draft/basic/authorization) — MCP 인가 스펙

- [OAuth 2.1 draft (draft-ietf-oauth-v2-1)](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) — OAuth 2.1 초안

- [RFC 8693 — OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693) — token exchange와 act 클레임

- [RFC 8707 — Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707) — resource 파라미터

- [RFC 9728 — OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728) — 보호 리소스 메타데이터

- [RFC 9700 — Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700) — OAuth 보안 BCP

- [Keycloak Release Notes](https://www.keycloak.org/docs/latest/release_notes/index.html) — 26.6 CIMD 등 변경 사항

- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) — VC 2.0 표준

- [EU Digital Identity Regulation (eIDAS 2.0)](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) — EU 디지털 신원 규정

- [NIST SP 800-63A — Enrollment and Identity Proofing](https://pages.nist.gov/800-63-3/sp800-63a.html) — 신원 증명 가이드라인

- [SPIFFE Documentation](https://spiffe.io/docs/) — 워크로드 아이덴티티 표준

- [FIDO Alliance — Passkeys](https://fidoalliance.org/passkeys/) — passwordless 전환 자료