Deception Gateway: Por qué el bloqueo pasivo de LLMs está matemáticamente roto (y cómo engañar a los atacantes con desinformación controlada)

A developer has released misdirection-proxy v0.5.0, a security gateway that implements Contextual Misdirection via Progressive Engagement (CMPE) to defend LLMs against automated attacks. The system uses four layers of defense to generate deceptive responses that appear successful to attackers but are semantically non-operational, degrading the optimization gradient. This approach is based on a formal proof by Soosahabi & Namsani (2026) showing that detect-and-block defenses are fundamentally incomplete against automated attacks.

Imagina que eres un atacante automatizado usando PAIR https://arxiv.org/abs/2310.08419 o GPTFuzz https://arxiv.org/abs/2309.10253 . Envías un prompt malicioso al LLM y recibes: "I cannot help with that request. I'm sorry." ¿Qué información te da eso? Todo. Te dice: Cada refusal predecible es un gradiente de optimización . El atacante ajusta su siguiente prompt basándose en el feedback. Con suficientes iteraciones, el ASR Attack Success Rate converge a 1.0: ASR block = 1 - 1 - β D · 1 - β A ^N → 1 as N → ∞ Esto no es intuición — es una demostración formal del paper de Soosahabi & Namsani 2026 https://arxiv.org/abs/2606.20470 : las defensas detect-and-block son fundamentalmente incompletas contra ataques automatizados. La solución: engañar al atacante con desinformación controlada ¿Y si en vez de decir "no puedo ayudarte", el sistema responde con algo que parece satisfacer la solicitud del atacante pero que es semánticamente no-operacional? Esto es exactamente lo que hace misdirection-proxy https://github.com/amurlaniakea/misdirection-proxy v0.5.0: un gateway de seguridad que implementa CMPE Contextual Misdirection via Progressive Engagement — defensa activa por engaño. Arquitectura: 4 capas de defensa síncrona Cuando una petición HTTP llega al proxy, pasa por 4 capas secuenciales: ┌─────────────────────────────────────────────────────────────────┐ │ PETICIÓN HTTP ENTRANTE │ └──────────────────────────────┬──────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ CAPA 1: CONTEXT FILTER Frente 2 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ ¿Hay datos externos sospechosos RAG, tools, documentos ? │ │ │ │ → Detección de inyecciones indirectas pasivas │ │ │ │ → Neutralización semántica preserva partes benignas │ │ │ └───────────────────────────────────────────────────────────┘ │ └──────────────────────────────┬──────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ CAPA 2: INTENTION DETECTOR │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ ¿El prompt del usuario es malicioso? │ │ │ │ → 5 categorías: jailbreak, exfiltración, code exec, │ │ │ │ prompt injection, ingeniería social │ │ │ └───────────────────────────────────────────────────────────┘ │ └──────────────────────────────┬──────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ CAPA 3: ADAPTIVE CONTROLLER Frente 1 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ ¿El atacante está persistiendo? X-Session-ID header │ │ │ │ → Escala γ A t = min 0.71 + ln 1 + 0.3·ΣM i , 0.99 │ │ │ │ → Más entropía en respuestas a medida que persiste │ │ │ └───────────────────────────────────────────────────────────┘ │ └──────────────────────────────┬──────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ CAPA 4: CMPE ENGINE │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ ¿Confirmado malicioso? Genera misdirection response: │ │ │ │ 1. Preámbulo positivo "I'd be happy to help..." │ │ │ │ 2. Prompt reshuffling mezcla + glue tokens │ │ │ │ 3. Follow-up question ramifica conversación │ │ │ │ → Respuesta PARECE exitosa al juez del atacante │ │ │ │ → Pero es operativamente nula │ │ │ └───────────────────────────────────────────────────────────┘ │ └──────────────────────────────┬──────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ RESPUESTA ENVIADA AL ATACANTE │ │ Parece exitosa, pero el gradiente del optimizador se degrada │ └─────────────────────────────────────────────────────────────────┘ Resultados: el atacante converge al estado absorbente de error Cuando el atacante recibe respuestas que parecen exitosas pero son falsos positivos inducidos, su optimizador se degrada ciclo a ciclo: | Ciclo | γ A t | PPV del atacante | Estado del optimizador | |-------|--------|------------------|----------------------| | 1 | 0.71 | 0.07 | Recibe basura, ajusta | | 2 | 0.97 | 0.01 | Gradiente corrupto | | 3+ | 0.99 | ~0.00 | Estado absorbente | Tras 3-4 ciclos, la probabilidad de que el atacante encuentre un verdadero jailbreak es prácticamente cero. El optimizador ha convergido a una región muerta del espacio latente. Reproducibilidad: clonar y ejecutar en 30 segundos El stack completo proxy + Ollama + benchmark se despliega con Docker Compose: bash git clone https://github.com/amurlaniakea/misdirection-proxy.git https://github.com/amurlaniakea/misdirection-proxy.git cd misdirection-proxy docker compose up -d docker compose --profile bench run --rm bench ls reports/ cat reports/eval report ollama.json El benchmark ejecuta 30 ataques 10 directos, 10 indirectos, 10 RAG injection y genera un reporte JSON con PPV, ASR, γ A t y latencia por ciclo. Para usar un modelo más potente: bash OLLAMA MODEL=llama3:8b docker compose up -d Stack técnico | Componente | Versión | Descripción | |---|---|---| | CMPE Engine | v0.1.0 | Motor de misdirection de 3 pasos | | Intention Detector | v0.1.0 | 5 categorías de amenazas | | HTTP Gateway | v0.2.0 | FastAPI, compatible con OpenAI API | | Adaptive Controller | v0.3.0 | γ A dinámico vía X-Session-ID | | Context Filter | v0.4.0 | Inyecciones indirectas en RAG/tools | | Adversarial Benchmark | v0.5.0 | Simulador dual-mode deterministic + Ollama | 147 tests pasando — cobertura completa de unitarios + integración. ¿Por qué importa? Los agentes de IA modernos no solo procesan input del usuario. Ingieren datos de RAG, herramientas externas, documentos y memoria. Cada uno de esos canales es una superficie de ataque. El paradigma clásico de "detectar y bloquear" no escala porque: 1. Es predecible — cada refusal da feedback al atacante 2. Es estático — un γ A fijo permite mapear la defensa 3. Es incompleto — no cubre inyecciones indirectas en datos pasivos La defensa activa por engaño resuelve los tres problemas simultáneamente. Enlaces - Repositorio: github.com/amurlaniakea/misdirection-proxy https://github.com/amurlaniakea/misdirection-proxy - Paper base: Soosahabi & Namsani 2026 https://arxiv.org/abs/2606.20470 - Licencia: AGPL-3.0-or-later --- ¿Qué opinas? ¿Crees que la defensa por engaño es viable en producción o sigue siendo demasiado teórica? Déjame tu opinión en los comentarios.