Full Workshop: Better Auth — Paola Estefania, Better Auth

한 줄 핵심

이 워크숍은 에이전트를 사용자처럼 가장한 도구가 아니라, 고유한 identity와 권한·감사 추적을 가진 주체로 다루어야 안전하게 Gmail·캘린더 같은 민감한 서비스에 연결할 수 있다고 주장한다.

시간별 요약

1. 0:12
   핵심 문제의식은 에이전트가 사용자를 대신해 행동하면서도 사실상 사용자의 자격증명을 쓰는 구조가 위험하다는 점이다. 따라서 에이전트에게는 사용자 credentials가 아니라 에이전트 authority를 주는 방향으로 사고를 바꿔야 한다.
2. 5:01
   첫 번째 해법은 에이전트가 무엇을 할 수 있는지 자동으로 발견하는 discovery 구조다. 서비스의 capabilities를 phone book처럼 directory에 공개하고, intent를 적절한 capability와 매칭해 에이전트가 임의로 모든 도구에 접근하지 않게 만든다.
3. 8:01
   두 번째 해법은 authorization을 세분화하는 것이다. read 같은 넓은 scope 대신 capability 단위로 읽기, 쓰기, 삭제를 분리해 허용하며, 필요하면 수동 등록도 가능하게 해 현재의 OpenAPI 기반 서비스와도 연결된다.
4. 17:00
   세 번째 해법은 identity와 traceability다. 각 agent에 private key와 고유 ID를 부여해 토큰 서명과 감사 로그를 남기고, 어떤 agent가 어떤 user를 대신해 무엇을 했는지 추적하며 필요할 때 revoke할 수 있게 한다.
5. 22:01
   구현 구조는 agent plugin, SDK, directory의 3층으로 나뉜다. server side에서는 권한과 제약을 검증하고, SDK와 MCP는 agent를 연결하며, directory는 intent와 capabilities를 매칭하는 중심 역할을 한다.
6. 30:00
   데모는 이메일 읽기와 보내기를 통해 권한 통제가 실제로 동작함을 보여준다. 읽기만 허용된 상태에서는 send email이 차단되고, 승인된 capability만 실행되며, revoke 후에는 동일 agent의 접근이 끊겨 통제 가능성이 확인된다.

실무 인사이트

• 에이전트 보안은 프롬프트 수준이 아니라 identity, capability, 감사 로그를 묶은 하네스 설계로 풀어야 실효성이 있다.
• 실무에서는 모든 권한을 한 번에 주기보다 read-only 기본값과 capability별 승인을 조합해 최소 권한 원칙을 적용하는 것이 안전하다.
• 조직 도입 시에는 revoke, host 정책, 사용자별 정책까지 포함한 운영 모델을 먼저 정해야 나중에 에이전트 확산에도 통제가 유지된다.