Contrôle d'accès agents IA Drupal : rôles et scopes

Pourquoi un agent IA pose une question d'accès différente

Un agent IA branché sur Drupal interroge le site à la demande, outil par outil, et chaque appel réclame sa propre décision d'accès. C'est exactement l'enjeu du contrôle d'accès agents IA Drupal : qui a le droit de voir quoi, et qui le décide à chaque appel plutôt qu'une fois pour toutes.

Ici, « modèles » désigne les modèles de contenu Drupal : types de nœuds, pages Canvas, sections de site. Pas les modèles de langage. Un agent IA peut tourner avec n'importe quel modèle de langage ; la question qui nous occupe ici est ce qu'il a le droit de voir et de faire sur votre Drupal.

Plus de 300 modules contrib, et autant de portes d'entrée

L'écosystème Drupal AI compte aujourd'hui plus de 300 modules contrib, dont AI Agents (des agents configurables en interface, dont l'intégration dans AI Core est prévue à partir de la version 2.0) et Context Control Center. (source) Cette croissance rapide explique pourquoi la question de l'accès se pose avec urgence : brancher un agent sur un site existant revient à lui donner les clés d'une partie du compte qui l'exécute, pas seulement un accès en lecture à des pages publiques.

La première barrière : rôles et permissions du compte qui exécute l'agent

Avant toute question de scope ou de contexte, il y a la question la plus ancienne de Drupal : quel rôle exécute l'agent. Un agent IA hérite des permissions du compte sous lequel il tourne, exactement comme n'importe quel autre client de l'API.

Une permission MCP Server dédiée, non accordée par défaut, aux appels vérifiés contre le compte de la session

Le module MCP Server protège son point d'accès HTTP (/mcp) par une permission dédiée, « Access MCP server », qui n'est accordée à aucun rôle par défaut. Sur le transport STDIO, chaque appel d'outil est vérifié contre les permissions du compte sous lequel la session Drush s'exécute. (source) Concrètement, un agent exécuté avec un compte qui n'a pas accès aux contenus non publiés ne les verra pas, quel que soit l'outil MCP sollicité.

À noter : l'ancien module « MCP », crédité de 456 sites utilisateurs sur sa page projet, est en cours de fusion avec MCP Server, la page recommandant déjà d'utiliser MCP Server pour toute nouvelle implémentation. Cette fusion n'est pas terminée à la date de rédaction. (source) Si vous évaluez les deux noms sur drupal.org, c'est la raison.

Scopes OAuth : limiter chaque outil, pas seulement chaque compte

Les rôles et permissions natifs de Drupal bornent ce qu'un compte peut faire sur l'ensemble du site. Les scopes, eux, ne sont pas une fonctionnalité de Drupal core : ils viennent d'un module contrib, et ils bornent ce qu'un jeton donné peut faire, outil par outil.

MCP Server OAuth : jeton Bearer, scope requis par outil, 401 authentication_required ou 403 insufficient_scope

Le module MCP Server OAuth ajoute une authentification par jeton Bearer sur /mcp et un contrôle de scope par outil. Un jeton absent ou invalide renvoie une erreur 401 authentication_required, avec un challenge WWW-Authenticate ; un jeton valide mais privé du scope requis renvoie une erreur 403 insufficient_scope. (source) Cette granularité change la nature de la décision : vous n'autorisez plus seulement « cet agent peut se connecter », mais « ce jeton peut appeler cet outil précis, et pas les autres ».

Découverte des scopes via /.well-known/oauth-protected-resource

MCP Server documente un point de découverte, /.well-known/oauth-protected-resource, qui permet à un client de connaître les scopes exposés par le serveur avant même de demander un jeton. (source) C'est la mécanique qui rend les scopes consultables outil par outil, avant même la première demande de jeton.

Réduire la surface de contexte, par modèle d'entité et par section : pas un contrôle d'accès

Une fois le compte et les scopes posés, une troisième couche existe, mais elle répond à une question différente : non pas « l'agent a-t-il le droit d'agir », mais « que voit-il dans le contexte qu'on lui transmet ».

Context Control Center (ai_context) : scope plugins, inclusions/exclusions, limites de contexte et de jetons

Le module Context Control Center borne les contenus qu'un agent IA reçoit en contexte via des scope plugins : portée globale, cas d'usage, langues, tags, sections de site, entités cibles. Il applique des règles d'inclusion et d'exclusion systématique, des limites de nombre d'éléments et de jetons, et des permissions granulaires pour la gestion du contexte et des réglages du module. (source)

Cibler le contexte par modèle de contenu avec Target Entities et Site Sections

Concrètement, vous ciblez le contexte par modèle de contenu : des pages Canvas précises, le contenu de certains types de nœuds, ou des sections entières du site. C'est là que le mot « modèles » du titre prend tout son sens : vous décidez quels types de contenu alimentent le prompt de l'agent, indépendamment de qui a le droit de les lire.

Ce qu'ai_context ne fait pas

C'est le point le plus facile à mal comprendre, et le plus coûteux si on s'y trompe. Le module ai_context filtre ce qu'un prompt reçoit en contexte ; il ne bloque aucune opération. Un compte autorisé à lire un contenu non publié continuera de le lire via n'importe quel outil MCP, quel que soit le réglage d'ai_context. Les scopes OAuth et le scoping de contexte d'ai_context sont deux couches distinctes, qu'il ne faut jamais confondre : la première refuse une opération, la seconde réduit un périmètre de lecture sans rien interdire.

Ce que ça change concrètement pour un site Drupal

Trois couches, trois décisions : compte, outil, contenu, et pourquoi aucune ne remplace les deux autres

Si vous branchez un agent IA sur un Drupal existant, trois décisions se posent, dans cet ordre. D'abord, quel rôle exécute l'agent, via les permissions natives et la permission « Access MCP server » de MCP Server. Ensuite, quels outils ce jeton précis peut appeler, via les scopes OAuth de MCP Server OAuth. Enfin, quels modèles de contenu et quelles sections alimentent le contexte transmis, via Context Control Center. Aucune des trois ne dispense des deux autres : resserrer le contexte d'ai_context sans revoir les permissions du compte laisse la vraie faille ouverte.

Maturité : aucune des trois briques n'est stable (beta, alpha, rc)

Avant d'engager cette architecture en production, aucun des trois modules n'a de release stable à ce jour. MCP Server en est à 2.0.0-beta6 ; MCP Server OAuth, à 1.0.0-alpha1, avec la mention explicite qu'il n'existe « aucune release stable supportée » ; Context Control Center, à 1.0.0-rc1. (source MCP Server, source MCP Server OAuth, source ai_context) Cela ne doit pas empêcher d'expérimenter, mais cela doit empêcher de traiter ces briques comme un socle figé : testez sur un environnement de préproduction, et prévoyez de revoir cette configuration à chaque montée de version majeure.

Si vous évaluez comment brancher un agent IA sur votre Drupal sans ouvrir une faille d'accès que personne n'avait anticipée, demandez un diagnostic.