Concevoir un assistant IA borné par ses outils, ses droits et son contexte

La frontière réelle d’un assistant IA est le contrat de service que son environnement peut exécuter, pas la liste d’interdictions inscrite dans sa consigne. 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 rendre le service contrôlable, il faut donc séparer ses capacités visibles — rechercher, résumer, rédiger, modifier ou envoyer — puis attribuer à chacune ses données admissibles, ses outils, ses droits, son plafond d’action, ses preuves, ses essais et son responsable.

Que doit-on autoriser l’assistant à faire ?

L’équipe doit commencer par une charte de service en une phrase, puis la décomposer en opérations précises assorties de non-objectifs explicites. Une formulation utile est : « Pour [les utilisateurs admissibles], l’assistant peut [réaliser cette famille de tâches] à partir de [ce périmètre d’information approuvé] afin de produire [ce résultat permis], mais il ne peut pas [réaliser ces actions ou décisions exclues]. » Cette méthode est une synthèse pratique inspirée des principes du NIST et d’OWASP ; elle ne constitue pas une exigence officielle de ces organismes.

• Remplacer « aider » ou « gérer » par des verbes distincts : rechercher, résumer, recommander, rédiger, modifier, envoyer, supprimer ou approuver.
• Nommer les utilisateurs admissibles, leur mode d’accès et le cadre de déploiement.
• Décrire les tâches prises en charge, les limites de connaissance et la supervision humaine attendue.
• Attribuer la propriété du service, de ses risques et de ses accès.
• Énoncer les résultats interdits avant de connecter le premier outil.

Cette décomposition évite qu’une fonction sans effet externe, comme la consultation d’un dossier, hérite des droits nécessaires à une fonction plus sensible, comme l’envoi d’une réponse. Elle rend également les arbitrages lisibles : un propriétaire métier peut accepter une capacité de rédaction tout en refusant son pouvoir de publication. OWASP recommande précisément de limiter les fonctions exposées et de préférer une opération étroite à un outil ouvert. Le périmètre utile devient ainsi vérifiable dans l’architecture, plutôt que seulement compréhensible dans une conversation.

Quelles informations chaque capacité peut-elle utiliser ?

Une limite de contexte est d’abord une enveloppe d’information : elle définit ce qui peut entrer dans la capacité, selon quels droits et avec quel niveau de confiance. Elle doit préciser les systèmes approuvés, les types d’enregistrements, les classifications, les filtres d’objet, les dates, la fraîcheur attendue, les habilitations de l’utilisateur et les données exclues. Un contexte techniquement plus grand ne donne aucune autorité supplémentaire et ne transforme ni une donnée ancienne ni une affirmation sans preuve en information fiable.

• Appliquer les droits de l’utilisateur avant la récupération, y compris les filtres de compte, de dossier et de champ.
• Qualifier la fraîcheur requise et refuser ou nuancer lorsque les preuves nécessaires sont absentes, inaccessibles ou périmées.
• Traiter les messages externes, pièces jointes, documents récupérés et réponses d’API comme des contenus non fiables, séparés des instructions.
• Définir indépendamment l’historique de session et la mémoire persistante.
• Fixer pour la mémoire l’éligibilité, l’isolation, la validation, l’expiration, la suppression et les données qui ne doivent jamais être conservées.

La séparation entre session et mémoire persistante est déterminante. Une information utile pendant un échange ne doit pas automatiquement devenir un souvenir réutilisable lors d’une autre session. Avant toute persistance, le service doit vérifier l’origine, l’intégrité et l’admissibilité de la donnée, puis l’isoler par utilisateur et par contexte. Les limites de taille, de durée et de conservation dépendent du service : les exemples techniques publiés par les guides de sécurité ne sont pas des seuils universels à recopier.

Comment l’identité, les outils et les droits font-ils respecter la frontière ?

L’authentification, l’autorisation et l’approbation doivent rester trois décisions séparées, appliquées par la passerelle d’outils et les systèmes en aval plutôt que par le modèle. L’authentification établit qui agit : utilisateur, client, agent ou charge de travail. L’autorisation répond ensuite à une question plus précise : cette identité peut-elle réaliser cette opération sur cette ressource ? L’approbation accepte enfin une action proposée déterminée. Une consigne en langage naturel peut orienter le comportement, mais elle ne constitue jamais un contrôle d’accès.

• Choisir explicitement entre l’autorité déléguée de l’utilisateur et une identité de service contrôlée.
• Ne jamais emprunter silencieusement le compte privilégié d’un opérateur.
• Exposer des opérations étroites avec des paramètres validés, plutôt qu’un accès général à une messagerie, une base, un navigateur ou un terminal.
• Limiter les verbes, ressources, objets, champs, destinations, durées d’identifiant et audiences de jeton dans le chemin d’exécution.
• Adapter au service les plafonds de débit, de tentative, de chaîne, de lot, de dépense et de durée, ainsi que l’idempotence et les coupe-circuits.

Pour une intégration MCP protégée, la spécification distingue le client, la ressource protégée et le serveur d’autorisation ; elle recommande aussi des portées minimales et le rattachement d’un jeton à la ressource visée. Ces mécanismes illustrent une bonne séparation des responsabilités, mais ne constituent pas une architecture universelle pour tous les outils. Quel que soit le protocole, le système destinataire doit vérifier l’identité, l’opération et la ressource à chaque demande, avec les droits minimaux réellement nécessaires.

La conversation peut sembler continue ; son autorité doit rester divisée en petites capacités contrôlées séparément.

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

Chaque capacité a besoin d’un plafond d’action explicite, renforcé par des contrôles indépendants à mesure qu’elle se rapproche d’un changement externe. L’échelle suivante est une synthèse éditoriale : elle sert à discuter l’impact sans prétendre imposer des catégories officielles. L’équipe doit maintenir une séparation nette entre une réponse et une décision, entre un brouillon et un envoi, entre une modification réversible et une suppression, ainsi qu’entre une proposition et un engagement dont une personne ou une fonction demeure comptable.

1. Répondre ou résumer à partir d’informations admissibles, sans modifier un système externe.
2. Recommander ou proposer une action inspectable, sans l’exécuter.
3. Créer un brouillon dans un espace non définitif soumis à relecture.
4. Effectuer une écriture bornée et réversible sur des objets et champs autorisés.
5. Déclencher une action externe conséquente après autorisation et approbation précises.
6. Refuser toute décision expressément interdite, même si un utilisateur demande de l’approuver.

Avant une action conséquente, l’interface doit présenter une prévisualisation vérifiable et l’approbation doit être liée à l’acteur, à l’outil, à la ressource cible, aux paramètres normalisés, au moment et à l’expiration. Toute modification significative de la proposition impose une validation nouvelle. L’approbation ne fournit jamais une autorisation manquante et n’élargit pas les droits permanents. Paiements, attributions d’accès, suppressions, changements de production, engagements externes et jugements professionnels à fort enjeu doivent rester soumis aux personnes qualifiées et aux politiques déterministes appropriées.

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 des résultats explicites, avec de véritables conditions d’arrêt. La réponse indique simplement la limite sans révéler de règles sensibles et ne prétend jamais qu’une source, une approbation, un appel d’outil ou une écriture a réussi lorsque ce n’est pas le cas. Elle peut fournir la partie sans risque — par exemple un brouillon ou une liste de vérification — mais elle ne poursuit pas silencieusement l’exécution.

• Tâche hors périmètre ou information non admissible.
• Autorisation insuffisante ou approbation nécessaire.
• Preuve absente, inaccessible ou trop ancienne.
• Jugement spécialisé ou politique métier requis.
• Outil ou dépendance indisponible.
• Limite opérationnelle atteinte.
• Signal de sécurité détecté.

Le transfert doit réunir l’objectif initial, le contexte non sensible utile, la capacité tentée, le motif, les preuves disponibles ou manquantes, la prochaine étape proposée et un identifiant de trace. Sa destination dépend du problème : le support courant reçoit une demande utilisateur incomplète, le responsable métier traite une approbation, tandis que l’équipe de sécurité reçoit un signal d’élévation de privilèges, d’exfiltration ou de contournement. L’exécution reste suspendue et une proposition modifiée exige une nouvelle validation avant toute reprise.

Comment transformer ces limites en conception opérationnelle ?

L’équipe doit remplir une ligne de canevas par opération visible et relier chaque ligne à des contrôles exécutoires, des traces, des essais, des indicateurs et un propriétaire. Elle y consigne l’acteur admissible, l’authentification, l’enveloppe d’information, les règles de session et de mémoire, l’opération d’outil, l’identité agissante, les ressources, le plafond d’action, l’approbation, les limites opérationnelles, le refus, les preuves, les scénarios d’évaluation et la destination d’escalade. Le canevas reste une synthèse pratique : sa valeur vient de son raccordement au service, pas de la documentation seule.

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

La mise en service exige de montrer que les tâches autorisées réussissent et que les demandes interdites sont refusées, arrêtées ou transférées dans des conditions proches de l’exploitation. Les essais doivent couvrir les accès entre comptes, les outils non autorisés, les preuves anciennes, les contenus récupérés empoisonnés, les données interdites, le contournement d’approbation, les paramètres modifiés, les doublons, les pannes de dépendance, les tentatives d’exfiltration et les chaînes incontrôlées. Une campagne réussie n’est toutefois pas une garantie permanente.

• Reconstituer qui a demandé quoi, quelle capacité et quelle politique se sont appliquées, quelles classes de sources et d’outils ont été utilisées et quel résultat a suivi.
• Conserver les décisions d’autorisation et d’approbation ainsi que les versions actives, sans enregistrer de secrets ni un contexte sensible illimité.
• Suivre par capacité les usages d’outil inattendus, refus répétés, échecs d’autorisation, changements d’approbation, séquences anormales, dérive, latence, consommation et pannes.
• Nommer les responsables du service, des habilitations, des transferts métier et des incidents, avec l’autorité de suspendre, réviser ou retirer une capacité.

Toute modification matérielle d’un modèle, d’une consigne, de la recherche documentaire, de la mémoire, d’un outil, d’un droit, d’une politique, d’une donnée, d’un fournisseur ou du contexte d’exploitation doit rouvrir les essais et preuves concernés. Il est prudent de partir de la plus petite capacité utile, de n’élargir son autorité qu’au moyen d’un changement examiné et de consulter les responsables de la sécurité, des identités, de la confidentialité, des archives, des risques et du service. Les jugements juridiques, réglementaires ou professionnels à fort enjeu relèvent de spécialistes qualifiés et d’un processus gouverné séparément.