AI 에이전트는 지갑은 있지만 신원은 없습니다 — 에이전트 신원 문제 해결하기

지난주 AgentMail이 HN(Hacker News)에 출시되어 169점을 기록했습니다. YC S25 프로젝트입니다. 이들의 피치(Pitch)는 다음과 같습니다: "에이전트에게 고유한 이메일 수신함(inbox)을 제공하는 API입니다."

사람을 위한 이메일이 아닙니다. AI 에이전트를 위한 이메일 주소입니다. 오직 에이전트만이 확인하는 수신함입니다. 에이전트가 신원을 확인하고, 확인 메시지를 수신하며, 다른 에이전트와 통신하는 데 사용할 수 있는 SMTP 엔드포인트(endpoint)입니다.

이것은 단순한 눈속임이 아닙니다. 에이전트 결제(agentic payments) 분야에서 가장 크고 해결되지 않은 문제의 증상입니다: 에이전트는 신원(identity)이 없습니다.

문제의 형태

오늘날 여러분의 에이전트가 돈을 쓰려고 할 때 발생하는 상황은 다음과 같습니다:

에이전트(Agent) → Stripe API → "당신은 누구입니까?"
에이전트(Agent) → "저는 API 키를 가지고 있습니다."
Stripe → "누구의 API 키입니까?"
...

제가 지금까지 다루어 온 모든 에이전트 결제 스택 — 권한 부여 래퍼(authorization wrappers), 정책 엔진(policy engines), 지출 명령(spending mandates) — 은 매우 취약한 가정 위에 놓여 있습니다: 바로 결제 레일(payment rail)이 어떤 에이전트가 요청을 보내고 있는지 알고 있다는 가정입니다.

하지만 실제로는 그렇지 않습니다. Stripe는 API 키를 봅니다. OpenAI는 API 키를 봅니다. AWS는 IAM 역할(IAM role)을 봅니다. 그들 중 누구도 *에이전트 신원(agent identity)*을 보지 못합니다. 지출 주체를 식별할 수 없다면, 에이전트별 예산을 강제하거나, 개별 에이전트를 감사(audit)하거나, 인간의 자격 증명을 함께 취소하지 않고도 탈주한 에이전트의 권한만 취소하는 것이 불가능합니다.

현재 출시되고 있는 것들

HN 메인 페이지가 갑자기 에이전트 신원 프로젝트들로 가득 차고 있습니다. 신원(identity) 개념이 새로워졌기 때문이 아니라, 에이전트 결제가 데모 단계에서 프로덕션(production) 단계로 넘어가면서 여러 팀이 같은 주에 이 벽에 부딪히고 있기 때문입니다.

Kontext CLI (HN 70점): 코딩 에이전트를 위한 자격 증명 브로커(credential broker)입니다. 가공되지 않은 API 키 대신, 에이전트는 런타임(runtime)에 해결되는 참조(reference)를 받습니다. 브로커는 실제 자격 증명을 주입하고, 어떤 에이전트가 사용했는지 기록하며, 사용 후 이를 교체(rotate)합니다. 이는 "에이전트를 위한 IAM 역할" 패턴으로, 일시적이고 범위가 지정되며 감사 가능한 방식입니다.

Pomerium Agentic Access Gateway (HN 10점): AI 에이전트를 위해 확장된 제로 트러스트(Zero-trust) 프록시입니다. 에이전트는 (개별 서비스가 아닌) 게이트웨이에 인증하며, 게이트웨이가 정책을 강제합니다. 에이전트는 자신을 배포한 인간과 분리된 고유의 신원을 갖게 됩니다.

Grantex: 에이전트 권한 부여 (Authorization)를 위해 IETF에 제출된 초안 — 인간의 클릭을 통한 동의 흐름(click-through consent flow)이 없는 OAuth라고 생각하면 됩니다.

Vouch Protocol: AI 에이전트를 위한 C2PA + DID. Adobe와 Microsoft가 채택한 것과 동일한 콘텐츠 진본성 표준을 에이전트 신원에 적용합니다.

아무도 이름을 붙이지 않은 패턴

이 모든 프로젝트는 동일한 아키텍처를 공유합니다:

에이전트 (Agent) → 신원 브로커 (Identity Broker) → 자격 증명 주입 (Credential Injection) → 서비스 (Service)
         ↑                    ↑
    (이것은 누구인가?)      (무엇을 할 수 있는가?)
...

이것은 새로운 컴퓨터 과학이 아닙니다. Kerberos입니다. SPIFFE입니다. 지난 20년 동안 존재했던 모든 서비스 간 인증 (service-to-service auth) 패턴이 마침내 에이전트 계층에 도달한 것입니다.

차이점은 다음과 같습니다: 마이크로서비스 (microservices)에서 신원은 포드 (pod)나 VM에 결합됩니다. 에이전트의 경우, 신원은 _작업 (task)_을 따라가야 합니다. 작업 X를 수행하는 에이전트 A는 작업 Y를 수행하는 에이전트 A와는 다른 권한이 필요할 수 있습니다. 신원은 정적이지 않고 문맥적 (contextual)입니다.

오늘 무엇을 구축해야 하는가

지금 바로 출시할 수 있는 최소 기능 에이전트 신원 계층 (minimum viable agent identity layer)은 다음과 같습니다:

# agent_identity.py — 최소 기능 에이전트 신원 계층
import hashlib
import time
...

세 가지 헤더: X-Agent-ID, X-Task-ID, X-Agent-Session. 그것이 전부입니다. 여러분이 비용을 지불하는 서비스들 (OpenAI, AWS, Stripe)은 현재 이를 무시하겠지만, 여러분의 인증 프록시 (auth proxy), 감사 추적 (audit trail), 그리고 정책 엔진 (policy engine)은 즉시 이를 사용할 수 있습니다. 결제 망 (payment rails)에 에이전트 신원 필드가 추가될 때 (그리고 추가될 것입니다 — Visa의 Replit 투자가 그 신호입니다), 여러분은 이미 데이터를 보유하게 될 것입니다.

결론

AgentMail이 HN(Hacker News)에서 169점을 기록한 것은 이메일에 관한 것이 아닙니다. 이는 빌더들이 에이전트 결제 스택에 기반이 빠져 있다는 것을 깨달았기 때문입니다. 인증 (authentication) 없이는 권한 부여 (authorization)를 할 수 없습니다. 신원 (identity) 없이는 인증을 할 수 없습니다. 그리고 현재 에이전트는 그 어느 것도 가지고 있지 않습니다.

신원 계층 (identity layer)을 출시하고 있는 팀들 — Kontext, Pomerium, AgentMail, Grantex, Vouch — 은 모든 에이전트 결제 스택 (payment stack)이 의존하게 될 기본 요소 (primitives)들을 구축하고 있습니다. 여러분의 CFO가 "저 API 청구서에 포함된 4,200달러를 어떤 에이전트가 사용했습니까?"라고 물었을 때, 감사 추적 (audit trail) 결과가 "API key sk-...xyz"라고 나온다면 — 여러분은 답을 할 수 없습니다. 그 답은 에이전트 신원 (agent identity)에서 시작됩니다.

AgentPay Labs — 자율 에이전트 (autonomous agents)를 위한 결제 제어 평면 (payment control plane)을 구축합니다.
이전 글: Visa Just Bet on Agentic Payments | Agent Spend Compliance