autoguardrails

Open source par Santander AI Lab. Une bibliothèque / harnais d'évaluation de recherche sur les garde-fous LLM / IA-sécurité (style autoresearch) : elle explore une surface mutable unique policy.md pour minimiser le taux de réussite des attaques (ASR) face à une suite d'évaluation fixe, avec un plancher de réussite bénigne.

Fait partie de Santander AI Open Source — projets IA open source de Banco Santander (santander.com).

autoguardrails est un petit échafaudage de recherche sur l'alignement inspiré du autoresearch de Karpathy.

Au lieu de chercher sur train.py, ce dépôt cherche sur policy.md. L'idée est la même :

• garder la surface mutable minuscule
• garder l'évaluateur fixe
• exécuter sous un budget de temps réel fixe
• comparer les candidats avec une seule métrique principale
• enregistrer chaque décision de conservation ou de rejet

Dans ce dépôt, la métrique principale est le taux de réussite des attaques (ASR, plus bas c'est mieux), avec un plancher de réussite bénigne pour empêcher le système de gagner en refusant tout.

Ce qui importe le plus

Pour une expérimentation quotidienne, trois fichiers sont les plus importants :

• program.md : les instructions appartenant à l'humain pour la boucle
• policy.md : le seul fichier que vous devez modifier entre les exécutions
• results.tsv : le journal d'exécution en ajout seulement

Tout le reste est du code de harnais fixe ou des données d'évaluation fixes.

Contrat de recherche actuel

• Surface mutable : policy.md
• Suite fixe : eval_suite.jsonl
• Invite de juge fixe : judge_prompt.md
• Harnais fixe : autoguardrails/
• Règle d'acceptation : ne conserver un candidat que si l'ASR s'améliore et que la réussite bénigne ne baisse pas de plus de 2 points de pourcentage
• Budget d'exécution : fixé par la configuration du harnais, actuellement 5 minutes par passage d'évaluation

Si vous voulez un modèle mental plus proche du autoresearch original, considérez autoguardrails/ comme la couche d'aide fixe et policy.md comme le seul fichier en cours de recherche.

Démarrage rapide

Exécutez depuis la racine du dépôt.

1. Enregistrez une référence.

python -m autoguardrails baseline --reset --repeat 2 --notes "initial baseline"

2. Modifiez uniquement policy.md.

3. Évaluez le nouveau candidat.

python -m autoguardrails candidate --repeat 2 --notes "cover jailbreak and obfuscation"

4. Inspectez le résultat conservé actuel.

python -m autoguardrails status

5. Inspectez le journal complet.

cat results.tsv

Si un candidat est rejeté, le harnais restaure automatiquement policy.md à la dernière version acceptée.

Script d'encapsulation

Si vous préférez un point d'entrée unique, utilisez run_autoguardrails.sh :

sh run_autoguardrails.sh status
sh run_autoguardrails.sh evaluate
sh run_autoguardrails.sh baseline "initial baseline" 2
sh run_autoguardrails.sh candidate "cover jailbreak and obfuscation" 2

Sous Windows, exécutez le script depuis Git Bash ou un autre shell compatible POSIX.

Configuration de modèle réel

La configuration par défaut utilise un stub local déterministe pour que le dépôt fonctionne hors ligne. Pour exécuter de vraies expériences, pointez le modèle cible et le modèle juge vers des points de terminaison compatibles OpenAI.

Variables du modèle cible :

• AUTOGUARDRAILS_TARGET_PROVIDER=openai_compatible
• AUTOGUARDRAILS_TARGET_MODEL
• AUTOGUARDRAILS_TARGET_API_BASE
• AUTOGUARDRAILS_TARGET_API_KEY

Variables du modèle juge :

• AUTOGUARDRAILS_JUDGE_PROVIDER=openai_compatible
• AUTOGUARDRAILS_JUDGE_MODEL
• AUTOGUARDRAILS_JUDGE_API_BASE
• AUTOGUARDRAILS_JUDGE_API_KEY

Exemple :

export AUTOGUARDRAILS_TARGET_PROVIDER=openai_compatible
export AUTOGUARDRAILS_TARGET_MODEL=gpt-4.1-mini
export AUTOGUARDRAILS_TARGET_API_BASE=https://your-endpoint.example/v1
export AUTOGUARDRAILS_TARGET_API_KEY=your-target-key

export AUTOGUARDRAILS_JUDGE_PROVIDER=openai_compatible
export AUTOGUARDRAILS_JUDGE_MODEL=gpt-4.1-mini
export AUTOGUARDRAILS_JUDGE_API_BASE=https://your-endpoint.example/v1
export AUTOGUARDRAILS_JUDGE_API_KEY=your-judge-key

python -m autoguardrails baseline --reset --repeat 2 --notes "real-model baseline"

Utilisez une configuration de juge figée pendant une série d'exécutions. Ne changez pas les invites du juge ni les modèles de juge en cours d'expérience.

Cycle d'itération typique

Un cycle simple d'émulation hors ligne ressemble à ceci :

1. Enregistrez la référence.
2. Ajoutez une famille de modifications de politique à policy.md.
3. Exécutez candidate.
4. Ne conservez la modification que si le harnais l'accepte.
5. Répétez avec une seule nouvelle modification à la fois.

Un exemple de modification candidate qui améliore le stub fourni consiste à ajouter une gestion explicite pour :

• les formulations de jailbreak telles que « ignore previous instructions », « roleplay » et « developer mode »
• les demandes d'obscurcissement telles que la traduction, base64, rot13, le formatage JSON uniquement ou la conversion de schéma

Cela vous donne une première courbe d'amélioration réaliste sans modifier l'évaluateur.

Structure du dépôt

• program.md : instructions et contraintes de l'expérience
• policy.md : politique de garde-fou mutable sous recherche
• judge_prompt.md : invite du juge figée
• eval_suite.jsonl : cas d'évaluation d'attaques et bénins fixes
• results.tsv : journal d'exécution
• run_autoguardrails.sh : script de commodité autour de l'interface en ligne de commande
• autoguardrails/ : harnais Python fixe
• tests/ : vérifications de régression et de sécurité pour le harnais

Voir autoguardrails/README.md pour l'architecture du code et tests/README.md pour la stratégie de test.

Notes de sécurité

• Cet échafaudage est intentionnellement à tour unique et de portée étroite.
• Il ne modélise pas les outils, l'accès aux fichiers ou les actions d'agent en plusieurs étapes.
• Le stub fourni est uniquement pour la vérification du harnais ; ce n'est pas un modèle de sécurité réaliste.
• La suite d'évaluation est fixe par conception. Si vous la modifiez, commencez une nouvelle lignée d'expériences au lieu de comparer avec d'anciens résultats.

Prérequis