Agent IA métier connecté au système d’information : permissions, traçabilité et sécurité

Un chatbot répond. Un agent peut choisir un outil, préparer des paramètres, déclencher une action et observer le résultat. Cette capacité ouvre des usages utiles : créer un ticket, préparer une commande, mettre à jour un dossier ou orchestrer une recherche. Elle change aussi la nature du risque. Une mauvaise réponse devient une opération réelle.

La sécurité d’un agent ne repose pas sur sa bonne volonté ni sur un prompt qui lui demande d’être prudent. Elle repose sur des outils bornés, des autorisations vérifiées, des validations, une idempotence et une traçabilité indépendantes du modèle.

Distinguer conversation, décision et exécution

Le système doit séparer :

1. l’intention exprimée par l’utilisateur ;
2. l’interprétation et le plan proposés par le modèle ;
3. la décision d’autoriser ;
4. l’exécution par un service déterministe ;
5. la vérification du résultat.

Le modèle peut suggérer. La couche de politique décide si l’outil est disponible, si l’utilisateur possède le droit et si une approbation est nécessaire. Le service métier valide les paramètres et applique les règles comme pour toute autre interface.

Propager l’identité de l’utilisateur

Un agent ne doit pas agir sous un compte administrateur générique. L’action doit être reliée à l’identité, à l’organisation et au contexte de la personne qui demande. Lorsque l’agent utilise un compte de service, il transporte une délégation vérifiable et limitée.

Les droits sont contrôlés à chaque outil et ressource. Une conversation antérieure ne constitue pas une autorisation durable. Les délégations expirent et ne peuvent pas être étendues par le modèle.

Concevoir des outils étroits

Un outil sûr correspond à une capacité métier précise : creer_brouillon_commande, rechercher_dossiers_autorises ou proposer_creneaux. Il possède un schéma d’entrée strict, des validations, un périmètre et un résultat structuré.

À l’inverse, un outil executer_sql, appeler_url ou lancer_commande donne au modèle un espace trop large. Même protégé par une consigne, il augmente fortement le risque d’exfiltration ou de destruction.

Les outils exposent le minimum de données et masquent les secrets. Ils n’acceptent pas de paramètres libres lorsqu’une liste autorisée est possible.

Classer les actions par niveau de risque

Une classification pragmatique peut distinguer :

• lecture de données déjà autorisées ;
• proposition sans modification ;
• création réversible en brouillon ;
• action avec confirmation de l’utilisateur ;
• action avec approbation indépendante ;
• action interdite à l’agent.

Le niveau dépend de l’impact, de la portée et de la réversibilité. Envoyer un brouillon à soi-même et envoyer un contrat à mille destinataires ne relèvent pas de la même politique.

Prévisualiser avant d’agir

Pour une action sensible, l’agent produit une représentation claire : objet, destinataires, données modifiées, montant, conséquences et possibilité de retour. L’utilisateur confirme l’action exacte, pas une formule vague comme « continue » après plusieurs échanges.

La confirmation expire et est liée à un hash des paramètres. Si l’agent modifie la commande, une nouvelle validation est nécessaire.

Appliquer l’idempotence

Les agents peuvent répéter un appel après un délai ou une réponse ambiguë. Chaque opération de création ou paiement utilise une clé d’idempotence et renvoie l’état d’une tentative existante.

L’outil distingue échec avant exécution, résultat inconnu et succès. Le modèle ne doit pas deviner qu’une opération a échoué et la relancer librement.

Vérifier le résultat

Une réponse HTTP réussie ne garantit pas que l’objectif métier est atteint. Après l’exécution, le système relit l’état, vérifie les invariants et compare le résultat attendu.

L’agent annonce seulement ce qui est confirmé. Il peut dire qu’une demande est « enregistrée et en attente » plutôt que « traitée » lorsque le workflow n’est pas terminé.

Prévoir la compensation

Certaines actions peuvent être annulées ; d’autres nécessitent une opération inverse ou une intervention. Chaque outil documente :

• fenêtre d’annulation ;
• compensation possible ;
• données à conserver ;
• responsable ;
• communication à envoyer.

Une transaction financière ou un message externe peut être difficilement réversible. Le seuil d’approbation doit en tenir compte.

Défendre contre la prompt injection

Les emails, pages et documents consultés peuvent contenir des instructions malveillantes. Le système les traite comme des données. Ils ne peuvent pas modifier la liste d’outils, les politiques ou les secrets.

Les données récupérées sont délimitées, les actions nécessitent des règles indépendantes et les sorties sont filtrées avant d’être utilisées comme paramètres. Une instruction provenant d’un contenu externe ne peut pas déclencher une approbation.

Limiter l’exfiltration

Un outil d’envoi ou de stockage externe peut servir à exfiltrer des données. Les destinations sont contrôlées : domaines, comptes, canaux et volumes. Les pièces jointes et champs sensibles sont détectés selon la politique de l’organisation.

L’agent ne reçoit pas les secrets d’API. Les connecteurs les utilisent côté serveur et ne les renvoient jamais dans les résultats.

Mémoire et contexte

La mémoire conversationnelle peut mélanger des dossiers, utilisateurs ou périodes. Chaque élément mémorisé possède un propriétaire, un périmètre et une durée. Les données sensibles ne sont pas conservées par défaut.

Avant une action, les paramètres critiques sont relus depuis la source de vérité, pas depuis un résumé de conversation potentiellement ancien.

Journal d’audit

Le journal doit permettre de reconstruire :

• demande et identité ;
• version de politique ;
• plan et outils sélectionnés ;
• paramètres validés ;
• approbations ;
• appels et résultats ;
• vérification ;
• erreur ou compensation.

Les prompts complets ne doivent pas être conservés sans nécessité. La journalisation respecte minimisation, droits d’accès et durée de conservation.

Environnements et limites

Les agents de test n’utilisent pas les outils de production. Les actions sont limitées par montant, volume, fréquence, horaire et périmètre. Un mécanisme de coupure permet de désactiver un outil ou un agent rapidement.

Les appels sortants, téléchargements et exécutions de code peuvent être placés dans des environnements isolés avec réseau et durée limités.

Tester les scénarios adverses

Les tests incluent :

• instruction malveillante dans un document ;
• utilisateur sans droit ;
• cumul de rôles ;
• paramètre hors schéma ;
• répétition après délai ;
• outil indisponible ;
• réponse partielle ;
• tentative d’envoyer à une destination interdite ;
• approbation périmée ;
• changement de paramètres après validation.

Les comportements attendus sont automatisés lorsque possible et rejoués à chaque changement de modèle ou prompt.

Superviser l’autonomie

Les indicateurs suivent taux d’actions proposées, approuvées, modifiées, échouées, annulées et compensées. Les écarts entre plan et résultat sont analysés. Un volume inhabituel ou une nouvelle destination déclenche une alerte.

L’autonomie peut être augmentée progressivement pour un outil stable, sur des montants et populations limités. Elle peut aussi être réduite immédiatement.

Construire un premier cas d’usage

Le meilleur pilote est fréquent, borné, réversible et mesurable. Par exemple : rechercher des informations autorisées, préparer un brouillon, demander une validation puis créer une tâche. Il évite les paiements, suppressions massives ou décisions réglementaires.

Le pilote établit les fondations réutilisables : identité, policy engine, registre d’outils, approbation, audit et observabilité.

L’agent comme nouvel utilisateur du SI

Un agent doit être traité comme un acteur à haut niveau d’automatisation, soumis à davantage de contrôles, pas à moins. Les règles métier restent dans les services, les pouvoirs sont limités et chaque action est prouvable.

Partitech peut concevoir des agents reliés à des applications, API et données, avec des outils étroits, une gouvernance des permissions et une validation humaine. La valeur vient de l’automatisation sûre d’un processus, non du nombre d’outils accessibles au modèle.

Parlons de votre projet

Identifier et sécuriser un premier processus agentique avec Partitech. Contactez Partitech.