Stop Giving Your AI Agents API Keys - Kim Maida, Keycard & Mason Egger, Temporal

한 줄 핵심

에이전트에 API 키를 직접 주는 대신 token exchange로 사용자·에이전트·도구의 신원을 분리하고, Temporal로 그 실행을 중단 없이 복구 가능하게 만들어야 안전하고 신뢰할 수 있다.

시간별 요약

1. 0:00
   소개 Keycard는 에이전트의 런타임 접근 신원과 권한 관리를, Temporal은 에이전트까지 포함한 애플리케이션의 durable execution을 제공한다. 워크숍은 공유 조직과 샌드박스 환경에서 진행되며, 사전 가입 없이 따라갈 수 있다.
2. 1:17
   에이전트에 API 키를 주는 문제 API 키를 에이전트에 직접 주면 사용자나 에이전트의 신원을 구분할 수 없고, 키가 가진 모든 권한이 그대로 노출된다. 또한 사람의 개입에만 의존할 수 없기 때문에 자율 실행 에이전트에는 더 정교한 접근 통제가 필요하다.
3. 1:59
   token exchange 설명 token exchange는 OAuth 2 위에서 사용자 신원과 위임 범위를 단계적으로 전달하는 표준이다. 사용자가 먼저 로그인하고, 동의한 scope만 에이전트에 위임되며, 그 결과 사용자와 권한 수준이 포함된 토큰이 발급된다.
4. 3:10
   에이전트 루프를 따라가기 에이전트는 LLM 호출과 도구 호출을 반복하는 제어 루프이며, 여기서는 expense desk agent가 예시다. 사용자 요청은 런타임, MCP client/server, ledger API를 거치며, 각 단계에서 토큰이 다음 홉으로 교환되어 전달된다.
5. 5:41
   도구 호출마다 별도 토큰 발급 각 tool call마다 필요한 범위로만 제한된 토큰을 새로 발급받아야 한다. 에이전트와 사용자의 신원, 위임 체인이 정책에 부합할 때만 MCP 서버용 토큰과 그 다음 ledger API용 토큰이 순차적으로 발급되고, 사용 후 즉시 폐기된다.
6. 8:49
   워크숍 환경 설정: expense desk agent 실습은 로그인 없이 시작되는 expense desk agent를 기준으로 진행되며, 모든 참가자가 같은 Keycard 조직을 공유한다. 필요 시 관리 권한을 부여받아 콘솔에서 직접 설정과 실습을 따라가게 된다.
7. 10:28
   변경 전: 모두가 API 키를 공유 초기 상태에서는 누가 요청했는지 알 수 없고, 모든 작업이 같은 MCP 서버와 API 키를 통해 처리된다. 지출 생성·승인 기록에도 사람이나 에이전트의 정체성이 남지 않아 감사 추적이 불가능하다.
8. 12:51
   에이전트에 고유한 신원 부여 Keycard에서 application과 resource를 등록해 에이전트가 토큰을 요청하고 동시에 토큰의 수신 대상이 되도록 구성한다. 이후 dependencies에 MCP 서버, LLM API, user info endpoint를 연결하고, client ID와 secret으로 에이전트가 자기 자신을 인증하게 만든다.
9. 21:47
   코드에 token exchange 연결 설정만으로는 부족하고, 실제 에이전트 코드가 토큰 교환을 수행하도록 연결해야 한다. MCP tool set과 mint 함수가 도구 호출마다 적절한 토큰을 발급하며, 로그인한 사용자가 없으면 client credentials grant로 에이전트 자신이 인증한다.
10. 26:05
    에이전트가 자기 자신으로 동작하기 로그인 사용자가 없을 때는 에이전트가 자기 신원으로 실행되며, approval limit 같은 권한도 그 에이전트 계정 기준으로 적용된다. 지출은 사용자 지시를 바탕으로 생성되지만, 실제 기록상으로는 에이전트 자신의 행위로 남는다.
11. 28:00
    감사 로그 읽기 Keycloak의 활동 기록에서 어떤 주체가 어떤 자원에 접근했는지 확인할 수 있다. 여기서는 agent application이 MCP 자원에 접근한 기록과, 그 뒤 MCP 서버가 ledger API로 토큰을 교환한 흔적이 남아 delegation chain으로 보인다.
12. 31:22
    임퍼서네이션 없이 인간 사용자 추가 이제 에이전트가 사람을 가장하지 않고, 실제 인간 사용자의 신원을 포함한 상태로 동작하게 만든다. 로그인한 사용자의 이메일과 approval limit이 식별되며, 과거에 생성된 항목은 그대로 남아 있고 이후부터만 인간 사용자 맥락이 반영된다.
13. 34:01
    승인 한도와 승인 주체 에이전트는 일정 금액 이하의 지출은 자체적으로 승인할 수 있지만, 한도를 넘으면 사람의 검토가 필요하다. 기록에는 누가 생성했고 누가 승인 또는 거절했는지가 명확히 남아, 에이전트가 자기 자신의 비용은 승인하지 못하게 된다.
14. 38:09
    위임 체인 추적 첫 번째 홉에서는 사용자의 sign-in token이 MCP 서버용 토큰으로 교환되고, 두 번째 홉에서는 MCP 서버가 그 토큰을 가지고 ledger API용 토큰을 발급받는다. session 번호를 통해 각 홉을 이어서 추적할 수 있어, 누가 누구를 대신해 어떤 자원에 접근했는지 끝까지 따라갈 수 있다.
15. 41:26
    에이전트를 위한 Temporal의 durable execution Temporal은 워크플로와 activity로 분리된 실행 상태를 유지해, 중간 실패가 나도 애플리케이션을 복구하고 이어서 실행한다. 에이전트 루프도 결국 분산 시스템의 반복 실행이므로, 실패 복구와 재시도가 가능한 실행 계층이 필요하다.
16. 46:01
    작업자 강제 종료 후 복구 작업자를 실행 중간에 강제로 종료해도 Temporal은 이미 저장된 상태를 바탕으로 워크플로를 재개한다. LLM 호출이나 이전 activity를 다시 수행하지 않고도 마지막 지점부터 이어서 처리하며, 사용자 입장에서는 장애를 거의 느끼지 않을 수 있다.
17. 48:07
    에이전트에서 내구성이 중요한 이유 에이전트는 긴 루프와 많은 외부 호출로 구성되며, 그 과정에서 상태 손실은 비용과 실패를 크게 키운다. durable execution을 쓰면 LLM 제공자 장애, 지역 장애, 프로세스 실패가 나도 마지막 지점에서 바로 재개할 수 있다.
18. 49:28
    이벤트 히스토리에서 비밀정보 숨기기 Temporal의 이벤트 히스토리에는 민감한 JWT나 비밀값이 남지 않도록 해야 한다. 이를 위해 interceptor로 just-in-time 주입을 하거나, payload encoder로 저장 데이터를 암호화해 실행 기록과 비밀정보를 분리할 수 있다.

실무 인사이트

• 에이전트 권한은 API 키 하나로 묶지 말고, 사용자·에이전트·자원별로 분리된 token exchange 체인으로 관리해야 감사와 최소권한 원칙을 동시에 만족한다.
• 도구 호출마다 짧게 살아 있는 scoped token을 발급하고 즉시 폐기하면, MCP 서버와 하위 API까지 권한 확산을 크게 줄일 수 있다.
• 에이전트 운영에서는 보안만큼이나 실행 복구가 중요하므로, durable execution과 비밀정보 비노출 설계를 함께 적용해야 실제 서비스 품질이 나온다.