It's 10pm. Do You Know Where Your Agents Are? — Kim Maida, Keycard

한 줄 핵심

에이전트에 API 키를 통째로 맡기면 과권한과 오남용 위험이 커지므로, OAuth 2 token exchange와 정책 기반 권한 축소로 작업별·주체별·단기 토큰을 발급해 안전하게 제어해야 한다.

시간별 요약

1. 0:01
   에이전트가 인간 대신 밤늦게 일을 처리하는 시대에는, “지금 내 에이전트가 어디서 무엇을 할 수 있는가”를 묻는 안전장치가 필요하다. API 키를 그대로 주면 에이전트는 의도와 다르게도 마음껏 실행할 수 있다.
2. 2:00
   장애 대응 예시에서 에이전트는 인증서 갱신, DB 삭제, 프로덕션 재시작, 비용 증가 같은 서로 다른 작업을 모두 같은 API 키로 수행할 수 있었다. 같은 자격증명이 여러 권한을 겸하면 에이전트는 도움이 되기도 하지만 쉽게 과권한 상태가 된다.
3. 6:02
   실행 경로는 사용자 입력 → runtime → LLM → MCP client → MCP server → resource로 이어지며, 보안은 이 경로의 중간에 넣어야 한다. 단순한 인간 승인만으로는 부족하고, 에이전트·사용자·요청 작업을 함께 식별하는 구조가 필요하다.
4. 8:02
   해결책은 authorization server와 RFC8693 token exchange를 이용해 사용자 동의 범위를 먼저 좁히고, 에이전트가 요청한 단일 작업에 대해서만 downstream access token을 발급하는 방식이다. 정책이 통과하지 못하면 토큰 자체가 발급되지 않으므로, 과권한 자격증명이 애초에 생기지 않는다.
5. 12:01
   이 방식으로 보면 각 작업은 필요한 scope만 받고, 금지된 작업은 정책 단계에서 차단되며, 인간 승인도 역할 기반 정책으로 제한된다. 결과적으로 토큰은 짧게 살고 버려지며, 키 재사용·유출·재생 위험이 크게 줄어든다.

실무 인사이트

• 에이전트 보안은 모델이 아니라 권한 발급 지점에서 해결해야 하므로, MCP와 resource 사이에 정책 검사를 두는 설계가 효과적이다.
• 기존 사용자 OAuth scope를 출발점으로 삼고, MCP tool call 전용 scope를 덧붙이는 방식이 초기에 가장 현실적이다.
• human-in-the-loop는 최종 안전망일 뿐이므로, 승인 자체에도 역할·정책 제한을 걸어야 consent fatigue를 막을 수 있다.