You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit

한 줄 핵심

인간과 API를 전제로 만든 인증·권한 구조는 에이전트의 비결정적 행동을 제대로 통제하지 못하므로, 에이전트에는 더 세밀한 권한, 주체-행위자 분리, 그리고 완전한 감사 추적이 필요하다.

시간별 요약

1. 0:00
   인간 중심으로 설계된 시스템은 에이전트가 들어오면 예상보다 훨씬 높은 빈도와 다른 패턴의 호출을 만들어 성능과 데이터베이스 쓰기 부담을 키운다. 단순한 지연 문제를 넘어, 인증·인가 자체를 다시 설계해야 한다는 문제의식으로 이어진다.
2. 2:01
   기존의 인증 모델은 주로 인간 사용자나 인간이 작성한 결정적 프로그램을 전제로 한다. 그러나 최근의 에이전트는 Salesforce, Databricks, HubSpot, Notion 같은 외부 데이터와 결합되며, 필요 이상으로 넓은 권한을 기본값처럼 받아 가는 경향이 있다.
3. 4:01
   기존 방식은 인증하는 주체와 실제로 행동하는 주체가 같다는 가정 위에 서 있다. 비밀번호, API key, 세션 토큰, service account 모두 등록 시점의 고정 권한으로 동작하며, 개발자가 작성한 결정적 코드라서 행위를 검토하고 통제할 수 있다.
4. 7:01
   에이전트는 주체와 행위가 분리되고, 같은 입력에도 다음 순간 다른 행동을 할 수 있는 비결정성을 가진다. 그래서 단일 identity만 부여하는 방식이나 user 자체처럼 취급하는 방식은 모두 부족하며, 사용자 맥락에 묶인 위임 권한이 필요하다.
5. 9:01
   MCP 서버와 같은 도구 표면은 사용자 권한 전체를 그대로 노출하기보다, 에이전트가 승인된 사용자와 목적에 맞는 도구만 보게 해야 한다. 이를 위해서는 시간·수신자·속성·컨텍스트 수준의 세밀한 스코프, least privilege, just-in-time authorization, 그리고 누가 무엇을 언제 누구를 대신해 허가했는지에 대한 추적이 필수다.
6. 11:00
   에이전트 오작동은 미래의 경고가 아니라 이미 운영 환경에서 발생하는 현재의 문제다. 따라서 인간용 보안 모델을 그대로 얹는 대신, 에이전트의 자율성과 위험을 전제로 한 결정적 가드레일과 가시성을 지금 구축해야 한다.

실무 인사이트

• 에이전트를 붙일 때는 먼저 "누가 인증했는가"보다 "누가 어떤 맥락에서 무엇을 대신 할 수 있는가"를 기준으로 권한 모델을 재설계해야 한다.
• MCP 서버나 도구 목록은 전부 노출하지 말고, 사용자·목적·시간 조건에 따라 동적으로 축소하는 구조를 넣어야 잘못된 도구 선택과 과권한 문제를 줄일 수 있다.
• 운영 환경에서는 모든 에이전트 행위에 대해 주체, 대리 관계, 승인 시점, 승인 범위, 만료 시점을 남겨야 사후 대응과 감사가 가능하다.