ID-JAG, 트랜잭션 토큰(Transaction Tokens), WIF: AI 에이전트 인증의 세 가지 계층

서론

Anthropic이 2026년 5월에 출시한 Workload Identity Federation을 보았을 때 무언가 깨달음이 있었습니다. sk-ant-... API 키를 삭제하고, k8s 서비스 계정 JWT가 수명이 짧은 sk-ant-oat01-... 토큰을 발행(mint)하게 한 뒤, 아무런 인자 없이 anthropic.Anthropic()을 호출하면 그냥 작동합니다. 보안 태세(security posture)가 명확하게 향상되었습니다.

하지만 에이전트가 "Alice의 GitHub PAT를 사용하여 Cursor를 실행하고 PR을 생성하는" 실제 일상적인 흐름은 눈곱만큼도 변하지 않았습니다. Cursor, Claude Code, Comet 모두 궁극적으로 사용자의 자체 자격 증명(credentials)을 보유하고 이를 사용하여 동작합니다. 비슷한 시기에 저는 ID-JAG (Identity Assertion JWT Authorization Grant)와 트랜잭션 토큰(Transaction Tokens)에 대한 IETF 초안(drafts)을 팔로우하고 있었는데, 계속해서 이 간극을 느꼈습니다. 사양(specs)은 수렴하고 있지만, 아무도 이를 채택하지 않고 있다는 점입니다.

이는 한 가지 명확한 질문을 던지게 합니다. "더 좁은 범위(Tighter scope)", "감사 가능성(auditable)", "더 작은 폭발 반경(smaller blast radius)"은 모두 사실이지만, 여러분이 매일 사용하는 에이전트 UX는 변하지 않습니다. 그렇다면 이 기술들이 실제로 유행하게 될까요?

이 글은 그 질문에 정면으로 맞섭니다. 결론을 먼저 말씀드리면 다음과 같습니다:

UX가 변하지 않는다는 것은, 리프레시 토큰(refresh tokens)과 마찬가지로 설계가 올바르다는 증거입니다.
ID-JAG, 트랜잭션 토큰(Transaction Tokens), 그리고 WIF는 각각 서로 다른 계층을 보호합니다. 이들을 나란히 놓고 비교하는 것은 범주 오류(category error)입니다.
채택 경로에는 두 가지가 있습니다. 하나는 MFA / IRSA / Sigstore와 같은 "사고 → 규제 → 채택" 경로입니다. 다른 하나는 DNSSEC / SPIFFE와 같은 "영원한 니치(niche) 시장, 벤더 통합을 통해 다른 이름으로만 확산됨" 경로입니다. UX 개선이 없는 프로토콜은 기본적으로 후자의 길을 걷게 되며, 이것이 기술 역사가 주는 냉혹한 교훈입니다.

결론부터 말씀드리자면: 저는 "우리는 ID-JAG를 배포했다" (계층 A)는 유행하지 않을 것이라고 예측합니다. 계층 C가 유행할 것입니다. 계층 B는 영원한 니치 시장으로 남을 것입니다.

2026년 5월의 지도: 주요 사양과 구현이 실제로 처한 위치

논의를 동일한 지점에서 시작하기 위해, 여기 주요 출처들이 있습니다.

IETF 초안 (drafts)

사양 (Spec)	최신 버전 (Latest)	발행일 (Published)	상태 (Status)
draft-ietf-oauth-identity-assertion-authz-grant (ID-JAG)	-04	2026-05-21	Standards Track, Internet-Draft
...

현재 상황에 대해 알 수 있는 사실은 다음과 같습니다:

ID-JAG는 아직 RFC가 아닙. 현재 Standards Track 초안(draft)이 유통되고 있을 뿐이며, 이 글을 쓰는 시점까지 공식적인 RFC 번호는 할당되지 않았습니다. 내용은 여전히 변경될 수 있습니다.
트랜잭션 토큰(Transaction Tokens)에 대한 에이전트 확장(Agent extension)은 여전히 개별 제안 단계이며, 작업 그룹(WG) 채택 전 단계입니다 (draft-ietf-가 아닌 draft-araut- 형태). 이는 AI 에이전트를 위해 act 클레임(claim)을 사용하고 주체(principal)를 위해 sub 클레임을 사용하며, 반년 만에 -00에서 -06으로 발전했습니다 (RFC 8693 Token Exchange의 행위자(actor)/주체(subject) 개념을 직관적으로 확장한 것입니다).
OAuth 2.1 (-15)은 WG 논의 단계에 있습니다. 아직 최종 의견 수렴(Last Call) 단계에 도달하지는 않았지만, RFC 6749를 폐기(obsolete)하는 방향으로 틀이 잡혀 있습니다. 필수적인 PKCE 적용, 암시적/비밀번호 부여 방식(Implicit/Password grants)의 제거 등이 에이전트 사양의 핵심적인 전제 조건이 됩니다.

저는 ID-JAG 자체에 대한 전용 가이드를 별도의 글(ID-JAG Deep Dive)로 작성했습니다. 여기서는 "이 세 가지를 나란히 놓았을 때 무엇이 보이는가"에 집중하고자 합니다.

구현 측면

사양만 쫓는 것은 무의미합니다. 2026년에 실제로 움직이고 있는 것들은 다음과 같습니다.

구현체 (Implementation)	출시일 (Released)	기능 (What it does)
Anthropic Workload Identity Federation	2026-05	RFC 7523 jwt-bearer를 통해 k8s SA / GHA / SPIFFE / AWS / GCP JWT를 `sk-ant-oat01-...` 형태의 단기 토큰으로 교환함
...

위 표에서는 조용하지만 중대한 두 가지 변화가 일어나고 있습니다.

첫째: 2026-03-15 MCP 사양(spec)은 RFC 8707 (Resource Indicators) 및 RFC 9728 (Protected Resource Metadata)을 필수(mandatory) 사항으로 만들었습니다. 이제 대상 바인딩(Audience binding)이 MCP 서버별로 강제되므로, 특정 MCP 서버를 위해 발급된 액세스 토큰(access token)을 다른 MCP 서버에 사용하려고 하면 권한 부여 서버(authorization server)에서 거부됩니다. Cursor가 실수로 GitHub MCP 토큰을 Slack MCP로 전달하는 것과 같은 유출 경로가 이제 사양(spec) 수준에서 차단되었습니다.

둘째: Okta XAA가 MCP의 "기업 관리 권한 부여 (Enterprise-Managed Authorization)" 확장 기능으로 통합되었습니다. ID-JAG 개념은 순수한 IETF 초안(draft) 형태가 아니라 MCP 위에서 구현되는 방식으로 먼저 구현 단계에 도달하고 있습니다.

요약하자면: 사양(specs)은 수렴되었고, Anthropic / Okta / Keycloak / Salesforce로부터 구현체들이 나왔지만, 현장에서 이를 사용하는 사람은 거의 없습니다. 이것이 2026년 5월의 현황입니다.

세 가지 계층은 실제로 무엇을 보호하는가?

세 가지를 모두 병렬로 나열하는 것은 혼란만 가중시킵니다. 그림에서 보여주듯, 서로 다른 계층은 서로 다른 사양(specs)에 의해 보호됩니다.

계층 A: 인간 → 에이전트 → 외부 리소스 (ID-JAG / XAA)

여기에서의 문제는 "에이전트가 인간인 Alice를 대신하여 어떻게 GitHub에 접근하는가"입니다.

배경 지식으로 필요한 두 가지 OAuth 확장 기능(extensions)이 있습니다. 이들은 반복해서 등장하므로 먼저 확실히 짚고 넘어가야 합니다.

RFC 7523 (JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants): "JWT 하나를 가져오면 그 대가로 OAuth 액세스 토큰을 받는" 프로필입니다. 이는 grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer와 함께 전송하는 형식을 정의합니다.
RFC 8693 (Token Exchange): "하나의 토큰을 다른 토큰으로 교환하는" 일반적인 프레임워크입니다. subject_token은 "토큰의 대상"을 의미하며, actor_token은 "실제로 동작하는 주체"를 의미합니다. act / sub 클레임(claim) 계층 구조 또한 여기서 유래되었습니다.

ID-JAG / XAA는 이 두 가지를 결합하여 "인간의 SSO(Single Sign-On)를 통해 구축된 IdP(Identity Provider) 신뢰를 에이전트를 통해 이루어지는 API 호출까지 확장하는" 프로필을 만듭니다.

구체적인 차이점을 확인하기 위해, 기존의 방식은 다음 두 가지뿐입니다:

에이전트에게 Alice의 GitHub PAT(Personal Access Token)를 전달함 (현재 거의 모든 방식)
Alice가 에이전트를 위한 OAuth 앱을 개별적으로 승인함 (ChatGPT Plugins / Claude Connectors가 작동하는 방식)

방식 1은 범위를 제한할 수 없습니다. 만약 Alice에게 repo:full 권한이 있다면, 에이전트도 repo:full 권한을 갖게 됩니다. 방식 2는 범위를 제한할 수 있지만, Alice가 에이전트마다 동의 화면(consent screen)을 거쳐야 하므로 수많은 에이전트가 존재하는 시대에는 무너질 수밖에 없습니다.

ID-JAG은 다음과 같이 작동합니다:

Alice는 이미 자신의 IdP(Okta / Entra ID / Google Workspace)에 SSO로 로그인되어 있습니다.
IdP는 Alice를 위한 신원 증명 JWT(identity assertion JWT)를 발급합니다.
에이전트는 RFC 7523의 jwt-bearer 권한 부여 방식을 통해 이를 GitHub의 권한 부여 서버(Authorization Server)로 가져갑니다.
GitHub의 AS는 IdP와의 신뢰 관계를 통해 JWT를 검증하며, RFC 8693 토큰 교환(Token Exchange)을 통해 이를 Alice를 위한 범위가 제한된(scoped-down) GitHub 액세스 토큰으로 교환합니다.
에이전트는 해당 토큰을 사용하여 GitHub API를 호출합니다.

Alice는 동의 화면을 전혀 마주하지 않습니다. 에이전트는 처음부터 좁게 제한된 범위의 토큰만을 보유하게 됩니다. 수많은 에이전트가 있더라도, IdP 측에서 에이전트별 정책을 관리하면 됩니다.

Okta의 경우, 상용 명칭은 "Cross-App Access (XAA)"입니다. 개념적으로는 OAuth Identity Chaining (draft-ietf-oauth-identity-chaining-12) 위에 올라가는 프로필이며, Okta는 2026년에 MCP의 "Enterprise-Managed Authorization" 확장 기능으로 구현체를 출시했습니다.

계층 B: 에이전트 → 내부 서비스 체인 (에이전트를 위한 트랜잭션 토큰)

여기서 발생하는 문제는 "에이전트가 단일 요청을 처리하면서 여러 내부 서비스를 호출할 때, 누가 어떤 목적으로 행동하고 있는지를 어떻게 전파할 것인가"입니다.

계층 A의 ID-JAG가 신뢰 도메인 경계(귀사 → GitHub)를 넘나드는 것에 관한 것이라면, 계층 B는 **자사 내부의 마이크로서비스 체인 (microservice chain)**에 관한 것입니다.

전제 조건인 트랜잭션 토큰 (Transaction Tokens, draft-ietf-oauth-transaction-tokens-08)은 API 게이트웨이에서 수신된 외부 토큰을 내부 체인을 통해 흐를 수 있는 수명이 짧은 JWT로 "변환"하는 메커니즘입니다. 수신된 OAuth 액세스 토큰을 5단계의 홉(hop)을 거쳐 그대로 전달하면 스코프(scope)가 너무 넓어지고 유출 위험이 쌓이게 됩니다. 따라서 신뢰 도메인(Trust Domain) 내부에서는 **트랜잭션 토큰 서비스 (Transaction Token Service, TTS)**가 "이 요청을 위한" 짧은 수명의 토큰을 발행하고 이를 체인을 통해 흐르게 합니다. 자세한 내용은 다른 곳에 작성할 계획이지만, 요점은 단순히 "요청별 컨텍스트를 JWT에 담아 전달한다"는 것입니다.

에이전트를 위한 트랜잭션 토큰은 AI 에이전트가 신뢰 도메인에 혼합되어 있을 때를 위한 클레임(claim) 설계를 추가하는 확장 기능입니다.

클레임 (claim)	의미
`sub`	주체 (인간 Alice, 또는 에이전트가 독립적으로 행동하는 경우 에이전트 자신)
`act`	행위자 (실제로 호출을 수행하는 AI 에이전트; RFC 8693의 행위자 토큰(actor token) 개념을 JWT에 직접 내장)

전체 내부 체인을 통해 이 두 가지 클레임을 전달함으로써, "누가 누구에게 권한을 위임했는지"에 대한 정보가 요청마다 유지됩니다.

이것이 왜 필요할까요? ID-JAG 토큰 자체에는 행위자 (actor)를 위한 act 클레임 (RFC 8693 기준)이 포함되어 있으므로, "위임 (delegation)을 표현할 수 없다"는 뜻은 아닙니다. 문제는 다른 곳에 있습니다. ID-JAG는 aud (audience)가 단일 리소스 AS (Resource AS)에 고정된 **단일 홉, 경계 간 권한 부여 (single-hop, cross-boundary grant)**이므로, 이를 있는 그대로 내부 체인을 통해 전달할 수 없습니다 (aud가 일치하지 않기 때문입니다). 수신된 아웃바운드 토큰 (outbound token)을 5개의 홉을 거쳐 그대로 밀어 넣는 방식 또한 권한 범위가 과도하며 (over-scoped) 유출 위험을 누적시킵니다. 따라서 실제로는 **게이트웨이에서 이를 수명이 짧은 내부 토큰으로 교환 (즉, 새로운 토큰을 발행 (mint))**해야 합니다.

정보가 사라진다면, 그것은 홉을 넘나들기 때문이 아니라 교환되는 순간 행위자 (actor) 정보가 누락되기 때문입니다. 토큰을 무지성으로 발행하면 sub=alice만 살아남고 act는 사라져서, 최종 서비스는 "Alice 자신의 트랜잭션" 외에는 아무것도 보지 못하게 됩니다. 에이전트를 위한 트랜잭션 토큰 (Transaction Tokens for Agents)은 교환 시점에 act=agent-X, sub=alice가 반드시 보존되도록 강제하는 클레임 설계를 확립합니다. 일단 발행되면, TraT는 Order Service → Risk Service → Payment Service를 통해 불변하게 전파되며, 각 홉은 JWT 레벨에서 "agent-X가 Alice의 트랜잭션을 실행 중임"을 검증할 수 있습니다. Payment Service의 감사 로그 (audit log)에는 "agent-X가 alice를 대신하여 이 이체를 실행함"이 영구적으로 기록됩니다. 이것이 바로 Layer A 단독으로는 도달할 수 없는 영역입니다.

Layer C: 에이전트 (workload) → LLM (Anthropic WIF)

여기에서의 문제는 "에이전트인 워크로드 (workload)가 어떻게 Anthropic / OpenAI / Google의 LLM API에 인증하는가"입니다.

Layer A와 B가 리소스 측 (GitHub / 내부 서비스)을 향한 인증이었다면, Layer C는 AI 측을 향한 인증입니다.

Workload Identity Federation (WIF)라는 용어에는 역사가 있습니다. AWS와 GCP는 원래 "IdP의 OIDC 토큰을 STS / GCP 토큰으로 교환함으로써 IAM 사용자의 정적 액세스 키(static access keys)를 삭제하는" 메커니즘으로 이를 구축했습니다. 이는 GitHub Actions의 OIDC나 Kubernetes 서비스 계정(service account)을 AWS sigv4 자격 증명으로 교환하는 전체 과정을 의미합니다. Anthropic WIF는 단지 그 과정을 LLM 제공자 버전으로 구현한 것일 뿐이며, 그 구조는 완전히 동형(isomorphic)입니다.

Anthropic 측의 흐름(공식 문서)은 다음과 같습니다:

에이전트(Agent)가 실행되는 플랫폼(k8s SA / GHA / SPIFFE / AWS / GCP)이 주변 OIDC JWT(Kubernetes의 투영된 서비스 계정 토큰, GitHub Actions의 OIDC 엔드포인트 등)를 발행합니다.
에이전트는 RFC 7523 urn:ietf:params:oauth:grant-type:jwt-bearer를 통해 해당 JWT를 Anthropic의 /v1/oauth/token으로 전송합니다.
Anthropic은 등록된 발행자(issuer)의 JWKS를 통해 JWT 서명을 검증하고, 연합 규칙(federation rule)의 subject_prefix 등을 확인합니다.
일치할 경우, 수명이 짧은 sk-ant-oat01-... 토큰을 반환합니다(서비스 계정당 기본 3600초).

좋은 점은 sk-ant-... 정적 API 키를 완전히 삭제할 수 있다는 것입니다. 더 이상 에이전트 컨테이너에 비밀(secret)을 주입하는 작업을 할 필요가 없습니다.

여기서 자주 오해받는 한 가지가 있습니다: "WIF가 있다면 ID-JAG가 정말 필요한가요?" 이들은 서로 다른 구간을 보호하므로 비교 대상이 아닙니다. WIF는 '에이전트 → Anthropic' 구간을 보호하고, ID-JAG는 '인간 → 에이전트 → GitHub' 구간을 보호합니다. Anthropic WIF는 에이전트가 아무리 심각한 프롬프트 인젝션(prompt injection)을 당하더라도 Alice의 GitHub PAT를 보호할 수 없습니다. 전제 조건은 두 가지를 모두 사용하는 것입니다.