Authentification, RBAC et limites
Une connexion MCP est un acteur authentifié qui interroge vos données, et elle est traitée comme tel. Il n'existe aucune dérogation propre à l'IA sur ce chemin : un appel d'outil passe par les mêmes permissions de rôle et les mêmes règles au niveau ligne que la requête HTTP équivalente d'une session humaine.
Deux stratégies d'authentification
| Stratégie | Par défaut quand | Identifiant |
|---|---|---|
token |
app.auth est absent |
Un jeton bearer statique par rôle, d'au moins 32 caractères. |
oauth2 |
app.auth est configuré |
OAuth 2.1 contre le greffon serveur OAuth de Better Auth. |
MCP_AUTH_STRATEGY=token
MCP_TOKEN_ADMIN=$(openssl rand -hex 32)
MCP_TOKEN_MEMBER=$(openssl rand -hex 32)
MCP_TOKEN_VIEWER=$(openssl rand -hex 32)
La validation au démarrage rejette token sans aucun MCP_TOKEN_* défini et oauth2 sans app.auth : aucune de ces erreurs de configuration ne peut donc aboutir à une route montée que personne ne peut atteindre — ou pire, que tout le monde peut atteindre.
Un jeton de rôle est un mot de passe sans expiration et sans propriétaire. En mode token, l'identifiant accorde un rôle, pas un utilisateur : il n'est attribuable à personne, et il reste valide jusqu'à ce que vous changiez la variable et redémarriez. N'émettez que les jetons nécessaires — une application sans automatisation administrateur ne devrait pas définir MCP_TOKEN_ADMIN du tout — et préférez oauth2 dès que app.auth existe, car il apporte identité par utilisateur et révocation.
Le RBAC est le plafond
Le rôle porté par l'identifiant connecté borne tout ce qui suit. Un jeton viewer ne peut que lire et lister, même sur une table dont l'aiAccess.operations autorise l'écriture — aiAccess élargit ce qui est proposé, jamais ce qui est permis.
| Couche | Répond à |
|---|---|
aiAccess sur l'entité |
Cette entité est-elle éligible à devenir un outil ? |
MCP_ENABLED |
Le serveur tourne-t-il ? |
| Permissions de rôle | Cet acteur peut-il effectuer cette opération ? |
| Permissions de champ | Quelles colonnes apparaissent dans le schéma et dans le résultat ? |
| Règles au niveau ligne | Quels enregistrements sont visibles ? |
Les cinq doivent passer. Conséquence pratique : vous ne pouvez pas surexposer une table par accident en y écrivant aiAccess: true — le pire des cas est qu'un rôle voie exactement ce qu'il aurait déjà pu récupérer par l'API.
Audit
Avec MCP_AUDIT_ENABLED (défaut true), chaque appel d'outil est consigné dans system.ai_tool_calls et dans le flux d'activité. Les administrateurs peuvent relire cette table via MCP lui-même, sous le nom {app}_system_ai_tool_calls_list.
Désactiver l'audit est permis pour des cas de conformité particuliers, et c'est un mauvais réglage par défaut. Un acteur IA est précisément celui dont vous voudrez plus tard reconstituer les appels.
Limitation de débit
| Variable | Défaut | Portée |
|---|---|---|
MCP_RATE_LIMIT_PER_MINUTE |
60 |
Par jeton, ou par client_id OAuth. |
MCP_RATE_LIMIT_PER_DAY |
5000 |
Idem. |
Les requêtes au-delà répondent 429 avec les en-têtes de limitation standard. C'est le plafond journalier qui compte le plus : un modèle pris dans une boucle de reprise peut brûler le budget d'une minute et continuer, mais il ne peut pas tourner discrètement toute la nuit contre votre base.
Internes admin
MCP_EXPOSE_INTERNALS vaut true par défaut et donne au rôle administrateur des outils en lecture seule sur les tables auth et system — {app}_auth_*_read, {app}_system_*_list et ainsi de suite — avec les colonnes secrètes exclues.
C'est ce qui rend « quels utilisateurs se sont inscrits cette semaine ? » répondable sans client de base de données. Passez la variable à false pour retirer entièrement ces outils de tools/list, y compris pour les administrateurs ; faites-le quand la surface MCP vise uniquement des données métier et que les internes de la plateforme sortent du périmètre de celui qui se connecte.
Pages associées
- Présentation de MCP — les variables
MCP_*en contexte. - Mode serveur —
aiAccesset ce qu'il ne fait pas. - Connecter un client — transmettre l'identifiant.
- Rôles et RBAC — les permissions appliquées.
- Suivi d'activité — où remontent les appels d'outils.
- Serveur OAuth — le greffon derrière la stratégie
oauth2.
Dernière mise à jour 27 juillet 2026
Cette documentation a été rédigée avec de l'IA : des erreurs ou du contenu obsolète sont donc possibles. Sovrium est en bêta — les contributions et corrections sont les bienvenues.