이 요청을 보낸 사람은 누구인가요? 에이전트 인증 101 - Kamil Potrec, Keycard

하이라이트

• 에이전트는 비결정론적으로 작동하므로 사용자의 자격 증명을 가졌을 때 수행할 작업을 예측할 수 없다.

• 에이전트가 서비스 계정과 영구적인 권한을 직접 축적하는 구조는 보안 취약점을 유발한다.

• 워크로드 아이덴티티 연동이나 개인키 인증을 활용해 에이전트가 작업 수행 전에 인증을 거치도록 해야 한다.

• 자격 증명을 에이전트 실행 환경에서 분리해 안전한 엔클레이브나 볼팅 서비스에 보관해야 한다.

• 게이트웨이 패턴을 도입하면 모든 요청을 즉시 검사하여 수명이 짧은 자격 증명을 관리하고 즉각적인 폐기가 가능하다.

타임라인

1. 00:00 - 05:14

   에이전트 인증 및 자격 증명 관리의 한계

   에이전트가 모델 제공자와 통신하거나 원격 MCP 서버를 호출할 때 다양한 자격 증명이 사용된다. 하지만 이러한 토큰들은 사용자의 개인용 컴퓨터 등에 방치되기 쉬우며, 취소할 방법이 마땅치 않아 남용의 위험에 노출된다. 특히 에이전트는 전통적인 소프트웨어와 달리 스스로 판단하여 행동을 결정하기 때문에, 송장 확인 등의 작업에서 에이전트가 직접 민감한 정보를 외부로 유출하더라도 요청 주체를 명확히 판별하기 어렵다.

   • 에이전트와 사용자가 소통할 때 사용하는 액세스 토큰은 보통 어디에도 귀속되어 있지 않다.
   • MCP 서버는 다중 사용자를 대신해 행동하기 위해 서비스 계정을 사용하며, 이는 특권을 가진 권한의 덩어리가 된다.
   • 에이전트는 비결정론적이므로 가져온 데이터를 바탕으로 예기치 않은 동작을 수행할 수 있다.
2. 05:14 - 12:31

   동적 자격 증명과 페더레이티드 트러스트의 필요성

   사용자가 직접 액세스 토큰을 관리하는 끔찍한 사용자 경험을 없애고, 에이전트가 외부 시스템에 권한 부여를 요청할 수 있는 구조를 만들어야 한다. OAuth와 워크로드 아이덴티티 연동 기술을 사용하면 에이전트에게 영구적인 권한을 부여하는 대신 필요한 시점에만 동적이고 수명이 짧은 자격 증명을 발급할 수 있다. 다만 수많은 레거시 시스템과 다양한 에이전트가 공존하는 대규모 환경에서는 시스템 간 신원을 연동하고 정책과 감사 기능을 함께 갖추는 것이 필수적이다.

   • 에이전트가 직접 액세스 토큰을 찾아 헤매는 대신 동적 자격 증명을 발급받아야 한다.
   • 워크로드 아이덴티티 연동이나 개인키 인증을 통해 에이전트가 자격 증명을 받기 전 인증을 거쳐야 한다.
   • 수백 개의 서로 다른 시스템이 존재하는 환경에서 페더레이티드 트러스트를 구축해야 한다.
3. 12:31 - 18:26

   게이트웨이 기반의 제어 플레인과 보안 아키텍처

   에이전트가 자격 증명을 직접 인지하고 악용하는 문제를 막기 위해, 모든 자격 증명을 실행 환경 외부의 안전한 엔클레이브에 보관한다. 에이전트가 통신할 때 게이트웨이를 경유하게 만들면 호출 주체를 인증하고 정책을 검증한 뒤 자격 증명을 요청 경로에 주입할 수 있다. 이를 통해 다운스트림 서비스의 코드를 변경하지 않고도 관측 가능성을 높이고 불필요한 권한 요청을 차단할 수 있다. 에이전트 보안은 선택이 아니며, 개방형 표준과 레퍼런스 구현체를 활용해 안전하게 구축해야 한다.

   • 자격 증명을 에이전트 실행 환경 밖의 안전한 볼팅 서비스로 옮겨야 한다.
   • 게이트웨이를 거치도록 강제하면 요청을 즉시 검사하여 즉각적인 폐기와 세밀한 범위 축소가 가능하다.
   • Keycard는 에이전트 신원, 토큰 발급, 정책, 감사를 통합 관리하는 제어 플레인을 제공한다.