Autorisations des agents IA : liste de contrôle par ressource et par action

Une autorisation accordée à un agent IA doit préciser qui lance l’appel, quelle connexion il utilise, à quelle ressource il peut accéder, ce que l’action modifie et qui valide définitivement l’opération. Le catalogue d’outils indique à l’agent les commandes disponibles. Il revient ensuite au serveur de décider si cet acteur peut exécuter cette commande sur cet objet, à cet instant, et de préciser dans sa réponse ce qui s’est réellement passé.

Cette distinction devient cruciale lorsqu’une même interface permet de découvrir des milliers d’opérations. Le 28 septembre, Cloudflare a présenté cf, une interface en ligne de commande conçue pour les agents et destinée à son API. Cette annonce facilite la recherche de commandes ; elle ne transforme pas leur découverte en autorisation. La discussion sur Hacker News montre pourquoi cette sortie a retenu l’attention des équipes d’exploitation, mais les commentaires expriment des questions et des avis, pas une évaluation de la sécurité de cette interface.

Dans un produit SaaS, chaque action qui a des conséquences mérite un contrat précis. Les outils de recrutement, de réponse aux incidents de sécurité et de gestion d’équipe de Kit offrent des exemples concrets : leurs verbes se ressemblent, mais leurs effets diffèrent nettement. On peut rédiger une réponse à un candidat sans l’envoyer. On peut proposer une prime sans l’attribuer. D’autres appels autorisés modifient immédiatement l’état du système. Ce sont des choix de conception que vous pouvez examiner et tester.

Qu’a changé le lancement de cf par Cloudflare ?

Selon Cloudflare, la version bêta ouverte de son interface cf expose des commandes issues d’une API de plus de 3 000 opérations, contre environ 280 chemins de commande pour Wrangler. Elle renvoie du JSON par défaut et propose cf cli search : un agent peut ainsi trouver la commande pertinente à partir d’une description en langage naturel, sans garder tout le catalogue en contexte. Ces nouveautés concernent la découverte des commandes et la conception de l’interface, comme l’expliquent l’annonce de Cloudflare et le dépôt de cf.

Cloudflare indique aussi que les agents représentaient 48 % de l’utilisation de Wrangler la semaine précédant l’annonce, contre 25 % en mars 2026. C’est la mesure que Cloudflare donne de l’utilisation de Wrangler ; l’article ne publie ni dénominateur ni méthode. Ce n’est pas un taux d’adoption par les clients.

Un agent peut rechercher, sur une même interface, une commande de lecture, de déploiement, de modification du WAF ou d’achat de domaine. Cela ne lui donne pas les identifiants nécessaires à toutes ces actions. La documentation de Cloudflare sur les jetons d’API définit des règles par ressource et groupe d’autorisations ; son référentiel des autorisations distingue les droits de lecture et d’écriture sur les ressources utilisateur, compte et zone. Ces documents décrivent les contrôles disponibles dans l’API. L’annonce du lancement ne précise pas le fonctionnement de l’authentification ou de la validation pour chaque appel à cf.

Voilà le point essentiel pour quiconque expose un vaste catalogue d’outils : une commande facile à trouver n’est pas forcément autorisée. Sa description peut indiquer à l’agent comment formuler sa demande. Seul le système derrière la commande peut décider si l’acteur actuel a le droit d’agir sur un objet donné, dans son état actuel. Plus l’interface facilite la découverte des commandes, plus il devient utile de documenter cette décision pour chacune d’elles.

Que doit préciser une autorisation accordée à un agent IA ?

Une autorisation efficace repose sur un contrat par ressource et par action, et non sur une simple étiquette « lecture » ou « écriture ». Avant d’exposer un outil, consignez les droits accordés à la connexion, l’identité actuelle de l’acteur, la manière de trouver l’objet, les vérifications de son état, l’effet produit, la personne qui valide définitivement l’opération, le destinataire éventuel, les données visibles dans la réponse et le comportement en cas de refus.

Imaginez la demande suivante : « Envoyer une réponse à ce candidat. » La connexion peut disposer de hiring_write, alors que le membre de l’équipe n’est affecté qu’à une seule offre. La candidature peut concerner une autre offre, la période de réponse peut être close, et l’outil peut uniquement créer un brouillon. Chacun de ces points influe sur la réponse à la question : « L’agent peut-il le faire ? » Un droit d’accès général est nécessaire, mais insuffisant.

Commencez par ces six questions :

1. Qui agit ? Identifiez la personne ou le compte de service lié à la connexion. Vérifiez son appartenance actuelle au compte et son rôle actuel, pas seulement ceux dont il disposait à la création de la connexion.
2. Quels droits ont été délégués ? Nommez la portée de la connexion ainsi que le compte ou le module concerné. Un jeton autorisé à écrire dans un module ne doit pas donner discrètement accès à un autre.
3. Quel objet est visé ? Recherchez son identifiant parmi les objets visibles par cet acteur. Une requête limitée au compte peut encore être trop vaste pour une offre à accès restreint ou un rapport privé.
4. Quel état permet l’action ? Un membre autorisé à modifier une candidature peut tout de même ne plus pouvoir répondre une fois le parcours clos. Vérifiez l’état au moment de l’exécution.
5. Qu’est-ce qui est effectivement enregistré ? Distinguez une suggestion, un brouillon interne, une modification directe en base de données, un message adressé à quelqu’un et un paiement. Le nom de l’outil ne suffit pas à exprimer cette différence.
6. Que peut voir l’appelant ensuite ? Une réponse peut révéler des nombres, des noms ou des dossiers privés même lorsque l’écriture était autorisée. Appliquez aussi les droits de lecture du destinataire à la réponse.

Ces questions rendent vérifiable l’expression « validation humaine requise » : qui valide, dans quel canal, et quel point d’accès l’impose ?

Pourquoi les portées d’une connexion ne sont-elles qu’un premier filtre ?

La portée d’une connexion limite les opérations qu’un client peut demander. Elle ne dit pas si un membre peut agir sur ce dossier précis. Le serveur doit croiser les droits de la connexion avec l’appartenance actuelle au compte, le périmètre du tenant, la visibilité du dossier, les règles d’accès et son état.

La connexion MCP externe de Kit utilise des portées OAuth comme hiring_read, hiring_write, csirt_read, csirt_write et team_write. Lors du consentement, les portées demandées sont limitées à celles que le membre actuel du compte peut accorder. La portée de base mcp ne donne, à elle seule, accès à aucun module produit. Lors de chaque appel d’outil, Kit vérifie de nouveau la portée du jeton ainsi que l’accès actuel au module ; masquer un outil dans le catalogue ne sert qu’à faciliter l’utilisation. Un client peut toujours soumettre le nom d’un outil qu’il n’a jamais vu dans la liste. Le guide de connexion des assistants IA de Kit décrit le parcours côté utilisateur.

Pour une candidature, Kit recherche ensuite parmi les offres visibles par ce membre et applique la règle d’accès propre à la candidature. Une candidature liée à une offre à accès restreint apparaît comme introuvable lorsque ce membre n’a pas accès à l’offre ; pour un dossier visible, l’action demandée peut en revanche être refusée par la règle d’autorisation. Les rapports de sécurité sont recherchés de façon comparable parmi les dossiers visibles par le membre, même si chaque action possède ses propres vérifications de rôle et d’autorisation. Le contexte du compte client limite les données au compte concerné ; la recherche de l’objet limite la cible.

Vous pouvez en tirer un test négatif utile. Connectez-vous en tant que membre non administrateur doté de hiring_write pour tout le module. Demandez à l’outil de modifier une candidature liée à une offre à accès restreint à laquelle ce membre n’a pas accès. Le résultat attendu est « introuvable », sans révéler si la candidature existe. Réduisez ensuite les droits de ce membre sur le module et recommencez avec la connexion existante. La vérification effectuée par Kit lors de l’appel applique le rôle actuel au prochain appel. Elle n’efface pas les informations que le client a déjà reçues et n’annule pas une action déjà enregistrée.

Les restrictions applicables aux jetons d’API Cloudflare illustrent une autre couche : un jeton peut être limité dans le temps et par adresse IP cliente. Cela réduit la période ou le lieu où l’identifiant est utilisable. Ces limites ne remplacent pas les règles d’accès à une ressource précise dans l’application SaaS derrière l’appel d’outil.

Que se passe-t-il quand un agent prépare une réponse à un candidat ?

Le nom hiring_send_message de Kit évoque un envoi. Son effet réel est plus limité : un appel autorisé prépare une réponse en attente, qu’un collègue relit et envoie depuis le fil d’e-mails de la candidature. La réponse de l’outil le précise. C’est l’état de brouillon imposé par le serveur, et non une instruction demandant au modèle de faire confirmer son texte, qui constitue la protection effective.

L’appel exige un membre du compte lié à la connexion et doté de hiring_write. Il recherche la candidature parmi les offres visibles par ce membre, vérifie qu’il peut la modifier et que l’état actuel du fil permet de préparer une réponse. En cas de succès, il crée un brouillon interne et fournit un lien vers le fil. L’action de confirmation dans l’interface web est le moment où l’e-mail est envoyé au candidat.

Ce brouillon n’est pourtant pas anodin. Il peut contenir des propos sensibles ou trompeurs et influencer le collègue qui cliquera plus tard sur « Envoyer ». Mais le résultat immédiat est « brouillon en attente », pas « candidat prévenu ». Une réponse d’outil limitée à « Terminé » masquerait le fait le plus important du parcours.

Décrivez le contrat comme deux actions : préparer la réponse et envoyer la réponse. Pour la première, l’agent peut enregistrer le brouillon une fois les vérifications effectuées ; le destinataire reste interne. Pour la seconde, le collègue valide l’envoi dans l’interface web et le candidat devient le destinataire. Si votre produit fonctionne autrement, décrivez ses effets avec la même précision. La portée de la connexion ne permet pas, à elle seule, de savoir quelle action a eu lieu.

Il en va de même pour un outil CRM nommé send_quote : il peut enregistrer un devis pour relecture, mettre un e-mail en file d’attente ou l’envoyer immédiatement. Vérifiez ce qui a été enregistré et transmis avant de décrire son effet.

En quoi une proposition de prime diffère-t-elle de son attribution ?

Les outils de réponse aux incidents de sécurité de Kit montrent pourquoi le droit d’« écriture » est trop général. csirt_propose_bounty crée une proposition de montant interne sur un rapport visible par le membre. Il ne crée ni attribution de prime, ni écriture au grand livre, ni notification au chercheur, ni paiement. Une proposition ultérieure peut remplacer celle qui est ouverte et rendre caducs les votes précédents. L’écriture est réelle, mais son public et ses conséquences restent limités.

Les membres de l’équipe peuvent utiliser csirt_vote_bounty_proposal pour enregistrer un avis consultatif. En mode de vote masqué, la réponse ne doit pas révéler le décompte caché dans son texte alors qu’elle le masque dans les données structurées. Il faut vérifier les données visibles dans la réponse en plus de l’autorisation d’écriture : pouvoir voter ne donne pas automatiquement accès aux votes de tout le monde.

csirt_approve_bounty exige un accès administrateur au module CSiRT et une connexion dotée de csirt_write. Un appel autorisé enregistre directement dans Kit la décision d’attribuer la prime, sous réserve des règles d’attribution du rapport. La description de l’outil demande à l’assistant de faire confirmer le montant et le type par l’utilisateur, mais ce texte guide le client : il ne crée pas une seconde validation côté serveur. L’attribution ne transfère pas de fonds ; le paiement s’effectue hors de Kit.

L’expression « humain dans la boucle » doit donc renvoyer à une étape précise. Pour une proposition, la décision humaine reste à venir. Pour l’outil d’attribution, l’appel effectué par l’administrateur autorisé valide définitivement l’opération dans Kit. Si votre politique exige une seconde validation avant l’attribution, créez une transition distincte côté serveur. Un « oui » dans la conversation ne peut s’y substituer.

Comparez l’effet annoncé dans la description de l’outil au résultat obtenu. « Prime attribuée dans Kit » laisse le statut du paiement distinct. Une réponse à une proposition ne doit jamais laisser penser qu’une somme a été promise au chercheur.

Quand faut-il sortir du chat pour modifier les accès de l’équipe ?

Modifier les accès d’un collègue a des conséquences au-delà d’un seul parcours. Kit traite cette action différemment selon le canal. Dans son chat IA intégré à l’application, l’adaptateur bloque les invitations, les modifications d’accès, la modification et la révocation des invitations, ainsi que le retrait des membres. Il renvoie l’utilisateur vers les paramètres authentifiés. Un « oui, j’approuve » visible par le modèle dans le chat n’en fait pas un canal fiable pour accorder des accès, surtout si le modèle a pu lire des documents contrôlés par des candidats.

La connexion MCP externe par OAuth suit un autre contrat. Un administrateur du compte peut obtenir team_write et utiliser team_update_member_access pour modifier directement le rôle ou les niveaux d’accès aux modules d’un membre. L’outil recherche le membre dans le compte et empêche de changer le rôle du propriétaire du compte ou de réduire ses droits. Selon les paramètres fournis, team_invite_member peut envoyer une invitation ou ajouter un utilisateur existant à une offre, après ses propres vérifications d’administration et de compte. Il s’agit d’actions directes, pas de renvois vers les paramètres.

Cette différence doit apparaître dans toute revue des autorisations. « Le chat de Kit ne peut pas modifier les accès de l’équipe » décrit correctement l’adaptateur intégré. « Aucun agent ne peut modifier les accès de l’équipe » serait faux. Les clients externes qui ont obtenu ces droits peuvent enregistrer la modification par une autre voie. Si votre produit comprend un assistant web, une API et un serveur d’outils distant, consacrez une ligne distincte à chaque canal capable d’effectuer la même action.

Le point d’accès compte davantage que la promesse du modèle de demander d’abord confirmation. Un renvoi vers les paramètres impose une limite entre canaux. Un outil externe réservé aux administrateurs impose une limite par les droits de connexion et les contrôles d’administration. Dans les deux cas, le terme « validation » seul manque de précision.

Que doit contenir votre liste de contrôle par ressource et par action ?

Consacrez une ligne à chaque effet réel, même si le produit regroupe plusieurs effets sous un verbe familier. Renseignez-la à partir du code et des tests, puis vérifiez-la avec un appel autorisé et un appel refusé. Voici une version condensée pour six actions de Kit :

Pour chaque ligne de votre système, ajoutez trois colonnes qui ne tiennent pas toujours dans un résumé destiné aux utilisateurs : destinataire externe, visibilité du résultat et preuves de la décision. Un e-mail a un destinataire. Un résumé de rapport privé a des lecteurs autorisés. Un appel refusé doit donner une raison utile à l’utilisateur autorisé sans révéler l’existence d’un dossier inaccessible. Ces détails révèlent souvent une limite invisible dans le tableau des portées.

Effectuez ensuite quatre vérifications sur l’implémentation :

1. Contournez le catalogue. Appelez directement un outil même si son nom n’y figure pas. Le serveur doit tout de même vérifier la portée et le rôle.
2. Testez la limite d’accès à l’objet. Utilisez un identifiant plausible provenant d’un autre tenant ou d’un objet à accès restreint dans le même tenant. Les deux appels doivent échouer sans révéler l’existence ni le contenu de données privées.
3. Modifiez les accès en cours de connexion. Réduisez les droits du membre, puis répétez l’appel. Le prochain appel doit appliquer les droits actuels. Les données déjà téléchargées, les résultats en cache et les URL signées posent des questions de révocation distinctes.
4. Lisez la réponse à la lettre. Vérifiez que « brouillon », « proposition », « attribution », « envoyé » et « payé » correspondent à l’état enregistré et aux effets externes. Le résumé du résultat fait partie du contrat de sécurité, car des personnes peuvent agir en s’y fiant.

La conservation des preuves exige également des termes précis. Kit signale certains outils aux clients MCP comme destructeurs ou tournés vers l’extérieur, et émet des événements structurés pour les appels d’outils en environnement ouvert. Ces indications aident le client à présenter les outils ; elles n’ajoutent pas de validation côté serveur. Les événements ne constituent pas un journal d’audit immuable couvrant chaque appel d’outil. Kit décompte aussi les appels d’outils MCP externes du budget d’un compte, y compris les appels au sein d’un lot : cela limite l’utilisation, mais n’autorise pas l’accès à un objet. Définissez vos propres exigences d’audit, puis vérifiez que le point d’accès qui enregistre l’action conserve assez de preuves pour y répondre.

La révocation a également ses limites. Vérifier le rôle actuel peut bloquer un futur appel sur une connexion existante. Cette vérification ne peut ni rappeler un e-mail envoyé, ni annuler une modification d’accès déjà enregistrée, ni récupérer des données déjà copiées dans le contexte d’un agent, ni faire disparaître une URL signée déjà émise. Si votre parcours crée de tels éléments, recensez-les et définissez pour chacun une durée de validité ou une procédure de révocation.

Comment Kit applique-t-il ce contrat ?

L’approche utile de Kit consiste à rendre explicites l’objet et l’effet final. Une portée MCP déléguée ouvre l’accès à un module ; les vérifications du membre actuel et du compte client limitent l’appelant ; la recherche du dossier par l’outil limite la cible. Ensuite, l’action peut préparer un brouillon, créer une proposition, renvoyer vers les paramètres ou enregistrer directement une décision. Consultez le parcours de connexion dans le guide des assistants IA de Kit et le cas d’usage du recrutement dans MCP pour le recrutement.

Choisissez un outil aux conséquences réelles, remplissez la liste de contrôle, puis testez un objet interdit, un changement de rôle et la réponse finale. Si vous connectez un assistant à Kit, examinez les parcours dont votre équipe a besoin avant d’accorder des droits d’écriture. L’agent doit pouvoir vous dire ce qu’il a modifié, en vertu de quels droits et quelle action reste à effectuer par une personne.