redthread

Un moteur de red-teaming autonome pour les LLM. RedThread gère l'ensemble du cycle de vie de la sécurité : génération d'attaques adversariales, exécution d'évaluations de précision et synthèse de garde-fous validés pour une auto-amélioration sûre.

Cette boucle est le produit central.

Ce que fait RedThread

1. Exécute des campagnes adversariales

RedThread prend en charge plusieurs stratégies d'attaque :

• PAIR — raffinement itératif de prompt adversarial.
• TAP — recherche arborescente avec élagage pour une exploration plus profonde des attaques.
• Crescendo — escalade multi-tour via l'historique de conversation.
• GS-MCTS — planification bornée sur les mouvements conversationnels possibles.

Les campagnes sont orchestrées via un runtime superviseur/travailleur de style LangGraph.

2. Évalue les résultats avec des classes de preuves explicites

RedThread sépare les types de preuves au lieu de traiter chaque score comme équivalent :

• preuves de juge en direct,
• preuves heuristiques scellées / de régression dorée,
• preuves de repli de juge en direct.

Cette distinction est importante. Un repli peut préserver la continuité, mais ce n'est pas la même chose qu'un chemin sain de juge en direct.

3. Synthétise des défenses candidates

Lorsqu'un jailbreak est confirmé, RedThread peut exécuter un pipeline de défense cadré :

1. isoler le segment d'exploit minimal,
2. classer le problème à l'aide de taxonomies de sécurité,
3. générer un garde-fou candidat,
4. rejouer l'exploit et les sondes bénignes,
5. persister les preuves cadrées pour examen et promotion.

Les défenses sont cadrées à la cible et au contexte du prompt. RedThread ne considère pas un correctif comme universel pour tous les systèmes.

4. Examine le risque de sécurité agentique

RedThread inclut une voie Phase 8 additive pour les risques agentiques modernes :

• empoisonnement d'outil,
• délégation de député confus,
• lignée non fiable,
• propagation de canari,
• amplification de ressources,
• autorisation pré-action déterministe,
• vérifications de promotion basées sur le rejeu.

Cette voie est conservatrice par conception. L'examen d'exécution scellé est une preuve utile, pas une preuve large d'application en entreprise.

5. Surveille les signaux de santé

La télémétrie et le score ASI aident les opérateurs à détecter la dérive et l'instabilité :

• dérive sémantique,
• cohérence des réponses,
• anomalies de latence / token,
• variance des sondes canari.

La télémétrie est traitée comme une couche de signal, pas comme une vérité de validation.

Ce que RedThread n'est pas

RedThread n'est pas :

• un badge de sécurité générique de chatbot,
• un remplacement pour l'examen de sécurité humain,
• une preuve qu'un modèle est sûr,
• un déploiement automatique de correctifs en production,
• une application large d'outils en direct par défaut,
• une promesse que toutes les défenses générées devraient être promues.

Le projet est intentionnellement honnête sur les preuves. La promotion nécessite des portes explicites et des preuves plus solides.

Architecture en un coup d'œil

Couches clés :

• src/redthread/orchestration/ — graphes superviseur et runtime.
• src/redthread/core/ — algorithmes d'attaque et synthèse de défense.
• src/redthread/evaluation/ — JudgeAgent, rubriques, rejeu, portes de promotion.
• src/redthread/telemetry/ — embeddings, dérive, ASI, canaris, budgets d'exécution.
• src/redthread/tools/ — abstractions d'outils, autorisation, registres simulés.
• src/redthread/pyrit_adapters/ — adaptateurs cibles et chemins d'envoi en direct contrôlés.
• src/redthread/memory/ — mémoire de campagne et de garde-fou cadrée.
• docs/wiki/ — synthèse de connaissances du projet organisée.

Démarrage rapide

Prérequis

• Python 3.12+
• Environnement virtuel local recommandé
• Optionnel : Ollama pour les modèles attaquants/cibles locaux
• Optionnel : identifiants compatibles OpenAI pour les rôles de juge ou d'architecte de défense

Installer

Ou installer le flux d'outil CLI :

Configurer

Copiez le fichier d'environnement exemple et remplissez vos propres valeurs :

Une configuration locale courante utilise Ollama pour les modèles locaux et un modèle de juge compatible OpenAI. Ne commitez pas .env.

Exécuter une campagne locale à sec

Le chemin normal écrit un répertoire de rapport standard par défaut :

• exécutions live/default : reports/<campaign_id>/
• exécutions à sec : reports/<campaign_id>/dry-run/
• racine de remplacement : --report-dir <path>

Le rapport Markdown commence par trois sections à l'épreuve de l'opérateur : ce qui s'est passé, pourquoi lui faire confiance et quoi faire ensuite. Les étiquettes de preuve et les avertissements d'incertitude apparaissent avant les résultats détaillés afin que les preuves de repli ou scellées ne soient pas confondues avec des preuves live propres.

Utilisez redthread run --help pour les drapeaux d'opérateur normaux et avancés. Utilisez redthread run --show-research seulement lorsque vous avez besoin de contrôles de recherche cachés.

Exécuter des vérifications locales

Commandes ciblées utiles :

Action GitHub

RedThread inclut une action GitHub composite pour les scans de sécurité CI/PR. Voir docs/github-action.md pour l'utilisation.

Exemple de flux de campagne

Une campagne RedThread typique produit plus qu'un résultat réussi/échoué.

Elle peut répondre :

• Quel persona ou stratégie a trouvé le problème ?
• Quel tour de prompt a causé l'échec ?
• Le chemin du juge a-t-il été exécuté en direct, scellé ou en repli ?
• Un candidat de défense a-t-il été généré ?
• Le rejeu a-t-il bloqué l'exploit ?
• Le rejeu bénin a-t-il toujours fonctionné ?
• L'examen de sécurité agentique a-t-il trouvé un risque d'outil, de délégation ou de budget ?
• La preuve est-elle promouvable ou seulement diagnostique ?

C'est pourquoi RedThread stocke les transcriptions, les résumés d'exécution, les preuves de rejeu et les décisions de promotion en tant qu'artefacts séparés orientés opérateur.

Exemple de résultat de campagne

Exemple de sortie de campagne locale. Une attaque a réussi, une a partiellement réussi et une a échoué. RedThread traite ces signaux comme des preuves pour examen, pas comme une preuve que l'ensemble du modèle ou de l'application n'est pas sûr.

Cette exécution a été confirmée par l'évaluation du juge local dans ce contexte de campagne. La capture d'écran masque le chemin de transcription ; les preuves publiable doivent utiliser des transcriptions nettoyées ou des rapports cadrés, pas les journaux d'exécution bruts.

Modèle de sécurité

RedThread utilise des frontières explicites :

Frontière de preuve

Un score n'est aussi fort que son mode de preuve. Les rapports et les résumés de terminal montrent des étiquettes de preuve canoniques, des compteurs et des notes d'incertitude afin que les vérifications scellées, les vérifications en direct, les vérifications de repli, les signaux importés faibles, les candidats de défense, les preuves promouvables et les garde-fous actifs ne soient pas traités comme équivalents.

Frontière de promotion

Les défenses générées sont des candidats. La chaîne de promotion est candidate_defense → validated_candidate → promotable_defense → active_guardrail. Un validated_candidate a passé les vérifications de rejeu/indexation, mais il n'est pas actif. promotable_defense nécessite des preuves de rejeu en direct, un passage de porte d'utilité, un état de proposition accepté et un passage de porte de contrôle. active_guardrail n'apparaît qu'après promotion explicite. redthread research promote et redthread research promote-inspect montrent le résultat de la promotion, les compteurs d'état, les modes de preuve de trace et les compartiments d'échec bloqués. L'injection d'exécution écrit logs/guardrail_audit.jsonl avec une preuve non secrète : action, IDs de trace actifs, hachages de clause, modèle cible et hachage de prompt. Les métadonnées héritées defense_deployed sont un alias de compatibilité pour l'état de candidat validé, pas une preuve de déploiement en production.

Frontière de mutation

Les voies de recherche automatique bornées peuvent proposer des changements, mais elles ne contournent pas la logique de validation ou de promotion.

Frontière d'exécution

Les contrôles de sécurité agentique préfèrent les vérifications déterministes en dehors du modèle :

• héritage des permissions,
• décisions d'autorisation,
• confinement des canaris,
• arrêts de budget d'exécution,
• portes d'adaptateur en direct contrôlées.

Frontière de télémétrie

La télémétrie peut déclencher une enquête. Elle ne prouve pas la sécurité par elle-même.

Voie de sécurité agentique

Les systèmes LLM modernes ne produisent pas seulement du texte. Ils appellent des outils, délèguent des tâches, écrivent en mémoire et déclenchent des effets externes.

La voie de sécurité agentique de RedThread se concentre sur ce risque d'exécution.

Elle modélise et examine actuellement :

• retours d'outil empoisonnés,
• injection de sortie d'outil de type MCP,
• chaînes de député confus,
• blanchiment de privilèges via les travailleurs,
• lignée non fiable atteignant des actions à haut risque,
• propagation de canari dans les coutures protégées,
• tentatives répétées et amplification des coûts,
• autorisation pré-action avant une exécution sensible.

Classe de preuve actuelle : examen d'exécution scellé, avec des chemins de preuve d'adaptateur en direct contrôlés limités. Ceci est utile pour la visibilité de l'opérateur et la préparation à la promotion, mais ce n'est pas une application universelle en direct.

Recherche automatique bornée

RedThread inclut deux voies d'auto-amélioration bornées :

• research phase5 — voie de proposition de correctif de source côté attaque.
• research phase6 — voie de proposition de mutation de prompt de défense.

Les deux voies sont conçues autour de contrôles conservateurs :

• mutation pilotée par modèle,
• surfaces de sécurité protégées,
• artefacts de correctif réversibles,
• états d'examen explicites,
• discipline de promotion.

L'objectif n'est pas une auto-modification récursive non contrôlée. L'objectif est des boucles de recherche plus sûres avec des artefacts inspectables.

Carte de documentation

Commencez ici :

• docs/product.md — cadrage produit.
• docs/TECH_STACK.md — choix de pile et dépendances.
• docs/PHASE_REGISTRY.md — historique des phases et statut actuel.
• docs/DEFENSE_PIPELINE.md — pipeline de synthèse de défense et de rejeu.
• docs/AGENTIC_SECURITY_RUNTIME.md — intégration d'exécution Phase 8.
• docs/ANTI_HALLUCINATION_SOP.md — discipline d'évaluation et d'ancrage.

Système de connaissances :

• docs/wiki/index.md — carte wiki.
• docs/wiki/SCHEMA.md — règles wiki.
• docs/wiki/systems/ — résumés au niveau système.
• docs/wiki/research/ — synthèse de recherche et plans d'implémentation.
• docs/wiki/concepts/ — concepts réutilisables.
• docs/wiki/decisions/ — décisions durables.

Comment RedThread se rapporte aux autres outils

RedThread ne cherche pas à remplacer tous les outils de sécurité IA.

Une répartition pratique :

• garak est fort pour le scanning large de vulnérabilités LLM.
• promptfoo est fort pour le flux de travail d'évaluation, la comparaison de fournisseurs, CI et le reporting.
• PyRIT est fort comme couche d'infrastructure de red-teaming.
• RedThread se concentre sur la boucle fermée : attaque, juge, défense, rejeu et préservation des preuves de promotion.

Les intégrations futures peuvent traiter les outils externes comme des expanseurs de surface tout en gardant intacte la boucle de preuves de RedThread.

Thèmes de feuille de route

Thèmes à court terme issus de la documentation et du wiki du projet :

• maintenir honnête le rapport des preuves en direct vs scellées,
• renforcer les suites de rejeu et les preuves de promotion,
• améliorer l'UX d'inspection de l'opérateur,
• étendre soigneusement les fixtures de sécurité agentique et les coutures en direct,
• intégrer la sortie des scanners externes sans remplacer la boucle centrale,
• maintenir la recherche automatique bornée à l'intérieur des portes d'examen et de promotion.

Contribuer

Ce projet favorise les changements petits et fondés sur des preuves.

Avant de modifier le comportement :

1. lisez la documentation pertinente,
2. identifiez la classe de preuve d'exécution affectée,
3. ajoutez ou mettez à jour les tests,
4. évitez d'affaiblir les frontières de promotion, de rejeu ou de sécurité,
5. gardez les affirmations dans la documentation alignées avec ce que le code prouve.

Vérifications locales :

Sécurité et utilisation responsable

Utilisez RedThread uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à tester.

Ne commitez pas :

• clés API,
• fichiers .env,
• journaux de campagne privés,
• transcriptions brutes contenant des données sensibles,
• artefacts d'opérateur locaux,
• captures d'écran contenant des informations privées.

Si vous prévoyez de publier ce dépôt, veuillez d'abord examiner les fichiers suivis, les fichiers ignorés et l'historique git.

Licence

MIT. Voir LICENSE.