2025년 Casbin: AI 에이전트 시대의 인가

2024년은 AI 에이전트가 데모에서 프로덕션으로 이동한 해였습니다. Model Context Protocol(MCP)은 Google, OpenAI, Microsoft 및 기타 여러 기업에 의해 채택되었으며, 애플리케이션이 외부 서비스와 통신하는 방식이 변화하고 있습니다. 이러한 변화는 우리가 Casbin에서 지속적으로取り組고 있는 새로운 일련의 인가 과제를 가져옵니다.

세상이 변했습니다

2017년에 Casbin을 시작했을 때, 일반적인 인가 시나리오는 단순했습니다. 사용자가 요청을 하고, 권한이 있는지 확인하며, 끝이었습니다. 오늘날에는 어떨까요? AI 에이전트가 사용자를 대신하여 행동하고, 각각 자체적인 도구 권한을 가진 여러 MCP 서버를 호출할 수 있으며, 전체 과정이 에지에서 밀리초 단위로 처리되어야 합니다.

MCP 사양은 이제 MCP 서버를 OAuth 2.0 리소스 서버로 분류합니다(2025년 6월 업데이트). mcp:tools:weather 또는 mcp:resources:customer-data:read와 같은 세분화된 범위를 포함합니다. 이는 Casbin이 설계된 정밀한 권한 모델이지만, MCP 및 OAuth와의 통합에는 아직 더 많은 작업이 필요합니다.

우리가 진행 중인 작업

MCP 서버 인가

이는 우리의 주요 관심 분야 중 하나입니다. AI 에이전트가 MCP 서버를 호출할 때, 서버는 다음을 결정해야 합니다. 이 에이전트가 이 사용자를 대신하여 이 매개변수로 이 도구를 실행할 수 있는가?

전통적인 RBAC만으로는 충분하지 않습니다. ABAC과 같은 것이 필요합니다. 예를 들어 “이 에이전트가 업무 시간 동안 Alice의 지역 고객 데이터에 접근할 수 있는가?” Casbin의 정책 모델이 이러한 제약 조건을 어떻게 표현할 수 있는지 탐색하고 있습니다.

난점은 다음과 같습니다. MCP 서버는 매우 빠르게 결정을 내려야 합니다. 별도의 인가 서비스를 호출하는 대신, MCP 서버 프로세스 내에서 경량 정책 평가를 수행하는 방안을 검토하고 있습니다.

엣지 우선 인가

Cloudflare Workers, Deno Deploy, Vercel Edge Functions 등 엣지 컴퓨팅 분야가 급성장했습니다. 2025년에는 50ms 미만의 응답 시간이 기본 요구 사항이 되었으며, 중앙 서버로의 인가 검사에 100ms를 할애할 여유가 없습니다.

이는 Casbin의 작동 방식을 다르게 생각하도록 우리를 추동하고 있습니다. 정책을 WebAssembly로 컴파일하여 V8 격리에 직접 실행할 수 있을까요? 일관성을 유지하면서 엣지에서 스마트 정책 캐싱을 수행할 수 있을까요? 이러한 문제는 어려운 과제이며, 우리는 아직 모든 답을 가지고 있지 않지만, 이것이 향후 방향입니다.

특히 Cloudflare Workers 생태계에 관심이 많습니다. 그들은 내장 OAuth 지원을 갖춘 MCP 서버용 전체 플랫폼을 구축했습니다. 그곳에서의 네이티브 Casbin 통합은 강력할 수 있습니다.

RAG 파이프라인 인가

반복되는 주제입니다. LLM이 내부 문서에 접근해야 하지만 각 사용자는 허용된 문서만 볼 수 있어야 하는 RAG 시스템을 구축하는 회사들이 있습니다.

OWASP Top 10 for LLM Applications 2025는 “민감 정보 노출”을 주요 위험으로 목록화했습니다. 해결책은 출력만 필터링하는 것이 아니라, LLM이 사용자가 접근 권한이 없는 문서를 절대 검색하지 않도록 보장하는 것입니다.

따라서 인가는 벡터 스토어 쿼리 수준에서 이루어져야 합니다. Casbin 정책을 벡터 DB의 메타데이터 필터로 변환하는 것을 검토하고 있습니다. 즉, 권한 검사가 검색으로 푸시다운되는 WHERE 절이 되는 것입니다.

멀티 에이전트 시나리오

체인에 여러 에이전트가 존재하는 경우(예: 코딩 에이전트 → 배포 에이전트 → 모니터링 에이전트), 권한 위임은 까다롭습니다. 각 에이전트는 다른 기능을 가질 수 있으며, 전체 체인을 추적해야 합니다.

OAuth의 On-Behalf-Of(OBO) 흐름은 이 부분 중 일부를 다루지만, “에이전트 B가 에이전트 A를 대신하여 사용자 alice를 위해 X를 수행할 수 있는가?”라는 로직에는 명확한 모델이 필요합니다. Casbin의 역할 계층 구조 및 도메인 RBAC은 에이전트 계층 구조로 확장될 수 있으며, 우리는 그 의미론적 부분을 정리하고 있습니다.

전통적인 로드맵 항목

물론, 우리는 기본 사항을 포기하지 않고 있습니다. 우리 목록에 있는 몇 가지 실용적인 사항들:

언어 구현 따라잡기 - SwiftCasbin 및 Lua-Casbin은 여전히 Go 및 Node.js 버전보다 기능이 뒤처져 있습니다. in 연산자, WatcherEx, g 함수를 위한 더 나은 캐싱 등은 모든 곳에서 일관성이 필요합니다.

새로운 프레임워크 미들웨어 - go-zero가 반복적으로 요청되었습니다. Rust용 Poem이 인기를 얻고 있습니다. Java용 Play Framework는 오랫동안 위시리스트에 있었습니다.

성능 작업 - 이러한 새로운 사용 사례를 위해 정책이 더 복잡해짐에 따라 평가 속도가 더 중요해집니다. 모든 구현 전반에서 더 나은 벤치마킹, 프로파일링 및 최적화가 필요합니다.

아직 모르는 것들

AI 에이전트 인가 분야는 빠르게 변화하고 있으며, 우리는 진행하면서 학습하고 있습니다. 미해결 과제:

• Casbin에 "에이전트 식별자"와 "사용자 식별자"를 위한 1급 원시 자료형(first-class primitives)을 제공해야 할까요?
• MCP를 통해 동적으로 발견된 도구에 대한 인가는 어떻게 처리하나요?
• 정책이 실시간 컨텍스트에 의존할 수 있을 때 올바른 캐싱 전략은 무엇인가요?

이 분야에서 개발 중이며 인가 관련 문제를 겪고 있다면, 여러분의 의견을 듣고 싶습니다. 최고의 기능은 실제 사용 사례에서 나옵니다.

참여하기

저희는 수년간 GSoC(Google Summer of Code) 단체로 활동해 왔으며, 이러한 AI 관련 주제는 여름 프로젝트로 적합합니다. GSoC를 기다릴 필요는 없습니다—흥미롭다면 Discord로 연락하거나 GitHub에 이슈를 열어 주세요.

앞으로 몇 년간 인가 분야는 격동기가 될 것입니다. 문제는 더 어려워지지만, 동시에 더 흥미로워집니다. 함께 해결책을 찾아나갈 것을 기대합니다.