핵심 주장
Scalekit 공동창업자 Ravi Madabhushi가 던지는 핵심 메시지는 하나다 — "사람을 위해 설계된 인증/인가(auth) 아키텍처는 에이전트에서 근본적으로 무너진다." 지난 10년간 Freshworks에서 수백만 사용자를 대상으로 아이덴티티 플랫폼을 구축해온 그는, 지금까지의 인증 체계가 암묵적으로 전제해온 "인증하는 주체(principal)가 곧 행동하는 주체(actor)"라는 공식이 AI 에이전트 시대에는 더 이상 성립하지 않는다고 말한다. 사람과 API를 염두에 두고 설계한 시스템이라면, 에이전트를 위한 결정론적(deterministic) 가드레일과 초정밀 권한 제어를 처음부터 다시 설계해야 한다는 것이 발표의 결론이다.
주요 근거와 사례
- 트리거가 된 사건: Scalekit 팀이 자사 아이덴티티/인증 인프라의 지연시간(latency) 지표를 들여다보던 중, 15분마다 규칙적으로 스파이크가 발생하는 패턴을 발견했다. 원인은 "마지막 로그인/활동 시각(last seen)"을 기록하는 타임스탬프 업데이트였는데, 최근 12개월 사이 에이전트들이 API를 호출하면서 이 업데이트가 기존 대비 60배 빠른 빈도로 발생해 DB 쓰기 시스템에 불필요한 부하를 주고 있었다.
- 해결은 쉬웠지만 질문이 남았다: 초 단위로 배치 처리하면 되는 사소한 문제였지만, Ravi는 여기서 더 큰 의문을 품는다 — "우리가 인증/인가에 대해 세운 가정들 중 에이전트 때문에 통째로 재설계해야 할 것이 또 있지 않을까?"
- 기존 두 가지 신원 슬롯: 전통적 시스템은 (1) 사람이 웹/모바일 앱이나 자신이 짠 스크립트에 API 키를 부여해 접근하는 경우와, (2) SPIFFE·OAuth 기반의 서비스 계정처럼 기계 자체에 독립된 신원을 부여하는 경우, 이 두 가지 슬롯만 있었다. 두 슬롯 모두 "인증한 자 = 행동한 자"라는 동일한 전제 위에 서 있다.
- 결정론(determinism)이 지금까지 안전망이었다: 서비스 계정이든 API 키든, 기존 프로그램은 사람 개발자가 짠 코드대로 예측 가능하게 동작했다. 구글 개발자 계정에서 OAuth 클라이언트 ID/스코프를 신청하면 보안 리뷰에서 코드베이스를 검사하는 것도 바로 이 "프로그램이 정해진 대로만 동작한다"는 전제 덕분에 가능했던 절차다.
- 에이전트가 이 전제를 깨는 두 가지 지점: 첫째, 에이전트는 principal(사용자)과 actor(행동 주체)가 분리되는데, 다수의 시스템·MCP 서버가 여전히 OAuth의 "대리 행동(on-behalf-of)" 개념을 지원하지 않아 지금 행동하는 게 사람인지 에이전트인지조차 구분 못한다. 둘째, 에이전트는 사람이 직접 짠 결정론적 프로그램이 아니라 비결정적(probabilistic)으로 동작하므로, 오늘 특정 행동을 했다고 해서 내일도 같은 행동을 보장할 수 없다.
- MCP 서버의 구조적 결함: 현재 접해본 대부분의 MCP 서버는 인가한 사용자 맥락에 따라 도구(tool) 접근을 제한하지 않고, 사용자가 접근 가능한 모든 도구를 그대로 노출한 뒤 에이전트가 알아서 판단하도록 방치한다. 결과적으로 에이전트가 엉뚱한 도구를 고르고 잘못된 행동을 할 위험이 구조적으로 내재돼 있다.
- Gmail 스코프의 한계: Gmail 같은 대중적 애플리케이션조차 OAuth 스코프가 "이 클라이언트가 당신을 대신해 이메일을 보낼 수 있는가?" 수준으로만 존재한다. "특정 시간대에만 행동 가능한가", "특정 발신자로부터만 읽을 수 있는가", "특정 수신자에게만 보낼 수 있는가" 같은 세밀한 통제는 없다.
- 실제 고객 사례 — ref.tools: Scalekit 고객사 중 ref.tools는 애초에 사람 행위자가 존재하지 않는 제품이다. 코딩 에이전트에게 맥락을 제공하는 것이 제품의 본질이라, 처음부터 OAuth 스코핑 전체를 새로 설계했다. Ravi는 이 사례를 "미래의 경고"가 아니라 "이미 오늘의 문제"라는 근거로 제시한다.
- 실제로 벌어지고 있는 사고: 에이전트가 통제 범위를 벗어나 프로덕션 데이터베이스를 삭제하는 등의 사고가 이미 다수 관측되고 있다고 언급한다.
구체적 인사이트
- 발표 제목("You Didn't Ship a Bug. You Just Wrote It for a Human.")의 핵심은 — 지금 벌어지는 에이전트 오작동은 코드 버그가 아니라, 애초에 인간만을 행위자로 가정하고 설계된 인증/인가 아키텍처를 에이전트에게 그대로 물려준 설계상의 실수라는 것. 즉 문제는 구현이 아니라 아키텍처 전제 자체에 있다.
- 인증(authentication)과 인가(authorization)를 사람 기준으로 설계할 때는 "동일한 비밀번호/토큰을 제시하면 동일한 정체성"이라는 결정론적 검증이 성립했다. 에이전트에는 이 결정론이 없다 — 이것이 전체 문제의 근본 원인이다.
- 에이전트 권한 설계는 결국 두 가지 나쁜 선택지로 수렴하는 경향이 있다: (1) 에이전트에게 독립된 identity(OAuth의 client ID 개념)를 부여해 "이 사용자를 대신해 행동한다"고 명시하거나, (2) 에이전트가 사람 사용자 자체인 것처럼 행세하게 두는 것(더 위험한 쪽). 두 경로 모두 "사용자 A를 대신할 때"와 "사용자 B를 대신할 때" 에이전트가 서로 다른 세밀한 권한을 가져야 한다는 요구를 기존 OAuth 스코프 체계가 충족하지 못한다.
- 개발자가 부주의해서가 아니라, 기존 권한 관리 프리미티브 자체가 세밀한(fine-grained) 권한 부여를 지원하지 않기 때문에 "필요 이상으로 넓은 권한을 에이전트에게 주는 것"이 업계 기본 패턴이 되어버렸다는 지적이 핵심이다. 이는 개인의 실수가 아니라 시스템/도구의 구조적 결함으로 봐야 한다는 프레이밍이다.
- 에이전트는 "최소 권한(least privilege)이 기본값"이어야 하고, 더 넓은 권한이 필요하면 그때그때 즉시 승인(just-in-time authorization)을 요청하는 구조가 되어야 한다는 원칙을 제시한다.
- "기도는 전략이 아니다(praying is not a strategy)" — 에이전트가 어떤 행동을 할 수 있고 할 수 없는지 결정론적으로 통제하지 못한 채 운영하는 것은, 사고가 나지 않기를 바라며 방치하는 것과 다름없다는 경고로 발표를 마무리한다.
실행 포인트
- 사람/API 중심으로 설계된 인증·인가 시스템을 그대로 에이전트에 확장해 쓰고 있다면, 지금 바로 "인증 주체 = 행동 주체" 전제가 깨지는 지점부터 점검할 것.
- 에이전트에는 반드시 독립된 identity를 부여하고, 어떤 사용자를 대신해 행동하는지(on-behalf-of)를 시스템 전체에서 항상 추적 가능하게 만들 것 — 이게 안 되면 지금 행동하는 게 사람인지 에이전트인지조차 구분할 수 없다.
- MCP 서버나 내부 도구 계층을 설계할 때, 사용자가 접근 가능한 모든 도구를 에이전트에 그대로 노출하지 말고 인가된 맥락 기준으로 도구 노출 자체를 제한할 것.
- 권한 스코프를 "이 기능을 쓸 수 있는가" 수준이 아니라 시간대·발신자/수신자·속성(attribute) 단위의 초세밀 스코핑으로 재설계할 것. 기존 OAuth 스코프만으로는 부족하며, 그 위에 추가 레이어가 필요하다.
- 기본값은 최소 권한으로 설정하고, 확장 권한이 필요한 순간에만 즉시(Just-In-Time) 승인을 받는 구조를 도입할 것.
- 시스템 내 모든 행동에 대해 "누가(에이전트/사람), 누구를 대신해서, 언제 승인받았는지, 어떤 권한을 얼마 동안 부여받았는지"를 완전히 가시화(visibility)할 것 — 이 로그/추적 체계가 없으면 사고 예방이 아니라 사고 대응만 가능하다.
- 에이전트 전용 제품(코딩 에이전트 지원 도구 등 사람 행위자가 아예 없는 제품)을 만든다면 ref.tools처럼 처음부터 OAuth 스코핑을 에이전트 중심으로 새로 설계할 것 — 기존 사람 중심 패턴을 재활용하지 말 것.