AI 에이전트 보안의 미래, ID-JAG
ID-JAG는 AI 에이전트의 API 접근을 IdP 중심으로 통제하는 새 권한 부여 방식이다.
AI 에이전트가 내부 DB 조회, 메시지 전송, 티켓 생성까지 대신 수행하는 시대가 오면서, 기존 인증·권한 부여 구조는 복잡도와 위험이 동시에 커지고 있다. 승인 팝업이 반복되는 consent fatigue, 승인되지 않은 연결인 shadow AI, 흩어지는 토큰과 자격 증명인 token sprawl이 대표적인 문제다.
ID-JAG(Identity Assertion JSON Web Token Authorization Grant) 는 이런 문제를 Enterprise IdP 중심으로 풀기 위한 새 표준 후보다. SSO에서 신뢰하던 IdP를 API 접근까지 확장해, IdP가 서명한 JWT를 일종의 “소개장”처럼 발급하고, 대상 서비스의 Authorization Server가 이를 신뢰해 최종 access token을 발급한다.
핵심 동작은 다음과 같다.
- Requesting Agent 가 사용자 SSO로 얻은 ID token을 IdP에 제시한다.
- IdP가 정책을 평가해 ID-JAG를 발급한다.
- Agent가 이 ID-JAG를 대상 Authorization Server 에 제출해 access token을 얻는다.
- 그 access token으로 Resource Server API를 호출한다.
이 구조는 RFC 8693 OAuth 2.0 token exchange와 RFC 7523 JWT profile for OAuth 2.0 authorization grants를 결합한 형태다. 중요한 변화는 권한 판단의 중심이 개별 앱 간 관계가 아니라, 조직이 관리하는 enterprise IdP 와 각 서비스 간의 신뢰 관계로 이동한다는 점이다.
도입 효과도 분명하다.
- UX 개선: 앱마다 뜨던 동의 화면을 줄여 승인 피로를 완화한다.
- 감사 추적성 강화: 어떤 사용자 대신 어떤 에이전트가 어떤 scope로 접근했는지 IdP에 집중해 기록할 수 있다.
- 중앙 통제: 승인되지 않은 연결이나 과도한 scope를 IdP 정책으로 차단할 수 있다.
- token sprawl 완화: 별도 refresh token을 남발하지 않고, 필요 시 ID-JAG를 다시 제출하는 방식으로 긴 수명의 자격 증명 확산을 줄인다.
다만 아직 Internet-Draft 단계이므로, 그대로 핵심 아키텍처에 묶는 것은 위험하다. 실제 도입을 위해서는 요청 에이전트와 IdP, Authorization Server 간의 사전 등록과 신뢰 관계가 필요하고, confidential client 중심으로 쓰는 것이 권장된다. 반면 public client 는 기존 authorization code grant 와 상호작용형 consent 흐름을 유지하는 편이 적절하다.
또한 운영 중에는 추가 인증이 필요해지는 step-up authentication 이 발생할 수 있고, 정책상 부족한 인증 맥락이면 오류로 되돌아올 수 있다. 결국 ID-JAG는 AI 에이전트 시대의 권한 부여를 더 중앙집중적이고 감사 가능한 형태로 재설계하려는 시도다.
이 요약은 원문 이해를 돕기 위한 큐레이션입니다. 저작권은 원저작자에게 있으며, 정확한 내용과 맥락은 원문을 확인하세요.
요약 오류, 출처 표기 문제, 삭제 요청은 문의 · 건의로 알려주세요.