Stratégies de cybersécurité pour le développement d’agents en low-code et en high-code

Lorsque les organisations déploient des agents d’intelligence artificielle dans leurs systèmes d’entreprise, la vitesse de développement et la supervision de la sécurité deviennent étroitement liées. Les stratégies de cybersécurité pour le développement d’agents en low-code et en high-code doivent tenir compte de la manière dont chaque approche accorde l’accès aux informations et permet d’effectuer des actions. Des mesures de protection ciblées peuvent répondre à ces différences, tandis qu’une gouvernance commune veille à ce que l’activité des agents reste conforme aux tâches autorisées à mesure que les déploiements prennent de l’ampleur.

Qu’est-ce qui distingue le développement d’agents d’IA en low-code et en high-code

Les plateformes low-code permettent de créer des agents au moyen d’interfaces visuelles et de connecteurs prédéfinis qui relient des services d’entreprise. Le développement en high-code offre aux programmeurs une plus grande souplesse pour définir le comportement des agents à l’aide de code personnalisé, d’intégrations d’outils et d’environnements d’exécution. Les deux approches nécessitent une supervision des informations auxquelles les agents peuvent accéder et des actions qu’ils peuvent effectuer.

Les responsabilités en matière de sécurité diffèrent, car le contrôle s’exerce à des endroits différents. Les développeurs low-code travaillent dans les paramètres de la plateforme qui régissent le partage et l’accès aux connecteurs, ce qui rend les décisions de configuration particulièrement importantes. Les équipes high-code assument davantage de responsabilités quant aux logiciels et aux environnements qui exécutent les instructions des agents, notamment en ce qui concerne les limites d’accès aux fichiers et aux identifiants.

The Cybersecurity and Infrastructure Security Agency recense plusieurs risques liés à l’IA agentique qui fournissent un cadre utile pour les deux approches. L’élargissement de la surface d’attaque désigne la multiplication des points d’entrée, tandis que l’accumulation progressive des privilèges correspond à l’extension des accès. Le désalignement comportemental se manifeste par des écarts par rapport aux tâches prévues, et des journaux d’événements peu clairs compliquent les enquêtes. Un connecteur largement utilisé et un outil en ligne de commande sans restriction peuvent engendrer différentes formes des mêmes problèmes.

Risques de sécurité des agents d’IA low-code et moyens d’y remédier

L’accessibilité du low-code permet à des employés qui ne font pas partie des équipes de développement traditionnelles de créer des agents. La supervision de la sécurité doit aussi s’étendre à ces créateurs, afin que les connexions pratiques restent conformes aux usages professionnels autorisés.

Les limites de sécurité des environnements low-code

Les développeurs citoyens peuvent connecter un agent à des fichiers partagés ou à des applications d’entreprise sans bien comprendre ses autorisations. Les accès accordés par ces connexions peuvent exposer des informations sensibles ou permettre des actions qui dépassent le cadre du processus prévu. Un partage trop large et des responsabilités mal définies peuvent aggraver cette exposition.

L’ampleur de l’adoption rend essentielle une supervision cohérente dans tous les services. Dans une analyse de marché publiée en 2024, Forrester indique que 87 % des développeurs en entreprise utilisent des plateformes low-code pour certaines tâches de développement. Ce constat porte sur le développement en général : il montre donc l’étendue de l’utilisation de ces plateformes, sans mesurer spécifiquement l’adoption des agents d’IA.

Des moyens concrets de renforcer la sécurité des agents low-code

Les équipes devraient vérifier que les autorisations des connecteurs correspondent à la tâche assignée à chaque agent et appliquer le principe du moindre privilège. Un inventaire central devrait consigner le responsable et les services connectés pour chaque déploiement, et prévoir une approbation pour les actions sensibles. Les équipes de sécurité disposeraient ainsi d’une base pour repérer les agents non enregistrés et enquêter sur les accès inappropriés.

L’approche de Microsoft en matière de gouvernance des données met l’accent sur le contrôle de l’accès aux informations d’entreprise. Naveen Jangir, architecte principal chez Microsoft Digital, recommande aux organisations de « régir et protéger ces informations en imposant des restrictions d’accès appropriées ». Ces contrôles permettent aux utilisateurs autorisés et aux fonctionnalités d’IA de les utiliser sans les exposer inutilement dans le respect des limites d’autorisation établies. L’application de politiques relatives aux connecteurs, conjuguée à une attribution claire des responsabilités, peut intégrer ces restrictions au développement quotidien.

Risques de sécurité des agents d’IA high-code et moyens d’y remédier

Lorsque les équipes utilisent des agents de programmation fondés sur l’IA pour créer des systèmes personnalisés, les modifications générées peuvent arriver plus vite que les personnes ne sont en mesure de les examiner. La sécurité du high-code exige donc des contrôles portant à la fois sur le processus de développement et sur les environnements dans lesquels les agents exécutent leurs tâches.

Les défis de sécurité propres au développement high-code

Les agents de programmation peuvent être victimes d’une injection indirecte d’instructions lorsqu’ils consultent des dépôts externes contenant des consignes fournies par des acteurs malveillants. Si un agent suit ces consignes alors qu’il dispose d’un accès aux outils de développement, il risque d’exécuter des commandes dangereuses ou d’exposer des identifiants. Les conséquences potentielles dépendent en partie des fichiers, des outils et des destinations externes auxquels son environnement d’exécution lui permet d’accéder.

Les recommandations de NVIDIA sur le bac à sable portent sur l’exposition des identifiants à l’intérieur de cette limite d’exécution. Elles indiquent que « les environnements en bac à sable devraient s’appuyer sur une injection explicite des secrets » afin de limiter l’accès aux identifiants. Par conséquent, les agents ne devraient pas hériter de l’ensemble des identifiants d’authentification de l’environnement lorsque leurs tâches ne nécessitent qu’un accès limité. Les équipes devraient fournir les identifiants nécessaires à la tâche concernée et maintenir les secrets sans rapport avec celle-ci hors de portée de l’agent.

Stratégies de sécurisation des pipelines d’agents développés avec du code

Les environnements d’exécution restreints devraient limiter l’accès aux fichiers et les connexions sortantes en fonction de la tâche. Les équipes devraient également effectuer des tests statiques de sécurité des applications sur le code généré. Des évaluateurs indépendants devraient examiner les décisions d’autorisation ou la logique métier qui pourraient échapper aux vérifications automatisées. Ces mesures répondent aux enjeux liés aux limites d’exécution et aux faiblesses du logiciel produit.

Amazon Web Services recommande de séparer la génération de code de son évaluation dans son cadre de contrôles des agents de programmation. L’entreprise souligne qu’« une session distincte aide à éviter le biais d’autoconfirmation ». Toutefois, deux sessions utilisant le même modèle peuvent présenter les mêmes angles morts sous-jacents lors de l’examen. Dans la mesure du possible, un modèle différent pour l’examen et une évaluation humaine des modifications sensibles du point de vue de la sécurité peuvent apporter un contrôle supplémentaire.

Élaborer une stratégie de sécurité qui couvre les deux approches

La sécurité de l’IA dans le développement d’agents low-code et d’agents développés avec du code nécessite une vision commune des activités chaque fois que les agents échangent des informations. Par exemple, un flux de travail low-code peut transmettre du contenu à un agent conçu sur mesure, lequel appelle ensuite un autre service métier. L’examen de chaque composant séparément peut priver les équipes de sécurité du contexte nécessaire pour comprendre l’ensemble de la séquence.

Les spécialistes de la sécurité de l’IA chez Darktrace estiment que les organisations doivent examiner les invites et les sessions ainsi que les réponses, dans les outils d’IA générative d’entreprise et les deux approches de développement. Leur analyse englobe également les environnements de logiciels en tant que service et de périphérie de service d’accès sécurisé. Grâce à cette visibilité, les organisations disposent du contexte nécessaire pour « détecter les attaques conversationnelles sophistiquées par injection d’instructions et les enchaînements malveillants ».

Le point de vue de Darktrace étaye une stratégie plus vaste de sécurité de l’IA pour le développement d’agents low-code et d’agents développés avec du code : la visibilité sur les instructions, le suivi des sessions et le contrôle des identités aident les équipes à comprendre comment les agents interagissent avec les outils connectés. Les équipes de sécurité devraient examiner comment les instructions évoluent au fil des sessions connectées et vérifier si les actions qui en découlent restent conformes à l’autorisation initiale. Elles devraient également tenir compte du degré de sensibilité des informations conservées à des fins d’enquête.

Gouvernance et suivi pour assurer la sécurité des agents d’IA à long terme

Chaque agent devrait avoir un responsable désigné et un périmètre de travail autorisé clairement défini, quelle que soit sa méthode de développement. La gouvernance devrait également préciser qui peut approuver les modifications de ce périmètre et qui peut suspendre les activités si un agent se comporte de manière inattendue.

Les recherches sur la gouvernance des agents indiquent que ceux-ci ont besoin d’ une autorité dont l’authenticité peut être vérifiée et qui peut faire l’objet d’un audit, afin de garantir cette responsabilité. Cette approche relie la personne qui accorde l’autorisation aux tâches qu’un agent peut entreprendre. Les organisations peuvent alors vérifier si une action est conforme à cette autorisation.

Les équipes devraient tenir des journaux d’activité reliant les autorisations déléguées à l’utilisation des outils et aux résultats obtenus. Des examens périodiques devraient réévaluer ces autorisations à mesure que les capacités évoluent, supprimer les accès devenus inutiles une fois le travail terminé et confirmer que les responsables sont toujours à jour. Les équipes de développement et de sécurité peuvent s’appuyer sur ces examens pour maintenir l’alignement des contrôles opérationnels sur la finalité approuvée de l’agent.

Anticiper les risques liés à la sécurité des agents d’IA

Le développement low-code exige une gestion rigoureuse des autorisations de la plateforme et de la gouvernance des connecteurs, tandis que le développement avec du code requiert une attention particulière aux environnements d’exécution personnalisés et à la revue du code. La centralisation du suivi et une responsabilisation cohérente constituent un socle commun pour superviser la manière dont les agents accèdent aux informations et agissent dans les systèmes métier connectés. À mesure que leurs capacités s’élargissent, les développeurs devraient réévaluer les mesures de protection en fonction de l’évolution des outils et des responsabilités des agents, et veiller à ce que les activités autorisées de chaque déploiement restent clairement définies tout au long de son cycle de vie.