인증은 당신이 누구인지 확인하고, 인가는 당신이 무엇을 할 수 있는지 결정합니다. 점점 더 많은 AI 기반 애플리케이션이 로그인 시 한 번만 사용자의 신원을 확인한 뒤, 세션이 유지되는 동안 기본 에이전트가 모든 리소스에 대해 작업할 수 있도록 허용하며, 사실상 에이전트에게 "백지 수표"를 건네주는 방식을 취하고 있습니다. 이러한 설계는 의도치 않은 데이터 유출, 원치 않는 이메일 발송, 심지어 파괴적인 데이터베이스 업데이트로 이어지는 문을 열어주며, AI 어시스턴트가 밀리초 단위의 지연 시간으로 여러 도구를 호출할 수 있게 됨에 따라 그 위험은 더욱 커집니다.
왜 이 실수가 반복되는가
대부분의 AI 개발자는 로그인 화면을 유일한 보안 관문으로 취급합니다. 코드는 비밀번호나 토큰을 요청하여 세션을 "인증됨"으로 표시한 뒤, 이후의 모든 요청이 안전하다고 가정합니다. 전통적인 웹 앱에서는 인간 사용자의 느린 클릭이 자연스러운 속도 제한(throttling) 역할을 합니다. 사람은 "삭제"를 누르기 전에 잠시 멈칫하기 때문입니다. 하지만 AI 에이전트는 몇 초 만에 수십 개의 도구 호출을 실행할 수 있습니다. 플랫폼이 "사용자가 로그인했는가?"만을 묻는다면, 각 호출은 동일한 무제한 권한을 상속받게 됩니다.
근본 원인은 편의성입니다. 팀들은 코드에서 여러 토큰이나 범위를 관리할 필요가 없도록 애플리케이션 전체에 대해 단일한 장기 서비스 계정을 할당하는 경우가 많습니다. 해당 계정은 일반적으로 모든 프로젝트에 대해 읽기, 쓰기, 삭제와 같은 광범위한 권한을 가집니다. AI 어시스턴트가 해당 세션 내에서 실행되면, 현재 작업에 실제로 해당 권한이 필요한지 여부와 관계없이 자동으로 그 권한을 상속받습니다.
무엇이 위태로운가
- 데이터 노출 – 사용자가 로그인한 후 어떤 파일이든 읽을 수 있는 에이전트는 기밀 문서를 의도치 않게 응답에 포함시켜 나중에 조직 외부로 공유될 위험이 있습니다.
- 의도치 않은 작업 – 지원 엔지니어의 AI 도우미는 엔지니어의 세션이 활성화되어 있다는 이유만으로, 현재 처리 중인 티켓과 관련이 없는 쿼리임에도 불구하고 운영 데이터베이스에 직접 SQL 쿼리를 실행할 수 있습니다.
- 규제 준수 – 많은 데이터 보호 규정은 액세스 권한을 최소한의 필요 범위로 제한할 것을 요구합니다. 포괄적인 권한 모델은 이러한 원칙을 위반하여 감사나 벌금으로 이어질 수 있습니다.
- 운영 비용 – 레코드를 삭제하거나 수정하는 실수는 팀이 변경 사항을 롤백하고, 근본 원인을 조사하며, 사용자와의 신뢰를 다시 구축하게 만듭니다. 이 모든 과정은 시간과 비용을 낭비합니다.
누락된 단계: 작업별 인가
인가는 시스템의 정문뿐만 아니라 내부의 모든 "문"에서 평가되어야 합니다. 질문은 "이 사람이 누구인가?"에서 "지금 이 특정 리소스에 대해 이 특정 작업을 수행해도 되는가?"로 바뀌어야 합니다. 이러한 확인 절차를 구현하는 데 전체적인 재설계가 필요한 것은 아닙니다. 단일 세션 플래그에서 수명이 짧고 범위가 지정된(scoped) 토큰으로 전환하기만 하면 됩니다.
실제 작동 방식
- 정의된 범위를 가진 토큰 요청 – AI 에이전트가 도구를 호출해야 할 때, 먼저 필요한 정확한 권한(예:
read:ticket,execute:sql_query)이 나열된 토큰을 획득합니다. - 각 호출에 대해 토큰 검증 – 도구가 실행되기 전에 서비스는 토큰에 필요한 범위가 포함되어 있는지, 토큰이 만료되지 않았는지 확인합니다.
- 리소스와 범위 일치 – 요청이 특정 프로젝트나 데이터베이스를 대상으로 하는 경우, 토큰은 해당 식별자에 대한 액세스 권한을 명시적으로 부여해야 합니다.
- 거부 또는 허용 – 확인 절차 중 하나라도 실패하면 호출이 거부되며, 에이전트는 사용자에게 전달할 수 있는 오류를 받게 됩니다.
코드의 차이는 명확합니다. "나쁜" 접근 방식은 다음과 같을 수 있습니다:
if session.is_authenticated():
tool.run(params)
"좋은" 접근 방식은 확인 절차를 확장합니다:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
두 번째 패턴은 몇 줄의 코드가 추가되지만, 시스템이 모든 작업에 대해 올바른 질문을 던지도록 강제합니다.
더 쉽게 만들어주는 표준들
OAuth 2.0 범위(scopes)는 이미 토큰이 할 수 있는 일을 제한하는 널리 채택된 방식을 제공합니다. project:1234:write 또는 email:send와 같은 범위를 인코딩한 수명이 짧은 액세스 토큰을 발행함으로써, 개발자는 기존 라이브러리를 사용하여 검증 단계를 수행할 수 있습니다.
최신 기술인 Rich Authorization Requests (RFC 9396)는 이 개념을 확장하여, 클라이언트가 정적인 목록을 미리 정의하는 대신 런타임에 세분화된 권한을 요청할 수 있도록 합니다. 이러한 유연성은 AI 워크플로가 사용자의 의도에 따라 기능을 즉석에서 추가하거나 제거해야 할 때 유용합니다.
반론: 단순성 대 보안
일부 팀에서는 특히 AI 어시스턴트가 여러 도구를 빠르게 연속적으로 호출해야 하는 경우, 작업별(per-action) 확인 절차가 지연 시간과 코드 복잡성을 증가시킨다고 주장합니다. 이들은 단일 세션 토큰을 사용하면 각 호출마다 새로운 토큰을 가져오고 검증하는 오버헤드를 피할 수 있다는 점을 지적합니다. 하지만 그 대가로 오용에 노출될 위험이 급격히 높아집니다. 현대적인 토큰 검증 서비스는 마이크로초 단위로 작동하도록 설계되었으며, 최소 권한 원칙을 저해하지 않으면서도 추가적인 네트워크 왕복(round-trip)을 배치 처리하거나 캐싱할 수 있습니다. 데이터 무결성과 컴플라이언스가 타협할 수 없는 필수 요소인 환경에서는, 약간의 성능 비용보다 위험 감소로 얻는 이득이 훨씬 더 큽니다.
향후 주목해야 할 사항
- AI SDK의 스코프 기반 토큰(scoped tokens) 도입 – 주요 AI 플랫폼 툴킷의 업데이트를 주시하십시오. 많은 툴킷이 OAuth 기반 스코프를 위한 헬퍼 함수를 제공하기 시작했습니다.
- Policy-as-code 프레임워크 – 새롭게 등장하는 솔루션들은 팀이 선언적 파일에 권한 부여 규칙을 정의하면 런타임에 이를 자동으로 적용할 수 있게 해줍니다.
- 작업별 결정 사항을 드러내는 감사 로그(Audit logs) – 더 많은 플랫폼이 각 권한 확인 절차를 기록함에 따라, 조직은 어떤 AI 작업이 허용되거나 차단되는지에 대한 가시성을 확보하게 되며, 이는 향후 정책을 미세 조정하는 데 도움이 될 것입니다.
핵심 요약
로그인된 세션을 모든 것을 수행할 수 있는 권한으로 간주하는 것은 의도치 않은 결과를 초래하는 지름길입니다. 권한 부여 결정을 로그인 시점이 아닌 개별 도구 호출 시점으로 옮기고, 수명이 짧은 스코프 기반 토큰을 활용함으로써, AI 애플리케이션은 자율 에이전트의 편의성을 유지하면서도 데이터를 보호하고 규정을 준수하며 비용이 많이 드는 사고를 방지할 수 있습니다. 작업이 시도될 때마다 올바른 질문을 던지는 시스템을 구축하기 위해 추가되는 몇 줄의 코드는 그리 큰 비용이 아닙니다.