Vous avez entendu parler de toute l'hystérie autour des agents IA et de leurs possibilités apparemment illimitées. Et bien que ces possibilités soient très intéressantes, vous ne vous intéressez vraiment qu'aux capacités de l'IA agentielle qui permettent de résoudre directement vos problèmes concrets.
Et puis, quand vous pensez à tous les gains de productivité et aux avantages en termes de retour sur investissement, vous vous arrêtez et vous vous dites : «D'accord, c'est génial, mais que se passerait-il si ces agents dépassaient leur champ d'action? » - Et cela, que vous déployiez vos propres agents IA en interne ou que vous tiriez parti des capacités des agents IA d'un fournisseur externe.
Et c'est une question légitime. Les agents, tout comme les autres capacités de l'IA, ont besoin de contraintes. Sans elles, ils peuvent devenir incontrôlables. Les agents sont curieux par nature. Comme un enfant en bas âge, ils essaieront toutes les portes à leur portée. Dans de nombreux cas, vous avez besoin qu'ils explorent, mais vous devez également vous assurer que les portes qui ne doivent pas s'ouvrir sont physiquement verrouillées.
En matière de cybersécurité, cela revêt une importance encore plus grande : les exigences minimales de sécurité pour les agents IA doivent être encore plus strictes. Pour Aikido , notre pentest IA , nous avons pris en compte chaque couche afin d'empêcher les agents de sortir du champ d'application. Cela couvre des éléments tels que le test accidentel de la production et la perte de contrôle.
Le dépassement du champ d'application est l'un des principaux sujets sur lesquels les responsables de la sécurité et les ingénieurs nous interrogent, et c'est un aspect que nous avons pris en compte dès le début lors du développement de notre plateforme. En tant qu'entreprise spécialisée dans la cybersécurité, nous voulions naturellement que tout soit parfait.
Il convient de rappeler que les agents sont censés emprunter des voies inattendues ou risquées, mais que des garde-fous existent pour contenir ce comportement, et non pour l'empêcher.
Aikido et le travail infini reposent sur une approche à plusieurs niveaux, utilisant à la fois des limites strictes et des limites souples. Voici les éléments clés que vous devez connaître :
Couche 1 : Séparation architecturale stricte : plan de contrôle vs exécution
Le système Aikidoest conçu avec une séparation stricte entre le système qui planifie et évalue les tests d'intrusion (le plan de contrôle) et l'environnement qui exécute réellement les actions (le bac à sable d'exécution isolé).
Tout le raisonnement, l'orchestration et l'accès aux données sensibles se font dans le plan de contrôle. L'exécution des outils, l'automatisation des navigateurs et les interactions réseau se font dans un environnement distinct.
Cette séparation existe parce que nous partons du principe que l'exécution peut présenter des dysfonctionnements et que, par conséquent, tout impact doit être limité. C'est pour cette raison que l'environnement d'exécution n'a pas accès aux secrets d'orchestration, à l'infrastructure interne ou aux systèmes de plan de contrôle.
Couche 2 : Application de la portée d'exécution
La production n'est jamais considérée comme faisant partie du champ d'application.
Notre système ne suppose jamais que la production est susceptible d'être attaquée. Les tests d'intrusion ne doivent être effectués que sur les environnements de staging et de test. La production doit être explicitement configurée comme étant concernée, et même dans ce cas, cela doit être vérifié et confirmé avant toute exécution.
Nous avons constaté l'efficacité de nos garde-fous dans la pratique. Dans un cas, un agent a suivi un comportement d'application qui l'aurait conduit à l'infrastructure de production. La limite stricte que nous avons mise en place a bloqué la requête au niveau de la couche réseau. Cependant, nous avons pu constater que l'agent avait tenté de passer. Cette tentative bloquée est la preuve que nos garde-fous fonctionnent.
Seuls les domaines autorisés sont accessibles.
Nos agents ne peuvent interagir qu'avec des domaines explicitement configurés. Si un domaine ne figure pas dans la liste des domaines autorisés, il est bloqué au niveau du réseau. Vous pouvez configurer vous-même cette option en spécifiant les domaines qui peuvent être attaqués ou accessibles. En termes simples, nous bloquons les domaines par défaut afin d'empêcher l'agent d'interagir avec des serveurs avec lesquels il n'est pas censé interagir.
Cela signifie que nous ne dépendons pas d'invites ou d'êtres humains pour faire respecter la portée. Aikido l'applique Aikido lui-même.
La dérive accidentelle de la lunette est bloquée
Revenons à notre analogie avec les tout-petits. Même si la plupart des autres contrôles de sécurité garantissent que les agents ne s'écartent pas de leur champ d'action, il existe un nombre limité d'agents qui, justement, le font. Surtout lorsque 250 agents fonctionnent en même temps.
Un exemple classique de ce phénomène est celui d'un agent redirigé vers une application externe via un lien. Il pense rester sur la même page, mais se retrouve en réalité sur un autre site web. Il se retrouve soudainement sur X ou Reddit, et suppose que cela fait partie du champ d'application.
C'est pourquoi vous devez mettre en place des contrôles rigoureux pour protéger les agents contre eux-mêmes. Comme l'explique Phillippe Dourassov, responsable des tests de pénétration IA chez Aikido :
« Il y aura toujours 5 % d'agents qui ne sont pas toujours raisonnables, et c'est pourquoi nous veillons à nous occuper de ces 5 %. »
Couche 3 : Injection de messages et exfiltration de données
Nous savons que l'injection rapide est un risque majeur dans les systèmes d'IA autonomes, dans lesquels un pirate insère des instructions malveillantes dans le contenu lu par l'agent. L'agent interprète ces instructions comme des directives légitimes et les suit.
Cela peut concerner des contenus qui incitent les agents à envoyer le code source ou des données internes à un endroit où ils ne devraient pas se trouver. Cette vulnérabilité provient de l'exposition à des contenus non fiables et de l'exécution d'actions sur ces derniers. Aikido ces deux options.
Tout d'abord, les agents Aikidon'ont pas accès à Internet. Cela signifie qu'ils ne peuvent pas effectuer de recherche sur Google pour découvrir le fonctionnement d'une technologie, ni se rendre sur Reddit pour obtenir des instructions sur la manière de réaliser une action dangereuse. Le seul contenu qu'ils traitent est celui qui existe au sein même de l'application concernée.
Deuxièmement, même si des instructions malveillantes étaient d'une manière ou d'une autre implantées dans l'application cible, les agents ne seraient toujours pas autorisés à exfiltrer des données. Des restrictions au niveau du réseau empêchent les connexions sortantes vers des destinations aléatoires, de sorte que l'agent ne peut pas télécharger le code source vers Google Drive, ni publier vers un point de terminaison externe, ni envoyer des données vers un domaine contrôlé par un attaquant.
Nous appliquons cette mesure au niveau de la couche réseau en interceptant et en contrôlant le trafic HTTP et DNS provenant des agents, les empêchant ainsi de résoudre ou de communiquer avec des domaines qui ne sont pas explicitement approuvés.
Ainsi, dans le pire des cas, où un modèle interprète mal les instructions, il sera toujours incapable d'envoyer quoi que ce soit à l'extérieur.
Un cas particulier mérite d'être mentionné : si un client injecte délibérément des instructions malveillantes dans son propre environnement (même si nous ne comprenons pas pourquoi il ferait cela !), l'agent pourrait très bien les traiter. Mais même dans ce cas, cela n'aurait d'impact que sur les propres tests du client. Il n'y aurait aucun risque inter-locataires, aucune exposition de l'infrastructure ni aucune fuite de données au-delà de ce qu'il contrôle déjà.
Couche 4 : Sandbox isolées pour chaque agent
Chacun de nos agents dispose de son propre petit bac à sable isolé (comme un enfant dans un parc). Cela signifie qu'ils sont séparés à la fois de l'infrastructure interne Aikido et des autres agents qui fonctionnent en même temps. Ils n'ont donc pas accès au réseau, à l'infrastructure et aux bases de données Aikido, et ne peuvent pas interférer avec les autres sessions actives ni les influencer.
Si quelque chose se comporte de manière inattendue pendant un test, l'impact est confiné à ce bac à sable unique, ce qui empêche à la fois l'impact sur les agents et l'exposition inter-tentants.
Couche 5 : Mesures de protection opérationnelles
Toutes les requêtes sont limitées en termes de débit et tiennent compte de la charge, ce qui garantit que les tests ne surchargent pas les systèmes cibles et ne déclenchent pas une avalanche d'alertes.
De plus, les tests peuvent être mis en pause ou interrompus immédiatement à tout moment. Les clients peuvent voir ce que font les agents en temps réel. Chaque requête et chaque action sont visibles. Cela signifie que les équipes peuvent intervenir si elles le jugent nécessaire.
Validation de la configuration
Les erreurs de configuration sont plus fréquentes que les comportements malveillants. C'est pourquoi, avant le début des tests, Aikido des vérifications préalables pour valider l'authentification et l'accessibilité. Si quelqu'un semble mal configuré ou ressemble à un environnement de production, des avertissements sont affichés rapidement. Cela signifie que les mesures de protection sont conçues pour détecter les erreurs humaines avant le début de l'exécution, plutôt que de s'appuyer sur des contrôles d'exécution pour corriger des erreurs de configuration évitables.
Frontières souples
Notre approche par couches signifie que nous avons également des limites souples. C'est là que vous n'auriez pas besoin d'un domaine pour que les agents puissent l'utiliser.
Par exemple, si vous disposez d'un portail d'authentification, vous pouvez souhaiter que les agents utilisent l'authentification pour se connecter à l'application, mais vous ne voulez pas qu'ils attaquent le portail lui-même.
La frontière souple signifie que les agents peuvent toujours accéder au portail d'authentification, mais qu'ils ont pour instruction spécifique de ne pas l'attaquer.
Comment la portée est appliquée : pentest IA humaine vs pentest IA
Dans un test d'intrusion traditionnel, la portée est définie par la documentation, les contrats et le jugement professionnel. Les testeurs sont informés des environnements concernés. Cela fonctionne bien dans la pratique, mais le respect des limites dépend de la discipline et de l'expérience du testeur.
Par exemple, si un testeur suit une redirection vers un environnement incorrect ou identifie mal un système, le problème est généralement découvert plus tard grâce aux journaux ou à une vérification.
Avec pentest IA, la portée est appliquée par le biais de contrôles techniques. Si un domaine ne figure pas dans la liste blanche, la connexion est bloquée. Si la production n'est pas explicitement sélectionnée, elle n'est pas accessible, et si une redirection mène en dehors de la portée, la requête échoue automatiquement.
Les deux approches sont efficaces. L'avantage de l'application technique est qu'elle réduit la dépendance à l'égard de la documentation et de l'interprétation.
Pour bénéficier des avantages pentest IA, qui a déjà démontré de meilleurs résultats que le pentesting manuel en termes de détection des problèmes critiques et de haute gravité, essayez Aikido dès maintenant.
