T3MP3ST : un framework multi-agent pour le red teaming autorise

Overview

T3MP3ST est présenté par son dépôt comme un framework de sécurité offensive multi-agent conçu pour transformer un agent de code IA déjà utilisé localement en harnais de red teaming (README: https://github.com/elder-plinius/T3MP3ST). Le projet parle d’un flux recon -> exploit -> report, accessible depuis une interface navigateur appelée War Room ou depuis la CLI, avec des connexions possibles vers Claude Code, Codex, Hermes, des fournisseurs API ou des modèles locaux comme Ollama, LM Studio et vLLM (README: https://github.com/elder-plinius/T3MP3ST).

Le dépôt expose une architecture TypeScript/JavaScript. Le package.json indique un paquet t3mp3st en version 1.0.0, une sortie principale dist/index.js, des binaires tempest et t3mp3st, un moteur Node >=18.0.0, ainsi que des scripts comme server, mcp, verify-claims, doctor, build, test, cloud:bench, mobile:bench et binary:bench (package.json: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/package.json).

Le projet est publié sous licence AGPL-3.0-or-later selon le package.json et le README renvoie vers une licence AGPL-3.0 (package.json: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/package.json, README: https://github.com/elder-plinius/T3MP3ST). Aucune release GitHub n’est publiée au moment de la consultation (Releases: https://github.com/elder-plinius/T3MP3ST/releases).

Important: cet article n’a pas exécuté T3MP3ST. Les descriptions ci-dessous synthétisent les sources du dépôt et de sa documentation. Les résultats de benchmark cités dans le README sont donc rapportés comme des affirmations du projet, pas comme des validations réalisées ici.

Objectif

L’objectif affiché de T3MP3ST est d’orchestrer des tâches de sécurité offensive sur des cibles explicitement autorisées, avec un modèle multi-agent, un arsenal d’outils, un journal de preuves et une interface de pilotage (README: https://github.com/elder-plinius/T3MP3ST). Le projet insiste aussi sur l’idée de mesures reproductibles: le README indique que les chiffres mis en avant peuvent être recalculés depuis les données commitées avec npm run verify-claims (README: https://github.com/elder-plinius/T3MP3ST).

Le dépôt ne présente pas seulement un outil de scan. Il propose une structure complète: Mission Control, Target Model, Arsenal, Evidence Vault, Credential Store, Findings Ledger, OPSEC Layer, communications et LLM Backbone (README architecture: https://github.com/elder-plinius/T3MP3ST). La documentation FEATURES.md suit ces composants avec une grille d’état [x], [~] et [ ], ce qui permet de distinguer les fonctionnalités indiquées comme implémentées, partielles ou planifiées (FEATURES: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/FEATURES.md).

Le cadre d’usage est explicite: le document SCOPE_AND_AUTHORIZATION.md indique que T3MP3ST est construit pour la recherche de sécurité autorisée, les assets possédés, les labs, les scopes bug bounty, le red team interne et le reporting défensif basé sur des preuves (Scope docs: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/SCOPE_AND_AUTHORIZATION.md). Cette contrainte n’est pas accessoire: elle conditionne la manière de lire l’outil.

Liens utiles

Installation

Le README donne un démarrage minimal avec npm install, puis le lancement du serveur War Room avec npm run server, accessible sur http://127.0.0.1:3333/ui/ (README: https://github.com/elder-plinius/T3MP3ST). Le package.json indique que le projet demande Node >=18.0.0 (package.json: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/package.json).

Commandes documentées pour démarrer la War Room:

npm install
npm run server

Le README indique ensuite d’ouvrir les paramètres de la War Room et de connecter un agent local, par exemple Claude Code, Codex ou Hermes (README: https://github.com/elder-plinius/T3MP3ST). Pour un usage avec clés API, le README mentionne des variables comme OPENROUTER_API_KEY, VENICE_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY ou XAI_API_KEY (README: https://github.com/elder-plinius/T3MP3ST).

Exemple documenté pour un fournisseur API:

export OPENROUTER_API_KEY=...
export XAI_API_KEY=...Langage du code : JavaScript (javascript)

Le README décrit aussi un mode local/offline via Ollama ou un serveur compatible OpenAI comme LM Studio, vLLM ou llama.cpp (README: https://github.com/elder-plinius/T3MP3ST):

ollama serve && ollama pull llama3
export TEMPEST_LOCAL_BASE_URL=http://localhost:11434/api
export TEMPEST_LOCAL_MODEL=llama3
npx tempestLangage du code : JavaScript (javascript)

Pour les outils externes, la matrice d’installation liste plusieurs familles: core evidence, Web/API recon, Web/API pressure, supply chain, cloud/IaC, AI/agent, smart contract, crypto audit, reverse/mobile/fuzz et outils gated/import (Install Matrix: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/INSTALL_MATRIX.md). La même page propose un minimum utile sur macOS avec nmap, ffuf, nuclei, semgrep, gitleaks, trivy, syft, grype, exiftool, yara, promptfoo et garak (Install Matrix: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/INSTALL_MATRIX.md).

Notions et concepts

War Room

La War Room est le point d’entrée navigateur mentionné par le README. Elle est lancée avec npm run server et doit servir d’interface pour connecter un agent local, configurer les paramètres et lancer une mission en langage naturel (README: https://github.com/elder-plinius/T3MP3ST).

Agent local et mode keyless

Le README insiste sur un usage keyless: l’agent de code déjà installé sur la machine devient le cerveau, tandis que T3MP3ST fournit l’orchestration et l’arsenal (README: https://github.com/elder-plinius/T3MP3ST). Le document VERIFIED_PROVENANCE.md précise que, pour les runs keyless, il faut d’abord connecter un agent local dans les paramètres de la War Room; si l’agent ne produit que de la prose sans demander d’outil, le harnais ne peut pas attacher de sortie d’outil comme preuve (Verified Provenance: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/VERIFIED_PROVENANCE.md).

Mission, scope et preuves

La documentation d’autorisation décrit plusieurs couches: intention humaine, scope receipt, tool gate, evidence ledger, finding ledger, retest et memory proposal (Scope docs: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/SCOPE_AND_AUTHORIZATION.md). Cette structuration sert à éviter qu’une mission devienne une action hors périmètre ou qu’une hypothèse soit présentée comme un finding vérifié.

Découvrez Nuclei : scanner des vulnérabilités avec des templates YAML

Le même document liste des non-négociables: pas de cible tierce sans scope explicite, pas d’écriture en production sans approbation nommée, pas de copie brute de secrets dans les preuves, pas de surface générique pour exploitation large ou credential tooling, et des findings qui nécessitent preuves et retests avant d’être considérés comme confiants (Scope docs: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/SCOPE_AND_AUTHORIZATION.md).

Provenance vérifiée

VERIFIED_PROVENANCE.md définit une règle simple: si l’Evidence Vault indique Provenance: none ou model-asserted, le finding doit rester une hypothèse jusqu’à ce qu’un outil, un retest ou un artefact opérateur le soutienne (Verified Provenance: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/VERIFIED_PROVENANCE.md). Un finding devient tool-proven quand l’agent demande un outil de l’Arsenal, que T3MP3ST l’exécute, que la sortie est capturée comme preuve et que le finding référence l’outil ou l’évidence associée (Verified Provenance: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/VERIFIED_PROVENANCE.md).

Arsenal et outils

La documentation FEATURES.md liste des outils intégrés comme dns_lookup, port_scan, http_request, subdomain_enum, dir_bruteforce, whois_lookup, header_analysis, technology_detect, xss_scan, sqli_scan, ssl_scan, jwt_decode et d’autres (FEATURES: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/FEATURES.md). Elle mentionne aussi des adaptateurs optionnels sous T3MP3ST_FULL_ARSENAL, dont nuclei, subfinder, httpx, naabu, katana, ffuf, gobuster, feroxbuster, nikto, dalfox, sqlmap, semgrep, gitleaks, trufflehog, trivy, grype, osv-scanner, checkov et d’autres (FEATURES: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/FEATURES.md).

MCP

Le package.json dépend de @modelcontextprotocol/sdk, et les scripts exposent mcp et mcp:prod (package.json: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/package.json). FEATURES.md indique que le serveur MCP expose security_recon, avec une surface orientée reconnaissance réseau, DNS, HTTP et fingerprinting (FEATURES: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/FEATURES.md). Le site MCP présente MCP comme un standard open source pour connecter des applications IA à des systèmes externes, outils, données et workflows (MCP docs: https://modelcontextprotocol.io/introduction).

Statut des fonctionnalités

Le README et FEATURES.md distinguent les composants stables, expérimentaux et planifiés. Le README indique notamment que les chiffres de benchmark mis en avant viennent d’un chemin single-agent, pas d’un swarm coordonné de huit opérateurs (README: https://github.com/elder-plinius/T3MP3ST). FEATURES.md précise que certains opérateurs comme Exploiter, Infiltrator, Exfiltrator, Ghost et Coordinator sont expérimentaux pour les runs end-to-end swarm (FEATURES: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/FEATURES.md).

Commandes

Les commandes ci-dessous sont tirées du README ou du package.json. Elles ne sont pas validées localement ici.

Installer les dépendances:

npm install

Lancer la War Room:

npm run server

Lancer le serveur en mode production après build, selon les scripts exposés:

npm run build
npm run server:prodLangage du code : CSS (css)

Démarrer la CLI depuis le paquet installé ou compilé:

npx tempest

Recalculer les claims du README selon le script du projet:

npm run verify-claims

Lancer le diagnostic indiqué dans les scripts:

npm run doctor

Lancer le serveur MCP en développement:

npm run mcp

Lancer les tests du projet:

npm test

Vérifier le typage TypeScript:

npm run typecheck

Exemple de configuration locale/offline mentionnée dans le README:

ollama serve && ollama pull llama3
export TEMPEST_LOCAL_BASE_URL=http://localhost:11434/api
export TEMPEST_LOCAL_MODEL=llama3
npx tempestLangage du code : JavaScript (javascript)

Exemple de minimum workstation issu de la matrice d’installation macOS:

brew install nmap ffuf nuclei semgrep gitleaks trivy syft grype exiftool yara
npm install -g promptfoo
pipx install garak

Demo : de la découverte au test local

Cette démo propose un chemin progressif: découvrir T3MP3ST, lancer la War Room, connecter un agent, puis tester le harness sur deux applications volontairement vulnérables déployées uniquement en local. Le but n’est pas de viser un service tiers, mais d’observer le comportement du framework dans un cadre contrôlé et autorisé.

Les deux cibles retenues sont OWASP Juice Shop et OWASP WebGoat. Juice Shop donne une cible web moderne avec API, frontend JavaScript et scoreboard; WebGoat donne une cible pédagogique structurée en leçons (OWASP Juice Shop: https://owasp.org/www-project-juice-shop/, OWASP WebGoat: https://owasp.org/www-project-webgoat/).

Cette section décrit donc un protocole de test reproductible. Elle ne présente pas un benchmark exécuté pour cet article.

Vue d’ensemble du flux

Le flux de test consiste à préparer T3MP3ST, démarrer une cible locale vulnérable, cadrer explicitement le scope, lancer une reconnaissance non destructive, puis relire les preuves produites.

lancer T3MP3ST et ouvrir la War Room;
connecter un agent local ou un provider LLM;
déployer Juice Shop sur 127.0.0.1:3000;
lancer une première mission de reconnaissance limitée;
déployer WebGoat sur 127.0.0.1:8080 et WebWolf sur 127.0.0.1:9090;
lancer une seconde mission plus pédagogique;
comparer les findings avec les preuves et les limites observées.

Préparation de T3MP3ST

Dans le dépôt T3MP3ST, on commence par installer les dépendances, lancer un diagnostic, puis démarrer la War Room. Ces commandes viennent du README et du package.json du projet (README: https://github.com/elder-plinius/T3MP3ST, package.json: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/package.json).

npm install
npm run doctor
npm run server

L’interface est ensuite disponible sur:

http://127.0.0.1:3333/ui/Langage du code : JavaScript (javascript)

Dans la War Room, il faut vérifier les paramètres, connecter un agent local ou configurer un provider LLM, puis consulter les sections Arsenal, Evidence et Missions. Si l’on veut contrôler les claims du README avant toute mission, le projet documente aussi:

npm run verify-claims

Test 1 : OWASP Juice Shop

OWASP Juice Shop est une application web volontairement vulnérable utilisable pour les formations sécurité, les CTF et le test d’outils de sécurité. Le projet indique qu’il couvre l’OWASP Top 10 et d’autres failles proches de cas réels (OWASP Juice Shop: https://owasp.org/www-project-juice-shop/).

Le dépôt Juice Shop documente un lancement Docker simple sur le port 3000 (README Juice Shop: https://github.com/juice-shop/juice-shop):

docker pull bkimminich/juice-shop
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

L’application est ensuite accessible localement:

http://127.0.0.1:3000Langage du code : JavaScript (javascript)

Le binding sur 127.0.0.1 est volontaire: l’application vulnérable reste limitée à la machine de test.

Découvrez vLLM : introduction pratique au serving LLM, à l’inférence et au KV cache

Exemple de prompt de mission pour T3MP3ST:

Cible autorisée : http://127.0.0.1:3000
Contexte : instance locale OWASP Juice Shop lancée volontairement pour test.
Objectif : reconnaissance web non destructive.
Scope strict : uniquement 127.0.0.1:3000.
Interdits : aucune cible externe, aucun brute force agressif, aucune action destructive, aucune exfiltration réelle.
Travail attendu : identifier les routes visibles, headers HTTP, endpoints publics, technologies, comportements d'erreur et signaux de vulnérabilités.
Chaque observation doit citer une preuve, une requête, une réponse ou une sortie d'outil.Langage du code : PHP (php)

Ce premier test permet d’évaluer T3MP3ST sur une application moderne avec frontend JavaScript et API. Le point important n’est pas seulement la liste des vulnérabilités supposées, mais la qualité des preuves attachées aux findings.

Points à observer sur Juice Shop

le scope reste-t-il limité à 127.0.0.1:3000 ?
les outils appelés sont-ils visibles dans la War Room ?
les endpoints ou routes découverts sont-ils accompagnés de réponses HTTP ?
les headers et comportements d’erreur sont-ils cités avec une preuve ?
les résultats sont-ils classés entre hypothèses et findings vérifiés ?
le rapport final est-il utile pour un humain qui veut retester ?

Test 2 : OWASP WebGoat

OWASP WebGoat est une application volontairement vulnérable maintenue par OWASP pour apprendre les failles web via des leçons. La page du projet rappelle que WebGoat doit être utilisé dans un environnement sûr et légal, et que sa configuration par défaut limite l’exposition à localhost (OWASP WebGoat: https://owasp.org/www-project-webgoat/).

Le lancement Docker documenté expose WebGoat sur le port 8080 et WebWolf sur le port 9090 (README WebGoat: https://github.com/WebGoat/WebGoat):

docker run -it -p 127.0.0.1:8080:8080 -p 127.0.0.1:9090:9090 webgoat/webgoat

WebGoat est accessible ici:

http://127.0.0.1:8080/WebGoat/Langage du code : JavaScript (javascript)

WebWolf, utilisé par certaines leçons comme helper côté attaquant simulé, est accessible ici:

http://127.0.0.1:9090/WebWolf/Langage du code : JavaScript (javascript)

Exemple de prompt de mission pour T3MP3ST:

Cible autorisée : http://127.0.0.1:8080/WebGoat/
Contexte : instance locale OWASP WebGoat lancée volontairement pour test.
Objectif : reconnaissance non destructive et analyse des surfaces visibles.
Scope strict : uniquement 127.0.0.1:8080 et 127.0.0.1:9090 si WebWolf est nécessaire.
Interdits : aucune cible externe, aucun brute force, aucune action destructive.
Travail attendu : identifier les endpoints visibles, mécanismes d'authentification, formulaires, headers et indices de vulnérabilités pédagogiques.
Chaque finding doit citer une preuve ou rester marqué comme hypothèse.Langage du code : PHP (php)

WebGoat est utile pour tester un second comportement: au lieu d’une application complète à explorer largement, on peut demander à T3MP3ST de rester sur une leçon précise.

Analyse uniquement la leçon actuellement accessible dans WebGoat.
Ne tente pas de résoudre toute l'application.
Objectif : comprendre le type de vulnérabilité enseigné, identifier les entrées utilisateur, proposer un plan de test non destructif et indiquer les preuves nécessaires pour confirmer un finding.

Comparer les deux retours

Juice Shop et WebGoat ne testent pas exactement le même aspect de T3MP3ST. Les utiliser ensemble permet d’avoir une lecture plus équilibrée.

Juice Shop sert surtout à évaluer:

la reconnaissance d’une application web moderne;
la découverte d’endpoints;
la lecture des headers et erreurs;
la compréhension de routes API;
la comparaison avec un scoreboard;
la production d’un rapport web/API.

WebGoat sert plutôt à évaluer:

la compréhension d’un scénario pédagogique;
la capacité à rester sur une leçon;
la clarté du plan de test;
la séparation entre explication, hypothèse et preuve;
l’usage éventuel de WebWolf dans un périmètre local.

Grille de retour d’expérience

Pour produire un retour utile, il faut noter les informations du run. Cela évite de confondre une réponse plausible du modèle avec un résultat réellement soutenu par une preuve.

Date du test :
Version T3MP3ST :
Mode utilisé : War Room / CLI / MCP
Agent ou provider utilisé :
Modèle utilisé :
Cible locale : Juice Shop / WebGoat
Commandes de lancement :
Prompt de mission :
Outils appelés :
Findings avec preuve :
Findings sans preuve :
Respect du scope :
Erreurs ou blocages :
Qualité du rapport :
Limites observées :
Actions de retest :Langage du code : JavaScript (javascript)

La documentation VERIFIED_PROVENANCE.md indique qu’un finding sans sortie d’outil, retest ou artefact doit rester une hypothèse. Cette règle doit guider la lecture de tous les résultats produits par T3MP3ST (Verified Provenance: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/VERIFIED_PROVENANCE.md).

Nettoyage

Si Juice Shop a été lancé au premier plan avec --rm, un Ctrl+C arrête et supprime le conteneur.

Pour WebGoat lancé au premier plan, le même principe s’applique:

Ctrl+C

Si les conteneurs tournent en arrière-plan, on peut les lister puis les arrêter:

docker ps
docker stop <container_id>Langage du code : HTML, XML (xml)

Ce que cette double démo apporte

Cette double cible rend l’article plus pratique. Juice Shop donne une cible web moderne, riche et locale. WebGoat donne une cible pédagogique et contrôlée. Ensemble, elles permettent de tester la War Room, les prompts, le respect du scope, l’appel aux outils, la provenance des findings et la qualité du rapport final.

Conclusion

T3MP3ST propose une approche ambitieuse: utiliser un agent IA, une War Room, une CLI, un serveur API, MCP et un arsenal d’outils pour structurer des missions de red teaming autorisées (README: https://github.com/elder-plinius/T3MP3ST). Le projet met en avant une logique de reproductibilité avec npm run verify-claims, mais précise aussi que certains résultats concernent un chemin single-agent et non un swarm complet de huit opérateurs (README: https://github.com/elder-plinius/T3MP3ST).

Pour un lecteur technique, le point à retenir est la combinaison entre orchestration, scope et preuves. Les documents SCOPE_AND_AUTHORIZATION.md et VERIFIED_PROVENANCE.md sont à lire avant les commandes, car ils expliquent comment éviter de confondre hypothèse générée par modèle et finding étayé par outil (Scope docs: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/SCOPE_AND_AUTHORIZATION.md, Verified Provenance: https://raw.githubusercontent.com/elder-plinius/T3MP3ST/main/docs/VERIFIED_PROVENANCE.md).

Comme l’outil touche à la sécurité offensive, il doit être réservé aux environnements possédés, aux labs, aux exercices internes ou aux scopes autorisés. Cet article n’a pas testé T3MP3ST localement; il fournit une synthèse structurée des sources officielles consultées.

Cookie	Durée	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.