Concevoir un assistant IA limité par ses outils, permissions et contextes

La véritable limite d’un assistant IA est le contrat de service que ses systèmes peuvent exécuter, pas la liste d’interdictions écrite dans son instruction système. Un modèle peut recevoir l’ordre de ne jamais envoyer de message tout en disposant d’un outil et d’un identifiant capables de le faire. Pour obtenir un service contrôlable, il faut donc délimiter séparément chaque capacité visible, puis faire respecter ses données, permissions, validations et conditions d’arrêt hors du modèle.

Que peut-on réellement autoriser à l’assistant ?

L’équipe doit d’abord rédiger une charte de service en une phrase, puis transformer cette promesse en capacités précises et en non-objectifs explicites. Une formulation utile est : « Pour [utilisateurs éligibles], l’assistant peut [famille de tâches] avec [informations approuvées] afin de produire [résultat permis], mais il ne peut pas [décisions ou effets exclus]. » Cette phrase oblige à nommer le public, le contexte d’utilisation, la supervision et le responsable du risque avant de brancher un outil.

• Rechercher dans une source approuvée.
• Résumer des éléments accessibles à l’utilisateur.
• Recommander une suite sans la décider.
• Créer un brouillon dans un espace non final.
• Mettre à jour des champs précisément autorisés.
• Envoyer un contenu déjà validé.
• Refuser de supprimer, approuver ou engager l’organisation lorsque la capacité ne le prévoit pas.

Les verbes vagues comme « aider » ou « gérer » masquent des différences d’autorité. Les remplacer par des opérations observables permet d’attribuer à chacune ses données, son identité d’exécution, ses essais et son propriétaire. Cette méthode par capacité est une synthèse éditoriale pratique, éclairée par le cadrage du NIST AI RMF et le principe OWASP de fonction minimale ; ni le NIST ni OWASP ne l’imposent comme architecture universelle.

Quelles informations chaque capacité peut-elle utiliser ?

Chaque capacité doit recevoir une enveloppe d’information qui définit les données éligibles et leurs frontières de confiance, plutôt qu’un simple nombre maximal de jetons. Cette enveloppe précise les systèmes, types de dossiers, classifications, filtres d’objets, périodes, exigences de fraîcheur et droits de l’utilisateur. Elle exclut aussi nommément les données que le service ne peut jamais consulter, même si elles sont techniquement proches ou disponibles dans le même système.

• Sources et types d’enregistrements approuvés.
• Comptes, objets, champs et périodes admissibles.
• Droits hérités de l’utilisateur authentifié.
• Niveau de fraîcheur exigé pour la réponse.
• Classe de confiance des documents et pièces jointes.
• Historique conservé pendant la session.
• Données admissibles dans une mémoire persistante.
• Règles d’expiration, d’isolation et de suppression.

Les messages externes, documents récupérés, pièces jointes et réponses d’API restent du contenu non fiable : ils ne peuvent pas devenir silencieusement des instructions de service. La mémoire persistante mérite des règles distinctes de l’historique de session, avec validation avant stockage, isolation par utilisateur et suppression prévue. Si une preuve requise est inaccessible, absente ou périmée, l’assistant doit qualifier sa réponse ou s’arrêter. Une fenêtre de contexte plus grande ne crée ni autorité ni vérité.

Comment l’identité, les outils et les permissions font-ils respecter la limite ?

L’authentification, l’autorisation et la validation doivent rester trois décisions séparées, appliquées dans la passerelle d’outils et les systèmes en aval. L’authentification établit qui est présent : utilisateur, client ou charge de travail. L’autorisation détermine quelle opération cette identité peut effectuer sur quelle ressource protégée. La validation accepte une action proposée particulière. Une consigne en langage naturel peut orienter le modèle, mais elle ne constitue jamais un contrôle d’accès.

• Avec une autorité déléguée, l’outil conserve les droits réels de l’utilisateur et ne dépasse pas les objets qu’il peut déjà consulter ou modifier.
• Avec une identité de charge de travail, les verbes, ressources, champs, destinations, durée du justificatif et audience du jeton sont limités au service prévu.
• Dans les deux cas, une opération étroite avec paramètres validés remplace l’accès général à une boîte mail, une base, un navigateur ou un environnement de commande.

La spécification MCP illustre cette séparation pour ses propres intégrations protégées : elle distingue client, ressource protégée et serveur d’autorisation, puis recommande des portées minimales et des jetons destinés à une ressource précise. Ce n’est pas une règle universelle pour tous les outils. Quel que soit le protocole, les limites d’opération, de ressource et d’identité doivent être vérifiées au moment de l’exécution, sans emprunter silencieusement le compte privilégié d’un opérateur.

La conversation peut rester continue ; son autorité, elle, doit être découpée en capacités petites et indépendamment contrôlées.

Jusqu’où une capacité peut-elle agir ?

Chaque capacité a besoin d’un plafond d’action explicite, avec des contrôles indépendants plus forts dès qu’elle modifie un état externe. Une échelle pratique distingue l’information, la proposition, le brouillon, l’écriture réversible, l’action externe conséquente et la décision interdite. Cette échelle est une synthèse éditoriale : elle aide l’équipe à ne pas confondre un résultat conversationnel convaincant avec le droit technique de produire un effet.

1. Répondre ou résumer sans modifier de système.
2. Recommander ou préparer une proposition inspectable.
3. Créer un brouillon clairement non final.
4. Effectuer une écriture bornée et réversible.
5. Déclencher une action externe ayant un effet matériel.
6. Rencontrer une décision interdite, que le service ne doit pas exécuter.

Pour une action conséquente, l’utilisateur doit voir une prévisualisation vérifiable, puis la validation doit être liée à l’acteur, l’outil, la cible, aux paramètres normalisés, au moment et à l’expiration. Toute modification de destinataire ou de contenu exige une nouvelle vérification. Une validation ne remplace jamais l’autorisation en aval et ne transforme pas une décision interdite en action permise. Paiements, octrois d’accès, suppressions, changements de production et engagements matériels restent sous contrôle humain qualifié et politique déterministe.

Que se passe-t-il lorsque l’assistant atteint une limite ?

Le refus, l’aide partielle sûre, le transfert humain et l’escalade de sécurité doivent être conçus comme de véritables résultats de service, assortis d’une condition d’arrêt. L’assistant indique la limite sans révéler des détails de politique sensibles et ne prétend jamais qu’une source, un appel d’outil, une validation ou une écriture a réussi. Il peut encore fournir la partie autorisée, demander une information manquante ou préparer un brouillon sans effet externe.

• Tâche hors périmètre.
• Information non éligible.
• Autorisation insuffisante.
• Validation nécessaire.
• Preuve absente ou périmée.
• Jugement spécialisé requis.
• Dépendance indisponible.
• Limite opérationnelle atteinte.
• Signal de sécurité détecté.

Le dossier de transfert rassemble l’objectif initial, le contexte non sensible utile, la capacité tentée, le motif, les preuves disponibles ou manquantes, la prochaine étape et un identifiant de trace. Il est envoyé au bon destinataire : collègue de service pour une reprise ordinaire, responsable métier pour une validation, équipe de sécurité pour un signal d’incident. L’exécution reste suspendue pendant le traitement. Si l’action proposée change, ses paramètres, son autorisation et sa validation sont contrôlés à nouveau.

Comment transformer ces limites en conception opérationnelle ?

L’équipe doit compléter une ligne de canevas par opération visible et relier chaque ligne à des contrôles exécutables, des traces, des essais, des indicateurs et un propriétaire. Écrire « accès au CRM » ne suffit pas : il faut distinguer « résumer un dossier éligible », « créer un brouillon de réponse » et « envoyer une réponse validée ». Le canevas est une synthèse pratique inspirée des principes du NIST et d’OWASP, pas un formulaire officiel de ces organismes.

• Acteur éligible et authentification.
• Enveloppe d’information.
• Session et mémoire.
• Opération d’outil.
• Identité d’exécution.
• Ressources et champs permis.
• Plafond d’action.
• Validation éventuelle.
• Limites et arrêt.
• Refus et aide sûre.
• Preuves et scénarios d’essai.
• Indicateurs, escalade et propriétaire.

Les limites opérationnelles portent notamment sur le débit, les nouvelles tentatives, la profondeur des chaînes, les lots, le coût, la durée, la prévention des doublons, le retour arrière et le coupe-circuit. Leurs valeurs dépendent du service : aucun seuil universel ne convient. Les traces doivent permettre de reconstruire la demande, la capacité, la politique, les classes de sources et d’outils, les décisions d’autorisation et de validation, le résultat et les versions actives, sans conserver de secrets ni de contexte sensible illimité.

Quelles preuves faut-il avant et après la mise en service ?

La mise en service exige des preuves que les tâches permises et les refus attendus fonctionnent dans des conditions proches de l’exploitation, puis un suivi et un réexamen après chaque changement substantiel. Les scénarios positifs ne suffisent pas. L’équipe doit vérifier les frontières de comptes et d’outils, les preuves périmées, les contenus récupérés empoisonnés, le contournement de validation, les paramètres modifiés, les nouvelles tentatives, les dépendances indisponibles, l’exfiltration et les chaînes qui s’emballent.

• Demande permise correctement exécutée.
• Accès à un autre compte refusé.
• Outil non autorisé bloqué.
• Contexte périmé signalé.
• Instruction récupérée ignorée.
• Donnée interdite exclue.
• Validation contournée refusée.
• Paramètres modifiés revalidés.
• Nouvelle tentative sans doublon.
• Dépendance en panne gérée.
• Chaîne excessive interrompue.

En exploitation, les indicateurs restent attachés à la capacité : usage inattendu d’un outil, refus répétés, échecs d’autorisation, validations modifiées, séquences anormales, dérive, latence, consommation de ressources et pannes. Les journaux doivent répondre à des questions d’audit précises sans devenir un entrepôt illimité de conversations. Les propriétaires du service, des accès, des transferts métier et des incidents disposent d’une autorité claire pour suspendre, corriger ou retirer une capacité.

Une modification du modèle, des instructions, de la récupération, de la mémoire, des outils, permissions, politiques, données, fournisseurs ou conditions d’exploitation rouvre les essais concernés et les preuves de mise en service. Il vaut mieux commencer par la plus petite capacité utile, observer ses succès comme ses refus, puis élargir son autorité par une modification examinée. Les sujets sensibles, l’accès privilégié, les actions destructrices et les jugements réglementés doivent être transmis aux responsables internes et spécialistes qualifiés compétents.