Your Agent Just Authorized What?! — Jay Mok & Ben Coumes, Paypal

한 줄 핵심

에이전트의 권한 부여는 한 가지 방식으로 풀 수 없으며, 낮은 위험·중간 위험·높은 위험 상황에 따라 허용 범위와 증빙 수준을 계층적으로 설계해야 한다는 점을 PayPal의 결제 사례로 설명한다.

시간별 요약

1. 0:00
   터미네이터와 지갑을 털어 가는 에이전트 미래의 위협은 로봇의 핵발사보다 에이전트가 사용자의 지갑으로 쇼핑을 하는 상황에 가깝다. 에이전트 권한 부여를 안전하게 다루기 위한 사고 틀을 결제 관점에서 정리한다.
2. 1:26
   모든 에이전트 권한 부여가 답해야 할 세 가지 질문 핵심은 인간이 승인했는지, 지금 이 범위에서 허용되는지, 나중에 증명할 수 있는지의 세 가지다. 이 답은 상황의 맥락에 따라 달라지며, 특히 위험도와 증빙 필요 수준이 중요하다.
3. 2:49
   위험도, 상대방, 그리고 배지 비유 같은 시스템 안에서 서로를 아는지, 아니면 처음 만나는 상대인지가 권한 설계의 기준이 된다. 사무실에 배지로 들어간 뒤에는 내부에서의 추가 신뢰가 생기듯, 신뢰 경계 안팎에 따라 필요한 확인 방식이 달라진다.
4. 4:12
   낮은 위험: allow, ask, deny를 쓰는 코딩 에이전트 Claude Code 같은 코딩 에이전트는 GitHub, Jira, Linear 같은 도구 연결과 세밀한 권한 설정으로 운영된다. 위험도가 낮아 로그 확인이나 되돌리기로 충분한 경우가 많고, 강한 암호학적 증명까지는 필요하지 않다.
5. 6:15
   중간 위험: 공유 금고와 OAuth 범위 결제가 개입되면 같은 닫힌 생태계라도 위험도가 올라가며, vault와 OAuth scopes로 통제된 권한 위임이 필요하다. 상거래용 카드와 거래 로그를 활용해 신뢰를 유지하면서도, 상호 연결된 buyer agent와 seller agent 생태계를 만든다.
6. 9:45
   높은 위험: 서로 만나 본 적 없는 상대방 상대가 검증되지 않았고 서로를 모르는 상황에서는 기존 신뢰를 빌려 쓸 수 없다. 이때는 거래 상대가 누구든 에이전트의 권한과 의도를 검증 가능한 형태로 증명해야 한다.
7. 10:29
   계층형 선택적 공개 JWT 높은 위험 영역에는 다층 구조의 selective disclosure JWT가 적합하다고 본다. 신뢰할 수 있는 credential provider, 사용자의 지시, 에이전트의 서명이 각각 분리되어 있어 각 참여자가 자신에게 필요한 부분만 검증할 수 있다.
8. 12:30
   승인 토큰과 주문 흐름의 역전 PayPal approval token은 에이전트가 상품을 먼저 찾고, 그 다음 사용자가 PayPal에서 지시를 확인하는 역순 흐름을 가능하게 한다. amount, expiry, merchant 정보가 포함된 JSON payload를 돌려주며, 현재는 PayPal이 승인 가능한 opaque string으로 동작한다.
9. 14:31
   이 사다리가 결제를 넘어 적용되는 이유 낮은 위험에는 내부 배지형 권한, 중간 위험에는 같은 경계 안의 위임, 높은 위험에는 외부 검증 가능한 증명이 필요하다는 계층 구조가 정리된다. 이 틀은 결제뿐 아니라 되돌리기 어려운 의료 주문, 전자서명, 증권 거래에도 그대로 적용된다.

실무 인사이트

• 에이전트 권한 설계는 기능별로 한 번에 풀지 말고, 위험도와 상대방의 신뢰 관계를 기준으로 허용·보류·거부·증명 수준을 분리해 설계하는 것이 효과적이다.
• 실무에서는 되돌릴 수 있는 작업과 되돌리기 어려운 작업을 먼저 구분하고, 후자에만 강한 서명·토큰·감사 가능성을 요구하는 계층적 정책이 운영 비용을 줄인다.
• 결제 외 영역에서도 상대방을 모르는 고위험 에이전트 액션은 동일한 검증 모델이 필요하므로, 제품 기획 단계에서부터 증빙 가능한 승인 흐름을 넣어야 한다.