Custom AI Agent pour Burp Suite : ce que la version 1.0.0 corrige vraiment

Le problème que l'extension attaque, et pour qui

Burp Suite excelle dans l'interception et la rejeu de requêtes, mais l'analyse reste largement manuelle : on lit une réponse, on repère une anomalie, on formule une hypothèse. Custom AI Agent ajoute une couche qui délègue une partie de cette lecture à un modèle, tout en gardant les requêtes à l'intérieur de Burp. Le public visé est précis : testeurs d'intrusion qui utilisent Burp Pro au quotidien, chasseurs de bugs qui veulent automatiser le tri d'un gros volume de trafic, et équipes AppSec qui souhaitent brancher un assistant IA sur leur proxy sans exporter les échanges vers un service tiers. Le README annonce deux scanners, passif et actif, couvrant 62 classes de vulnérabilités, ainsi qu'un jeu de 59 outils MCP permettant à un client externe de conduire Burp de façon autonome. Un point de vocabulaire à ne pas manquer : l'extension s'appelle désormais Custom AI Agent, alors que le dépôt GitHub, le site de documentation et le répertoire de configuration conservent l'identifiant burp-ai-agent. Ce décalage vient d'une exigence de nommage de PortSwigger, destinée à éviter la confusion avec le fournisseur Burp AI intégré. Concrètement, vous chercherez le dépôt sous un nom et l'extension dans l'interface de Burp sous un autre.

Architecture : ce qui circule entre Burp, le modèle et le client MCP

L'extension est écrite en Kotlin et se charge comme n'importe quel plugin Java dans Burp. Elle s'articule autour de trois flux. Le premier relie l'interface de Burp aux backends IA : le README en liste douze, dont Burp AI, Anthropic, Ollama, LM Studio, NVIDIA NIM, Perplexity, un endpoint compatible OpenAI générique, et plusieurs interfaces en ligne de commande (Gemini CLI, Claude CLI, Codex CLI, OpenCode CLI, Copilot CLI). Le deuxième flux est le serveur MCP : un client externe comme Claude Desktop ouvre une connexion vers l'extension et appelle des outils, 59 dans la build complète, 8 seulement dans la build destinée au BApp Store. Le troisième flux est interne : le scanner passif s'enregistre comme PassiveScanCheck, ce qui suppose Burp Pro, et le scanner actif émet ses propres requêtes. La nouveauté de la 1.0.0 tient à l'ordre des décisions. Les contrôles de contrôle d'accès MCP s'exécutent désormais avant le routage, et non après résolution de la route. C'est ce déplacement qui referme la faille SEC-04, où le listener acceptait des appels d'outils non authentifiés lorsque l'accès externe était activé. Autre mécanisme à retenir : les appels d'outils issus de la sortie du modèle passent par une validation humaine. Les outils bornés en lecture s'exécutent sans confirmation, tout le reste affiche une carte d'approbation dans le chat, et un nom d'outil non reconnu demande confirmation à chaque fois plutôt que de s'exécuter en silence.

Installation et configuration : les commandes réelles

Le README privilégie le téléchargement du JAR depuis les Releases. La compilation depuis les sources demande Java 21 et produit deux artefacts distincts. Pour la build complète, celle des releases GitHub avec les 59 outils MCP :

git clone https://github.com/six2dez/burp-ai-agent.git cd burp-ai-agent JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar

Le résultat se trouve dans build/libs/Custom-AI-Agent-full-<version>.jar. Pour la build « store », limitée aux 8 outils MCP natifs de l'extension, la commande ajoute un paramètre :

JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar -PstoreBuild=true

Le JAR sort sous build/libs/Custom-AI-Agent-<version>.jar. Une fois le fichier obtenu, la procédure documentée est celle de Burp : Extensions > Installed > Add, type Java, puis sélection du JAR. L'extension apparaît sous le nom Custom AI Agent dans la liste des extensions et dans l'onglet Suite. Au premier lancement, elle installe les profils d'agents fournis dans ~/.burp-ai-agent/AGENTS/. Pour ajouter vos propres profils, il suffit de déposer des fichiers *.md dans ce même répertoire. Le reste de la configuration se fait dans le panneau de réglages de l'extension : choix du backend, mode de confidentialité parmi STRICT, BALANCED et OFF, et restriction éventuelle des outils MCP aux hôtes du périmètre. Le README ne détaille pas les clés de configuration individuelles, et cette zone reste à explorer dans l'interface elle-même.

La faille PRIV-05 et ce qu'elle dit du traitement des cookies

La correction la plus instructive de la 1.0.0 ne concerne pas l'authentification MCP mais la sortie des données. Le défaut PRIV-05, classé high, décrit des cookies de session transmis aux backends IA sans rédaction, y compris en mode STRICT et BALANCED. Deux causes se cumulaient : le scanner passif émettait les cookies sous la forme brute name=value, ce qui supprimait le préfixe sur lequel la rédaction s'appuyait, et seul un cookie nommé littéralement session était intercepté. Autrement dit, un cookie d'authentification portant un autre nom partait tel quel. Le README demande explicitement de faire tourner les cookies concernés, ce qui suppose que des valeurs ont pu être exposées à un tiers. Deux enseignements pour l'évaluation. D'abord, un mode de confidentialité n'est pas une garantie homogène : il faut vérifier ce qu'il couvre réellement, et le cas des cookies montre qu'une rédaction dépendante du nom est fragile. Ensuite, la 1.0.0 n'est pas une simple release de confort. Si vous avez fait tourner une version 0.9.x contre des cibles réelles, la rotation des identifiants n'est pas optionnelle. À noter aussi : aucun identifiant CVE ou GHSA n'a été attribué à ces deux défauts, ce que le README signale explicitement pour éviter des recherches infructueuses dans les bases publiques.

Ce que la 1.0.0 durcit, et pourquoi cela complique l'usage

Trois durcissements méritent d'être pesés avant l'adoption, car ils ont un coût en ergonomie. Le premier est la confirmation des appels d'outils émis par le modèle. Un agent qui enchaîne vingt appels demandera vingt validations, sauf pour les outils bornés en lecture. C'est le prix d'un comportement qui échoue en mode fermé : un nom d'outil inconnu déclenche une confirmation, jamais une exécution silencieuse. Le deuxième concerne la reprise de port. Auparavant, un processus local qui occupait le port MCP et renvoyait l'en-tête d'identité pouvait récupérer le jeton donnant accès à l'ensemble des outils. Désormais le client présente une preuve de possession HMAC, et sous TLS il épingle le certificat du serveur à son propre keystore. Cette dernière contrainte signifie qu'un certificat régénéré côté extension cassera la connexion tant que le client n'aura pas été mis à jour. Le troisième est le traitement des notations IP alternatives : SsrfGuard reconnaît maintenant http://2852039166/, qui est la forme décimale de 169.254.169.254, et la classification ne fait plus aucune résolution de nom. Le corollaire est qu'un nom d'hôte résolvant vers une adresse privée ne sera plus classé comme tel par cette couche. Ces choix réduisent la surface d'attaque mais déplacent une partie du jugement vers l'opérateur.

Limites et cas où l'outil n'est pas le bon

La contrainte la plus dure est l'absence de publication sur le BApp Store. Le README indique que la soumission est ouverte depuis janvier 2026 et que l'installation passe par les Releases GitHub. Cela veut dire une mise à jour manuelle : télécharger le JAR, le recharger dans Burp, redémarrer l'extension. Pas de canal de mise à jour automatique, pas de signature par le magasin. Le scanner passif s'appuie sur PassiveScanCheck, une API de Burp Pro : en Community, cette partie ne fonctionnera pas. Ensuite, la build « store » ne contient que 8 outils MCP contre 59 pour la build complète. Si vous installez le JAR destiné à la soumission en croyant obtenir l'ensemble des outils, vous serez limité. Troisième limite : la couverture de tests. Le README annonce une progression de 660 à 1131 tests et une couverture de lignes passée de 34 % à 58 %. Une couverture de 58 % reste partielle, et la baseline detekt n'a reculé que de 1096 à 1040, ce qui signifie que des avertissements statiques subsistent. Enfin, l'extension dépend d'un backend IA, local ou distant. En mode STRICT, la rédaction est agressive et peut dégrader la qualité de l'analyse ; en mode OFF, les données partent telles quelles. Il n'existe pas de réglage intermédiaire fin documenté dans le README.

Face à Caido et à Burp AI : deux approches différentes

Le concurrent le plus direct sur le terrain des proxys modernes est Caido, qui propose une architecture de plugins et une interface repensée. La différence d'approche est structurelle : Caido est un proxy alternatif qu'on adopte à la place de Burp, alors que Custom AI Agent est une extension qui s'installe dans Burp. Si votre flux de travail, vos macros et vos habitudes de rejeu sont déjà dans Burp, migrer vers Caido représente un coût que l'extension évite. À l'inverse, si vous partez de zéro, le choix d'un proxy complet se pose avant celui d'une extension. Le second point de comparaison est Burp AI, le fournisseur intégré de Burp Suite. Custom AI Agent s'en distingue par le nombre de backends, douze contre un, et par l'exposition MCP : c'est cette dernière qui permet à Claude Desktop ou à un assistant en ligne de commande de piloter Burp comme un outil parmi d'autres. Burp AI reste lié à l'écosystème PortSwigger. La contrepartie est la surface de sécurité : un serveur MCP local, un jeton, un listener, autant d'éléments que la 1.0.0 a dû corriger. Un utilisateur qui se satisfait de l'analyse intégrée de Burp n'a aucune raison d'ajouter cette couche.

Maintenance, licence et coût de mise à jour

La licence est MIT, ce qui autorise la modification et la redistribution avec conservation de la mention de copyright. Le README ne comporte pas de clause supplémentaire ni de restriction d'usage commercial. Rien dans le matériel fourni n'indique de conditions liées aux backends IA : les obligations contractuelles viendront de votre fournisseur de modèle, pas de l'extension. Côté maintenance, le rythme observé est soutenu : 0.9.1 et 0.9.2 le 29 juillet 2026, puis 1.0.0 le 22 août 2026, avec un dernier push sur main au 2 septembre 2026. Le coût réel se situe ailleurs. Deux défauts confirmés par exécution du code publié ont touché toutes les versions 0.9.x, et l'un d'eux impose la rotation d'identifiants. Cela signifie qu'une mise à jour de cette extension n'est pas une opération neutre : elle peut invalider des cookies, des jetons MCP, voire un certificat épinglé. La compilation depuis les sources ajoute sa propre charge, avec un JDK 21 requis et deux variantes d'artefacts à ne pas confondre. Pour un déploiement en équipe, la question n'est pas seulement de savoir si l'outil fonctionne, mais qui suit les avis de sécurité et qui recharge les JAR.

Conclusion éditoriale

Adoptez Custom AI Agent si vous travaillez déjà sous Burp et qu'un client MCP externe doit piloter vos outils sans sortir du périmètre autorisé. Passez votre chemin si vous n'avez pas de JDK 21 à disposition, si le scanner passif vous est indispensable sans licence Pro, ou si vous cherchez un outil qui ne dépend pas d'un fournisseur de modèle. Avant toute installation, lisez SECURITY.md, vérifiez que le JAR chargé porte bien le numéro 1.0.0 et non un 0.9.x, et faites tourner l'extension en STRICT sur une cible de test avant de la brancher sur un programme réel.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. six2dez/burp-ai-agent on GitHub