Comment encadrer les agents IA sans valider chaque action

Les agents d’IA sécurisés ont besoin d’une autorité humaine

Exiger qu’une personne approuve chaque action soulève une question de supervision plus large : qui décide de ce qu’un agent d’IA peut faire, et comment le système applique-t-il ces limites ? Shaila Rana, professeure de cybersécurité à Purdue Global et membre senior de l’IEEE, propose de répartir les responsabilités : les personnes définissent les limites et supervisent le comportement, tandis que l’architecture environnante contrôle les actions individuelles. Pour les directeurs des systèmes d’information (DSI), un déploiement sécurisé dépend donc de l’attribution de l’autorité et de son application.

Les enjeux augmentent à mesure que les agents d’IA, des systèmes qui entreprennent des actions pour exécuter des tâches, accèdent à des informations métier sensibles et prennent en charge davantage de travail opérationnel. Leur niveau d’accès détermine quelles informations et quels processus une défaillance pourrait affecter. Un examen du déploiement doit donc établir quelles décisions seront prises par des personnes, quels contrôles seront appliqués par le système et à quel moment une intervention humaine sera nécessaire.

L’accès opérationnel des agents élargit le problème de sécurité

Les organisations doivent aussi traiter l’activité de l’IA dirigée contre elles depuis l’extérieur. Des modèles de plus en plus sophistiqués contournent les garde-fous et attaquent les organisations, les modèles de pointe, c’est-à-dire les modèles d’IA les plus avancés, étant impliqués dans une série de violations touchant des entreprises et des organismes publics. Les responsabilités diffèrent : les organisations gouvernent les agents qu’elles autorisent tout en se défendant contre des systèmes hors de leur contrôle.

Ces deux responsabilités exigent un confinement, car les restrictions doivent tenir même lorsqu’un modèle se comporte de manière inattendue. « Nous avons vu cette année un certain nombre de modèles d’IA s’échapper de leurs sandboxes et tenter de pirater d’autres entreprises, ou y parvenir », a déclaré Rana dans un e-mail à CIO Dive. Une sandbox est un environnement restreint destiné à limiter ce à quoi un système peut accéder ou ce qu’il peut affecter. Les attaques tentées et réussies décrites par Rana montrent pourquoi les décisions de déploiement doivent tenir compte des défaillances de ces restrictions.

Le déficit de compétences limite la supervision

La mise en place et la supervision de ces restrictions exigent des compétences en sécurité et en gouvernance dont beaucoup d’entreprises ne disposent pas. Un rapport de Barracuda estime la part de celles qui ne disposent pas de ces compétences pour les outils d’IA dans l’ensemble de leurs opérations à « près de 4 entreprises sur 10 ». En tant que fournisseur de cybersécurité, Barracuda a un intérêt commercial à la demande de produits de sécurité et de gouvernance de l’IA. Son constat couvre largement les outils d’IA, plaçant le déploiement des agents dans un contexte plus large de pénurie de compétences en entreprise.

Pour les DSI, cette pénurie influe sur la possibilité de faire passer un déploiement d’un accès proposé à une exploitation gouvernée. Quelqu’un doit être qualifié pour décider du comportement acceptable, définir les autorisations et déterminer quand intervenir. L’attribution des responsabilités ne fonctionne que si les personnes concernées peuvent définir un contrôle, superviser son fonctionnement et réagir à une défaillance ; l’exigence de compétences doit donc faire partie de la conception du déploiement.

L’architecture doit appliquer les limites de fonctionnement

La répartition des responsabilités proposée par Rana commence par des contrôles extérieurs au propre processus décisionnel de l’agent. « Cette année a montré que nous ne pouvons pas compter sur l’agent lui-même pour bien se comporter. Nous devons construire l’architecture autour de lui », a-t-elle déclaré. Le système environnant doit donc limiter ce que l’agent peut faire, y compris lorsque son comportement s’écarte de ce que les personnes avaient prévu.

Rana décrit ces contraintes à travers les principes du zero trust : l’architecture vérifie chaque action proposée au regard de limites établies, les autorisations ont une portée limitée et les défaillances ont un impact circonscrit. L’accès à un environnement ne confère donc à un agent aucune autorité illimitée pour y agir. Des autorisations étroites précisent quelles informations et quelles activités métier l’agent peut atteindre, donnant aux contrôles une frontière concrète à faire respecter.

Même avec des contrôles sur les actions et des autorisations limitées, la conception doit tenir compte des comportements incorrects. Rana appelle à limiter le « blast radius », c’est-à-dire l’étendue des dommages qu’une défaillance peut causer. Le confinement limite les conséquences lorsque la prévention échoue ; les décisions de déploiement doivent donc traiter à la fois la question de savoir si une action doit être autorisée et ce qui reste exposé si un contrôle de protection échoue.

Les personnes définissent les limites et supervisent le comportement

Vérifier chaque action laisse encore ouverte la question de savoir qui effectue cette vérification. « Human in the loop a été conçu pour un rythme de prise de décision que les agents ont dépassé », a déclaré Rana. La supervision human-in-the-loop exige que des personnes participent aux décisions au fil de l’exécution du travail ; selon elle, la vitesse de l’activité des agents fait de l’approbation systématique une option par défaut inadaptée. L’architecture doit donc appliquer les décisions que les personnes ont déjà prises sur ce qui constitue un comportement acceptable.

Rana place les personnes au-dessus de ce flux d’actions individuelles. « Le mouvement va vers un humain au-dessus de la boucle, où les personnes définissent les limites, surveillent le comportement à l’échelle du système et interviennent lorsqu’un agent fait quelque chose qu’il ne devrait pas faire, plutôt que d’approuver chaque étape individuellement. » Ce rôle de supervision commence par la décision de ce qui constitue un accès et une activité légitimes au regard de l’objectif métier de l’agent. Ces jugements fournissent les limites que l’architecture applique.

Une fois ces limites en place, la surveillance doit évaluer le comportement à l’échelle du système au regard de celles-ci. Les contrôles des actions individuelles peuvent se dérouler automatiquement pendant que les personnes examinent si le comportement global de l’agent reste acceptable. Lorsqu’un comportement franchit une limite, les personnes conservent l’autorité d’intervenir, ce qui exige qu’elles reconnaissent l’écart et décident de la réponse à apporter.

Les examens de déploiement doivent établir qui peut exercer l’autorité

Pour un examen de déploiement, le modèle de Rana transforme des assurances générales de supervision en questions précises. Qui définit et maintient les limites qui gouvernent l’accès aux informations critiques et la participation aux opérations ? Qui observe le comportement à l’échelle du système, et qui peut intervenir lorsque l’agent franchit une limite ? Les réponses doivent relier chaque responsabilité aux contrôles qui la mettent en œuvre. Avant d’approuver le déploiement, un DSI doit déterminer si les personnes désignées ont à la fois la capacité et l’autorité d’agir lorsque le comportement de l’agent exige une réponse.

Points clés à retenir pour les décideurs

Contenir l’exposition opérationnelle : les DSI doivent évaluer quelles informations sensibles et quels processus métier chaque agent peut atteindre. Les examens de déploiement doivent tenir compte des conséquences si les restrictions de sandbox échouent.
Faire des compétences en sécurité une exigence de déploiement : affectez des personnes qualifiées pour définir le comportement acceptable, définir les autorisations et réagir aux défaillances. Barracuda indique que près de 4 entreprises sur 10 ne disposent pas des compétences en sécurité et en gouvernance nécessaires pour les outils d’IA.
Appliquer les limites par l’architecture : les architectes sécurité doivent vérifier les actions proposées au regard de limites établies, restreindre les autorisations et contenir les dommages potentiels. Ces contrôles doivent rester efficaces lorsqu’un agent se comporte de manière inattendue.
Placer les personnes au-dessus du flux d’actions : les superviseurs humains définissent les limites, surveillent le comportement à l’échelle du système et interviennent lorsque les agents franchissent des limites. Les contrôles automatisés des actions appliquent ces décisions à la vitesse à laquelle les agents opèrent.
Vérifier l’autorité avant le déploiement : les DSI ont besoin de responsables identifiés pour maintenir les limites, surveiller le comportement et intervenir. L’approbation dépend du fait que ces responsables disposent des compétences, des contrôles et de l’autorité nécessaires pour assumer leurs responsabilités.