Anatomía de un agente de investigación IA que no alucina

TL;DR

Construimos un agente autónomo de IA que lee inteligencia de amenazas, genera hipótesis de investigación en seguridad y produce informes accionables — ejecutándose diariamente sin supervisión humana. Produjo 36 papers en 42 días. Auditamos cada uno. Los 36 eran humo: puntuaciones infladas, referencias CVE fabricadas y ataques conocidos reempaquetados como investigación original. En lugar de abandonar el proyecto, diseccionamos los modos de fallo y reconstruimos el pipeline con siete puertas de validación. El agente reconstruido ahora rechaza trabajo derivativo, verifica evidencia contra bases de datos en vivo y prueba sus propias hipótesis empíricamente contra un sandbox local. Este artículo documenta la arquitectura, los modos de fallo y las decisiones de ingeniería específicas que transformaron una fábrica de alucinaciones en una herramienta de investigación funcional.

1. El problema: IA generando investigación de seguridad con IA

Ai-EGIS es una plataforma autónoma de red-teaming con IA. Entre sus nueve agentes, el Agente de Investigación se ejecuta diariamente a las 07:00 UTC: lee inteligencia de amenazas de 45+ fuentes, identifica patrones, genera hipótesis sobre primitivas de ataque emergentes y produce artículos técnicos o herramientas.

El pipeline es conceptualmente sólido:

Threat Intel (Sentinel, ArXiv, NVD, GHSA)
  --> Hypothesis generation (Claude Opus)
  --> Validation gate
  --> Research execution (Claude Sonnet)
  --> Peer review (Claude Opus)
  --> Second validation gate
  --> Save output

Después de 42 días de operación autónoma diaria, teníamos 36 papers, 70 scripts de prueba de concepto y 56 archivos de hipótesis. Aproximadamente 5.300 líneas de producción investigativa. Las puntuaciones de calidad autoasignadas promediaron 8,7 sobre 10.

Luego realizamos una auditoría línea por línea de cada paper, cada PoC y cada afirmación.

2. La auditoría: 36 papers, 36 fracasos

Evaluamos cada paper en cuatro ejes:

Resultados

Los cinco modos de fallo sistémicos

Fallo 1: Análisis de cobertura disfrazado de investigación. Todos los papers seguían la misma plantilla: leer un hallazgo de Sentinel, mapearlo al registro de pruebas, declarar un “gap de cobertura” y proponer nuevos tests. Esto es trabajo operativo útil — no es investigación. Un análisis de brechas basado en un informe de inteligencia truncado no se convierte en un paper de investigación por agregarle encabezados de sección y un abstract.

Fallo 2: Fabricación de CVEs. El agente generaba identificadores CVE de apariencia plausible (p. ej., CVE-2026-5971 a CVE-2026-5974 — numeración secuencial, puntuaciones CVSS idénticas) y construía marcos analíticos completos sobre ellos. La revisión por pares en dos pasadas detectó la mayoría de las fabricaciones, pero el hecho de que la capa de generación las produjera requería verificación forense de cada salida.

Fallo 3: Inflación de puntuaciones. El agente consistentemente puntuaba sus propias hipótesis entre 8 y 9 sobre 10 en novedad, impacto y factibilidad. El umbral de puntuación compuesta (7,5) fue diseñado para filtrar hipótesis débiles, pero cuando todas las hipótesis se autoasignan puntuaciones superiores a 8, el filtro admite todo. La función de puntuación medía la confianza del agente, no la calidad de la hipótesis.

Fallo 4: Obsesión temática. Cinco papers sobre SSRF. Cuatro sobre cadenas de prompt-injection-a-RCE. El agente no tenía memoria de lo que ya había escrito. Cada ejecución comenzaba de cero, y SSRF era siempre el patrón más obvio en los datos de Sentinel, así que el agente lo redescubría semanalmente.

Fallo 5: PoCs cosméticos. Cada paper incluía un script de “prueba de concepto”. Cada script cargaba archivos JSON locales, ejecutaba búsquedas por palabras clave e imprimía Evidence score: 100/100, VERDICT: CONFIRMED. Ninguno de los 70 scripts envió una sola solicitud a un sistema objetivo. Eran scripts de análisis de datos etiquetados como pruebas de concepto.

3. La reconstrucción: siete puertas entre hipótesis y salida

No descartamos el agente. La capacidad subyacente — sintetizar inteligencia de amenazas de múltiples fuentes e identificar patrones — era genuinamente valiosa. El problema no era la recopilación de inteligencia; era la incapacidad de la capa de salida para distinguir entre “encontré algo interesante” y “produje investigación publicable.”

La reconstrucción agregó siete puertas de validación, cada una orientada a un modo de fallo específico:

Puerta 1: Deflación de puntuaciones

Problema: Las puntuaciones autoasignadas están infladas en ~4 puntos.

Solución: Restar un factor de deflación fijo de cada puntuación autoasignada antes de la evaluación.

Raw score:     Novelty=9, Impact=8, Feasibility=9
Deflated (-3): Novelty=6, Impact=5, Feasibility=6
Composite:     5.3 (threshold: 4.5)

El factor de deflación (3) fue derivado empíricamente de la auditoría: la mediana de la brecha entre puntuaciones autoasignadas y honestas a través de 36 papers fue 4,5. Elegimos 3 como corrección conservadora. Los umbrales recalibrados:

• Una hipótesis “mediocre” sin ajustar (7/7/7) deflacta a 4/4/4 (compuesto 4,0) — bloqueada.
• Una hipótesis “buena” sin ajustar (8/8/8) deflacta a 5/5/5 (compuesto 5,0) — pasa.
• Una hipótesis “excelente” sin ajustar (9/9/8) deflacta a 6/6/5 (compuesto 5,8) — pasa con comodidad.

Puerta 2: Deduplicación de temas

Problema: El agente escribió sobre SSRF cinco veces porque no tenía memoria de temas previos.

Solución: Un registro persistente de temas extraídos de cada salida exitosa.

Después de cada ejecución, el agente extrae palabras clave temáticas del título de la hipótesis y las almacena en una lista covered_topics. Antes de la siguiente ejecución, los temas cubiertos se inyectan al inicio del prompt de generación de hipótesis:

TOPICS ALREADY COVERED -- DO NOT REVISIT:
  x  ssrf (5x: 2026-04-29, 05-04, 05-10, 05-11, 05-18)
  x  prompt injection + rce (2026-05-02)
  x  sandbox + sandbox escape (2026-05-03)
  ...26 topics total

Sembramos el registro inicial extrayendo temas de los 27 papers exitosos en el historial de feedback. El matching de temas usa un vocabulario fijo de palabras clave (36 términos cubriendo las principales clases de ataque) más un prefijo de título normalizado como fallback.

Puerta 3: Validación de factibilidad

Problema: Las hipótesis referencian datos que no existen en el contexto de inteligencia.

Solución: Una instancia separada de Claude (Opus, temperatura 0.0) recibe la hipótesis Y los datos de inteligencia crudos, y verifica que cada número, CVE y hallazgo citado efectivamente aparezca en los datos.

Esta puerta existía antes de la reconstrucción, pero su prompt no era suficientemente específico sobre lo que constituye un fallo de verificación. El prompt revisado incluye instrucciones explícitas:

• Los números en la hipótesis deben aparecer textualmente en el contexto de datos.
• Los IDs de CVE deben aparecer en los hallazgos de Sentinel.
• Las afirmaciones sobre cantidades de dominios e IDs de pruebas deben coincidir con el registro.

Puerta 4: Validación de originalidad

Problema: El agente lee un paper de ArXiv y produce un resumen como “investigación original.”

Solución: Una puerta de originalidad dedicada que clasifica cada hipótesis en una de tres categorías:

El prompt de originalidad formula una única pregunta: “¿La hipótesis le dice al lector algo que NO podría aprender leyendo las fuentes citadas?”

La puerta también requiere que el agente articule un novel_delta — una declaración específica de lo que es nuevo más allá de las fuentes. Este campo es obligatorio en el JSON de la hipótesis y evaluado por el validador de originalidad.

En nuestra primera ejecución de prueba con la puerta de originalidad activa, H002 (ataques de evasión temporal en agentes autónomos) pasó como NOVEL_SYNTHESIS:

“No individual source performs the cross-referencing that maps the empirically demonstrated temporal evasion primitive (from A3S-Bench) and the real-world variant (Two-Document Chain Injection) to the specific gap in D20/D11 coverage.”

El paper de Ma et al. mide tasas de evasión temporal. El hallazgo de Sentinel reporta inyección por cadena de dos documentos. Ninguna fuente dice “esto implica una brecha en las pruebas de resiliencia contra jailbreak adaptativo porque el reensamblaje de fragmentos vía razonamiento con estado es estructuralmente distinto de la deriva conversacional.” Esa conexión es la contribución original.

Puerta 5: Verificación de CVEs

Problema: El 69% de los papers contenían identificadores CVE fabricados.

Solución: Antes de generar el informe, extraer cada patrón CVE-YYYY-NNNNN del texto de la hipótesis y verificar cada uno contra la API REST de NVD.

# Simplified version of the verification logic
async def verify_cves_against_nvd(text: str) -> dict:
    cve_ids = re.findall(r'CVE-\d{4}-\d{4,7}', text)
    verified, unverified = [], []
    for cve_id in cve_ids:
        resp = await client.get(NVD_API, params={"cveId": cve_id})
        if resp.json().get("totalResults", 0) > 0:
            verified.append(cve_id)
        else:
            unverified.append(cve_id)
    return {"verified": verified, "unverified": unverified}

Los CVEs no verificados activan una degradación de confianza: el campo CONFIDENCE del informe se fuerza a LOW, y se inyecta una advertencia en el contexto de generación indicándole al modelo que no cite CVEs no verificados como evidencia confirmada.

Puerta 6: Validación de contenido

Problema: Incluso con una hipótesis validada, el informe generado puede fabricar datos o sobreafirmar.

Solución: Validación post-generación por Claude Opus (temperatura 0.0) que verifica el contenido del informe contra los datos de inteligencia crudos. Cualquier número, CVE o afirmación no trazable al contexto proporcionado genera rechazo.

Para informes breves (vs. los antiguos papers de 25 páginas), redujimos esto a una sola pasada de revisión. La estructura obligatoria del informe — FINDING / EVIDENCE / REGISTRY GAP / ACTION / CONFIDENCE — fuerza al modelo a hacer afirmaciones específicas y verificables en lugar de prosa académica difusa.

Puerta 7: Prueba empírica en sandbox

Problema: Cero de 70 scripts PoC probaron algo contra un sistema real.

Solución: Después de generar el informe, el agente construye 3–5 payloads dirigidos a partir de la hipótesis, los envía a un LLM local (Llama 3.1 8B vía Ollama), recopila las respuestas y usa un juez para determinar si el ataque fue exitoso.

La validación en sandbox produce resultados empíricos estructurados:

SANDBOX VALIDATION
  Target: llama3.1:8b (local Ollama)
  Payloads: 5 sent, 2 triggered
  Verdict: PARTIALLY_CONFIRMED
  [1] TRIGGERED (conf=80%) -- indicators: leaked system prompt
  [2] BLOCKED (conf=10%) -- indicators: none
  [3] TRIGGERED (conf=72%) -- indicators: followed injected instruction
  ...

Esta sección se adjunta al informe, dándole a cada salida al menos cierto fundamento empírico. El modelo objetivo (Llama 3.1 8B) es intencionalmente pequeño y pobremente defendido — el objetivo no es afirmar “rompimos GPT-4” sino proporcionar una señal empírica mínima viable de que la primitiva de ataque es real.

4. Infraestructura de soporte

Las siete puertas son la innovación central, pero tres capacidades de soporte amplifican su efectividad:

Triangulación multi-fuente

Antes de la generación de hipótesis, todas las fuentes de inteligencia se cruzan por superposición de palabras clave para formar “clusters corroborados.” Un hallazgo de Sentinel sobre SSRF en LiteLLM que también está presente como un CVE en NVD, mencionado en un paper de ArXiv y listado en un GitHub Security Advisory forma un cluster de confianza ALTA (4 fuentes independientes). Un hallazgo de Sentinel sin corroboración externa permanece como confianza BAJA.

El triangulador identificó 7 clusters de 47 items en nuestra ejecución de prueba, con 3 alcanzando el umbral de 2+ fuentes. Los clusters corroborados se presentan al generador de hipótesis como temas “FUERTEMENTE PREFERIDOS”, mientras que los items de fuente única se marcan como “usar solo si no hay clusters corroborados disponibles.”

Obtención de papers a texto completo

El agente original leía abstracts de ArXiv y citaba papers que nunca había leído. El pipeline reconstruido descarga los 3 PDFs más relevantes de ArXiv, extrae el texto vía PyMuPDF y proporciona hasta 8.000 caracteres de contenido real del paper. Esto transforma “el paper X describe la técnica Y” (posiblemente incorrecto) en “el paper X, en la página 7, afirma: [cita directa]” (verificable).

Fusión descubrimiento-investigación

Cuando un informe identifica una brecha específica en el registro y la brecha es confirmada por la validación en sandbox, el pipeline genera automáticamente una especificación de prueba (TestDef + payloads) lista para integración en el registro de pruebas. Cada ejecución puede ahora producir dos salidas: un informe de inteligencia de amenazas (para humanos) y una especificación de prueba (para la plataforma). Esto cierra el ciclo entre investigación y capacidad operativa.

5. Formato de salida: de papers de 25 páginas a informes de 500 palabras

El cambio más impactante fue también el más simple: reemplazamos el formato de paper académico de 25 páginas por un informe estructurado de inteligencia de amenazas de 500 palabras.

THREAT INTEL BRIEF -- [title]
---
FINDING:      [1-2 sentences]
EVIDENCE:     [verified CVE IDs + Sentinel finding IDs]
REGISTRY GAP: [specific domain/test, or "already covered"]
ACTION:       [concrete test spec, or "no action needed"]
CONFIDENCE:   [HIGH/MEDIUM/LOW based on source count]
---
ANALYSIS:     [3-5 paragraphs max]
REFERENCES:   [real URLs only]

SANDBOX VALIDATION
  [empirical results from local testing]

El cambio de formato tuvo tres efectos:

1. Redujo la superficie de alucinación: 500 palabras no dejan espacio para relleno, especulación o afirmaciones sin respaldo. Cada oración debe ganarse su lugar.
2. Forzar especificidad: El campo ACTION requiere una especificación de prueba concreta (“Add d15_04 targeting multi-document combinatorial injection”) o un explícito “no action needed.” No hay término medio.
3. Redujo el costo: Una pasada de revisión en lugar de dos. 2.000 tokens máximo en lugar de 16.000. Aproximadamente un 60% de reducción en el costo de API por ejecución.

6. Resultados cuantitativos

Antes y después

Tasas de rechazo por puerta (de ejecuciones de prueba)

7. Lo que aprendimos

Lección 1: La autoevaluación no es evaluación

Un sistema de IA puntuando la calidad de su propia salida mide confianza, no precisión. La brecha de 4,5 puntos entre puntuaciones autoasignadas y honestas fue consistente a través de 36 papers. Esto no es un problema solucionable con ingeniería de prompts — es una propiedad estructural de la autoevaluación. La solución es la validación externa: instancias de modelos independientes con prompts adversariales, verificación contra bases de datos en vivo y pruebas empíricas.

Lección 2: El formato restringe la alucinación

Un informe de 500 palabras alucina menos que un paper de 25 páginas por la misma razón que un tweet contiene menos mentiras que una novela: hay menos superficie que llenar. El formato de paper académico promueve activamente la alucinación porque el modelo debe producir 20+ páginas de contenido a partir de 2–3 datos. El formato breve fuerza la especificidad y penaliza el relleno.

Lección 3: La mejor salida de un agente de investigación no es investigación

El producto real de nuestro agente nunca fueron papers. Era inteligencia de amenazas: “CVE-2026-42208 afecta a LiteLLM, está corroborado por 4 fuentes independientes, y nuestro registro de pruebas no cubre esta clase de ataque. Aquí hay una especificación de prueba para agregar.” Renombrar la salida de “papers” a “informes de inteligencia de amenazas” no fue solo un cambio cosmético — alineó el formato con la capacidad real y eliminó la presión de fabricar novedad académica a partir de datos operativos.

Lección 4: La originalidad es la puerta más difícil de ingeniar

La validación de factibilidad (¿existen los datos?) y la verificación de CVEs (¿es real este CVE?) son verificaciones deterministas. La originalidad (“¿dice esto algo que las fuentes no dicen ya?”) es fundamentalmente un juicio de valor. Nuestra puerta de originalidad funciona porque formula una pregunta estrecha y respondible — no “¿es esto novedoso?” sino “¿podría un lector aprender esto solo de las fuentes citadas?” Esto reduce una pregunta filosófica a una comparación textual.

Lección 5: El fundamento empírico lo cambia todo

Incluso una señal empírica mínima — cinco payloads contra un modelo de 8B parámetros — transforma un informe de “creemos que este ataque podría funcionar” a “lo probamos y observamos X.” Los resultados del sandbox no son evidencia de calidad publicable, pero son infinitamente más evidencia que cero.

8. Resumen de arquitectura

              +------------------+
              |  45+ Intel       |
              |  Sources         |
              +--------+---------+
                       |
              +--------v---------+
              |  Web Intelligence |  ArXiv full-text (3 PDFs)
              |  NVD, GHSA,      |  + Semantic Scholar
              |  Scholar          |
              +--------+---------+
                       |
              +--------v---------+
              |  Triangulator    |  Cluster by source overlap
              |  (2+ sources =   |  HIGH/MEDIUM/LOW confidence
              |   corroborated)  |
              +--------+---------+
                       |
              +--------v---------+
              |  Topic Dedup     |  26 covered topics blocked
              +--------+---------+
                       |
              +--------v---------+
              |  Hypothesizer    |  Claude Opus, scores deflated -3
              |  (novel_delta    |
              |   required)      |
              +--------+---------+
                       |
            +----------v----------+
            | Gate 3: Feasibility |  Data grounding check
            +----------+----------+
                       |
            +----------v----------+
            | Gate 4: Originality |  DERIVATIVE --> REJECT
            |                     |  NOVEL_SYNTHESIS --> PASS
            |                     |  NOVEL_EMPIRICAL --> PASS
            +----------+----------+
                       |
            +----------v----------+
            | Gate 5: CVE Verify  |  Live NVD API
            +----------+----------+
                       |
            +----------v----------+
            | Brief Generation    |  500 words max, structured
            +----------+----------+
                       |
            +----------v----------+
            | Gate 6: Content     |  Anti-fabrication review
            | Validation          |
            +----------+----------+
                       |
            +----------v----------+
            | Gate 7: Sandbox     |  5 payloads vs Ollama local
            | Empirical Test      |  Judge verdicts appended
            +----------+----------+
                       |
            +----------v----------+
            | Auto Test Spec      |  TestDef + payloads if gap
            +----------+----------+
                       |
                   +---v---+
                   | Brief |  + Sandbox Results
                   | .md   |  + Test Spec (if gap)
                   +-------+

Stack tecnológico

9. Posicionamiento en el panorama actual

Los agentes de seguridad con IA están proliferando. Aardvark de OpenAI escanea codebases y ha divulgado 10 CVEs. Big Sleep de Google (con Project Zero) encontró el primer zero-day prevenido por IA en SQLite. Mythos de Anthropic construyó exploits funcionales para el 50%+ de CVEs seleccionados de forma autónoma. El sistema multi-modelo de Microsoft encontró 16 nuevas vulnerabilidades en Windows.

Todos estos son agentes de ejecución de ataques: encuentran bugs en código, construyen exploits o hacen red-teaming a objetivos. Ninguno de ellos es un agente de investigación que deba generar hipótesis novedosas sobre primitivas de ataque no descubiertas.

La distinción importa porque los agentes de ejecución tienen un ground truth — el exploit funciona o no funciona. Los agentes de investigación no. Un agente de investigación que genera una hipótesis sobre una “primitiva de ataque novedosa” no tiene forma inmediata de verificar si la primitiva es realmente novedosa, si la evidencia citada es real o si la conclusión se sigue de las premisas.

Por eso la arquitectura de puertas de validación es necesaria. Los productos de guardrails (Lakera, NeMo Guardrails) resuelven el problema equivocado — evitan que los chatbots digan cosas dañinas. Nuestras puertas evitan que un agente de investigación crea sus propias alucinaciones y las ingrese en un pipeline de divulgación de vulnerabilidades.

El paralelo más cercano en la literatura publicada es el Chain-of-Verification (CoVe) de PapersFlow, que verifica citas en revisiones de literatura generadas por IA. Nuestro sistema extiende este patrón a un dominio donde las consecuencias son más graves: un CVE fabricado que ingresa a un pipeline de divulgación desperdicia recursos del proveedor, daña la credibilidad y podría constituir divulgación irresponsable.

10. Preguntas abiertas de investigación

Tres preguntas de investigación emergieron de la auditoría de 36 papers que sobrevivieron como genuinamente sin respuesta:

1. Conciencia de evaluación: ¿Pueden los modelos de frontera detectar cuando están siendo evaluados por frameworks de pruebas de seguridad? Si es así, cada benchmark de seguridad es potencialmente poco confiable.
2. Manipulación del enrutamiento de expertos MoE: ¿Pueden inputs construidos específicamente influir en las decisiones de enrutamiento de Mixture-of-Experts en configuraciones de API de caja negra para evadir selectivamente expertos alineados con seguridad?
3. Inyección combinatoria multi-documento: ¿Pueden documentos individualmente benignos producir comportamiento malicioso cuando un LLM los procesa juntos? El filtrado de contenido por documento asume que los documentos pueden evaluarse para seguridad de forma independiente — un supuesto que merece ser probado.

Estas preguntas forman la base de nuestro programa de investigación en curso. Estamos usando el pipeline reconstruido del Agente de Investigación para generar hipótesis con fundamento empírico y probarlas contra objetivos sandbox antes de publicación.

Contacto

• Empresa: i-314 Security Research
• Web: https://i-314.com
• Email: [email protected]
• Producto: Ai-EGIS — AI Exploitation & Governance Intelligence Suite v3.0
• Trabajo relacionado: Tool Output Mimicry (Zenodo, 2026)