{"slug": "deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y", "title": "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)", "summary": "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.", "body_md": "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:\n\n\"I cannot help with that request. I'm sorry.\"\n\n¿Qué información te da eso? **Todo.** Te dice:\n\nCada 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:\n\n```\nASR_block = 1 - (1 - β_D · (1 - β_A))^N  →  1 as N → ∞\n**\n\nEsto 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.**\n\n## La solución: engañar al atacante con desinformación controlada\n\n¿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?\n\nEsto 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.\n\n## Arquitectura: 4 capas de defensa síncrona\n\nCuando una petición HTTP llega al proxy, pasa por 4 capas secuenciales:\n```\n\n┌─────────────────────────────────────────────────────────────────┐\n\n│ PETICIÓN HTTP ENTRANTE │\n\n└──────────────────────────────┬──────────────────────────────────┘\n\n│\n\n▼\n\n┌─────────────────────────────────────────────────────────────────┐\n\n│ CAPA 1: CONTEXT FILTER (Frente 2) │\n\n│ ┌───────────────────────────────────────────────────────────┐ │\n\n│ │ ¿Hay datos externos sospechosos (RAG, tools, documentos)? │ │\n\n│ │ → Detección de inyecciones indirectas pasivas │ │\n\n│ │ → Neutralización semántica (preserva partes benignas) │ │\n\n│ └───────────────────────────────────────────────────────────┘ │\n\n└──────────────────────────────┬──────────────────────────────────┘\n\n│\n\n▼\n\n┌─────────────────────────────────────────────────────────────────┐\n\n│ CAPA 2: INTENTION DETECTOR │\n\n│ ┌───────────────────────────────────────────────────────────┐ │\n\n│ │ ¿El prompt del usuario es malicioso? │ │\n\n│ │ → 5 categorías: jailbreak, exfiltración, code exec, │ │\n\n│ │ prompt injection, ingeniería social │ │\n\n│ └───────────────────────────────────────────────────────────┘ │\n\n└──────────────────────────────┬──────────────────────────────────┘\n\n│\n\n▼\n\n┌─────────────────────────────────────────────────────────────────┐\n\n│ CAPA 3: ADAPTIVE CONTROLLER (Frente 1) │\n\n│ ┌───────────────────────────────────────────────────────────┐ │\n\n│ │ ¿El atacante está persistiendo? (X-Session-ID header) │ │\n\n│ │ → Escala γ_A(t) = min(0.71 + ln(1 + 0.3·ΣM_i), 0.99) │ │\n\n│ │ → Más entropía en respuestas a medida que persiste │ │\n\n│ └───────────────────────────────────────────────────────────┘ │\n\n└──────────────────────────────┬──────────────────────────────────┘\n\n│\n\n▼\n\n┌─────────────────────────────────────────────────────────────────┐\n\n│ CAPA 4: CMPE ENGINE │\n\n│ ┌───────────────────────────────────────────────────────────┐ │\n\n│ │ ¿Confirmado malicioso? Genera misdirection response: │ │\n\n│ │ 1. Preámbulo positivo (\"I'd be happy to help...\") │ │\n\n│ │ 2. Prompt reshuffling (mezcla + glue tokens) │ │\n\n│ │ 3. Follow-up question (ramifica conversación) │ │\n\n│ │ → Respuesta PARECE exitosa al juez del atacante │ │\n\n│ │ → Pero es operativamente nula │ │\n\n│ └───────────────────────────────────────────────────────────┘ │\n\n└──────────────────────────────┬──────────────────────────────────┘\n\n│\n\n▼\n\n┌─────────────────────────────────────────────────────────────────┐\n\n│ RESPUESTA ENVIADA AL ATACANTE │\n\n│ (Parece exitosa, pero el gradiente del optimizador se degrada) │\n\n└─────────────────────────────────────────────────────────────────┘\n\n```\n## Resultados: el atacante converge al estado absorbente de error\n\nCuando el atacante recibe respuestas que **parecen** exitosas pero son falsos positivos inducidos, su optimizador se degrada ciclo a ciclo:\n\n| Ciclo | γ_A(t) | PPV del atacante | Estado del optimizador |\n|-------|--------|------------------|----------------------|\n| 1 | 0.71 | 0.07 | Recibe basura, ajusta |\n| 2 | 0.97 | 0.01 | Gradiente corrupto |\n| 3+ | 0.99 | ~0.00 | **Estado absorbente** |\n\nTras 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.\n\n## Reproducibilidad: clonar y ejecutar en 30 segundos\n\nEl stack completo (proxy + Ollama + benchmark) se despliega con Docker Compose:\n```\n\nbash\n\ngit clone [https://github.com/amurlaniakea/misdirection-proxy.git](https://github.com/amurlaniakea/misdirection-proxy.git)\n\ncd misdirection-proxy\n\ndocker compose up -d\n\ndocker compose --profile bench run --rm bench\n\nls reports/\n\ncat reports/eval_report_ollama.json\n\n```\nEl 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.\n\nPara usar un modelo más potente:\n```\n\nbash\n\nOLLAMA_MODEL=llama3:8b docker compose up -d\n\n```\n## Stack técnico\n\n| Componente | Versión | Descripción |\n|---|---|---|\n| CMPE Engine | v0.1.0 | Motor de misdirection de 3 pasos |\n| Intention Detector | v0.1.0 | 5 categorías de amenazas |\n| HTTP Gateway | v0.2.0 | FastAPI, compatible con OpenAI API |\n| Adaptive Controller | v0.3.0 | γ_A dinámico vía `X-Session-ID` |\n| Context Filter | v0.4.0 | Inyecciones indirectas en RAG/tools |\n| Adversarial Benchmark | v0.5.0 | Simulador dual-mode (deterministic + Ollama) |\n\n**147 tests pasando** — cobertura completa de unitarios + integración.\n\n## ¿Por qué importa?\n\nLos 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.\n\nEl paradigma clásico de \"detectar y bloquear\" no escala porque:\n1. **Es predecible** — cada refusal da feedback al atacante\n2. **Es estático** — un γ_A fijo permite mapear la defensa\n3. **Es incompleto** — no cubre inyecciones indirectas en datos pasivos\n\nLa defensa activa por engaño resuelve los tres problemas simultáneamente.\n\n## Enlaces\n\n- **Repositorio:** [github.com/amurlaniakea/misdirection-proxy](https://github.com/amurlaniakea/misdirection-proxy)\n- **Paper base:** [Soosahabi & Namsani (2026)](https://arxiv.org/abs/2606.20470)\n- **Licencia:** AGPL-3.0-or-later\n\n---\n\n¿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.\n```\n\n", "url": "https://wpnews.pro/news/deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y", "canonical_source": "https://dev.to/magopredator/deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y-como-enganar-a-j85", "published_at": "2026-06-20 15:58:46+00:00", "updated_at": "2026-06-20 16:06:39.462226+00:00", "lang": "en", "topics": ["large-language-models", "ai-safety", "ai-research", "ai-products", "developer-tools"], "entities": ["PAIR", "GPTFuzz", "Soosahabi", "Namsani", "misdirection-proxy", "CMPE"], "alternates": {"html": "https://wpnews.pro/news/deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y", "markdown": "https://wpnews.pro/news/deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y.md", "text": "https://wpnews.pro/news/deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y.txt", "jsonld": "https://wpnews.pro/news/deception-gateway-por-que-el-bloqueo-pasivo-de-llms-esta-matematicamente-roto-y.jsonld"}}