Your AI Agent Shouldn't Hold Your OAuth Tokens

개요

AI 에이전트의 보안 강화를 위해 OAuth 토큰과 같은 민감한 자격 증명을 에이전트 자체에서 분리하여 관리하는 새로운 접근 방식이 제시됩니다. OpenConnector 프로젝트를 예시로 들어, 인증 및 제공업체별 실행을 커넥터 게이트웨이 뒤에 배치하고 명시적인 Action 계약을 통해 에이전트가 작동하도록 하는 방안을 설명합니다.

주요 내용

• AI 에이전트가 다양한 서비스(Gmail, GitHub, Notion, Slack 등)와 연동될수록 보안 취약성이 증가하며, 특히 OAuth 리프레시 토큰과 같은 민감한 자격 증명의 관리 문제가 중요해집니다.
• API 키를 환경 변수에 저장하는 방식은 소규모 스크립트에는 적합하지만, 다수의 사용자 계정과 연동되는 제품에는 취약한 아키텍처 경계가 됩니다.
• 제안된 접근 방식은 커넥터 게이트웨이를 통해 인증 및 제공업체별 실행을 분리하고, 에이전트가 명시적인 Action 계약을 사용하도록 합니다.
• 에이전트는 어떤 Action을 사용할지, 어떤 입력이 필요한지, 어떤 출력이 반환되는지 등 Action의 계약만 알면 되며, 실제 인증에 사용되는 개인 액세스 토큰(PAT)과 같은 민감한 정보는 알 필요가 없습니다.
• 커넥터 게이트웨이는 자격 증명 저장 및 로테이션, Action 제한, 계정 분리, 실행 검사 등을 위한 단일 지점을 제공하여 관리 용이성을 높입니다.
• OpenConnector는 API 키, OAuth 2.0, 사용자 지정 인증 등 다양한 인증 방식을 지원하며, 제공업체 Action 카탈로그, 명명된 연결, Action 허용/차단 정책, 실행 기록 검사 기능 등을 제공합니다.
• 로컬 환경에서 OpenConnector를 실행하고 Hacker News의 no-auth Action을 호출하는 방식으로 기본적인 사용법을 테스트할 수 있습니다.
• GitHub와 같은 인증이 필요한 Action의 경우, 커넥터 게이트웨이에 연결 정보를 저장하고 에이전트는 해당 정보를 직접 사용하지 않고 Action을 실행할 수 있습니다.
• OOMOL-hosted connectors는 OAuth 앱 등록 및 관리 부담 없이 OpenConnector의 기능을 사용할 수 있는 SaaS 옵션을 제공합니다.
• 프로덕션 환경 배포 전 확인해야 할 사항으로는 관리와 실행 분리, 최소한의 Action 세트 부여, 데이터 보호, 로그 민감성 처리, 부작용을 고려한 재시도 설계 등이 있습니다.
• OpenConnector는 로컬, Docker, Cloudflare Workers 등 다양한 환경에 배포 가능하며, OOMOL에서 호스팅하는 관리형 서비스도 이용할 수 있습니다.
• 단일 제공업체, 단일 계정, 소수의 API 호출만 필요한 경우에는 기존 SDK가 더 적합할 수 있으며, 여러 사용자의 계정 연결, 다수의 제공업체 지원, 자격 증명 외부 관리 등의 요건이 충족될 때 커넥터 게이트웨이 접근 방식의 이점이 커집니다.

시사점

AI 에이전트가 외부 서비스와의 연동을 확대함에 따라, 자격 증명 관리의 복잡성과 보안 위험이 증가하므로 아키텍처 설계 시 이 문제를 효과적으로 해결할 수 있는 커넥터 게이트웨이와 같은 솔루션 도입을 고려해야 합니다.