Lorsque l'AI cesse de répondre et commence à agir dans les entreprises

Publié 7 min de lectura 122 lecture

Nous assistons à une mutation profonde dans la façon dont l'intelligence artificielle est intégrée dans le travail quotidien des entreprises. Ces dernières années, l'adoption s'est concentrée sur les assistants conversationnels et copilotes qui répondent aux questions, résument des textes ou facilitent les recherches. Toutefois, la tendance actuelle est celle des agents d'IV capables non seulement de dialoguer, mais aussi de planifier, de raisonner et de mettre en œuvre des mesures dans les systèmes d'entreprise au nom des utilisateurs ou des organisations.

Ce saut - de "répondre" à "agir" - change complètement le paysage des risques. Les nouveaux acteurs ne se contentent pas de montrer des informations : ils interagissent avec les applications, consultent les bases de données, lancent des flux de travail et, dans certains cas, modifient les ressources. Cette capacité d'intervention transforme l'AI en une entité qui nécessite des contrôles autres que ceux d'un robot traditionnel.

Lorsque l'AI cesse de répondre et commence à agir dans les entreprises
Image générée avec IA.

Tous les agents ne créent pas le même danger. Le niveau de risque dépend principalement de deux variables: ce qu'ils peuvent accéder et combien d'indépendance ils doivent agir sans supervision humaine. Un assistant qui recherche uniquement de la documentation locale présente un risque très différent pour un agent qui peut, par exemple, exécuter des déploiements de cloud ou modifier des paramètres critiques.

Dans la pratique, il convient de distinguer au moins trois familles d'agents corporatifs. Les premières versions sont les chatbots intégrés aux plateformes gérées : ils apparaissent dans les outils de productivité, les systèmes de soins à la clientèle ou les bases de connaissances et sont activés avec l'interaction humaine pour récupérer ou condamner l'information. Ils sont souvent de faible autonomie, mais ne sont pas sans problèmes: s'ils utilisent des connecteurs avec des identifiants statiques ou des permis trop larges, ils deviennent des portes d'accès privilégiées aux ressources sensibles.

La deuxième catégorie, et probablement la plus problématique en raison de son expansion rapide, est les agents locaux qui fonctionnent dans les paramètres des employés. Ces assistants sont intégrés avec des éditeurs de code, des terminaux, des outils d'analyse ou des scripts automatisés et héritent des identifiants et des permissions de l'utilisateur qui les exécute. Cette propriété facilite l'adoption car elle élimine les étapes d'approvisionnement centralisées, mais génère également un trou de gouvernance : chaque employé peut, sans être si conscient, transformer son environnement de travail en vecteur d'action avec les permissions de l'entreprise.

Le troisième groupe est les agents de production : des services continus qui orchestrent des tâches complexes, répondent aux événements et agissent sans intervention humaine. Ils sont utilisés pour automatiser l'intervention en cas d'incident, les pipelines DevOps ou les processus opérationnels et fonctionnent avec des identités de machine et des identifiants dédiés. Ici, les risques sont plus évidents parce qu'ils combinent une grande autonomie, l'accès aux infrastructures essentielles et, souvent, le traitement d'intrants externes qui peuvent contenir des instructions malveillantes.

Le fil conducteur entre ces scénarios est l'identité. Chaque agent est en fait un nouveau type d'identité numérique au sein de l'entreprise: il demande des jetons, consomme des API, écrit dans des dépôts et shoots emplois. Si ces identités sont mal gérées - permissions excessives, cycle de vie incontrôlé, rotation défectueuse - l'agent devient une fenêtre pour les attaquants ou une source d'erreurs avec des conséquences opérationnelles et réglementaires.

De plus, la configuration typique d'architectures avec plusieurs agents peut générer des chaînes de confiance cachées : un agent peut en invoquer un autre et donc étaler les privilèges ou diffuser des actions involontaires. Et vous n'avez pas à sous-estimer l'exposition aux instructions d'injection (injection rapide), un vecteur où les entrées externes manipulent le comportement du modèle pour l'inciter à effectuer des actions indésirables; à ce sujet, il est nécessaire de revoir des ressources spécialisées telles que le guide OWASP sur l'injection rapide ( OWASP Injection rapide).

Pour ceux qui dirigent la sécurité (CISUS), la priorité n'est plus de déterminer si l'IV entrera dans l'organisation et de déterminer où elle est déjà et comment elle fonctionne. Il est nécessaire de savoir quels agents existent, quelles identités ils utilisent, quels systèmes ils peuvent accéder et si ces autorisations correspondent au but déclaré de chaque agent. Cette vision sert de base pour décider quel ordre traiter les risques et quels contrôles appliquer.

Certaines références à la bonne gouvernance et à la gestion des risques peuvent aider à structurer cette réponse. Le cadre de gestion des risques NIST IA fournit des principes et des outils pour évaluer et atténuer les risques spécifiques des systèmes intelligents ( NISTE AU FGR), tandis que les guides d'identité numérique du NIST sont utiles pour comprendre comment gérer le cycle de vie des identités humaines et des identités de machines ( NIST SP 800-63). À la fin de la chaîne d'approvisionnement, les recommandations du Centre national de cybersécurité du Royaume-Uni sur la sécurité de la chaîne d'approvisionnement logicielle sont utiles pour atténuer les risques associés aux plugins et aux unités externes ( CNSC Sécurité de la chaîne d'approvisionnement logicielle).

Concrètement, les organisations devraient investir dans la détection et la visibilité : découvrir les agents déployés, inventer des identités et enregistrer leurs actions. De là, il convient d'appliquer le principe de moins de privilèges et de mécanismes d'accès dynamiques qui limitent ce que chaque identité peut faire et pour combien de temps. La rotation automatique des identifiants, l'utilisation des identités fédérées et le contrôle de l'utilisation des plugins tiers sont des mesures qui réduisent la surface de la menace sans arrêter la productivité.

Il n'est pas moins important de mettre en oeuvre la télémétrie : traces, dossiers de vérification et alertes permettant de reconnaître un comportement anormal d'un agent. Les tests de résilience contre les instructions défavorables et la validation sûre des entrées externes aident à combattre les vecteurs tels que l'injection d'invites. Pour concevoir ces tests, il convient de consulter les bonnes pratiques des plates-formes offrant des modèles et des API, qui comportent souvent des recommandations de sécurité spécifiques ( Directives de sécurité OpenAI) et la documentation sur l'intelligence artificielle responsable par les fournisseurs de cloud ( Microsoft Responsible AI).

Lorsque l'AI cesse de répondre et commence à agir dans les entreprises
Image générée avec IA.

Le paradoxe de l'âge des agents est que la vitesse et l'autonomie qui les rendent si utiles sont aussi celles qui nécessitent un réexamen des contrôles traditionnels. Les outils d'identité et d'accès conçus pour les humains et les services conventionnels ne sont pas suffisants : des solutions sont nécessaires pour gérer l'identité des agents sur une échelle, avec des dispositions, des règles d'accès temporaires, une rotation automatique et des capacités d'audit spécifiques aux activités automatisées.

En fin de compte, la sécurité de l'IV n'est pas de l'interdire, mais de la gouverner. Les organisations qui avancent plus rapidement seront celles qui savent cartographier leurs agents, harmoniser les permis avec les intentions opérationnelles et appliquer des contrôles d'identité comme plan de contrôle. En ce sens, l'identité n'est plus une composante de l'architecture : elle devient le levier central permettant l'adoption en toute sécurité d'agents agissant sans supervision humaine fréquente.

Si votre entreprise déploie ou évalue des agents, il convient de commencer par un inventaire, de définir des critères de risque fondés sur l'accès et l'autonomie, et de prioriser les contrôles sur les agents ayant la plus grande capacité d'impact. La documentation et les modèles d'organismes tels que le NIST et les équipes de sécurité des fournisseurs de plates-formes fournissent des cadres solides pour structurer cette transition vers une IA qui apporte de la valeur sans compromettre la sécurité.

Couverture

Autres

Plus de nouvelles sur le même sujet.