PortSwigger ajoute Burp AT, mais le contrôle est le véritable test des tests d'intrusion par IA

PortSwigger a placé son premier système agentique de tests d'intrusion en bêta publique, faisant passer Burp Suite au-delà de l'assistance IA vers un travail de sécurité délégué. Le titre de Google News présente Burp AT comme un lancement de produit IA parmi d'autres. Le véritable changement est plus conséquent : un agent peut désormais utiliser des outils de sécurité établis au sein d'un projet Burp actif.

Burp AT accepte un objectif de test, sélectionne des actions, examine les résultats et ajuste son étape suivante. Pourtant, PortSwigger ne présente pas l'autonomie sans restriction comme son principal argument de vente. L'entreprise place le périmètre, les autorisations et les journaux d'activité hors du contrôle direct du modèle.

Cette conception crée la tension centrale. Les agents IA promettent des investigations plus rapides, mais les tests d'intrusion impliquent des requêtes susceptibles de modifier des données, de perturber des applications ou de franchir des limites juridiques. PortSwigger parie que l'adoption par les professionnels dépend moins de l'intelligence du modèle que de limites applicables et de preuves reproductibles.

Ce lancement met également la pression sur les éditeurs autonomes de tests d'intrusion par IA et les agents de programmation généralistes. Ces produits peuvent raisonner sur les vulnérabilités, mais ils n'héritent pas automatiquement de l'historique du trafic, des outils de test, des enregistrements d'incidents et du flux de travail existant des praticiens dans Burp Suite.

Burp AT transforme un objectif de test en actions d'outils

Burp AT fait passer Burp Suite d'un ensemble d'outils utilisés par des experts à un espace de travail dans lequel un agent supervisé peut poursuivre un objectif.

PortSwigger a présenté Burp AT via la version Early Adopter de Burp Suite Professional 2026.7, le 16 juillet 2026. L'entreprise a ensuite développé son explication publique et positionné le produit comme une couche agentique destinée aux tests d'intrusion menés par des humains.

Un agent IA diffère d'un assistant conventionnel parce qu'il peut planifier et exécuter une séquence d'actions. Un chatbot peut suggérer une charge utile. Un agent peut sélectionner un outil, envoyer la charge utile, inspecter la réponse, réviser son hypothèse et poursuivre les tests.

Selon la publication officielle de Burp AT, les utilisateurs commencent par décrire un objectif de test. L'agent utilise ensuite les outils existants de Burp tout en s'adaptant aux informations renvoyées par la cible.

Une tâche peut porter sur un domaine large ou sur une suspicion précise. Un testeur peut demander à l'agent de cartographier une application inconnue, d'examiner un endpoint, de reproduire un problème connu ou de vérifier une catégorie de vulnérabilités.

Il ne s'agit pas d'une automatisation en arrière-plan qui analyse silencieusement tout. Burp AT ne démarre qu'après son ouverture par un utilisateur et la saisie d'une instruction. L'utilisateur définit également le périmètre cible et détermine quels outils nécessitent une approbation.

Le système fonctionne dans le projet Burp actuellement ouvert. Les utilisateurs peuvent joindre une requête HTTP, un nœud de plan de site ou un problème existant comme contexte. Ce détail fournit à l'agent des informations déjà collectées pendant le travail manuel.

Burp AT réécrit également son activité dans le projet. Les requêtes apparaissent dans le Logger de Burp, les analyses sur le Dashboard, et les vulnérabilités signalées intègrent le flux de travail Issues habituel.

Ce contexte partagé est important, car les tests de sécurité commencent rarement à partir d'une instruction vierge. Un consultant peut déjà disposer de trafic authentifié, de notes sur les rôles de l'application, de faiblesses suspectées et de preuves partielles issues de tests antérieurs.

Un agent distinct nécessiterait que ces éléments soient copiés dans un nouvel environnement. Burp AT peut puiser sélectivement dans le projet sans obliger le testeur à recréer l'historique de la mission.

L'agent utilise également des compétences de test conçues à cet effet et développées avec PortSwigger Research. Ces compétences regroupent des techniques ciblées que l'agent peut appliquer lors d'une évaluation. PortSwigger indique que la bibliothèque s'enrichira à mesure que ses chercheurs perfectionneront de nouvelles méthodes.

Toutefois, le statut bêta mérite d'être souligné. PortSwigger qualifie cette étape de première phase et recommande aux testeurs de vérifier chaque découverte avant d'agir. L'entreprise n'a pas publié de benchmark indépendant et étendu montrant les performances sur des applications de production variées.

La couverture de Google News peut donner l'impression que la version est finalisée et largement validée. Les éléments disponibles étayent une conclusion plus limitée : PortSwigger a livré un agent fonctionnel dans Burp Suite Professional, dont la conception est façonnée par les flux de travail des tests professionnels.

Pourquoi les flux de travail existants des tests d'intrusion sont sous pression

La pression immédiate s'exerce sur les équipes de sécurité qui séparent encore les tests manuels, l'analyse automatisée et l'expérimentation IA dans des systèmes déconnectés.

Les tests dynamiques traditionnels de sécurité des applications envoient des vérifications prédéfinies à une application en cours d'exécution. Ils offrent répétabilité et couverture, mais un scanner peut peiner lorsqu'une découverte exige plusieurs étapes dépendantes du contexte.

Les pentesters humains comblent cette lacune. Ils formulent des hypothèses, comparent le comportement d'une application selon les rôles, enchaînent les faiblesses et déterminent si une réponse inhabituelle justifie une nouvelle piste d'investigation.

Ce jugement est précieux, mais le travail répétitif absorbe une grande partie d'une mission. Cartographier les endpoints, rejouer des requêtes, faire varier les entrées, recueillir des preuves et confirmer des schémas connus peut réduire le temps disponible pour une analyse plus approfondie.

Les agents IA généralistes ont introduit une autre option. Les testeurs peuvent connecter des modèles de programmation à des outils en ligne de commande, à l'automatisation de navigateur ou à des intégrations personnalisées. Cette approche offre de la flexibilité, mais elle transfère également le travail d'orchestration et de sécurité au praticien.

PortSwigger tente d'intégrer cette expérimentation dans un environnement familier. Son modèle de tests agentiques associe un planificateur IA aux outils Burp, au contexte du projet, à des compétences réutilisables et à des contrôles d'autorisation.

La pression stratégique dépasse les testeurs individuels. Les cabinets de conseil en sécurité doivent décider si le travail assisté par IA modifie la capacité de mission, les exigences de preuve ou les procédures de revue. Les équipes internes de sécurité des applications doivent déterminer quelles tâches peuvent être exécutées de manière répétée entre les évaluations formelles.

Les fournisseurs autonomes de tests d'intrusion automatisés font face à un problème différent. Ils peuvent promettre une indépendance vis-à-vis des flux de travail humains, mais Burp occupe déjà l'espace de travail quotidien de nombreux praticiens de la sécurité web. L'intégration peut compter davantage que l'autonomie théorique lorsque les acheteurs ont besoin d'adoption sans remplacer des processus établis.

Les agents de programmation généralistes font également face à un déficit de crédibilité. Ils peuvent écrire des scripts et raisonner sur du code, mais un test d'intrusion professionnel exige un périmètre soigneusement défini, un comportement prévisible des outils et un historique défendable des actions.

L'agent de sécurité d'OpenAI illustre l'approche voisine. Initialement présenté sous le nom d'Aardvark, puis intégré à Codex Security, il analyse des dépôts de code source, évalue l'exploitabilité, valide les découvertes et propose des correctifs.

OpenAI a indiqué que son système avait identifié 92 % des vulnérabilités connues et introduites synthétiquement dans certains dépôts de benchmark sélectionnés. L'entreprise a également fait état de 10 découvertes open source ayant reçu des identifiants CVE. Il s'agit de résultats communiqués par l'entreprise, et non d'une comparaison directe avec Burp AT.

Les produits partent également de points de départ différents. L'agent de recherche en sécurité se concentre sur le code source et les flux de développement. Burp AT interagit avec une application web en cours d'exécution à travers les outils et le trafic d'un projet Burp.

Cette distinction montre que le marché de la sécurité IA ne se réduira pas à un agent universel unique. La revue du code source, les tests externes de surface d'attaque, les tests d'applications web, la validation cloud et la remédiation exigent chacun des contextes et des contrôles différents.

Le cadrage de Google News se concentre sur l'ajout d'un agent IA au portefeuille de PortSwigger. L'histoire plus large est que les plateformes de sécurité doivent désormais répondre à l'investigation déléguée, et pas seulement générer des explications.

Un scanner conventionnel suit des vérifications programmées. Un agent généraliste peut improviser, mais manquer de garde-fous spécialisés. Burp AT occupe une position intermédiaire, en exploitant le raisonnement du modèle tout en limitant l'exécution par des outils établis.

Cette combinaison pousse les concurrents à expliquer où se situent leurs limites. La promesse qu'un agent est « sûr » parce que son instruction l'affirme paraîtra plus faible face à des contrôles appliqués par l'application environnante.

L'avantage de PortSwigger réside dans la cage autour de l'agent

Le mécanisme le plus important de Burp AT est la séparation architecturale entre ce que le modèle propose et ce que Burp autorise.

Les grands modèles de langage produisent des résultats probabilistes, ce qui signifie qu'un même contexte peut conduire à des réponses différentes. Les outils de tests d'intrusion nécessitent généralement un comportement déterministe, où une commande définie produit une opération prévisible.

PortSwigger associe ces propriétés plutôt que de demander au modèle de remplacer chaque composant de test. L'agent choisit parmi les outils Burp, tandis que les outils exécutent des opérations établies.

L'entreprise indique que le périmètre, l'accès aux outils et les politiques d'approbation résident dans la couche d'outillage de Burp. Ils sont séparés architecturalement du modèle, de sorte que celui-ci ne peut pas simplement réinterpréter une restriction formulée en langage naturel.

Cette séparation répond à un problème fréquent des agents. Les instructions dans une instruction entrent en concurrence avec d'autres éléments de contexte, y compris du contenu récupéré depuis une application. Une page malveillante peut contenir du texte conçu pour rediriger un agent, une technique appelée injection indirecte d'instructions.

Une vérification de politique externe ne rend pas l'injection d'instructions sans importance. Elle limite ce qu'un agent manipulé peut exécuter. L'agent peut proposer une action inappropriée, mais la couche d'outillage peut rejeter cette action lorsqu'elle viole le périmètre ou les autorisations.

Burp AT offre plusieurs niveaux de contrôle utilisateur. Un testeur peut exiger une approbation pour chaque action, autoriser les opérations courantes ou permettre une plus grande autonomie dans des limites configurées.

Certaines actions restent sensibles, indépendamment de leur commodité. Burp AT peut envoyer les mêmes types de requêtes qu'un testeur humain, y compris des requêtes qui modifient ou suppriment des données. Cette capacité fait de la configuration un élément du modèle de sécurité de la mission.

PortSwigger affirme que les actions à fort impact nécessitent une approbation. Les utilisateurs peuvent également désactiver certains outils, restreindre le périmètre et arrêter une tâche pendant son exécution.

Il existe une exception importante. Les scripts personnalisés dont l'exécution est approuvée peuvent envoyer directement des requêtes réseau au lieu de passer par l'outil de requêtes standard de Burp. PortSwigger recommande aux utilisateurs de vérifier ces scripts et de désactiver les outils de script lorsque cela est nécessaire.

Cette exception empêche de conclure trop simplement que chaque action est automatiquement contenue. La limite de sécurité ne reste efficace que si les équipes comprennent quels outils contournent certaines vérifications.

La journalisation constitue la deuxième partie de la conception. Burp enregistre les requêtes de l'agent et l'activité des outils dans le projet, tandis que les découvertes incluent les requêtes et réponses HTTP à l'appui.

Ces preuves permettent à un humain de reproduire le comportement et de déterminer si le problème signalé est exploitable. Elles créent également un historique pour la revue interne, les rapports destinés aux clients et l'analyse après mission.

La reproductibilité est essentielle, car une explication IA plausible ne constitue pas une preuve de vulnérabilité. Une découverte valide exige un comportement observable, un chemin d'attaque défini et suffisamment de preuves pour qu'un autre testeur puisse la reproduire.

Le contexte du projet fournit le troisième mécanisme. L'agent peut utiliser du trafic, des problèmes et des données de plan de site sélectionnés sans téléverser l'intégralité du projet Burp.

Cela réduit les redécouvertes. Si un testeur s'est déjà authentifié, a cartographié un flux de travail ou a isolé une requête suspecte, l'agent peut commencer à partir de ce point.

Cela place également la responsabilité sur l'utilisateur. Le trafic joint peut contenir des jetons de session, des informations personnelles, du code source ou des données client. Davantage de contexte peut améliorer le raisonnement tout en augmentant la sensibilité des données qui quittent le système local.

L'architecture de Burp AT représente donc un compromis, et non une solution complète. L'agent gagne en utilité en accédant à des données de test réelles et en exécutant de véritables outils. Ces mêmes capacités créent la nécessité de décisions strictes concernant le périmètre, la revue et la gouvernance des données.

C'est pourquoi la couche de contrôle compte davantage qu'une vidéo de démonstration. Un exploit ingénieux découvert dans un laboratoire prouve une capacité. Un modèle d'autorisations qui résiste à un usage professionnel courant détermine si les équipes peuvent déployer cette capacité de manière responsable.

L'attention de Google News ne résout pas les risques liés aux données

Burp AT laisse les humains contrôler les actions, mais les clients doivent toujours décider si son cheminement des données répond à leurs obligations de sécurité et de conformité.

PortSwigger indique que Burp AT et Burp AI utilisent l'infrastructure d'IA de l'entreprise. Une requête circule de Burp vers cette infrastructure, puis vers un fournisseur de modèles externe.

L'entreprise utilise actuellement des modèles Anthropic pour Burp AT. Les utilisateurs ne peuvent pas sélectionner un modèle ni imposer un traitement dans une zone géographique précise.

PortSwigger indique que son infrastructure fonctionne dans des régions AWS situées en Virginie et en Irlande. Les fournisseurs d'IA traitent les requêtes dans des centres de données aux États-Unis, tandis que le routage entre les régions de PortSwigger s'effectue automatiquement.

Le système peut transmettre des prompts, des ressources jointes, des messages d'agent, des appels d'outils et des résultats d'outils. Lorsqu'un outil envoie une requête HTTP, ces résultats peuvent inclure des requêtes et réponses complètes.

Ces éléments contiennent souvent les informations les plus sensibles d'un test d'intrusion. Des cookies d'authentification, dossiers clients, identifiants internes, réponses d'API et logique applicative propriétaire peuvent tous apparaître dans le trafic capturé.

PortSwigger précise que Burp AT ne masque pas automatiquement ces éléments. Les utilisateurs qui doivent examiner les données sortantes peuvent exiger une approbation avant les actions concernées, mais cette protection ajoute des frictions opérationnelles.

L'entreprise stocke également les prompts, réponses, détails des tâches et métadonnées associées. Ses conditions de traitement des données indiquent que les données de conversation et d'audit sont conservées indéfiniment à des fins de dépannage et de développement de fonctionnalités à long terme.

Les journaux opérationnels ont une période de conservation annoncée plus courte, de 31 jours. PortSwigger indique que les données stockées utilisent le chiffrement AES-256, tandis que les données en transit utilisent TLS 1.2 ou une version ultérieure.

L'entreprise affirme que ses contrats interdisent aux fournisseurs de modèles de conserver les données clients ou de les utiliser pour l'entraînement. PortSwigger se réserve néanmoins le droit d'utiliser des données anonymisées afin d'améliorer ses fonctionnalités d'IA et de diagnostiquer des problèmes.

Ces conditions sont suffisamment précises pour que les équipes de sécurité puissent les évaluer, mais elles ne conviendront pas à toutes les missions. Certains clients interdisent le traitement par des modèles externes, exigent une résidence régionale des données ou imposent des calendriers de suppression fixes.

Une bêta publique introduit également une incertitude technique. PortSwigger indique que Burp AT utilise des outils déterministes, mais une exécution déterministe ne garantit pas une planification correcte. L'agent peut toujours choisir une piste improductive, mal comprendre la logique de l'application ou s'arrêter avant d'identifier une chaîne pertinente.

Les faux positifs constituent un autre risque. Le système consigne des preuves, mais un humain doit déterminer si celles-ci étayent l'impact allégué. PortSwigger demande explicitement aux utilisateurs de considérer chaque découverte comme une piste nécessitant une vérification.

Les faux négatifs peuvent être plus difficiles à détecter. Un résumé de tâche soigné peut laisser croire à une couverture complète même lorsque l'agent a ignoré un endpoint, mal compris une limite d'autorisation ou abandonné une hypothèse prometteuse.

Les documents publics actuels de Burp AT n'établissent pas la fréquence de telles défaillances. PortSwigger n'a pas publié d'évaluation indépendante couvrant différentes architectures applicatives, classes de vulnérabilités et flux d'authentification complexes.

Cette lacune compte lorsqu'on compare un agent à un testeur humain. La vitesse est mesurable, mais la valeur professionnelle dépend aussi de la couverture, de la nouveauté, de l'exactitude, de la reproductibilité et de la sensibilité au contexte métier.

Un agent peut identifier efficacement une faille de cross-site scripting persistante tout en manquant le fait que la page concernée est isolée des utilisateurs significatifs. Il peut aussi écarter un problème d'autorisation de faible sévérité qui devient critique lorsqu'il est combiné à une autre faiblesse.

La revue humaine n'est donc pas une simple étape cérémonielle d'approbation. Elle apporte le contexte métier et de menace que les seules réponses HTTP peuvent ne pas révéler.

La nature à double usage de cette technologie soulève une autre préoccupation. Un agent capable de trouver et de valider des vulnérabilités peut aider les défenseurs, les chercheurs autorisés ou les attaquants. L'accès au produit, la surveillance et l'application du périmètre réduisent les abus, mais ne peuvent effacer cette capacité fondamentale.

La visibilité dans Google News accroîtra la curiosité des équipes de sécurité comme des attaquants. Elle ne doit pas être prise pour une validation indiquant que chaque organisation peut connecter en toute sécurité un trafic applicatif sensible au service.

La décision pratique commence par les règles de mission. Les équipes doivent identifier les données interdites, les cibles autorisées, les exigences d'approbation, les normes de preuve et les obligations de conservation avant de confier un véritable travail à l'agent.

Burp AT mise sur le flux de travail, pas sur l'autonomie maximale

PortSwigger choisit une intégration supervisée plutôt que d'affirmer qu'un agent d'IA peut remplacer un pentester professionnel.

Ce choix distingue Burp AT des produits commercialisés autour de tests autonomes de bout en bout. L'autonomie maximale est attrayante, car elle promet une couverture plus large avec moins de travail humain.

Cependant, l'autonomie peut devenir un risque lors du test d'une application de production. Un système qui agit sans contexte peut générer un trafic excessif, modifier des données client ou produire une découverte que personne ne peut reproduire.

Burp AT considère le testeur humain comme le responsable de la mission. L'agent réalise l'investigation déléguée, tandis que l'utilisateur définit le périmètre, contrôle les autorisations, examine les scripts et valide les résultats.

Ce modèle préserve également la reprise manuelle. Les outils existants de Burp restent disponibles ; un testeur peut donc interrompre l'agent et poursuivre directement une investigation.

La conception reflète la façon dont les praticiens expérimentés travaillent déjà avec des membres plus juniors de leur équipe. Un testeur senior peut déléguer une tâche circonscrite, examiner les preuves, réorienter l'investigation et conserver la responsabilité de la conclusion finale.

Un agent d'IA n'a toutefois pas de responsabilité professionnelle. Il ne peut pas comprendre les obligations contractuelles de la même manière que le consultant ayant signé les règles de mission. Les restrictions appliquées par les outils doivent traduire ces obligations en politiques exécutables.

Les fournisseurs autonomes peuvent toujours concurrencer cette approche en prenant en charge des surfaces d'attaque plus larges, des tests continus ou une remédiation automatisée. L'objectif initial de Burp AT est le test d'intrusion web au sein de Burp Suite Professional.

Les agents orientés code occupent également un terrain distinct. Ils peuvent analyser le code avant le déploiement et recommander des correctifs, tandis que Burp AT observe le comportement externe d'une application en cours d'exécution.

Les scanners automatisés restent eux aussi pertinents. Ils offrent une couverture planifiée et prévisible, et peuvent exécuter des vérifications établies sur de nombreuses cibles sans raisonnement d'agent ouvert.

La concurrence émergente se joue donc entre des modèles opérationnels :

• Les scanners traditionnels mettent l'accent sur la répétabilité, l'échelle et des vérifications prédéfinies.

• Les agents généralistes mettent l'accent sur la flexibilité, mais exigent que les utilisateurs assemblent les outils, le contexte et les contrôles.

• Les plateformes de pentest autonomes mettent l'accent sur une couverture déléguée dans des environnements définis.

• Burp AT met l'accent sur l'investigation menée par l'humain au sein d'un espace de travail établi pour les tests web.

Aucun de ces modèles n'élimine les autres. Un programme mature de sécurité applicative peut utiliser l'analyse du code pendant le développement, le scan automatisé dans les pipelines de livraison, la validation continue après le déploiement et des tests humains ciblés pour les risques complexes.

L'avantage de PortSwigger apparaît lorsqu'un testeur humain travaille déjà dans Burp. L'agent peut réutiliser le trafic, les outils, les découvertes et le flux de travail de ce projet, au lieu de créer un système d'enregistrement distinct.

Son désavantage apparaît lorsque les acheteurs souhaitent des tests sans surveillance sur de nombreux actifs. Le positionnement actuel et la bêta publique mettent l'accent sur un travail interactif, piloté par l'humain, plutôt que sur un service de test entièrement indépendant.

Les fonctionnalités plus larges de Burp AI clarifient encore la distinction. Burp AI assiste dans des outils particuliers, tandis que Burp AT poursuit un objectif à travers plusieurs étapes.

Ce portefeuille offre à PortSwigger une voie allant de l'assistance ciblée à la délégation supervisée. Les clients peuvent adopter des fonctionnalités d'IA individuelles sans accorder immédiatement à un agent un accès plus étendu.

L'entreprise doit encore démontrer que cette progression améliore les résultats. L'adoption par les utilisateurs dépendra de la capacité des testeurs à gagner un temps significatif sans consacrer ce temps à examiner des découvertes peu solides ou à gérer des approbations.

Les équipes doivent mesurer les investigations achevées, les vulnérabilités vérifiées, le temps de revue, le travail dupliqué et les interruptions causées par l'agent. Compter les prompts ou les découvertes générées récompenserait l'activité plutôt que la valeur de sécurité.

L'article de Google News ne se résume donc pas à PortSwigger face à un autre fournisseur. La principale confrontation oppose l'autonomie supervisée à la délégation sans restriction.

PortSwigger a clairement fait son choix. L'agent peut planifier, mais Burp contrôle l'exécution. L'agent peut rédiger un rapport, mais le testeur doit vérifier. L'agent peut utiliser le contexte du projet, mais l'organisation doit décider quel contexte peut quitter la machine.

Ce que les équipes de sécurité doivent surveiller ensuite

Trois signaux détermineront si Burp AT devient un partenaire de test standard ou reste une fonctionnalité bêta intéressante.

Le premier signal concerne des preuves de performance indépendantes. PortSwigger doit fournir des évaluations qui distinguent le rappel des vulnérabilités, les faux positifs, le temps de test et l'effort de revue humaine.

Une comparaison utile examinerait les mêmes applications au périmètre défini dans le cadre de tests manuels, de scans conventionnels et de tests assistés par Burp AT. Elle devrait inclure des flux authentifiés et des failles de logique métier, et pas seulement des schémas d'injection connus.

Des preuves de découvertes inédites renforceraient le dossier de PortSwigger. L'entreprise a associé le lancement de Burp AT à des recherches présentées autour de Black Hat USA 2026, où la recherche en sécurité pilotée par l'IA a suscité une attention importante.

Le programme Black Hat confirme à quel point la sécurité de l'IA est devenue centrale lors de l'événement de 2026. Les démonstrations de conférence doivent encore être traduites en résultats clients reproductibles.

Si des tests indépendants montrent une couverture vérifiée plus élevée sans charge de revue proportionnelle, les agents supervisés gagneront en crédibilité. Si les résultats dépendent fortement de cibles soigneusement sélectionnées, la bêta restera un assistant plutôt qu'un multiplicateur de tests.

Le deuxième signal concerne le contrôle des données en entreprise. Les acheteurs surveilleront la conservation configurable, les options de traitement régional, le masquage, la sélection de modèles et des politiques administratives plus strictes.

Ces fonctionnalités ne rendraient pas l'agent plus intelligent. Elles le rendraient déployable dans un éventail plus large de contrats et d'obligations réglementaires.

Une option de conservation plus courte ou contrôlée par le client répondrait à une objection claire. Le traitement local ou des modèles privés approuvés ouvriraient des missions qui interdisent actuellement les services d'IA externes.

PortSwigger pourrait aussi avoir besoin de modèles de politiques centralisés. Les cabinets de conseil en sécurité devraient pouvoir définir des autorisations d'outils et des exigences de preuve communes entre les testeurs sans configurer chaque projet manuellement.

Si l'entreprise étend ces contrôles, sa stratégie d'« agent dans une cage » deviendra plus convaincante. Si la gouvernance reste figée, l'adoption pourrait se concentrer parmi les petites équipes et les évaluations moins contraintes.

Le troisième signal concerne le comportement des praticiens. PortSwigger devra montrer si les testeurs confient des tâches d’investigation substantielles ou s’ils utilisent Burp AT principalement pour des vérifications ciblées et répétitives.

Des reprises fréquentes en manuel ne signifieraient pas automatiquement un échec. Elles pourraient indiquer que le système est plus efficace comme collaborateur, en accélérant la préparation tout en laissant les raisonnements difficiles aux humains.

La mesure la plus importante est le volume de résultats vérifiés par unité de temps de relecture. Un agent qui produit de nombreuses conclusions mais exige un nettoyage considérable peut alourdir la charge de travail d’une équipe.

Les praticiens devraient également surveiller la bibliothèque de compétences. De nouvelles compétences peuvent transformer des techniques de recherche en procédures de test réutilisables, ouvrant la voie d’une découverte par des spécialistes à une application plus large.

Cette voie comporte des risques en matière de qualité. Une technique qui fonctionne de manière fiable dans un environnement de recherche peut se comporter différemment selon les architectures de production. Les compétences nécessitent un versionnage, des tests et des exigences claires en matière de preuves.

Pour les responsables de la sécurité, l’étape suivante raisonnable consiste en une évaluation limitée. Choisissez une cible non productive autorisée, restreignez l’ensemble des outils, exigez des validations et comparez les résultats à une évaluation existante.

Conservez les conclusions de l’agent, le trafic justificatif, les décisions des relecteurs et les problèmes non détectés dans une base de connaissances d’ingénierie consultable. Cet historique rend les comparaisons ultérieures plus utiles que les impressions tirées d’une seule démonstration.

PortSwigger a déjà répondu à une question : l’IA agentique fait désormais partie d’un outil professionnel de pentest grand public. La question sans réponse est de savoir si ses contrôles peuvent rendre les tests délégués systématiquement dignes de confiance.

Ignorez l’enthousiasme suscité par un titre de Google News et observez les preuves. Burp AT détecte-t-il plus rapidement des problèmes vérifiés, respecte-t-il le périmètre, protège-t-il les données sensibles et réduit-il le travail répétitif ?

Si c’est le cas, le pentesteur humain ne disparaîtra pas. Son rôle évoluera vers la définition des objectifs, la supervision des actions risquées, l’interprétation de l’impact métier et la décision quant à savoir si les preuves de l’agent sont suffisamment solides pour être jugées fiables.