Les agents exposent les limites de la confiance

L'informatique d'entreprise dépend depuis longtemps de chaînes de confiance. Les organisations font confiance à leurs fournisseurs de cloud, à leurs éditeurs de logiciels, à leurs systèmes d'identité et à leurs administrateurs pour fonctionner comme prévu. Ce modèle a fonctionné parce que les humains sont restés les décideurs ultimes.

L’intelligence artificielle agentique change cette équation. Les systèmes autonomes peuvent récupérer des informations, prendre des décisions, invoquer des outils externes, collaborer avec d'autres agents et exécuter des actions au nom de l'entreprise. À mesure que les organisations délèguent davantage d’autorité aux systèmes intelligents, elles ont également besoin d’un moyen de déterminer si ces systèmes se comportent comme prévu.

La question n’est plus simplement de savoir si l’IA peut effectuer un travail complexe. Il s’agit de savoir si chaque action consécutive peut être examinée et vérifiée de manière indépendante. La prochaine ère de l’informatique d’entreprise sera définie non seulement par ce que les systèmes autonomes peuvent faire, mais aussi par la capacité des organisations à reconstruire et à vérifier ce qu’elles ont fait.

Les limites de la confiance

Un agent IA peut récupérer des informations sur plusieurs systèmes d'entreprise, les transmettre à un autre agent, invoquer un service externe et autoriser une action financière. Chaque composant individuel peut être sécurisé, mais l'entreprise peut toujours ne pas disposer d'un enregistrement complet et vérifiable de manière indépendante de la manière dont l'action finale s'est produite.

Les technologies de sécurité traditionnelles peuvent aider à déterminer qui était autorisé à agir, à quels systèmes ils pouvaient accéder et si un comportement inhabituel s'est produit. Les journaux traditionnels peuvent montrer qu'une interface de programmation d'application a été appelée ou qu'une transaction a eu lieu. Mais ces enregistrements ne reflètent pas nécessairement la chaîne complète des instructions, des apports, des décisions et des actions qui ont conduit à un résultat.

La question est de savoir si la confiance elle-même constitue un principe architectural suffisant pour un monde informatique autonome.

Une grande partie du débat actuel sur la cybersécurité commence par une question familière : à quelle plateforme devons-nous faire confiance ? C'est une question raisonnable. C'est aussi de plus en plus la mauvaise solution.

Les technologies de sécurité traditionnelles restent indispensables, mais elles ont été largement conçues pour protéger les systèmes en appliquant des politiques, en surveillant les comportements et en contrôlant l'accès. Ils ne peuvent pas, par eux-mêmes, établir quelles instructions et quelles données ont façonné le comportement d'un agent, reconstruire ses interactions à travers plusieurs systèmes ou démontrer que l'enregistrement qui en résulte n'a pas été modifié.

Les dirigeants d’entreprise devraient poser une question différente lorsque des agents sont impliqués : quelles preuves ce système produit-il, et ces preuves peuvent-elles être vérifiées de manière indépendante ? Si la réponse dépend principalement de la confiance accordée au fournisseur, à l’infrastructure ou au logiciel lui-même, alors l’entreprise continue de fonctionner selon les hypothèses de l’ère informatique précédente.

L'informatique autonome exige quelque chose de plus fort. Cela nécessite des systèmes capables de produire des preuves vérifiables de manière indépendante de ce qui leur a été demandé de faire, des informations qu’ils ont utilisées et des actions qu’ils ont entreprises. C'est la différence entre l'informatique fiable et l'informatique vérifiable.

De la confiance à la preuve

Cette transition ne nécessite pas l’abandon des pratiques actuelles en matière de cybersécurité. La gestion des identités, la protection des terminaux, la surveillance et l’application des politiques resteront indispensables. Mais ils s’inscrivent désormais dans un modèle architectural plus large dans lequel la vérification indépendante ajoute une base de confiance.

La première étape consiste à déterminer quel comportement doit être auditable. Toutes les interactions ne comportent pas le même niveau de risque. Les organisations doivent identifier les actions qui pourraient avoir des conséquences financières, opérationnelles, de sécurité ou réglementaires significatives et établir des normes de preuve plus élevées pour ces activités. Un agent résumant un document interne, par exemple, ne nécessite pas le même niveau de contrôle qu'un agent approuvant un paiement, modifiant le code de production ou accédant à des données réglementées.

Pour chaque action consécutive, les organisations doivent définir ce que l'agent peut faire, les conditions qu'il doit remplir avant d'agir et les circonstances qui nécessitent l'approbation humaine. Ces exigences créent une base de référence par rapport à laquelle le comportement réel de l'agent peut ensuite être évalué.

Cela devient particulièrement important à mesure que les agents commencent à agir au-delà des frontières organisationnelles et systémiques. La décision d'un agent peut dépendre des informations générées par un autre, qui peut lui-même s'appuyer sur un système externe. Sans chaîne vérifiable reliant ces événements, les organisations peuvent connaître le résultat sans être en mesure d’établir comment cela s’est produit.

La prochaine étape consiste à déterminer quelles preuves sont nécessaires pour reconstituer ces actions. Ces preuves doivent relier l'intention initiale au comportement de l'agent : ce que l'agent a été chargé ou autorisé de faire, à quelles informations il a accédé, quels outils il a invoqués, quelles décisions ou actions ont suivi et quel résultat en a résulté.

Selon le cas d'utilisation, l'enregistrement d'audit peut également devoir capturer l'utilisateur ou le système initiateur, les politiques et autorisations en vigueur, les communications avec d'autres agents, les appels de service externes, les événements d'approbation et toute modification apportée aux systèmes de l'entreprise. L’objectif n’est pas de conserver toutes les informations rencontrées par un agent, mais de conserver suffisamment de preuves pour reconstruire le comportement qui en résulte tout en respectant les exigences de confidentialité, de sécurité et de minimisation des données.

Étant donné que les agents opèrent rarement de manière isolée, les preuves doivent persister dans tous les systèmes. Un agent peut extraire des informations d'une base de données, recevoir des instructions d'un utilisateur, déléguer une tâche à un autre agent et appeler un service externe. Une piste d'audit qui s'arrête à l'application peut manquer des éléments critiques de la chaîne.

Chaque flux de travail consécutif doit avoir une identité cohérente et traçable reliant la demande d'origine aux délégations, appels d'outils, approbations et résultats ultérieurs. Les organisations doivent également déterminer les éléments probants qu'elles exigent des plateformes d'agents tiers et des services externes afin que la responsabilité ne disparaisse pas lorsqu'une action traverse les limites d'un système ou d'une organisation.

La dernière question est de savoir si les preuves elles-mêmes sont fiables.

Le rôle de la cryptographie

C’est là que les techniques cryptographiques peuvent s’avérer puissantes. Les organisations peuvent utiliser des signatures cryptographiques, des hachages et d'autres preuves pour établir l'intégrité et la provenance des enregistrements, des entrées et des sorties. Cela permet de démontrer que les preuves n'ont pas été altérées et qu'une action particulière est liée aux données et instructions qui lui sont associées.

Différents mécanismes répondent à différents besoins d'audit. Les signatures numériques aident à établir la source d'un enregistrement. Les hachages révèlent si les instructions, les entrées, les sorties ou les journaux ont été modifiés. Les attestations horodatées relient une action à une autorisation, une politique ou un état du système particulier. Des preuves cryptographiques plus avancées peuvent vérifier certaines affirmations concernant une action sans exposer toutes les informations sensibles qui la sous-tendent.

Mais la cryptographie n’est qu’une partie de l’équation. Un enregistrement protégé par cryptographie n’est pas utile si l’organisation ne détermine jamais ce qu’elle doit enregistrer en premier lieu. Un audit efficace des agents nécessite des contrôles clairement définis, une capture complète des événements, des relations traçables entre les actions et une vérification indépendante des preuves qui en résultent.

La cryptographie ne peut pas non plus déterminer uniquement si le jugement d'un agent était approprié ou si les données qu'il a reçues étaient exactes. Son rôle est d'établir l'intégrité et la provenance des preuves. Le niveau de vérification approprié doit correspondre aux conséquences de l'action, plutôt que d'appliquer les mêmes contrôles à chaque interaction d'un agent.

Les organisations doivent périodiquement essayer de reconstruire les actions conséquentes des agents en utilisant les preuves produites par leurs systèmes. Peuvent-ils déterminer ce que l'agent était autorisé à faire, les informations sur lesquelles il s'est appuyé, ses interactions avec d'autres systèmes et que l'enregistrement qui en résulte n'a pas été modifié ?

Les réponses à ces questions donnent aux équipes de sécurité un moyen d'enquêter sur les incidents, aux équipes de conformité un moyen de justifier leurs décisions et aux chefs d'entreprise un moyen d'évaluer si les systèmes autonomes fonctionnent dans les limites établies.

Construire cette capacité nécessite de prendre certaines décisions opérationnelles avant de déployer des agents. Il s'agit notamment des actions qui nécessitent un audit amélioré, des preuves qui doivent être capturées, de la durée pendant laquelle elles doivent être conservées, de la manière dont les enregistrements seront connectés entre les systèmes, qui peut y accéder et qui est responsable de leur examen. Les organisations doivent également établir un processus récurrent pour tester si les actions consécutives peuvent être reconstituées et pour corriger les lacunes révélées par les exercices.

Le changement le plus important concerne la conception de systèmes simplement fiables vers des systèmes dont le comportement conséquent peut être examiné et prouvé. S’ils ne le peuvent pas, ils ne sont peut-être pas encore prêts à bénéficier d’une autonomie conséquente.

Davis est co-fondatrice et directrice commerciale d'OpenMatter Network Inc. Elle a écrit cet article pour SiliconANGLE.

Newsletter

Rejoignez notre newsletter pour des astuces chaque semaine