Vous avez entendu parler de toute l'hystérie autour des agents IA et de toutes les possibilités apparemment illimitées. Et bien que ces possibilités soient toutes bonnes et valables, vous n'êtes vraiment intéressé que par les capacités d'IA agentique qui s'attaquent directement à vos problèmes réels.
Et puis, lorsque vous pensez à tous les gains de productivité et aux avantages en termes de ROI, vous vous arrêtez et vous dites : « c'est super, mais que se passe-t-il si ces agents dépassent leur périmètre ? » – et ce, que vous déployiez vos propres agents IA en interne ou que vous bénéficiiez des capacités d'agents IA d'un fournisseur externe.
Et c'est une question légitime à poser. Les agents, tout comme d'autres capacités d'IA, ont besoin de contraintes. Sans elles, ils peuvent s'emballer. Les agents sont curieux par conception. 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 devraient pas s'ouvrir sont physiquement verrouillées.
En matière de cybersécurité, cela est encore plus important : les exigences minimales de sécurité pour les agents IA doivent être encore plus strictes. Pour Aikido Attack, notre capacité de pentest IA, nous avons examiné chaque couche pour empêcher les agents de dépasser leur périmètre. Cela couvre des éléments tels que le test accidentel de la production et la perte de contrôle.
Le dépassement de périmètre est l'un des sujets clés 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 du développement de notre plateforme. Naturellement, en tant qu'entreprise de cybersécurité, nous voulions bien faire les choses.
Il est important de se rappeler que les agents sont censés tenter des chemins inattendus ou risqués, mais que des garde-fous existent pour contenir ce comportement, et non pour l'empêcher.
Aikido Attack et Infinite fonctionnent selon une approche multicouche, utilisant à la fois des limites strictes et des limites souples. Voici les éléments clés à connaître :
Couche 1 : Séparation architecturale stricte : Plan de contrôle vs exécution
Le système d'Aikido est conçu avec une séparation stricte entre le système qui planifie et évalue les pentests (le plan de contrôle) et l'environnement qui exécute réellement les actions (le sandbox d'exécution isolé).
Toute la logique, l'orchestration et l'accès aux données sensibles se déroulent dans le plan de contrôle. L'exécution des outils, l'automatisation des navigateurs et les interactions réseau se produisent dans un environnement séparé.
La séparation existe parce que nous partons du principe que l'exécution peut mal se comporter et que, par conséquent, tout impact doit être contenu. 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 du plan de contrôle.
Couche 2 : Application du périmètre d'exécution
La production n'est jamais considérée comme faisant partie du périmètre.
Notre système ne considère jamais la production comme faisant partie du périmètre d'attaque. Le pentest est censé s'exécuter uniquement sur des environnements de staging et de test. La production doit être explicitement configurée comme faisant partie du périmètre, et même dans ce cas, cela serait examiné et approuvé avant toute exécution.
Nous avons constaté l'efficacité de nos garde-fous en pratique. Dans un cas, un agent a suivi un comportement applicatif qui l'aurait mené à 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 essayé. Cette tentative bloquée est la preuve que nos garde-fous fonctionnent.
Seuls les domaines autorisés peuvent être accédés
Nos agents ne peuvent interagir qu'avec des domaines explicitement configurés. Si un domaine n'est pas mis sur liste blanche, il est bloqué au niveau du réseau. C'est une configuration que vous pouvez effectuer vous-même, en spécifiant quels domaines sont attaquables ou accessibles. En termes simples, nous bloquons les domaines par défaut pour empêcher l'agent d'interagir avec des serveurs avec lesquels il n'est pas censé interagir.
Cela signifie que nous ne nous appuyons pas sur des invites ou des humains pour l'application du périmètre. Aikido l'applique techniquement de manière autonome.
La dérive accidentelle du périmètre est bloquée
Revenons à notre analogie avec le jeune enfant. Même si la plupart des autres contrôles de sécurité garantissent que les agents ne s'écarteront pas du périmètre, il existe un nombre limité d'agents qui, eh bien, le font. Surtout lorsque vous avez 250 agents exécutés simultanément.
Un exemple classique est celui où un agent est redirigé vers une application externe via un lien ; il suppose qu'il est toujours sur la même page, mais il est en réalité sur un autre site web. Il se retrouve donc soudainement sur X ou Reddit, et suppose que cela fait partie du périmètre.
C'est pourquoi vous avez besoin de vérifications rigoureuses pour protéger les agents d'eux-mêmes. Comme le dit Phillippe Dourassov, Responsable Pentest IA chez Aikido Security :
« Il y aura cinq pour cent d'agents qui ne sont pas toujours sensés, et c'est pourquoi nous nous assurons de gérer ces cinq pour cent ».
Couche 3 : Injection de prompt et exfiltration de données
Nous savons que l'injection de prompt est un risque majeur dans les systèmes d'IA autonomes, où un attaquant 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 pourrait signifier un contenu qui incite les agents à envoyer le code source ou des données internes vers un endroit où elles ne devraient pas se trouver. Cette vulnérabilité provient de l'exposition à du contenu non fiable et de l'exécution de ce contenu. Aikido supprime ces deux options.
Premièrement, les agents d'Aikido n'ont pas d'accès ouvert à Internet. Cela signifie qu'ils ne peuvent pas effectuer de recherche Google pour comprendre le fonctionnement d'une technologie, ni se rendre sur Reddit pour suivre des instructions dangereuses. Le seul contenu qu'ils traitent est celui qui se trouve au sein de l'application ciblée elle-même.
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 sont toujours pas autorisés à exfiltrer des données. Les 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 de code source sur Google Drive, ni publier sur un point de terminaison externe, ni envoyer de données à un domaine contrôlé par un attaquant.
Nous appliquons cela au niveau de la couche réseau en interceptant et en contrôlant le trafic HTTP et DNS des agents, les empêchant de résoudre ou de communiquer avec des domaines qui ne sont pas explicitement approuvés.
Ainsi, dans le scénario du pire, où un modèle interprète mal les instructions, il sera toujours incapable d'envoyer quoi que ce soit vers l'extérieur.
Un cas limite à mentionner est celui où un client injecte délibérément des instructions malveillantes dans son propre environnement (bien que nous ne soyons pas sûrs de la raison pour laquelle cela se produirait ?!), l'agent pourrait bien traiter cela. Mais même dans ce cas, le seul impact sera sur le propre test du client. Il n'y a pas de risque inter-locataire, d'exposition d'infrastructure ou de fuite de données au-delà de ce qu'ils contrôlent déjà.
Couche 4 : Sandboxes isolées pour chaque agent
Chacun de nos agents dispose de sa propre petite sandbox isolée (pensez : jeune enfant dans un parc). Cela signifie qu'ils sont séparés à la fois de l'infrastructure interne d'Aikido et des autres agents exécutés simultanément. Ils sont donc séparés de l'accès au réseau, à l'infrastructure et aux bases de données d'Aikido, et ne peuvent pas interférer avec ou influencer d'autres sessions actives.
Si quelque chose se comporte de manière inattendue pendant un test, l'impact est contenu dans cette seule sandbox, ce qui prévient à la fois l'impact sur les autres agents et l'exposition inter-locataire.
Couche 5 : Mesures de protection opérationnelles
Toutes les requêtes sont soumises à des limites de débit et conscientes de la charge, garantissant que les tests ne surchargent pas les systèmes cibles et ne déclenchent pas un barrage d'alertes.
De plus, les tests peuvent être mis en pause ou terminés immédiatement à tout moment. Les clients peuvent voir ce que font les agents en temps réel. Chaque requête et action est visible. Cela signifie que les équipes peuvent intervenir si elles le jugent nécessaire.
Validation de la configuration
Les erreurs de configuration sont plus probables que les comportements malveillants. C'est pour cette raison qu'avant le début des tests, Aikido utilise des contrôles préliminaires pour valider l'authentification et l'accessibilité. Si une configuration semble incorrecte ou ressemble à un environnement de production, des avertissements sont émis tôt. 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.
Limites souples
Notre approche par couches implique également des limites souples. C'est là que vous n'auriez pas besoin qu'un domaine soit accessible pour que les agents l'utilisent.
Par exemple, si vous aviez un portail d'authentification, alors au sein de ce portail, vous pourriez vouloir que les agents utilisent l'authentification pour se connecter à l'application, mais vous ne voulez pas que les agents attaquent le portail lui-même.
La limite souple signifie que les agents peuvent toujours atteindre le portail d'authentification, mais reçoivent l'instruction spécifique de ne pas l'attaquer.
Comment le périmètre est appliqué : Pentest humain vs pentest IA
Dans un pentest traditionnel, le périmètre est défini par la documentation, les contrats et le jugement professionnel. Les testeurs sont informés des environnements inclus dans le périmètre. Cela fonctionne bien en 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 via les logs ou une revue.
Avec le pentest IA, le périmètre est appliqué via des contrôles techniques. Si un domaine n'est pas sur 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 du périmètre, la requête échoue automatiquement.
Les deux approches sont efficaces. L'avantage de l'application technique est qu'elle réduit la dépendance à la documentation et à l'interprétation.
Pour bénéficier du pentest IA, qui a déjà montré de meilleurs résultats que le pentest manuel en termes de découverte de problèmes critiques et de haute gravité, essayez Aikido Attack dès maintenant
