WorkOS(기업용 인증 및 사용자 관리 플랫폼)가 이번 주 에이전트 등록을 위한 오픈 프로토콜인 auth.md를 공개했다. 이 프로토콜은 서비스 제공자가 `https://service.com/auth.md`와 같은 정해진 경로에 마크다운 파일을 게시하여, AI 에이전트가 사람이 개입하지 않고도 스스로 서비스에 등록하고 권한을 획득하게 만드는 구조다.

기존의 웹 인증 모델은 브라우저 앞에 앉은 인간이 버튼을 클릭하고 폼을 채우는 동작을 전제로 설계되었다. 하지만 에이전트가 직접 코드를 작성하고 티켓을 처리하는 현재의 환경에서 이러한 방식은 병목이 된다. 그동안 개발자들은 에이전트에게 범위가 지정되지 않은(unscoped) API 키나 세션 토큰을 직접 전달하는 임시방편을 사용해 왔으며, 이는 세션별 감사가 어렵고 선택적 권한 회수가 불가능하다는 보안 취약점을 야기했다. auth.md는 이러한 한계를 극복하기 위해 에이전트가 읽을 수 있는 구조화된 문서와 런타임 아티팩트를 결합한 새로운 등록 경로를 제시한다.

auth.md와 /.well-known 경로를 통한 자동 발견

에이전트가 서비스에 접속할 때 가장 먼저 확인하는 지점은 `https://service.com/auth.md` 경로에 게시된 마크다운 파일이다. 과거에는 개발자가 API 문서를 일일이 읽고 API 키를 수동으로 복사해 환경 변수에 저장하는 방식이 표준이었으나, 이 모델은 에이전트가 직접 명세를 읽고 등록하는 구조로 전환한다. `auth.md`는 사람이 읽는 가이드라인인 동시에 에이전트가 런타임에 프로그램적으로 해석할 수 있는 아티팩트 역할을 수행한다. 에이전트는 이 파일을 통해 해당 서비스가 지원하는 인증 흐름과 사용 가능한 스코프(Scope, 권한 범위), 그리고 자격 증명의 발급 및 취소 절차를 스스로 파악하여 사람이 폼을 채우는 과정 없이 등록을 수행한다.

기계가 읽는 실제 진실의 원천은 두 단계의 홉(Hop)을 거치는 발견 경로로 설계된다. 첫 번째 단계에서는 `/.well-known/oauth-protected-resource` 경로에 위치한 PRM(Protected Resource Metadata, 보호된 리소스 메타데이터)이 해당 리소스를 식별하고 인증 서버의 위치를 가리킨다. 이후 에이전트는 `/.well-known/oauth-authorization-server` 경로의 인증 서버 메타데이터에 접근하여 `agent_auth` 블록을 확인한다. 이 블록에는 에이전트 등록을 위한 `register_uri`, 권한 주장을 위한 `claim_uri`, 자격 증명 무효화를 위한 `revocation_uri`, 그리고 지원되는 신원 유형을 명시하는 `identity_types_supported` 값이 구조화된 객체 형태로 포함된다. `auth.md` 파일은 에이전트가 이러한 기술적 발견 경로로 진입하도록 유도하는 서술적 동반자 역할을 한다.

사전 정보 없이 API에 접근했다가 401 Unauthorized 응답을 받은 상황에서도 에이전트는 스스로 인증 경로를 찾아낼 수 있다. 서비스는 응답 헤더에 `WWW-Authenticate: Bearer resource_metadata="..."`를 포함하여 반환함으로써 에이전트가 즉시 발견 프로세스를 시작할 수 있는 부트스트랩 지점을 제공한다. 이는 에이전트가 사전에 문서를 학습하거나 개발자로부터 설정값을 주입받지 않아도 런타임에 동적으로 인증 체계를 구축할 수 있게 만든다. 이러한 표준화된 발견 경로는 에이전트의 온보딩 비용을 획기적으로 낮추며, 서비스 제공자가 인증 정책이나 엔드포인트를 변경하더라도 에이전트가 코드 수정 없이 즉각적으로 대응할 수 있는 환경을 조성한다.

ID-JAG 기반의 검증 및 OTP 클레임 동작 원리

에이전트 인증의 핵심은 신뢰할 수 있는 제공자가 신원을 보증하는 방식과 사용자가 직접 소유권을 증명하는 방식의 분리에서 시작된다. 먼저 에이전트 검증 흐름(Agent verified flow)은 OpenAI나 Anthropic 같은 신뢰 플랫폼이 에이전트의 신원을 보증하는 구조를 취한다. 에이전트는 제공자로부터 특정 대상(audience)을 위한 ID-JAG(Identity-JSON Agent Grant, 에이전트 신원 증명 토큰)를 발급받아 서비스의 `/agent/auth` 엔드포인트로 POST 요청을 보낸다. 서버는 ID-JAG 헤더에서 kid(Key ID)와 alg(Algorithm)를 추출해 해당 제공자의 JWKS(JSON Web Key Set, 공개키 집합)를 조회하고 서명을 검증한다. 이 과정에서 aud(대상), exp(만료 시간), iat(발행 시간), jti(JWT ID), client_id(클라이언트 식별자)와 같은 클레임을 정밀하게 검증하여 신뢰성을 확보한다. 별도의 OTP나 이메일 왕복 없이 동기적으로 자격 증명이 발행되므로 인간의 개입이 완전히 배제된 자동화된 등록이 가능하다.

사용자 클레임 흐름(User claimed flow)은 에이전트 제공자의 개입 없이 OTP(One-Time Password, 일회용 비밀번호)를 통해 사용자가 직접 바인딩하는 경로를 제공한다. 에이전트가 `/agent/auth/claim` 엔드포인트를 통해 OTP 발송을 요청하면, 사용자는 이메일로 수신한 코드를 에이전트에게 전달하고 에이전트는 이를 `/agent/auth/claim/complete` 엔드포인트에 제출하여 인증을 완료한다. 이 흐름은 시작 방식에 따라 두 가지 변형으로 나뉜다. 익명 시작 방식은 신원 확인 전에도 서비스가 정의한 사전 권한을 부여받아 즉시 자격 증명을 획득하며, 이후 OTP 인증을 통해 권한을 업그레이드하는 구조다. 이때 API 키가 교체되지 않고 권한만 제자리에서 업그레이드되는 특성을 보인다. 반면 이메일 필수 방식은 등록 시 이메일을 먼저 제출해야 하며 OTP 인증이 완료되기 전까지는 어떠한 자격 증명도 발행되지 않는다. 이는 사전 사용이 불가능한 엄격한 보안 정책이 필요한 환경에서 관찰된다.

두 흐름 모두 최종적으로는 서비스 내 기존 사용자와 매칭하거나 새로운 사용자를 생성하는 프로비저닝 단계로 이어진다. 우선 동일한 발행자(iss)와 주체(sub) 쌍의 기존 위임 기록을 확인하고, 이후 검증된 이메일을 대조하며, 마지막으로 정책에 따라 JIT(Just-In-Time, 적시) 프로비저닝을 수행하는 순서가 권장된다. 특히 ID-JAG 검증으로 발행된 액세스 토큰에는 리프레시 토큰을 포함하지 않아야 하며, 권한 연장을 위해서는 매번 새로운 ID-JAG를 제시해야 한다는 제약 조건이 붙는다. 운영 관점에서는 registration.created, claim.requested, otp.generated, claim.confirmed, registration.expired, registration.revoked와 같은 표준 감사 이벤트를 기록하여 가시성을 확보한다. 이러한 상세 설계는 Repo와 Technical details에서 확인할 수 있다.

원시 API 키 방식과 auth.md 프로토콜의 결정적 차이

개발자가 에이전트를 서비스에 연결할 때 가장 먼저 마주하는 변화는 등록 프로세스의 자동화다. 기존에는 사람이 직접 브라우저에서 폼을 입력하고 이메일을 인증한 뒤, 생성된 API 키를 복사해 에이전트의 설정 파일에 붙여넣는 방식이 일반적이었다. 이 과정은 인간이 개입해야만 하는 Human-in-the-loop 구조로, 수많은 에이전트를 동시에 배포하거나 관리해야 하는 환경에서는 심각한 운영 병목을 초래한다. 하지만 auth.md 프로토콜에서는 에이전트가 서비스의 특정 경로에 게시된 마크다운 파일을 직접 읽어 지원되는 인증 흐름과 사용 가능한 권한 범위를 스스로 파악한다. 이는 수동 입력 단계가 사라진 프로그래밍적 등록(Programmatic registration) 체계로의 전환을 의미하며, 에이전트가 런타임에서 직접 서비스의 명세서를 읽고 등록 절차를 수행하는 구조로 바뀐다.

권한 제어의 정밀도에서도 원시 API 키 방식과 결정적인 차이가 관찰된다. 기존의 unscoped API 키나 세션 토큰은 발급 시점에 권한 범위가 모호하거나 지나치게 광범위하게 설정되는 경향이 있다. 이러한 정적 키는 한 번 유출되면 해당 키가 가진 모든 권한이 노출되며, 특정 세션만 선택적으로 회수하거나 세부적인 감사 로그를 남기는 것이 기술적으로 매우 어렵다. 반면 auth.md는 발행자(iss), 주체(sub), 대상(aud) 정보를 조합하여 생성하는 위임 기록 체계를 도입한다. 서비스 제공자는 `revocation_uri`를 통해 특정 위임 기록만을 정밀하게 타격하여 회수할 수 있다. 이는 보안 사고 발생 시 전체 시스템의 API 키를 교체하는 대규모 작업 없이도, 문제가 된 특정 에이전트의 접근권만 즉각적으로 차단할 수 있는 실무적 제어권을 제공한다.

인증 유지 방식 또한 정적인 토큰 소유에서 동적인 검증 체계로 전환된다. ID-JAG(Identity-Joint Agent Grant, 에이전트 공동 인증 부여) 검증을 통해 액세스 토큰이 발행될 때, auth.md 프로토콜은 리프레시 토큰의 발행을 엄격히 금지하는 제약 조건을 둔다. 일반적인 OAuth 흐름에서는 리프레시 토큰을 통해 장기간 세션을 유지하지만, 에이전트 환경에서는 이것이 권한 남용의 경로가 될 수 있기 때문이다. 따라서 에이전트는 액세스 권한을 연장하기 위해 반드시 새로운 ID-JAG를 제시하여 신원을 재검증받아야 한다. 이러한 설계는 에이전트의 신원 확인 주기를 강제함으로써, 제공자가 에이전트의 상태를 실시간으로 제어하고 시스템 내에 유효 기간이 불분명한 좀비 토큰이 잔존하는 리스크를 원천적으로 제거하는 효과를 가져온다.

JIT 프로비저닝과 감사 이벤트 기반의 운영 효율화

에이전트가 시스템에 진입하는 순간부터 권한이 회수되는 시점까지 전 과정을 가시화하는 것은 엔터프라이즈 환경의 보안 통제권을 확보하는 핵심 과제다. 서비스 제공자는 에이전트의 요청을 처리할 때 기존 사용자 데이터베이스와의 정합성을 유지해야 하며, 이때 권장되는 사용자 매칭 순서는 명확한 우선순위를 따른다. 가장 먼저 기존 위임 기록인 iss(Issuer)와 sub(Subject) 쌍을 통해 식별을 시도하며, 여기서 일치하는 기록이 없을 경우 검증된 이메일 주소를 대조한다. 마지막 단계로, 정책에 따라 즉시 계정을 생성하는 JIT-provision(Just-In-Time provisioning)을 수행하거나, 수동 온보딩이 필수인 서비스라면 요청을 거절하는 방식으로 운영의 안정성을 도모한다.

운영 효율화를 위해 표준화된 감사 이벤트 체계를 도입하는 것 또한 필수적이다. 시스템은 registration.created를 시작으로 claim.requested, otp.generated, claim.confirmed, registration.expired, 그리고 registration.revoked에 이르는 일련의 상태 변화를 기록해야 한다. 특히 ID-JAG(Identity-JSON Agent Grant) 흐름을 활용할 경우, 로그에는 반드시 iss와 sub, 그리고 agent_platform 정보를 포함해야 한다. 이러한 데이터는 에이전트 제공자 측 로그와 상관관계를 분석하는 데 결정적인 단서가 되며, 사고 대응 시 에이전트가 어떤 경로로 권한을 획득하고 행위를 수행했는지 추적하는 가시성을 제공한다.

개발팀이 이러한 구조를 코드에 도입할 때 주목해야 할 지점은 권한의 생명주기 관리다. ID-JAG를 통한 인증 시 리프레시 토큰을 발행하지 않는 제약 조건을 설정함으로써, 에이전트는 매번 새로운 ID-JAG를 제시해야만 권한을 연장할 수 있다. 이는 보안상 불필요한 권한 유지를 방지하고, 제공자가 언제든 logout 토큰을 통해 권한을 즉각적으로 회수할 수 있는 구조를 만든다. 결과적으로 엔터프라이즈 운영자는 에이전트의 활동을 단순한 API 호출의 연속이 아닌, 명확한 식별자와 감사 로그가 결합된 관리 가능한 개체로 다룰 수 있게 된다. 이는 기존 OIDC(OpenID Connect)나 SAML(Security Assertion Markup Language) 기반의 사용자 관리 패턴과 동일한 논리적 구조를 공유하므로, 기존 인프라에 이식하는 과정에서 개발자가 겪는 학습 곡선 또한 최소화될 것으로 관찰된다.

한국 B2B SaaS 기업의 '에이전트 우선' API 설계 전략

기존의 B2B SaaS 인증 방식은 브라우저 앞에 사람이 앉아 버튼을 클릭하고 이메일을 확인하는 시나리오를 전제로 설계되었다. 개발자가 API 키를 직접 복사해 설정 창에 붙여넣는 방식은 인간 사용자에게는 익숙한 흐름이지만, 자율적으로 동작하는 에이전트에게는 치명적인 병목이 된다. 특히 범위가 지정되지 않은 raw API 키나 세션 토큰을 에이전트에게 부여하는 임시방편은 세션별 감사(audit)가 어렵고 특정 권한만 선택적으로 회수하는 것이 불가능하다는 보안상 취약점이 관찰된다. 이는 에이전트의 권한 오남용 시 대응 속도를 늦추는 실무적 리스크로 작용한다.

이러한 한계를 극복하기 위해 OpenAI나 Anthropic, Cursor와 같은 신뢰할 수 있는 에이전트 제공자와의 호환성을 고려한 기계 가독형(Machine-readable) 인증 체계 도입이 제안된다. 에이전트가 서비스의 auth.md 파일을 통해 등록 흐름과 권한 범위를 스스로 파악하고 등록하는 구조다. 구체적으로는 `/.well-known/oauth-protected-resource`와 같은 표준 경로를 통해 리소스 메타데이터를 확인하고, 인증 서버의 agent_auth 블록에서 지원되는 흐름과 등록 URI를 식별하는 과정이 포함된다. 이는 단순한 문서화를 넘어 에이전트가 런타임에 읽고 실행할 수 있는 아티팩트로 기능하며, 인간의 개입 없이도 인증 프로세스를 완결 짓는 기반이 된다.

실무적인 구현 관점에서 한국의 많은 B2B SaaS 기업들은 이미 OIDC(OpenID Connect)나 SAML(Security Assertion Markup Language) 기반의 JIT(Just-In-Time) 프로비저닝 로직을 보유하고 있다. 이 기존 로직을 ID-JAG(Identity-JSON-Agent-Gateway) issuer로 확장 적용하는 전략이 실무적으로 유효하다. 에이전트 제공자가 발행한 ID-JAG를 수신하고, 헤더의 kid와 alg를 통해 신뢰할 수 있는 제공자 목록에서 issuer를 확인한 뒤 JWKS(JSON Web Key Set)로 서명을 검증하는 과정은 기존 기업용 인증 흐름과 구조적으로 동일하다. 여기에 aud, exp, iat, jti, client_id와 같은 클레임 검증 단계만 추가하면 기존 인증 인프라를 크게 수정하지 않고도 에이전트 인증을 수용할 수 있다.

결과적으로 이는 인증의 중심축이 인간을 위한 UI/UX에서 에이전트를 위한 API 설계로 이동함을 의미한다. 사용자가 직접 설정 화면에서 권한을 부여하는 대신, 에이전트가 표준화된 프로토콜에 따라 권한을 요청하고 서비스가 이를 검증하여 동기적으로 자격 증명을 발행하는 방식으로 전환되는 것이다. 인증 계층의 표준화가 시급한 이유는 이것이 단순한 기능 추가가 아니라, 글로벌 에이전트 생태계라는 거대한 배포 채널에 제품을 노출시키기 위한 필수 인프라 작업이기 때문이다. 기계가 읽을 수 있는 인증 명세의 도입은 한국 SaaS 기업들이 글로벌 시장에서 에이전트 우선(Agent-First) 전략을 구체화하는 첫 번째 기술적 단계가 될 것으로 관찰된다.