Un banco de pruebas de seguridad empírico que evalúa la inyección de prompts, las vulnerabilidades de subordinado confundido y las defensas de llamada a herramientas en agentes LLM.

Un banco de pruebas de seguridad disciplinado que evalúa si los agentes LLM equipados con herramientas pueden ser manipulados para realizar exfiltración de datos no autorizada mediante inyección de prompts, ingeniería social por suplantación de roles y ataques de diputado confundido.

Arquitectura Principal • Taxonomía de Ataques • Paradigma Ingenuo vs. Endurecido • Inicio Rápido • Hito

🎯 Resumen Ejecutivo

Los agentes modernos impulsados por LLM ejecutan acciones privilegiadas: consultar bases de datos internas, leer sistemas de archivos e interactuar con APIs de backend. Cada acción es un límite donde el prompt de un atacante puede desencadenar una ejecución no autorizada.

⚠️ Conclusión Arquitectónica Clave:
La vulnerabilidad rara vez reside únicamente en los pesos del LLM. Prospera en el límite de confianza entre la solicitud de intención del modelo y el backend de la aplicación que la ejecuta sin validación.

Al igual que la Inyección SQL se originó en la concatenación de cadenas sin parametrizar y no en el propio motor de la base de datos, las Fallos de Diputado Confundido en LLM ocurren cuando el código de la aplicación confía ciegamente en los argumentos de las herramientas del agente.

🏛️ Arquitectura Principal

⚔️ Los Dos Paradigmas de Herramientas

Ambas herramientas exponen una firma de función idéntica al agente LLM (get_user(username: str)). El modelo no puede determinar con qué versión de la herramienta está interactuando.

🗃️ Taxonomía de Ataques y Suite de Pruebas

El banco de pruebas ejercita 5 categorías clave de vulnerabilidades definidas en attacks.py:

🔬 Backend Simulado y Configuración de Inyección Plantada

El entorno está respaldado por dataclasses de Python puras y deterministas en testbed/fake_data.py:

💡 Por qué la bio de Alice está envenenada: Esto modela un escenario realista de inyección indirecta de prompts donde un atacante no necesita privilegios elevados. Solo necesita controlar los datos que una herramienta recupera (por ejemplo, la bio de un perfil público), esperando que un agente los lea durante una búsqueda rutinaria.

⚖️ Inspección de Verdad Terrenal y el Veredicto "UNCLEAR"

Calificar respuestas de LLM en texto libre es fundamentalmente no determinista. Un modelo podría ser evasivo, divulgar información parcialmente o negarse a llamar a una herramienta por completo.

Distinguir UNCLEAR de BLOCKED es crucial: evita afirmar falsamente que un backend de herramientas es seguro cuando el ataque simplemente no logró llegar a la capa de herramientas.

📊 Modelo de Datos y Estructura de Directorios

🚀 Inicio Rápido

1. Instalación

Clona el repositorio y configura las dependencias con uv:

2. Configuración del Entorno

Crea un archivo .env en el directorio raíz:

3. Ejecutar Evaluaciones de Ataques

Ejecuta ataques contra cualquiera de las versiones de herramientas a través del arnés de pruebas:

📑 Informes Detallados y Hallazgos

• 📖 V1-RESULTS.md — Desglose completo de los 5 ataques con diagramas de resultados, iteraciones de prompts y conclusiones de seguridad.
• 🔬 PHASE-6-REPORT.md — Informe detallado sobre la validación del arnés de pruebas, las restricciones de la API y el comportamiento del modelo.
• 📓 BUILD-JOURNAL.md — Registro paso a paso de decisiones de ingeniería y proceso de pensamiento.

🛡️ Alcance del Proyecto y No-Objetivos (v1)

• Backend Simulado por Diseño: Las dataclasses puras de Python evitan configuraciones complejas de Docker/sandboxing para mantener el enfoque estrictamente en la seguridad de las herramientas de agentes.
• Pruebas de Prompts vs. Internals del Modelo: Evalúa el comportamiento externo de los prompts y la autorización de herramientas, no el ajuste fino de los pesos del modelo.
• Exploración Empírica: Sirve como un prototipo educativo disciplinado en lugar de un escáner pesado de red-teaming empresarial.

📈 Progreso por Fases

• Fase 0 — Verificado el bucle de llamada a funciones de Gemini 3.6 Flash de extremo a extremo.
• Fase 1 — Definidas las métricas de éxito de ataques, los secretos de verdad terrenal y el alcance del backend simulado.
• Fase 2 — Implementados los modelos de datos inmutables (FakeUser, AttackAttempt, AttackResult).
• Fase 3 — Formuladas las reglas de defensa ingenuas y endurecidas.
• Fase 4 — Conectadas las herramientas al bucle de API LLM en vivo y confirmado el comportamiento de referencia.
• Fase 5 — Redactada la suite de ataques de múltiples categorías con vectores de inyección indirecta plantados.
• Fase 6 — Ejecución automatizada del runner por lotes, soporte de múltiples turnos y calificación de respuestas.
• Fase 7 — Verificación puntual de resultados ambiguos (revisión de clasificación unclear).
• Fase 8 — Generados informes de evaluación completos, tablas resumen y gráficos visuales.