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

La vraie limite d’un assistant IA est le contrat de service exécutable qui entoure le modèle, et non une interdiction inscrite dans son message système. Si un outil et un justificatif d’identité lui permettent d’envoyer un message, lui demander de ne pas le faire ne constitue pas un contrôle d’autorisation. Une conception bornée sépare donc chaque opération visible, puis lui attribue ses propres données, permissions, plafonds d’action, preuves, essais et responsables. Cette discipline rend le service vérifiable avant son lancement et gouvernable lorsque ses composants changent.

Que devrait-on permettre à l’assistant de faire?

L’équipe devrait d’abord rédiger une charte de service d’une phrase, puis la diviser en capacités précises assorties de non-objectifs explicites. Une formulation utile est la suivante : « Pour les utilisateurs admissibles, l’assistant peut accomplir telle famille de tâches à partir de telle information approuvée afin de produire tel résultat, mais il ne peut pas prendre telles décisions ni produire tels effets. » Cette méthode est une synthèse éditoriale inspirée des principes du NIST et d’OWASP; elle n’est pas une exigence officielle de ces organismes.

• Remplacer « aider » ou « gérer » par des opérations observables : chercher, résumer, recommander, rédiger, modifier, envoyer, supprimer ou approuver.
• Nommer les utilisateurs admissibles, le milieu de déploiement, les tâches soutenues et les limites de connaissance.
• Préciser la supervision humaine, le propriétaire du risque et les résultats expressément interdits avant de brancher un outil.
• Créer une capacité distincte dès que l’opération exige une autre donnée, une autre identité, un autre pouvoir ou un autre responsable.
• Commencer par la plus petite capacité utile; une extension ouverte ou polyvalente ne devrait pas être le point de départ par défaut.

Quelles informations chaque capacité peut-elle utiliser?

Une limite de contexte devrait être une enveloppe d’information, pas seulement un nombre maximal de jetons. Pour chaque capacité, elle détermine les systèmes, types de dossiers, classifications, filtres d’objets, périodes, exigences de fraîcheur et droits de l’utilisateur qui rendent une donnée admissible. Un document récupéré, une pièce jointe ou une réponse d’API reste du contenu non fiable : il peut éclairer une réponse, mais ne doit pas devenir silencieusement une nouvelle instruction de service. Une grande fenêtre de contexte ne crée ni autorité ni preuve.

• Séparer l’historique temporaire de la session de toute mémoire persistante; chacun exige sa propre règle d’admissibilité.
• Isoler les utilisateurs et les sessions, valider l’information avant sa persistance et protéger son intégrité.
• Fixer la taille, l’expiration, l’effacement et la conservation selon le risque, la vie privée et les besoins du service, sans seuil universel.
• Exclure explicitement les secrets, les justificatifs d’identité et toute catégorie de données que la capacité ne doit jamais mémoriser.
• Refuser ou nuancer la réponse lorsque la preuve nécessaire est inaccessible, manquante ou périmée, plutôt que de combler le vide.

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

L’authentification, l’autorisation et l’approbation doivent être traitées comme trois décisions séparées. La première établit qui agit; la deuxième permet une opération sur une ressource protégée; la troisième accepte une action proposée précise. La passerelle d’outils et le système cible doivent appliquer ces décisions selon l’identité agissante. Une consigne en langage naturel peut guider le comportement du modèle, mais elle n’est pas un contrôle d’accès. Il faut aussi choisir consciemment entre l’autorité déléguée de l’utilisateur et une identité de charge de travail contrôlée.

• Exposer une opération étroite avec des paramètres validés, plutôt qu’un accès général à une boîte courriel, une base de données, un navigateur ou un terminal.
• Limiter les verbes, ressources, objets, champs, destinations, durées de justificatifs d’identité et auditoires de jetons dans le chemin d’exécution.
• Préserver le contexte d’autorisation de l’utilisateur lorsqu’une action est accomplie en son nom; ne jamais emprunter tacitement le compte privilégié d’un opérateur.
• Définir selon le service les limites de débit, de reprise, de chaîne, de lot, de coût et de durée, ainsi que l’idempotence, le retour arrière et le coupe-circuit.
• Pour une intégration MCP protégée, appliquer ses règles de portée minimale et de ressource cible sans prétendre qu’elles régissent toutes les architectures d’outils.

Une conversation peut sembler continue, mais son autorité doit rester divisée en petites capacités appliquées séparément.

ModelFold Editorial Team

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

Chaque capacité a besoin d’un plafond d’action explicite, accompagné de contrôles indépendants plus forts à mesure qu’elle se rapproche d’un changement externe conséquent. L’échelle pratique ci-dessous est une synthèse éditoriale, non une norme. Elle empêche notamment qu’une permission de rédiger devienne une permission d’envoyer ou qu’une proposition se transforme en décision. Pour une action conséquente, l’utilisateur doit voir une prévisualisation vérifiable, et l’exécution doit valider l’acteur, l’outil, la cible, les paramètres, le moment et l’expiration de l’approbation.

1. Répondre ou résumer à partir de données admissibles, sans modifier un état externe.
2. Recommander ou proposer une prochaine étape clairement présentée comme telle.
3. Créer une ébauche modifiable dans un espace non final, sans engagement externe.
4. Effectuer une écriture bornée et réversible sur des objets et champs approuvés.
5. Déclencher une action externe conséquente seulement avec autorisation, approbation précise et politique d’exécution indépendantes.
6. Refuser une décision interdite, même si quelqu’un tente de l’approuver dans la conversation.

Une approbation ne fournit jamais l’autorisation manquante, n’élargit pas une permission permanente et ne rend pas admissible une décision interdite. Les paiements, octrois d’accès, suppressions, changements en production, engagements externes importants et jugements professionnels à forts enjeux doivent rester sous le contrôle déterministe et humain qualifié que l’organisation juge approprié. Le modèle peut préparer l’information ou une proposition, mais il ne doit pas contourner le processus gouverné qui porte la responsabilité de la décision.

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

Le refus, l’aide partielle sécuritaire, le transfert humain et l’escalade de sécurité doivent être conçus comme de véritables résultats du service, avec une condition d’arrêt. L’assistant explique sobrement la limite sans révéler une politique sensible et ne prétend jamais qu’un appel d’outil, une vérification, une approbation ou une écriture a réussi. Il peut offrir la portion permise, demander l’information manquante ou préparer une ébauche, mais toute exécution en attente demeure arrêtée jusqu’à l’intervention du responsable approprié.

• Utiliser des motifs stables : tâche hors portée, information inadmissible, autorisation insuffisante, approbation requise, preuve manquante ou périmée, jugement spécialisé requis, dépendance indisponible, limite opérationnelle ou signal de sécurité.
• Transmettre l’objectif original, le contexte non sensible utile, la capacité tentée, le motif, la preuve disponible ou manquante, la prochaine étape et un identifiant de trace.
• Acheminer un soutien courant vers le propriétaire du service, une approbation d’affaires vers la personne responsable et un signal de sécurité vers la voie d’incident.
• Exiger une nouvelle validation si la cible, le contenu ou tout autre paramètre de l’action change pendant l’attente.
• Prévoir des essais pour le contournement d’approbation, l’élévation de privilèges, l’exfiltration, l’empoisonnement de mémoire et les chaînes récursives.

Comment transformer ces limites en conception opérationnelle?

Les équipes devraient remplir une ligne de canevas par opération visible et relier chacune à des contrôles applicables, une trace, des scénarios d’essai, des signaux de production et un responsable habilité à intervenir. La ligne précise l’acteur admissible, l’authentification, l’enveloppe d’information, la session et la mémoire, l’opération d’outil, l’identité agissante, la portée des ressources, le plafond d’action, l’approbation, les limites d’exploitation, le refus et le transfert. Le canevas est une synthèse pratique : il ne vaut que si ses champs correspondent au service réellement exécuté.

• Faire reconstruire chaque résultat à partir des identifiants de requête, capacité, politique, source, outil, autorisation, approbation, version et résultat.
• Occulter les secrets et limiter le contenu sensible des journaux selon les exigences de sécurité, de vie privée et de gestion documentaire.
• Nommer séparément les propriétaires du comportement du service, des droits d’accès, des décisions d’affaires et des incidents de sécurité.
• Donner aux responsables l’autorité de suspendre, corriger ou retirer une capacité lorsque les preuves ou les contrôles deviennent insuffisants.

Quelles preuves faut-il pour lancer et maintenir l’assistant?

La mise en service exige des preuves que les tâches permises réussissent et que les refus attendus fonctionnent dans des conditions ressemblant au déploiement. Les essais doivent couvrir l’accès intercomptes, l’outil non autorisé, la preuve périmée, le contenu récupéré empoisonné, les données interdites, le contournement d’approbation, les paramètres modifiés, les reprises en double, la panne d’une dépendance, l’exfiltration et les chaînes incontrôlées. Les limites et modes de défaillance connus doivent être communiqués aux personnes qui exploitent et utilisent le service.

• Rendre reconstructibles le demandeur, la capacité, la politique, les classes de sources et d’outils, les décisions d’autorisation et d’approbation, le résultat et les versions actives.
• Surveiller par capacité l’usage inattendu d’outils, les refus répétés, les échecs d’autorisation, les approbations modifiées, les séquences anormales, la dérive, la latence, les ressources et les pannes.
• Recueillir uniquement les données nécessaires à ces questions opérationnelles; un journal utile n’est pas une permission de conserver indéfiniment tous les messages ou secrets.
• Attribuer des responsables capables de suspendre le service, de réviser un droit, de traiter un transfert d’affaires ou de déclencher la réponse à un incident.
• Rouvrir les essais touchés après une modification importante au modèle, aux instructions, à la récupération, à la mémoire, aux outils, aux permissions, aux politiques, aux données, au fournisseur ou au contexte d’exploitation.

Le meilleur point de départ est la plus petite capacité qui apporte une valeur observable. Son autorité ne devrait augmenter qu’au moyen d’un changement révisé, accompagné de preuves renouvelées, plutôt que par une simple retouche au message système. Lorsqu’une capacité touche des renseignements sensibles, une mémoire persistante, un accès privilégié, une suppression, un engagement externe ou une réponse à incident, il faut associer les responsables concernés de la sécurité, de l’identité, de la vie privée, des dossiers, du risque et du service. Les jugements juridiques, réglementaires ou autrement spécialisés doivent suivre un processus distinct avec des spécialistes qualifiés.