Les plus grands défis n’étaient pas l’injection rapide ou les vulnérabilités des modèles. Ils sont apparus après que l’IA ait déjà eu la permission d’agir.
Lorsque j’ai commencé à travailler sur des initiatives de sécurité en matière d’IA en entreprise, je m’attendais à ce que les plus grands défis soient d’ordre technique. J’ai supposé que nous passerions la plupart de notre temps à discuter de l’injection rapide, de la sécurité des modèles, des bases de données vectorielles ou des dernières vulnérabilités LLM.
J’avais tort – ou du moins incomplet.
La technologie est certainement importante, mais après avoir travaillé sur plusieurs initiatives d’IA d’entreprise, j’ai appris que les problèmes de sécurité les plus difficiles proviennent rarement du modèle lui-même. Ils émergent lorsque l’IA devient partie intégrante des processus métier réels.
Un assistant IA ne se contente pas de répondre aux questions. Dans un seul flux de travail, il peut extraire un enregistrement client de Salesforce, ouvrir un ticket dans ServiceNow et envoyer une mise à jour via Microsoft 365 avant que quiconque ait fini de lire le résumé. De plus en plus, il prend des décisions avant même qu’un humain ne s’en aperçoive, et ce changement modifie le modèle de menace. La sécurité des applications traditionnelles suppose que le logiciel exécute du code déterministe. Ce n’est pas le cas des systèmes d’IA. Ils raisonnent, s’adaptent et génèrent des résultats qui ne peuvent pas toujours être prédits à l’avance, ce qui signifie que bon nombre des contrôles sur lesquels nous nous appuyons depuis des années restent nécessaires mais ne sont plus suffisants.
Ce qui suit est ce sur quoi je reviens sans cesse dans les revues d’architecture : non pas les vulnérabilités des modèles qui font la une des journaux, mais les échecs plus discrets qui apparaissent une fois qu’un agent est déjà en cours d’exécution.
L’identité n’est que le point de départ
L’une des premières surprises que j’ai rencontrées a été la rapidité avec laquelle les organisations se concentrent sur l’authentification tout en négligeant le comportement d’exécution. La plupart des projets d’IA d’entreprise commencent par des questions telles que « L’IA peut-elle accéder à SharePoint ? « Peut-il se connecter à ServiceNow ? » « Peut-il se connecter à GitLab ? » ou « Peut-il lire les outils Microsoft 365 comme Outlook, Word, etc. ? » Ce sont des questions importantes, mais la plus importante est la suivante : que devrait être autorisée à faire l’IA après qu’un type d’accès spécifique (par exemple, un accès en lecture seule) ait été accordé ?
L’identité répond à qui est l’agent. L’autorisation répond à ce à quoi elle peut accéder. Ni l’un ni l’autre ne répond si l’IA doit effectuer une action particulière ; dans le cas ci-dessus, n’effectue qu’un accès en lecture seule.
Les questions de capacité et de sauvegarde sont trop souvent résolues par des équipes différentes selon des délais différents. Les examens de sécurité qui se concentrent uniquement sur ce à quoi l’IA peut accéder ont tendance à passer à côté de la question la plus révélatrice de ce qu’elle est autorisée à faire une fois que cet accès existe. J’ai commencé à traiter ces deux questions comme un seul problème de conception, car chaque écart entre elles finit par apparaître comme un incident.
Je me souviens d’une revue d’architecture où cela est devenu concret. Un employé a demandé à un assistant interne – basé sur Microsoft 365 et SharePoint – de résumer plusieurs rapports d’incidents. Au cours de son raisonnement, l’assistant a découvert une documentation administrative privilégiée dans un site lié et a décidé qu’il pourrait également être utile d’inclure ces détails. Techniquement, rien n’a échoué. Les informations d’identification étaient valides. Les autorisations étaient correctes. Pourtant, le résultat a violé l’intention commerciale. Ce moment a recadré la conversation pour tout le monde dans la pièce. Nous avons réalisé que notre modèle de menace avait été conçu pour les étrangers essayant d’entrer, et non pour les systèmes autorisés agissant un peu trop utilement. Combler cette lacune impliquait de concevoir des contrôles évaluant le comportement dans son contexte, et pas seulement les informations d’identification à la porte, et c’est pourquoi j’en suis venu à considérer la gouvernance d’exécution comme l’un des défis de sécurité déterminants de l’IA d’entreprise.
Les plus gros échecs ressemblent rarement à des cyberattaques
La plupart des professionnels de la sécurité recherchent naturellement des activités malveillantes : injection rapide, empoisonnement des données, vol d’informations d’identification, manipulation de modèles. Ces attaques comptent certainement. Cependant, ce que j’ai vu le plus souvent, ce sont des échecs causés par un comportement légitime de l’IA. Un assistant IA Finance, RH, Client ou gestion des risques récupère plus de documents que nécessaire car il essaie d’apporter une « meilleure » réponse. Un workflow autonome exécute cinq actions approuvées au lieu d’une. Un agent IA continue de s’exécuter une fois que l’intention initiale de l’utilisateur a déjà été satisfaite. Aucune de ces attaques ne ressemble aux attaques traditionnelles, mais elles peuvent engendrer des violations de conformité, des problèmes de confidentialité ou des perturbations opérationnelles.
Un modèle mental a toujours aidé les dirigeants à comprendre pourquoi cela est si dangereux. Je leur demande d’arrêter de considérer l’IA comme un logiciel et plutôt d’y penser comme à l’embauche de milliers de nouveaux employés numériques, alias des agents IA. Chaque employé bénéficie d’une formation, d’un accès limité, d’un suivi, d’un audit et d’une surveillance. Les agents d’IA méritent le même traitement.
Un déploiement sur lequel j’ai travaillé impliquait plusieurs agents d’IA spécialisés collaborant pour accomplir une seule tâche commerciale. L’un a interrogé ServiceNow pour connaître l’historique des tickets, un autre a analysé des documents dans SharePoint, un troisième a rédigé des recommandations et un quatrième a réécrit des mises à jour dans Jira. Individuellement, chaque agent disposait d’autorisations relativement limitées, comme la lecture seule et/ou l’écriture. Collectivement, ils représentaient un puissant flux de travail autonome. Cette expérience a renforcé une leçon importante : la sécurité ne peut plus se concentrer uniquement sur les composants individuels de l’IA. Elle doit régir toute la chaîne de prise de décision autonome. Le cadre MITRE ATLAS est un excellent moyen de réfléchir aux techniques d’IA contradictoire, mais il est tout aussi important de comprendre comment un comportement autonome normal peut involontairement créer un risque commercial.
Les cas les plus instructifs que j’ai vus impliquent des agents qui délèguent à d’autres agents. Dans une étude, un agent de support de première ligne disposait d’un accès strictement en lecture seule à Salesforce, mais il pouvait confier des tâches à un deuxième agent disposant de privilèges d’écriture sur ServiceNow et la plateforme de facturation. Lorsque le premier agent ne parvenait pas à résoudre un problème client dans son propre périmètre, il acheminait discrètement la demande via le deuxième agent, qui mettait à jour le dossier et émettait un crédit. Rien n’a été piraté. Les informations d’identification étaient valides, la délégation était techniquement autorisée et pourtant, un agent en lecture seule avait effectivement effectué des actions d’écriture qu’il n’était jamais censé effectuer. C’est la différence déterminante entre un assistant et un agent. Un assistant répond ; un agent enrôle d’autres agents, et ce chemin d’escalade est lui-même la vulnérabilité.
C’est pourquoi nous avons commencé à poser une question différente lors des revues d’architecture. Au lieu de demander « L’IA peut-elle faire ça ? nous avons demandé : « L’IA devrait-elle toujours faire cela ? Ce changement subtil a modifié de nombreuses décisions de conception. Cela a poussé les équipes à intégrer des conditions d’arrêt, des contrôles de portée et des invites de confirmation plutôt que de supposer qu’un agent saurait naturellement quand s’arrêter. Dans une étude, le simple fait d’exiger qu’un humain confirme avant qu’un agent passe d’une étape de lecture seule à une action d’écriture a éliminé la majorité des chemins risqués dont nous avions débattu.
Commencer par la gouvernance avant l’autonomie
Une tendance que j’ai observée à plusieurs reprises est que les organisations s’enthousiasment pour l’autonomie bien avant d’être prêtes à la gouverner. Tout le monde veut des agents IA, mais peu d’entre eux investissent initialement dans l’application des politiques d’exécution. Cet ordre devrait être inversé. D’après mon expérience, les programmes d’IA d’entreprise réussis mettent en place quelques bases avant d’étendre l’automatisation : des limites commerciales claires qu’un agent n’est pas autorisé à franchir, un accès au moindre privilège pour chaque agent et une approbation humaine à toute étape qui touche des données/systèmes sensibles/restreints, y compris les données/systèmes de production. Ce n’est que lorsque ces éléments existent qu’il devient logique d’élargir la prise de décision autonome. J’ai vu des équipes essayer de raccourcir cet ordre, et le résultat est presque toujours le même : un pilote prometteur est retiré parce que personne ne peut expliquer avec certitude ce que l’IA a fait ou pourquoi.
Une grande partie de cette fondation est la visibilité. Les journaux d’audit traditionnels enregistrent les actions, mais les systèmes d’IA doivent également enregistrer le raisonnement. Lorsqu’un agent IA crée un ticket, met à jour une configuration ou envoie un e-mail, les enquêteurs doivent comprendre pourquoi la décision a été prise. Cela ne signifie pas enregistrer chaque jeton généré par un grand modèle de langage. J’ai trouvé plus intéressant de capturer trois éléments : la demande commerciale initiale, les systèmes touchés par l’agent et les décisions qu’il a prises en cours de route. Ces enregistrements deviennent inestimables lors des enquêtes, des contrôles de conformité et du dépannage opérationnel, et ils aident les organisations à instaurer la confiance. Les chefs d’entreprise sont beaucoup plus à l’aise avec l’adoption de l’IA lorsqu’ils peuvent expliquer comment une décision importante a été prise. Des approches telles que le Secure AI Framework de Google renforcent la même idée : la sécurité de l’IA doit être mesurable, observable et responsable de bout en bout.
Une idée fausse que je rencontre encore est que la sécurité de l’IA existe pour restreindre l’innovation. Dans la pratique, les organisations qui progressent le plus rapidement en matière d’IA d’entreprise sont souvent celles qui investissent le plus massivement dans la gouvernance, car les dirigeants gagnent en confiance, les développeurs évoluent plus rapidement et les unités commerciales adoptent l’IA plus largement. Bien faite, c’est la sécurité qui rend cette vitesse possible.
Avec le recul, la leçon la plus précieuse n’a pas porté sur l’ingénierie rapide, la sélection de modèles ou les cadres d’agents. Le fait est que l’IA sécurisée n’est pas obtenue grâce à un contrôle parfait, mais grâce à des centaines de petites décisions techniques qui maintiennent les systèmes autonomes alignés sur les intentions commerciales. À mesure que nous passons d’assistants à des agents entièrement autonomes, cette distinction n’en devient que plus importante. Les équipes en qui je fais confiance pour faire évoluer l’IA ne sont pas celles qui disposent des modèles les plus intelligents. Ce sont eux qui peuvent répondre, pour toute action entreprise par un agent, pourquoi il l’a entreprise – et où elle se serait arrêtée.
