Agents IA, identités compromises, dépendances logicielles : concevoir des défenses qui tiennent

Résumer avec

Un agent IA utilise une permission légitime pour transmettre des données à la mauvaise destination. Un compte de maintenance reste actif après la suspension de son propriétaire. Une mise à jour signée introduit un composant dangereux. Dans ces situations, ajouter une alerte ne suffit pas toujours : il faut parfois revoir la manière dont le système autorise, exécute et contrôle les actions. Nous présentons ici les éléments d’une série qui comprendra cinq exercices de conception appliqués à des problèmes de cybersécurité.

La méthode C-K au service de l’architecture de cybersécurité

Jean Langlois-Berthelot et Clémence Foufa

Lorsque le contrôle existe, mais ne protège pas l’action

La difficulté commence souvent par une phrase rassurante : « l’accès est authentifié ». Cette information compte. Elle ne permet pourtant pas de conclure que l’opération est légitime. Un attaquant peut utiliser un compte compromis. Un service peut disposer de permissions excessives. Un agent logiciel peut agir avec ses propres droits à la suite d’une instruction qu’il n’aurait jamais dû accepter.

La sécurité des applications d’IA rend cette distinction particulièrement visible. L’OWASP distingue, dans son édition 2025, l’injection de prompt et les risques liés à une capacité d’action excessive. Un contenu externe peut influencer le comportement du modèle ; les outils et les permissions de l’application déterminent ensuite ce que ce comportement peut provoquer. La question de sécurité dépasse donc la formulation de la réponse produite par l’IA. Elle concerne les accès aux données, les appels d’outils et les actions effectivement exécutées. [1, 2]

Considérons un agent de maintenance qui consulte des tickets et des journaux techniques. Sa mission est de comprendre un incident puis de proposer, ou d’effectuer, certaines réparations. Si un ticket malveillant le conduit à demander un export documentaire, le problème traverse plusieurs composants : la lecture du ticket, la décision du modèle, le connecteur documentaire et le service de transmission. Un contrôle placé sur un seul de ces passages peut laisser les autres ouverts.

Il faut alors poser une question d’architecture : comment conserver un service de maintenance utile sans lui permettre de transformer n’importe quelle information consultée en autorisation d’agir ? La réponse peut exiger une nouvelle répartition des responsabilités entre le modèle, les connecteurs, le moteur d’autorisation et l’opérateur humain. C’est sur ce travail que portera notre série.

C-K : développer une solution et les connaissances qui lui manquent

La théorie C-K, développée notamment par Armand Hatchuel et Benoît Weil, distingue deux espaces : les concepts, C, et les connaissances, K. Un concept décrit un objet dont on ne peut pas encore établir les propriétés avec les connaissances disponibles. Le travail de conception développe cet objet tout en produisant les connaissances nécessaires pour le préciser. [3]

Dans notre cas, le point de départ serait : « un agent capable de contribuer à la résolution d’un incident sans qu’un ticket consulté puisse lui accorder des droits supplémentaires ». Cette formulation décrit une fonction et une exigence. Elle ne dit pas encore quel dispositif les réunira. L’équipe doit ouvrir plusieurs pistes, puis déterminer ce qu’il faut apprendre pour les comparer.

Les connaissances de départ sont très concrètes. Quels outils l’agent peut-il appeler ? Sous quelle identité ? Quels documents peut-il lire ? Quelles destinations peut-il joindre ? Qui choisit les paramètres d’une opération ? Les journaux permettent-ils de relier un ticket à une lecture de document puis à un envoi ? Une réponse inconnue reste une question à traiter ; elle ne devient pas une propriété sûre parce qu’un schéma la représente.

La démarche ne consiste pas à renommer une revue d’architecture. Elle doit permettre d’envisager un objet différent de celui que l’équipe croyait devoir protéger. Par exemple, nous pouvons remettre en cause l’idée qu’un agent de maintenance aurait nécessairement besoin d’un accès direct à la production. Il pourrait travailler sur des observations filtrées et préparer une réparation dont l’exécution dépendrait d’un composant distinct.

Ce changement ouvre une possibilité, mais crée aussi une difficulté : l’agent disposera-t-il encore d’assez d’informations pour être utile ? La question de sécurité conduit à une question de connaissance. Il faudra comparer la qualité du diagnostic avec différents jeux d’observations. La méthode C-K organise cet aller-retour entre une propriété recherchée et les essais qui permettront d’en apprécier la faisabilité.

Trois façons de déplacer la frontière de confiance

Une première piste agit sur les droits. Au lieu d’un compte permanent capable de consulter de nombreuses ressources, l’application pourrait recevoir une autorisation limitée à une tâche et à certains objets. Une intervention sur un service donné ne donnerait pas automatiquement accès aux documents d’un autre client. L’équipe doit vérifier si les connecteurs et les services cibles peuvent réellement appliquer cette limitation.

Une deuxième piste sépare la proposition de l’exécution. Le modèle prépare une demande structurée ; un service distinct décide si cette demande respecte les règles prévues. Le modèle ne choisit pas lui-même les règles ni les droits qui permettent de les contourner. Il faut cependant examiner toute la chaîne : si un connecteur reste joignable directement, la séparation affichée dans l’interface peut être sans effet.

Une troisième piste change l’environnement de travail. L’agent reçoit une copie filtrée des éléments nécessaires, prépare une action dans un espace de test et ne possède aucun secret de production. Un autre composant applique une action déterminée après les contrôles requis. Cette piste réduit certains accès, mais sa valeur dépend de la fidélité des informations fournies et de la maîtrise du passage vers la production.

Ces propositions mobilisent des mécanismes de sécurité connus. Leur simple présence ne prouve pas l’intérêt de C-K. Le travail de conception porte sur la combinaison de propriétés que l’organisation cherche encore à obtenir : un diagnostic utile, des permissions étroites, une exécution contrôlée et un délai acceptable. L’exercice devient intéressant lorsque les essais obligent à modifier cette combinaison, voire la fonction initialement demandée.

L’architecture zero trust du NIST fournit un repère pour centrer les contrôles sur les ressources et distinguer authentification et autorisation. Elle ne livre pas une solution prête à déployer pour chaque agent. [4] L’équipe doit traduire ces principes en décisions vérifiables : quel composant refuse quelle opération, sur quelle information et avec quelle trace ?

Évaluer ce qui reste possible pour l’attaquant

Une proposition de défense doit être confrontée à un adversaire défini. Dans le premier exercice, celui-ci pourra déposer un contenu dans un ticket, mais ne disposera pas d’un compte administrateur. Son objectif sera de détourner l’agent afin d’obtenir une lecture ou une transmission qui dépasse la mission de maintenance. Cette limite permet de comprendre ce que la protection est censée empêcher.

L’équipe pourra alors suivre une tentative étape par étape. Le contenu a-t-il influencé le modèle ? Une demande d’outil a-t-elle été produite ? Le service cible l’a-t-il accepté ? Des données ont-elles été lues ? Une transmission a-t-elle eu lieu ? Ces événements ne sont pas équivalents. Un refus de sortie réseau ne signifie pas qu’aucun document sensible n’a été consulté auparavant.

Il faut également examiner les chemins secondaires. Un outil de messagerie peut transmettre des données sans utiliser le navigateur de l’agent. Une pièce jointe peut quitter le système par le service de support déjà autorisé. Une permission générale sur un dépôt peut rendre inutile une tentative d’élévation de privilèges. La conception doit porter sur les chemins disponibles, pas seulement sur celui imaginé dans la première démonstration.

À chaque propriété annoncée correspond donc un essai. Pour un accès limité à une tâche, on tente une lecture hors périmètre. Pour un contrôle d’exécution, on cherche un appel qui l’éviterait. Pour une séparation entre clients, on vérifie qu’un objet d’un autre espace reste inaccessible. Les données utilisées sont fictives ou prévues pour le test ; l’objectif est de mesurer les contrôles sans exposer des informations réelles.

L’évaluation doit aussi conserver des tâches légitimes. Un système qui refuse toute action peut bloquer la tentative et rendre le service inutilisable. L’équipe mesurera séparément les opérations interdites effectivement bloquées, les tâches utiles accomplies et les interventions humaines nécessaires. Elle pourra ainsi discuter un compromis réel, au lieu de présenter un taux de refus isolé comme un résultat suffisant.

Produire une décision d’architecture, pas une collection d’idées

Le compte rendu d’un exercice C-K doit permettre de comprendre le chemin parcouru. Il conserve la fonction recherchée, les pistes examinées, les connaissances acquises et les raisons d’un abandon. Une proposition peut être écartée parce qu’un connecteur ne permet pas de limiter ses droits. Une autre peut être modifiée parce que la copie de travail ne suffit pas au diagnostic. Ces résultats orientent les développements suivants.

Une décision de sécurité doit également désigner son point de contrôle. Dire « l’agent ne doit pas accéder aux secrets » n’est pas encore une architecture. Dire « le service documentaire applique la restriction avant de renvoyer les objets, indépendamment du texte produit par le modèle » rend l’exigence examinable. Il reste à tester son application et les autres chemins d’accès.

Le retour d’expérience peut aussi révéler un besoin nouveau. Si l’opérateur reçoit trop de demandes d’approbation, l’équipe doit chercher une autorisation plus précise ou une meilleure présentation des effets. Ajouter une confirmation à chaque écran ne garantit pas une attention soutenue. La conception peut porter sur l’objet soumis à approbation : une action bornée, avec les ressources concernées et les conséquences attendues.

Nos cinq exercices exploreront des terrains distincts : les agents de maintenance, la restauration après une compromission d’identité, la distribution de correctifs à des équipements isolés, le partage d’indicateurs entre organisations et l’observation d’un réseau industriel. Les situations changeront ; chacune posera une question de cybersécurité que le choix immédiat d’un produit ne suffit pas à résoudre.

Cette proposition prolonge notre travail commun sur l’innovation de sécurité et de défense. Elle s’adresse aux équipes qui doivent préparer une architecture, justifier une évolution ou choisir un essai avant d’investir. C-K apporte un cadre pour ouvrir les possibilités et organiser les connaissances manquantes. La sécurité de la solution restera à établir par l’analyse, l’ingénierie et les tests. C’est cette articulation que nous voulons rendre accessible aux lecteurs d’INCYBER.