Más allá del prompt: jailbreaking de LLMs con llamada a funciones mediante trazas de moderación simuladas

Introducción

Este repositorio contiene la implementación oficial de nuestro artículo:

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

Si este repositorio le resulta útil para su investigación, considere citar nuestro artículo. Las preguntas, los informes de errores y los problemas de reproducibilidad son bienvenidos a través de GitHub Issues.

Descripción general

Estructura del repositorio

.
├── 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

Primeros pasos

1. Crear el entorno

Proporcionamos un script de instalación para configurar automáticamente el entorno de Python e instalar todas las dependencias necesarias.

chmod +x install.sh
./install.sh

Una vez completada la instalación, active el entorno virtual:

source .venv/bin/activate

Alternativamente, puedes crear el entorno manualmente usando Conda:

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

2. Configurar el acceso a la API

Cree utils/config.json a partir del archivo de ejemplo:

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

Un archivo de configuración mínimo debe seguir este formato:

{
  "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"
  }
}

Las dos entradas corresponden a:

• llm_api: el endpoint de API compatible con OpenAI predeterminado para modelos comerciales.
• local: un endpoint de inferencia local compatible con OpenAI, utilizado para modelos locales seleccionados.

3. Seleccionar un benchmark y un modelo objetivo

Abra main.py y modifique la configuración del experimento cerca del inicio del archivo:

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", 
]

Utilice identificadores de modelo que sean válidos para el endpoint de la API configurado en utils/config.json.

4. Configurar los parámetros de evaluación

Los parámetros predeterminados se definen en main.py:

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

Sus significados son:

Parámetro	Descripción
MAX_THREADS	Número máximo de trabajadores concurrentes por modelo objetivo
MAX_ROUNDS	Número máximo de rondas de reintento externas
TURNS_NUM	Número máximo de intentos de interacción multiturno por muestra
RESET	Si se debe descartar un checkpoint existente antes de la evaluación

Establezca:

RESET = True

para iniciar una ejecución nueva para el modelo seleccionado. Déjalo como False para reanudar desde un checkpoint existente.

5. Ejecutar la evaluación

python main.py

Para cada modelo objetivo, el script automáticamente:

1. Carga el benchmark seleccionado desde data/.
2. Ejecuta SMT contra todas las muestras pendientes.
3. Guarda el progreso intermedio después de cada muestra.
4. Reanuda los experimentos interrumpidos desde los checkpoints guardados.
5. Reporta métricas agregadas después de la evaluación.

Formato de salida

Los resultados se guardan en:

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

Por ejemplo:

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

Cada elemento de benchmark se almacena con campos similares a:

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

El script informa las siguientes métricas:

Métrica	Descripción
ASR	Tasa de éxito del ataque: porcentaje de muestras cuya puntuación alcanza el umbral configurado
Avg.Q	Número promedio de consultas a la API utilizadas por muestra
Avg.Score	Puntuación media de evaluación externa en todas las muestras

Requisitos aproximados de recursos

Los experimentos principales de SMT se basan en API y no requieren una GPU local.

• CPU / Memoria: Un portátil o equipo de escritorio estándar es suficiente para ejecutar los scripts de evaluación.
• GPU: No se requiere para experimentos que utilizan API de LLM comerciales.
• Red: Se requiere una conexión a Internet estable.
• Acceso a la API: Se requieren credenciales de API válidas para los modelos objetivo y el modelo de evaluación seleccionados.
• Presupuesto de consultas: Con los valores predeterminados MAX_ROUNDS = 3 y TURNS_NUM = 3, SMT utiliza como máximo 9 consultas al modelo objetivo por muestra de referencia antes de la parada anticipada.
• Tiempo de ejecución: El tiempo de ejecución depende principalmente del modelo seleccionado, el tamaño del benchmark, la latencia de la API y los límites de tasa. Una evaluación completa puede tardar varias horas.
• Costo de la API: Depende del proveedor del modelo y de los precios actuales de la API.

Para los modelos desplegados localmente, los requisitos adicionales de GPU y memoria dependen del modelo seleccionado y del backend de inferencia.

Notas de reproducibilidad

Las API de LLM comerciales se actualizan continuamente. Incluso cuando se utiliza el mismo alias de modelo, los resultados pueden variar debido a actualizaciones del modelo por parte del proveedor, comportamiento de enrutamiento, cambios en las políticas de seguridad, configuraciones de decodificación o fallos transitorios de la API.

Para mejorar la reproducibilidad:

• Prefiera instantáneas de modelo con fecha siempre que estén disponibles.
• Mantenga los archivos del benchmark sin cambios.
• Registre el proveedor, el endpoint, el ID del modelo, la fecha y los parámetros de cada ejecución.
• Utilice el mismo umbral y presupuesto de consultas reportados en el artículo.