Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard

한 줄 핵심

에이전트 인증·인가를 사용자 토큰이나 단순 SDK에 맡기면 권한 추적과 폐기가 어려워지므로, 에이전트 신원·위임·정책·감사를 갖춘 게이트웨이 중심의 보안 계층이 필요하다는 점을 설명한다.

시간별 요약

1. 0:00
   소개 발표 범위는 에이전트 인증·인가의 핵심 요구사항을 넓게 훑고, 실무에서 어떻게 풀 수 있는지와 질문할 때 볼 포인트를 제공하는 데 맞춰져 있다.
2. 0:43
   에이전트는 오늘 어떻게 자격 증명을 얻는가 현재는 사용자 PAT나 정적 API key, 서비스 계정이 뒤섞여 쓰이며, MCP server는 호출 주체가 사람인지 에이전트인지 구분하지 못하는 경우가 많다. 이 때문에 에이전트가 도구 호출을 통해 실제로 어떤 작업을 했는지 책임 소재가 흐려진다.
3. 3:46
   이 그림의 문제점 흩어진 자격 증명은 사용자 기기로 쉽게 이동하고, 폐기도 어렵고, 에이전트가 권한을 계속 쌓아 가는 구조를 만든다. 비결정적인 에이전트가 권한을 가진 채 동작하는 순간, 기존의 서비스 계정 문제는 더 큰 보안 위험으로 바뀐다.
4. 5:15
   에이전트에 OAuth를 적용하기 에이전트가 먼저 스스로 인증하고, 필요한 작업에 한해 동적으로 범위가 제한된 토큰을 발급받는 방식이 가능하다. OAuth, workload identity federation, 인증서, URL 기반 인가 등 어떤 메커니즘이든 핵심은 에이전트가 시스템에 먼저 신원 증명을 하도록 만드는 것이다.
5. 7:10
   규모가 커지면 왜 어려워지는가 실제 환경에서는 수백 개 API, 여러 종류의 에이전트, 여러 단계의 위임 흐름, 그리고 수많은 사용자 동의가 동시에 등장한다. 규모가 커질수록 단일한 인증 방식이 아니라, 서로 다른 시스템과 에이전트 유형을 모두 포괄하는 설계가 필요해진다.
6. 8:21
   올바른 에이전트 인증에 필요한 것 에이전트별 신원, 위임 의미론, 범위가 좁고 수명이 짧은 자격 증명, 연합 신뢰, 레거시 자격 증명을 중계하는 적응형 계층, 정책 표현, 감사 기능이 모두 필요하다. 즉, 인증만이 아니라 누가 어떤 행동을 허용받았는지와 그 근거를 함께 관리해야 한다.
7. 9:52
   하나의 요청, 여러 단계 클라이언트와 서버의 발견, 에이전트 인증, 토큰 검증, 정책 집행, 외부 시스템용 추가 자격 증명 획득, 감사 로그 기록까지 한 번의 상호작용에 여러 단계가 들어간다. 이 복잡성을 매번 LLM에 맡기는 것은 현실적이지 않으며, 공통화된 라이브러리나 미들웨어가 필요해진다.
8. 11:16
   SDK만으로는 부족한 이유 SDK는 채택률, 다중 언어 지원, 수정 불가능한 에이전트, 버그 추적 문제를 모두 해결하지 못한다. 특히 에이전트는 자격 증명을 캐시하거나 악용할 수 있으므로, 클라이언트 사이드 코드만으로 안전하게 통제하기 어렵다.
9. 12:37
   게이트웨이: 자격 증명을 에이전트에서 떼어내기 자격 증명을 실행 환경 밖의 안전한 저장소에 두고, 게이트웨이가 호출을 가로채 필요한 시점에만 자격 증명을 주입하는 구조가 제안된다. 이렇게 하면 즉시 폐기, 세분화된 권한 축소, 네트워크 경로 기반 가시성을 얻고, 다운스트림 서비스를 바꾸지 않아도 된다.
10. 14:55
    게이트웨이의 트레이드오프 게이트웨이는 지연 증가, 강제 경로 설정, 로컬 도구 실행의 사각지대, 신원 문제 미해결, 단일 병목과 공격 표면 확대 같은 비용을 수반한다. TLS 처리와 라우트·정책·커넥터 운영도 별도의 복잡성을 만든다.
11. 16:24
    Keycard의 접근 방식 Keycard는 에이전트 신원, 토큰 발급, 연합, 정책, 감사, 클라이언트·서비스 SDK, 필요 시 게이트웨이를 하나의 제어 평면에서 제공한다. 즉, 채팅 앱이든 오케스트레이션 플랫폼이든 필요한 보안 기능만 골라 조합할 수 있게 설계되어 있다.
12. 17:26
    핵심 정리 에이전트 인증은 더 이상 선택 사항이 아니며, 오픈 표준과 상호운용성을 바탕으로 설계해야 한다. LLM이 보안을 알아서 구현해 주지 않으므로, 구현된 코드가 실제로 안전한지 검증하는 과정까지 포함해야 한다.

실무 인사이트

• 에이전트 보안 설계는 '누가 호출했는가'보다 '누가 그 행동을 승인했는가'까지 추적하는 방향으로 바꿔야 한다.
• 단순한 토큰 전달보다 게이트웨이·정책·감사를 결합한 구조가 레거시 시스템을 바꾸지 않고도 통제력을 높이는 현실적 해법이다.
• SDK는 편의 도구일 뿐이며, 에이전트의 비결정성과 악용 가능성을 막으려면 네트워크 경로와 자격 증명 수명 자체를 통제해야 한다.