Au-delà du prompt : jailbreaker les LLM à appel de fonctions via des traces de modération simulées

Introduction

Ce dépôt contient l'implémentation officielle de notre article :

Beyond the Prompt: Jailbreaking Function-Calling LLMs via Simulated Moderation Traces

Si vous trouvez ce dépôt utile pour vos recherches, nous vous invitons à citer notre article. Les questions, rapports de bugs et problèmes de reproductibilité sont les bienvenus via les GitHub Issues.

Aperçu

Structure du dépôt

.
├── install.sh                      # Installation script for setting up the environment and dependencies
├── main.py                         # Main evaluation entry point
├── demo.ipynb                      # Minimal working example
├── requirements.txt                # Python dependencies
├── data/
│   ├── SafeBench-Tiny.txt          # Default benchmark
│   └── JailbreakBench.txt          # Optional benchmark
├── figures/
│   ├── pipline.jpg                 # Framework overview
│   ├── main_res1.jpg               # Main result figure
│   └── main_res2.jpg               # Main result figure
├── utils/
│   ├── config.example.json         # Example API configuration
│   ├── eval_h_cot.py               # External evaluation utility
│   ├── fake_tool_call_noharmful.json
│   ├── moderation_generator.py
│   └── moderation_validator.py
└── output/                         # Checkpoints and evaluation results

Premiers pas

1. Créer l'environnement

Nous fournissons un script d'installation pour configurer automatiquement l'environnement Python et installer toutes les dépendances requises.

chmod +x install.sh
./install.sh

Une fois l'installation terminée, activez l'environnement virtuel :

source .venv/bin/activate

Vous pouvez également créer manuellement l'environnement avec Conda :

conda create -n SMT python=3.12
conda activate SMT
pip install -r requirements.txt

2. Configurer l'accès à l'API

Créez utils/config.json à partir du fichier d'exemple :

cp utils/config.example.json utils/config.json

Un fichier de configuration minimal doit suivre ce format :

{
  "llm_api": {
    "base_url": "https://your-api-endpoint/v1",
    "api_key": "YOUR_API_KEY"
  },
  "local": {
    "base_url": "http://localhost:1234/v1",
    "api_key": "YOUR_LOCAL_API_KEY"
  }
}

Les deux entrées correspondent à :

• llm_api : le point de terminaison API compatible OpenAI par défaut pour les modèles commerciaux.
• local : un point de terminaison d'inférence local compatible OpenAI, utilisé pour certains modèles locaux sélectionnés.

3. Sélectionner un benchmark et un modèle cible

Ouvrez main.py et modifiez la configuration de l'expérience au début du fichier :

DATA_FILE = "SafeBench-Tiny.txt"
# DATA_FILE = "JailbreakBench.txt"

TARGET_MODELS = [
    "gpt-4o-2024-11-20",
    # "gpt-5.4-2026-03-05",
    # "qwen3-max-2026-01-23",
    # "gemini-3-flash-preview",
    # "deepseek-v4-flash",
    # "claude-sonnet-4-5-20250929", 
]

Utilisez des identifiants de modèle valides pour le point de terminaison API configuré dans utils/config.json.

4. Configurer les paramètres d'évaluation

Les paramètres par défaut sont définis dans main.py :

MAX_THREADS = 1
MAX_ROUNDS = 3
TURNS_NUM = 3
RESET = False

Leur signification est :

Paramètre	Description
MAX_THREADS	Nombre maximal de workers simultanés par modèle cible
MAX_ROUNDS	Nombre maximal de cycles de nouvelle tentative externes
TURNS_NUM	Nombre maximal de tentatives d'interaction multi-tours par échantillon
RESET	Indique s'il faut supprimer un checkpoint existant avant l'évaluation

Définir :

RESET = True

pour démarrer une nouvelle exécution pour le modèle sélectionné. Laissez-le à False pour reprendre à partir d'un checkpoint existant.

5. Exécuter l'évaluation

python main.py

Pour chaque modèle cible, le script effectue automatiquement les opérations suivantes :

1. Charge le benchmark sélectionné depuis data/.
2. Exécute SMT sur tous les échantillons en attente.
3. Enregistre la progression intermédiaire après chaque échantillon.
4. Reprend les expériences interrompues à partir des points de contrôle enregistrés.
5. Rapporte les métriques agrégées après l'évaluation.

Format de sortie

Les résultats sont enregistrés sous :

output/attack_checkpoint_<dataset>_<model>.json

Par exemple :

output/attack_checkpoint_SafeBench-Tiny_gpt-4o-2024-11-20.json

Chaque élément de benchmark est stocké avec des champs similaires à :

{
  "target_question": {
    "success": true,
    "queries": 3,
    "payload": "...",
    "score": 60
  }
}

Le script rapporte les métriques suivantes :

Métrique	Description
ASR	Taux de réussite des attaques : pourcentage d'échantillons dont le score atteint le seuil configuré
Avg.Q	Nombre moyen de requêtes API utilisées par échantillon
Avg.Score	Score d'évaluation externe moyen sur l'ensemble des échantillons

Approximate Resource Requirements

Les principales expériences SMT sont basées sur des API et ne nécessitent pas de GPU local.

• CPU / Mémoire : Un ordinateur portable ou de bureau standard suffit pour exécuter les scripts d'évaluation.
• GPU : Non requis pour les expériences utilisant des API de LLM commerciaux.
• Réseau : Une connexion Internet stable est requise.
• Accès API : Des identifiants API valides sont requis pour les modèles cibles et le modèle d'évaluation sélectionnés.
• Budget de requêtes : Avec les valeurs par défaut MAX_ROUNDS = 3 et TURNS_NUM = 3, SMT utilise au plus 9 requêtes au modèle cible par échantillon de benchmark avant l'arrêt anticipé.
• Durée d'exécution : La durée d'exécution dépend principalement du modèle sélectionné, de la taille du benchmark, de la latence de l'API et des limites de débit. Une évaluation complète peut prendre plusieurs heures.
• Coût API : Dépend du fournisseur du modèle et de la tarification actuelle de l'API.

Pour les modèles déployés localement, les exigences supplémentaires en GPU et en mémoire dépendent du modèle sélectionné et du backend d'inférence.

Notes de reproductibilité

Les API de LLM commerciaux sont continuellement mises à jour. Même en utilisant le même alias de modèle, les résultats peuvent varier en raison de mises à jour des modèles côté fournisseur, du comportement de routage, de modifications des politiques de sécurité, des paramètres de décodage ou de défaillances transitoires de l'API.

Pour améliorer la reproductibilité :

• Privilégier les instantanés de modèles datés lorsqu'ils sont disponibles.
• Conserver les fichiers de benchmark inchangés.
• Enregistrer le fournisseur, le point de terminaison, l'ID du modèle, la date et les paramètres pour chaque exécution.
• Utiliser le même seuil et le même budget de requêtes que ceux rapportés dans l'article.