Casbin en 2025 : Autorisation pour l'ère des agents IA

2024 fut l'année où les agents IA sont passés des démonstrations à la production. Le Model Context Protocol (MCP) a été adopté par Google, OpenAI, Microsoft et bien d'autres, et la façon dont les applications communiquent avec les services externes est en train de changer. Ce changement apporte un nouveau lot de défis d'autorisation sur lesquels nous travaillons chez Casbin.

Le monde a changé

Lorsque nous avons lancé Casbin en 2017, le scénario d'autorisation typique était simple : un utilisateur effectue une requête, nous vérifions s'il a la permission, terminé. Aujourd'hui ? Un agent IA pourrait agir au nom d'un utilisateur, appelant plusieurs serveurs MCP, chacun avec ses propres permissions d'outils, et tout cela doit se produire en quelques millisecondes à la périphérie (edge).

La spécification MCP classe désormais les serveurs MCP comme des Resource Servers OAuth 2.0 (mise à jour de juin 2025), avec des scopes fins tels que mcp:tools:weather ou mcp:resources:customer-data:read. C'est le type de modèle de permission granulaire pour lequel Casbin a été conçu ; l'intégration avec MCP et OAuth nécessite encore plus de travail.

Sur quoi nous travaillons

Autorisation des serveurs MCP

C'est l'un de nos principaux domaines de focus. Lorsqu'un agent IA appelle un serveur MCP, le serveur doit décider : cet agent, agissant au nom de cet utilisateur, peut-il invoquer cet outil avec ces paramètres ?

Le RBAC traditionnel ne suffit pas. Il faut quelque chose comme l'ABAC — par exemple « cet agent est-il autorisé à accéder aux données clients pour la région d'Alice pendant les heures ouvrables ? ». Nous explorons comment le modèle de politique de Casbin peut exprimer ces contraintes.

Le piège : les serveurs MCP doivent décider très rapidement. Nous envisageons une évaluation légère des politiques directement dans le processus du serveur MCP plutôt qu'en appelant un service d'autorisation séparé.

Autorisation centrée sur l'Edge

Cloudflare Workers, Deno Deploy, Vercel Edge Functions - le domaine du computing edge a explosé. En 2025, les temps de réponse inférieurs à 50 ms sont la norme, et vous ne pouvez pas vous permettre d'ajouter 100 ms pour une vérification d'autorisation vers un serveur central.

Cela nous pousse à repenser le fonctionnement de Casbin. Pouvons-nous compiler les politiques en WebAssembly et les exécuter directement dans les isolats V8 ? Pouvons-nous effectuer une mise en cache intelligente des politiques à la périphérie tout en maintenant la cohérence ? Ce sont des problèmes difficiles, et nous n'avons pas encore toutes les réponses, mais c'est la direction que prennent les choses.

Nous sommes particulièrement intéressés par l'écosystème Cloudflare Workers - ils ont construit toute une plateforme pour les serveurs MCP avec prise en charge native d'OAuth. Une intégration Casbin native là-bas pourrait être puissante.

Autorisation des pipelines RAG

Un thème récurrent : les entreprises construisant des systèmes RAG où le LLM doit accéder à des documents internes, mais chaque utilisateur ne devrait voir que les documents auxquels il est autorisé.

Le OWASP Top 10 for LLM Applications 2025 liste la « Divulgation d'informations sensibles » comme un risque majeur. La solution consiste non seulement à filtrer les sorties, mais aussi à garantir que le LLM ne récupère jamais de documents que l'utilisateur n'est pas autorisé à consulter.

L'autorisation doit donc avoir lieu au niveau de la requête vers le magasin vectoriel. Nous envisageons de transformer les politiques Casbin en filtres de métadonnées pour les bases de données vectorielles — c'est-à-dire qu'une vérification de permission devient une clause WHERE poussée jusqu'à la récupération.

Scénarios multi-agents

Avec plusieurs agents dans une chaîne (par exemple agent de codage → agent de déploiement → agent de surveillance), la délégation de permissions est délicate. Chaque agent peut avoir des capacités différentes, et vous devez suivre la chaîne complète.

Le flux On-Behalf-Of (OBO) d'OAuth couvre une partie de cela, mais la logique pour « l'agent B peut-il faire X au nom de l'agent A au nom de l'utilisateur alice » nécessite un modèle clair. Les hiérarchies de rôles et le RBAC par domaine de Casbin pourraient s'étendre aux hiérarchies d'agents ; nous travaillons sur la sémantique.

Les éléments classiques de la feuille de route

Bien sûr, nous n'abandonnons pas les fondamentaux. Quelques points pratiques sur notre liste :

Rattrapage des implémentations linguistiques - SwiftCasbin et Lua-Casbin sont toujours en retard sur les fonctionnalités par rapport aux versions Go et Node.js. L'opérateur in, WatcherEx, une meilleure mise en cache pour la fonction g - ces éléments doivent être cohérents partout.

Nouveaux middlewares de frameworks - go-zero a été demandé à maintes reprises. Poem pour Rust gagne en traction. Play Framework pour Java figure depuis toujours sur la liste de souhaits.

Travail sur la performance - À mesure que les politiques deviennent plus complexes pour ces nouveaux cas d'utilisation, la vitesse d'évaluation compte davantage. Nous avons besoin de meilleurs benchmarks, profils et optimisations dans toutes les implémentations.

Ce que nous ne savons pas encore

Le domaine de l'autorisation des agents IA évolue rapidement ; nous apprenons au fur et à mesure. Questions ouvertes :

• Casbin devrait-il disposer de primitives de premier plan pour distinguer « identité d'agent » et « identité d'utilisateur » ?
• Comment gérez-vous l'autorisation pour les outils découverts dynamiquement via MCP ?
• Quelle est la stratégie de mise en cache appropriée lorsque les politiques peuvent dépendre du contexte en temps réel ?

Si vous développez dans ce domaine et rencontrez des problèmes d'autorisation, nous souhaitons avoir votre retour. Les meilleures fonctionnalités proviennent de cas d'utilisation réels.

Getting involved

Nous sommes une organisation GSoC depuis plusieurs années, et ces sujets liés à l'IA sont bien adaptés aux projets d'été. Vous n'avez pas besoin d'attendre le GSoC—si cela vous intéresse, contactez-nous sur Discord ou ouvrez un problème (issue) sur GitHub.

Les prochaines années seront passionnantes pour l'autorisation. Les problèmes sont plus difficiles, mais aussi plus intéressants. Nous sommes enthousiastes à l'idée de les résoudre ensemble.