Better Agent Auth - Bereket Habtemeskel & Paola Estefania, Better Auth
📺 원본 영상: Better Agent Auth — Bereket Habtemeskel & Paola Estefania, Better Auth
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-22
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 코드, 슬라이드, 로그 화면 등은 포함되지 않을 수 있습니다.
개요
이 워크숍의 핵심 질문은 단순하다. AI 에이전트가 이메일을 읽고, 캘린더를 확인하고, 사용자를 대신해 작업을 수행하는 시대에 과연 에이전트에게 사용자의 자격 증명을 그대로 넘겨도 되는가라는 문제다. 강연자는 현재 많은 에이전트 통합이 사실상 “사용자인 척하기” 방식으로 동작한다고 지적하며, 앞으로는 에이전트가 독립된 신원(identity)을 가진 주체(principal)로 행동해야 한다고 주장한다.
강연의 기술적 중심에는 AgentAuth 프로토콜이 있다. 이 프로토콜은 에이전트가 어떤 서비스를 사용할 수 있는지 발견(discovery)하고, 어떤 작업을 수행할 수 있는지 세밀하게 인가(authorization)받으며, 이후 어떤 에이전트가 어떤 사용자 대신 어떤 행동을 했는지 추적(traceability)할 수 있도록 설계된다. 이를 통해 AI 에이전트는 더 이상 사용자의 비밀번호나 토큰 뒤에 숨어 행동하는 존재가 아니라, 권한을 위임받은 독립 행위자로 다뤄지게 된다.
에이전트에게 “사용자인 척할 권한”을 주는 문제
강연자는 먼저 청중에게 AI 에이전트를 매일 사용하는지, 그리고 그 에이전트에게 Gmail, 캘린더, 개인 계정 접근 권한을 주는지 묻는다. 흥미로운 점은 AI 에이전트를 사용하는 사람은 많지만, 실제 개인 계정 접근까지 허용하는 사람은 훨씬 적었다는 것이다. 이는 사용자들이 이미 직관적으로 위험을 감지하고 있음을 보여준다. 에이전트가 편리하다는 사실과 에이전트에게 민감한 계정 권한을 넘기는 일이 안전하다는 사실은 전혀 다른 문제이기 때문이다.
현재 흔한 방식은 MCP 서버를 연결하거나 개인 토큰을 특정 엔드포인트에 붙여서 에이전트가 사용자의 리소스에 접근하도록 만드는 것이다. 강연자는 이 구조를 “에이전트가 우리를 대신해 행동하지만, 실제로는 우리인 척한다”고 표현한다. 이 표현은 문제의 본질을 정확히 짚는다. 시스템 입장에서 보면 누가 행동했는지 구분되지 않고, 로그에는 사용자가 직접 행동한 것처럼 남을 수 있으며, 에이전트별 권한 제한이나 사후 폐기가 어려워진다.
강연자는 이를 회사의 채용 상황에 비유한다. 회사가 새 직원을 고용하면 그 사람에게 CEO의 이메일과 비밀번호를 주지 않는다. 대신 개인 계정, 직무에 맞는 권한, 필요한 시스템 접근 권한을 별도로 발급한다. AI 에이전트도 마찬가지로 “사용자의 자격 증명(credentials)”을 가져서는 안 되며, 사용자가 정한 범위 안에서 행동할 “권한(authority)”을 받아야 한다는 것이 강연의 출발점이다.
발견, 인가, 신원이라는 세 가지 문제
강연자는 에이전트 보안을 세 가지 문제로 나누어 설명한다. 첫 번째는 에이전트가 무엇을 할 수 있는지 어떻게 알 것인가라는 발견(discovery)의 문제다. 오늘날에는 개발자가 직접 도구를 연결하거나, 특정 MCP 서버를 설정하거나, 에이전트에게 사용할 수 있는 기능을 수동으로 알려주는 방식이 많다. 그러나 에이전트가 점점 더 다양한 서비스를 다루게 되면, 매번 사람이 직접 연결하고 설명하는 방식은 확장성이 떨어진다.
두 번째 문제는 에이전트에게 무엇을 허용할 것인가라는 인가(authorization)의 문제다. 단순히 Gmail 읽기 권한을 줄 것인지, 이메일 발송 권한까지 줄 것인지, 특정 기간의 메일만 읽게 할 것인지, 특정 작업은 매번 승인을 요구할 것인지가 모두 다른 보안 판단이다. 기존 OAuth scope는 대체로 “read”처럼 넓은 단위로 표현되는 경우가 많기 때문에, 에이전트가 실제 수행하려는 개별 행동과 정확히 대응되지 않을 수 있다. 강연자가 capabilities를 강조한 이유도 여기에 있다.
세 번째 문제는 에이전트가 누구인지 식별할 수 있어야 한다는 신원(identity)의 문제다. 어떤 에이전트가 어떤 사용자 대신 어떤 서비스를 호출했는지 알 수 없다면, 감사 로그도 충분하지 않고 권한 회수도 거칠어진다. 반대로 에이전트마다 고유한 신원이 있다면 특정 에이전트만 추적하고, 특정 에이전트만 폐기하고, 특정 호스트나 사용자 정책에 따라 접근을 제한할 수 있다. 강연자는 이 지점에서 에이전트를 “사용자 뒤에 숨어 있는 도구”가 아니라 “식별 가능한 행위자”로 보아야 한다고 주장한다.
Capability는 왜 Scope보다 에이전트에 더 적합한가
강연자는 청중에게 capability라는 개념을 들어본 적 있는지 묻고, 많은 사람이 익숙하지 않다는 반응을 보이자 scope와 비교해 설명한다. 일반적인 OAuth scope는 “read”처럼 넓은 권한 묶음으로 표현되는 경우가 많다. 하지만 에이전트의 세계에서는 “읽기”조차 너무 넓을 수 있다. 이메일 전체를 읽는 것과 지난주 이메일 제목만 가져오는 것, 특정 라벨의 메시지만 조회하는 것은 보안상 매우 다른 행위이기 때문이다.
Capability는 에이전트가 수행할 수 있는 구체적 행동을 더 잘게 나누어 표현하려는 접근이다. 사용자가 “지난주 이메일을 보여줘”라고 요청하면, 에이전트는 그 의도를 하나 이상의 도구 호출로 변환해야 한다. 이때 intent가 어떤 capability와 매핑되는지 알 수 있어야 하고, 실제 실행 전에 해당 capability가 허용되어 있는지도 확인해야 한다. 강연자는 이 구조가 에이전트의 발견과 인가를 연결하는 핵심이라고 설명한다.
이 관점에서 중요한 변화는 권한의 단위가 사람 중심의 애플리케이션 접근에서 행동 중심의 에이전트 실행으로 이동한다는 점이다. 기존 앱 권한 모델에서는 “이 앱이 Gmail을 읽을 수 있다”가 주요 판단이었다면, 에이전트 모델에서는 “이 에이전트가 이 사용자 대신 이 시점에 이 특정 기능을 실행할 수 있다”가 중요해진다. 그 차이는 작아 보이지만, 실제 감사 가능성과 사고 대응에서는 결정적이다. 특히 여러 에이전트가 서로 다른 업무를 수행하는 기업 환경에서는 이 구분이 보안 체계의 기본 단위가 된다.
AgentAuth의 발견 방식과 OpenAPI 기반 중간 단계
강연자가 제안하는 발견 방식의 이상형은 서비스가 공개된 위치에서 에이전트용 설정과 capability 목록을 제공하는 것이다. 강연자는 OpenID Connect(OIDC)의 well-known configuration endpoint를 떠올리게 하는 방식으로, 에이전트가 서비스와 상호작용하는 방법을 공적인 위치에서 확인할 수 있어야 한다고 설명한다. STT에 “Asian Dals”처럼 오인식된 표현이 반복되지만, 문맥상 이는 AgentAuth 또는 agent authorization 계열 프로토콜을 가리키는 것으로 보는 것이 자연스럽다.
10:59 - AgentAuth의 well-known configuration endpoint와 capability 목록 구조를 설명하는 화면
다만 강연자는 모든 서비스가 곧바로 AgentAuth 명세를 구현하는 세계가 당장 오지는 않는다고 인정한다. 그래서 중간 단계로 OpenAPI specification을 활용하는 방법을 제안한다. 많은 서비스가 이미 OpenAPI JSON을 제공하고 있으므로, 이를 읽어 API endpoint들을 capability로 변환할 수 있다는 것이다. 예를 들어 Notion처럼 접근 가능한 OpenAPI 문서를 가진 서비스는 endpoint 구조를 바탕으로 “읽기”, “생성”, “삭제” 같은 capability 후보를 구성할 수 있다.
13:40 - OpenAPI endpoint를 capability로 변환한 예시가 표시되는 화면
이 중간 단계는 현실적인 절충안이다. 이상적으로는 서비스 제공자가 직접 에이전트 친화적인 capability 명세를 제공해야 하지만, 초기 생태계에서는 기존 API 명세를 변환해 디렉터리에 등록하는 방식이 도입 장벽을 낮춘다. 강연자는 이 디렉터리를 전화번호부(phone book)에 비유한다. 에이전트가 “무엇을 하고 싶은지”를 알면, 디렉터리를 통해 “어떤 서비스를 어떤 capability로 호출해야 하는지”를 찾는 구조다.
에이전트를 Principal로 만든다는 것
강연의 가장 중요한 전환점은 에이전트에게 독립된 신원을 부여하는 부분이다. 강연자는 각 에이전트가 자체 private key를 가지고, 이 키가 에이전트의 identity와 연결된다고 설명한다. 이 구조에서는 에이전트가 자체적으로 토큰에 서명하거나, 에이전트 식별 정보를 포함한 토큰을 발급받을 수 있다. 따라서 Gmail 같은 서비스는 단순히 “사용자가 접근했다”고 보는 것이 아니라 “특정 에이전트가 특정 사용자 대신 접근했다”고 기록할 수 있다.
18:22 - 에이전트 private key, 독립 identity, principal actor 개념을 설명하는 슬라이드 또는 코드 화면
이 변화는 로그의 의미를 바꾼다. 기존 방식에서는 에이전트가 사용자의 access token을 들고 행동하면, 리소스 서버 입장에서는 그 요청이 사용자 본인의 직접 행동인지, 사용자가 연결한 에이전트의 행동인지 구분하기 어렵다. 반면 에이전트가 principal로 다뤄지면 로그에는 agent ID, user ID, host, 실행된 capability, 결과 등이 함께 남을 수 있다. 강연자는 Cursor, Claude 같은 호스트에서 생성된 에이전트를 예로 들며, 어느 호스트의 어느 에이전트가 무엇을 했는지 추적할 수 있어야 한다고 설명한다.
이 구조는 권한 회수에서도 중요하다. 특정 에이전트가 잘못된 행동을 하거나 예상과 다른 작업을 수행하면, 전체 계정 연결을 끊는 대신 해당 에이전트의 접근만 revoke할 수 있다. 강연자는 “채용” 비유를 다시 사용해, 문제가 있는 직원을 해고하듯 문제가 있는 에이전트의 권한을 제거할 수 있어야 한다고 말한다. 결국 신원은 단순한 식별자가 아니라 수명주기 관리, 감사, 폐기, 정책 적용의 기반이 된다.
데모가 보여준 워크플로우
강연 후반부에서는 AgentAuth 프로토콜과 MCP를 결합한 데모가 진행된다. 사용자는 웹사이트의 디렉터리에서 서비스를 연결하고, MCP를 Claude나 Cursor 같은 클라이언트에 붙여 사용해 볼 수 있다. 강연자는 데모용 이메일 계정을 사용해 개인정보 노출을 피하면서, 에이전트가 이메일을 읽고 권한 요청을 거쳐 이메일을 보내는 흐름을 보여준다. 이 과정에서 중요한 것은 이메일을 읽을 수 있다는 사실 자체가 아니라, 에이전트의 identity, capability 요청, 승인, 로그, revoke가 모두 관찰 가능하다는 점이다.
데모에서는 에이전트가 “마지막 이메일을 가져와 달라”는 의도를 받으면, 디렉터리를 통해 필요한 capability를 찾고 사용자에게 승인을 요청한다. 이때 OAuth 2.0 Device Authorization Grant, 흔히 device flow라고 부르는 방식과 유사한 흐름이 등장한다. 강연자는 에이전트를 하나의 “장치(device)”처럼 취급해 사용자가 별도 승인 화면에서 권한을 허용하는 모델을 설명한다. 승인 화면에는 “email reader” 같은 에이전트 이름과 요청 capability가 표시되며, 사용자가 승인하면 에이전트는 해당 범위 안에서 이메일을 읽을 수 있게 된다.
25:29 - 이메일 읽기 에이전트가 capability 승인을 요청하는 device flow 데모 화면
이후 강연자는 로그 화면을 통해 어떤 agent ID가 어떤 user ID와 연결되어 어떤 결과를 얻었는지 확인한다. 여기서 데모의 핵심 메시지가 드러난다. 에이전트가 이메일을 읽는 기능은 이미 많은 시스템에서 가능하지만, 그 행동을 독립적으로 추적하고 설명할 수 있는 구조는 별개의 문제다. AgentAuth가 해결하려는 것은 바로 이 관찰 가능성과 통제 가능성이다.
26:35 - agent ID, user ID, 실행 결과가 포함된 감사 로그를 확인하는 데모 화면
읽기 권한과 쓰기 권한 사이의 UX와 보안 균형
데모의 다음 단계에서는 에이전트가 이메일을 보내려 할 때 어떤 일이 일어나는지 보여준다. 강연자는 기본적으로 읽기 capability는 호스트 정책에 따라 허용될 수 있지만, 이메일 발송처럼 더 위험한 행동은 별도 승인을 요구해야 한다고 설명한다. 이때 STT에는 “Siva”처럼 들리는 표현이 나오는데, 문맥상 CIBA(Client-Initiated Backchannel Authentication) 또는 유사한 backchannel authorization 흐름을 설명한 것으로 보인다. 강연자는 redirect나 device approval 대신, 사용자가 현재 흐름 안에서 승인할 수 있는 방식을 보여준다.
29:09 - 이메일 발송 capability가 추가되고 실제 발송 결과를 확인하는 데모 화면
이 장면은 에이전트 보안에서 UX가 얼마나 중요한지 보여준다. 모든 읽기 작업마다 사용자가 승인해야 한다면 보안은 강해질 수 있지만, 실제 사용자는 곧 피로감을 느낄 것이다. 반대로 모든 작업을 자동 승인하면 편리하지만, 이메일 발송이나 삭제처럼 돌이키기 어려운 작업에서 사고가 발생할 수 있다. 강연자는 좋은 사용자 경험과 충분한 보안 사이의 균형이 필요하며, 이를 host policy, user policy, capability constraint로 조정할 수 있다고 설명한다.
특히 capability에는 실행 시간, 최대 실행 횟수, 특정 조건 같은 제약을 넣을 수 있다고 언급된다. 이는 단순히 “이 에이전트는 이메일을 보낼 수 있다”가 아니라 “이 에이전트는 이 조건 안에서만 이메일을 보낼 수 있다”로 권한 모델을 좁히는 방향이다. 기업 환경에서는 사용자 직무, 호스트 신뢰도, 에이전트 유형에 따라 기본 정책이 달라질 수 있다. 강연자가 말한 것처럼 CEO에게 허용되는 행동과 새로 합류한 구성원에게 허용되는 행동이 같을 필요는 없다.
Revoke와 감사 가능성의 실제 의미
강연자는 데모에서 에이전트를 revoke한 뒤 다시 이메일 읽기와 발송을 시도한다. 이때 기존 에이전트 연결은 폐기되고, 새 identity를 가진 에이전트가 다시 생성되는 흐름이 관찰된다. 읽기 capability가 기본적으로 안전하다고 설정된 데모 환경에서는 일부 읽기 작업이 다시 가능하지만, 발송 같은 작업은 다시 승인을 요구한다. 이는 권한 회수와 정책 적용이 어떻게 함께 작동하는지 보여주는 중요한 장면이다.
30:20 - 에이전트 revoke 이후 연결이 폐기되고 재승인 흐름이 발생하는 데모 화면
Revoke의 의미는 단순히 토큰 하나를 삭제하는 데 그치지 않는다. 에이전트가 독립된 신원을 가진다면, 특정 에이전트의 수명주기를 종료하고 더 이상 해당 identity로 권한을 행사하지 못하게 만들 수 있다. 또한 로그에는 과거 그 에이전트가 수행한 행동이 남아 있기 때문에, 사후 감사도 가능하다. 보안 사고 대응에서 중요한 것은 “무엇을 차단할 수 있는가”뿐 아니라 “무슨 일이 있었는지 설명할 수 있는가”인데, AgentAuth의 identity 중심 설계는 이 둘을 연결한다.
강연자는 proxy라는 표현에 대해서도 조심스럽게 선을 긋는다. 이 구조에서 디렉터리는 실제 데이터 프록시라기보다 intent와 capability를 매칭하는 장소에 가깝다고 설명한다. 실제 proxy가 모든 데이터를 통과시키는 방식은 확장성 측면에서 좋지 않으며, 데이터 처리 부담도 커진다. 따라서 AgentAuth의 디렉터리는 서비스를 대신 호출하는 중앙 통로라기보다, 에이전트가 어떤 capability를 사용할 수 있는지 발견하고 권한 흐름을 시작하는 안내 지점으로 이해하는 편이 적절하다.
AgentAuth Plugin, SDK, Directory의 세 계층
강연자는 구현을 세 계층으로 설명한다. 첫 번째는 서버 측 계층으로, 서버는 에이전트를 검증하고, 사용자가 승인한 grant를 발급하며, 정책과 constraint를 강제한다. 두 번째는 SDK 계층으로, MCP와 함께 제공되어 Claude나 Cursor 같은 MCP 클라이언트에서 실험할 수 있다. 세 번째는 디렉터리 계층으로, 에이전트의 intent를 capability와 연결해 주는 장소다.
이 구조에서 SDK는 에이전트 키를 생성하고 신원을 부여하는 역할을 맡는다. 서버는 그 에이전트가 실제로 권한을 가지고 있는지 검증하고, 사용자 승인 또는 정책에 따라 grant를 발급한다. 디렉터리는 서비스별 capability를 탐색 가능하게 만들고, 에이전트가 무작정 모든 API를 호출하는 대신 명시된 capability를 따라 행동하도록 돕는다. 세 계층은 각각 별도의 역할을 갖지만, 함께 작동할 때 “발견, 인가, 신원”이라는 강연 초반의 세 문제를 하나의 프로토콜 흐름으로 묶는다.
강연자는 이 프로젝트가 open source이며, 더 많은 사람이 참여해 개선하기를 바란다고 말한다. 특히 V1에서 V2로 넘어가며 장기 실행 에이전트, 여러 에이전트, 기업 정책, 사용자 정책 같은 요소를 더 깊게 다루고 있다고 언급한다. 이는 에이전트 보안이 단기 데모를 넘어 실제 운영 환경의 문제로 확장되고 있음을 보여준다. 앞으로 에이전트가 단순한 챗봇이 아니라 지속적으로 실행되는 업무 주체가 된다면, identity와 policy 모델은 선택 사항이 아니라 기반 구조가 될 가능성이 크다.
AI Gateway와의 차이
질의응답에서는 AI Gateway와의 관계도 언급된다. 강연자는 AgentAuth가 기존의 게이트웨이 접근과 영감을 공유할 수는 있지만, 동일한 것은 아니라고 설명한다. 가장 큰 차이는 에이전트를 principal로 취급하는지 여부다. AI Gateway가 API 호출을 중계하거나 접근 정책을 적용할 수는 있어도, 각 에이전트에 독립된 신원을 부여하고 그 신원을 중심으로 전체 수명주기를 관리하지 않는다면 AgentAuth가 목표로 하는 감사 가능성과 revoke 모델에는 도달하기 어렵다.
이 차이는 기술 구현의 세부가 아니라 보안 모델의 철학에 가깝다. 게이트웨이 중심 모델은 “요청이 어디를 지나가는가”에 초점을 맞추는 반면, AgentAuth는 “누가 어떤 권한으로 행동하는가”에 초점을 맞춘다. 에이전트가 principal이 되면 권한은 사용자에게만 붙는 것이 아니라, 사용자와 에이전트와 호스트의 관계 속에서 결정된다. 이 관계 모델이 있어야 특정 에이전트를 추적하고, 제한하고, 폐기하고, 필요하면 조사할 수 있다.
강연자는 이 점을 “사용자인 척하지 말고, 사용자를 위해 정해진 한계 안에서 행동하라”는 문장으로 압축한다. 이 문장은 AgentAuth의 핵심 메시지에 가깝다. AI 에이전트가 더 많은 일을 맡게 될수록, 단순한 API 키 공유나 사용자 토큰 위임은 점점 더 위험해진다. 에이전트가 진짜 행위자가 되는 순간, 보안 시스템도 그 행위자를 독립적으로 식별하고 다룰 수 있어야 한다.
마무리 / 핵심 정리
이 강연은 AI 에이전트 보안을 “어떤 토큰을 줄 것인가”의 문제가 아니라 “에이전트를 어떤 행위자로 볼 것인가”의 문제로 재정의한다. 지금까지 많은 에이전트 통합은 사용자의 자격 증명을 빌려 사용자인 척하는 방식으로 동작했지만, 이 방식은 감사, 권한 회수, 세밀한 인가, 책임 추적에서 구조적 한계를 가진다. AgentAuth는 에이전트에게 독립된 identity를 부여하고, capability 단위로 권한을 제한하며, 디렉터리를 통해 서비스 기능을 발견하게 함으로써 이 한계를 줄이려 한다.
강연의 가장 실용적인 메시지는 “credentials가 아니라 authority를 주라”는 것이다. 사용자는 에이전트에게 자신의 계정 전체를 맡기는 대신, 필요한 작업과 조건을 명시한 권한을 위임해야 한다. 서비스는 에이전트가 사용자의 뒤에 숨지 않도록 agent ID, user ID, host, capability, 실행 결과를 기록해야 한다. 그렇게 해야 에이전트가 점점 더 자율적인 업무 주체가 되는 환경에서도, 우리는 편리함과 통제 가능성을 동시에 유지할 수 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Better Agent Auth — Bereket Habtemeskel & Paola Estefania, Better Auth |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-22 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.