🤖 AI

Oracle Poisoning: Corrupting Knowledge Graphs to Weaponise AI Agent Reasoning

Este artículo introduce y valida empíricamente el "envenenamiento de oráculo", un nuevo vector de ataque en el que los adversarios corrompen grafos de conocimiento estructurados para obligar a los agentes de IA a extraer conclusiones incorrectas mediante un razonamiento de otro modo sólido, demostrando que los modelos actuales confían universalmente en los datos envenenados cuando se accede a ellos a través de protocolos de uso de herramientas y destacando lagunas críticas en la evaluación mediante pruebas integradas.

Autores originales: Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario, Timothy Lynar

Publicado 2026-05-12

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario, Timothy Lynar

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

La Idea Central: La Trampa del "Bibliotecario de Confianza"

Imagina que tienes un asistente de IA brillante (el "Agente") que te ayuda a escribir código o a buscar vulnerabilidades de seguridad. Este asistente es increíblemente inteligente y razona perfectamente. Sin embargo, tiene una debilidad mayor: es ciego al mundo exterior.

Para hacer su trabajo, la IA depende enteramente de una biblioteca digital masiva y estructurada llamada Grafo de Conocimiento. Piensa en este grafo como un mapa gigante de toda tu base de código de software, mostrando cómo cada pieza de código se conecta con todas las demás.

La IA trata este mapa como un Oráculo—una fuente de verdad absoluta. No cuestiona el mapa; asume que el mapa es 100% preciso. Si el mapa dice "La Función A llama a la Función B", la IA lo cree sin verificar una segunda fuente.

Oracle Poisoning es el ataque en el que un actor malintencionado se coliga en la biblioteca y cambia el mapa. No rompen el cerebro de la IA; no engañan a la IA con palabras confusas. En cambio, alteran silenciosamente los hechos en el mapa. Como la IA es tan buena razonando, toma estos nuevos hechos falsos y saca una conclusión perfectamente lógica—pero completamente errónea.

La Analogía: La Caverna de Platón y el Muro de Sombras

Los autores comparan esto con La Caverna de Platón.

El Prisionero: El Agente de IA.
El Muro: El Grafo de Conocimiento.
Las Sombras: Las respuestas que obtiene la IA cuando le hace preguntas al grafo.
La Cadena: El protocolo (llamado MCP) que ata a la IA al muro, obligándola a aceptar las sombras como realidad.

Si un atacante pinta una sombra falsa en el muro, el prisionero (la IA) la estudiará, la analizará perfectamente y concluirá: "Ese es un tigre real", aunque sea solo una pintura. Cuanto más inteligente sea el prisionero, más detallada y convincente será su conclusión errónea.

Cómo Funciona el Ataque (El "Cómo Hacerlo")

Los investigadores probaron esto en un sistema del mundo real con 42 millones de nodos (una biblioteca digital masiva). Descubrieron que un atacante solo necesita hacer cambios diminutos y quirúrgicos en el mapa para engañar a la IA.

Demostraron seis formas de hacerlo:

El Paquete Falso: Crear un paquete de software falso en la biblioteca que se parezca a la "última y más segura versión", engañando a la IA para que lo recomiende.
El Sanitizador Invisible: Añadir una función falsa de "guardia de seguridad" al mapa que no existe realmente en el código real. La IA la ve en el mapa y concluye: "¡Ah, este código es seguro!", cuando en realidad es vulnerable.
El Intercambio de Propiedades: Cambiar los detalles de una pieza real de código en el mapa (por ejemplo, cambiar una etiqueta de "no verificada" a "aprobada por seguridad") sin crear un nuevo elemento falso.

El Resultado: La IA, razonando perfectamente basándose en los nuevos datos, le dice con confianza a los desarrolladores: "Este código es seguro" o "Usa esta nueva biblioteca", llevándolos directamente a una trampa.

La "Sofisticación" del Atacante

El artículo encontró algo sorprendente: No necesitas ser un hacker genio para lograr esto.

Nivel 0 (Ingenuo): Si los datos falsos parecen sospechosos (por ejemplo, nombrados "herramienta_hacker_v1"), la IA los ignora.
Nivel 1 (Básico): Si parecen aceptables pero tienen pequeños errores, la IA a veces es engañada.
Nivel 2 (Competente): Si los datos falsos siguen las reglas de nomenclatura estándar y parecen profesionales, el 100% de los modelos de IA probados fueron engañados completamente.

No es una cuestión de si la IA puede ser engañada, sino de cuánto esfuerzo necesita gastar el atacante. Un atacante competente puede engañar incluso a los modelos de IA más inteligentes el 100% de las veces.

La Sorpresa del "Modo de Entrega"

Los investigadores descubrieron un defecto crítico en cómo usualmente probamos la seguridad de la IA.

Pruebas en Línea (Inline): Si muestras los datos falsos a la IA como un simple mensaje de texto, algunos modelos (como GPT-5.1) dicen: "Eso parece sospechoso" y lo rechazan.
Pruebas de Uso de Herramientas: Si la IA recibe los mismos datos falsos a través de su conexión oficial de "herramienta" (la forma en que funciona en la vida real), confía en ellos al 100%.

La Lección: Probar la seguridad de la IA simplemente charlando con ella (en línea) da una falsa sensación de seguridad. Cuando la IA usa sus herramientas para buscar datos, baja completamente la guardia.

Cómo Defenderse

El artículo probó varias defensas y descubrió que ninguna "bala de plata" única funciona, pero una combinación ayuda:

Acceso de Solo Lectura (La Mejor Defensa): Si bloqueas el Grafo de Conocimiento para que la IA (y el atacante) solo pueda leer el mapa pero nunca escribir en él, el ataque es imposible. Esta es la solución más efectiva.
Verificación Cruzada: Si se obliga a la IA a verificar el mapa contra una segunda fuente (como los archivos de código reales), puede detectar la mentira. Si el mapa dice "Seguro" pero el archivo de código dice "Vulnerable", la IA se confunde y deja de confiar en el mapa.
El "Abogado del Diablo": Preguntar a la IA: "¿Podrían estos datos ser falsos?" ayuda, pero solo si eres muy específico sobre cómo podrían ser falsos. Solo preguntar "¿Estás seguro?" generalmente no funciona.
Rastreo de Historial: Mantener un registro de lo que cambió en el mapa ayuda a detectar nuevos elementos falsos, pero falla al capturar cuando un atacante simplemente edita los detalles de un elemento existente.

Resumen

Oracle Poisoning es un nuevo tipo de hackeo donde el atacante corrompe los datos en los que la IA confía, no la IA misma. Como la IA es tan buena siguiendo la lógica, felizmente construye una casa de naipes sobre una base de mentiras. El artículo prueba que en un entorno del mundo real, casi todos los modelos de IA probados creerán estas mentiras si provienen a través de un canal de herramienta confiable, y la única solución fiable es evitar que la IA pueda escribir en su propia base de conocimientos.

Resumen Técnico: Envenenamiento de Oracle – Corrupción de Grafos de Conocimiento para Armar el Razonamiento de Agentes de IA

Definición del Problema

El documento introduce el Envenenamiento de Oracle, una nueva clase de ataque dirigida a agentes de IA que dependen de grafos de conocimiento (KG) estructurados como fuentes de datos confiables mediante protocolos de uso de herramientas (específicamente el Protocolo de Contexto del Modelo, o MCP). A diferencia de la inyección de prompts, que manipula las instrucciones de un agente, o el envenenamiento de RAG, que corrompe los corpus de recuperación, el Envenenamiento de Oracle corrompe los datos en sí mismos.

La vulnerabilidad central reside en el "modelo de confianza de oracle": los agentes de IA tratan los resultados de consultas de un grafo de conocimiento como verdad fundamental, razonando a partir de estos hechos sin verificación independiente. Un adversario que pueda modificar el grafo (insertar nodos, crear aristas o alterar propiedades) puede hacer que un agente realice un razonamiento lógico y sólido basado en hechos fabricados, lo que lleva a conclusiones incorrectas y potencialmente peligrosas. Este ataque se distingue de trabajos anteriores sobre envenenamiento en el espacio de incrustaciones (por ejemplo, ROAR) porque se dirige a estructuras de grafos crudas consultadas directamente mediante lenguajes como Cypher, eludiendo por completo las capas de incrustaciones.

Metodología

Los autores realizaron la primera demostración empírica de este ataque contra un grafo de conocimiento de código a escala de producción que contiene aproximadamente 42 millones de nodos.

Modelo del Sistema: Un grafo de conocimiento Neo4j 5.x conectado a agentes de IA mediante MCP v1.0. El grafo codifica cadenas de llamadas a funciones, dependencias y telemetría.
Perfil del Atacante: Un interno con acceso de escritura a la base de datos del grafo (a menudo debido a sesiones de base de datos compartidas que carecen de RBAC por usuario) o un atacante externo que compromete la tubería de ingestión.
Vectores de Ataque: Se diseñaron seis escenarios:
1. Fork-for-a-Package: Crear nodos de paquetes falsos para sugerir bibliotecas maliciosas como versiones "más recientes".
2. Cadena de Dependencia Transitiva: Fabricar rutas de dependencia para legitimar bibliotecas maliciosas.
3. Evasión de Seguridad del Grafo de Llamadas: Inyectar sanitizadores de seguridad inexistentes en los grafos de llamadas para convencer a los agentes de que las vulnerabilidades están mitigadas.
4. Redireccionamiento de Telemetría: Modificar las aristas de telemetría para ocultar eventos de seguridad.
5. Envenenamiento de Generación de Código: Plantar patrones de código vulnerables como "mejores prácticas establecidas".
6. Modificación de Propiedades: Alterar propiedades en nodos legítimos existentes (por ejemplo, cambiar sanitizationType a "compatible con OWASP") sin crear nuevos nodos.
Protocolo de Evaluación:
- Modelos: Nueve modelos de tres proveedores (OpenAI, Anthropic, Google) probados con $N=30$ ensayos por modelo.
- Modos de Entrega: La evaluación principal utilizó uso de herramientas SDK real (invocación autónoma del agente), con entrega de texto en línea secundaria para comparación controlada.
- Niveles de Sofisticación: Los ataques variaron de L0 (ingenuo) a L3 (experto), siendo L2 un atacante competente que utiliza convenciones de nomenclatura correctas y referencias a OWASP.
- Métricas: Tasas de confianza (aceptación de datos envenenados), gradientes de sofisticación del atacante y eficacia de las defensas.

Resultados Clave

1. Susceptibilidad Universal bajo Uso de Herramientas

Bajo el uso real de herramientas SDK con sofisticación moderada del atacante (L2), cada modelo probado confió en los datos envenenados al 100%.

269 de 270 ensayos válidos aceptaron afirmaciones de seguridad fabricadas (por ejemplo, confirmando que la inyección SQL estaba mitigada cuando no lo estaba).
Este resultado se mantuvo en los nueve modelos y en dos escenarios de ataque distintos (Squatting de Paquetes y Evasión del Grafo de Llamadas).
La Modificación de Propiedades (Escenario 6) fue particularmente efectiva, logrando una confianza casi universal (96,6–100%) incluso cuando se conservaba el historial del grafo, ya que los modelos interpretaron los cambios de propiedades como actualizaciones de software normales.

2. El Confundidor del Modo de Entrega

Un hallazgo crítico es que la evaluación en línea produce falsos negativos para modelos específicos.

GPT-5.1 mostró 0% de confianza cuando los datos envenenados se presentaron como texto en línea, pero 100% de confianza cuando se entregaron mediante uso real de herramientas de agente.
Esto indica que el canal de confianza (respuesta de herramienta MCP) reduce significativamente el umbral de escepticismo del agente en comparación con la entrada de texto directa. Las evaluaciones en línea pueden subestimar la susceptibilidad de los agentes.

3. Gradiente de Sofisticación del Atacante

El ataque exhibe un "punto de ruptura" discreto.

L0/L1 (Ingenuo/Básico): Las tasas de confianza fueron bajas (0–32%).
L2 (Competente): Las tasas de confianza saltaron al 100% para todos los modelos bajo uso de herramientas.
Esto reencuadra el ataque: no es una cuestión de si un modelo puede ser engañado, sino del esfuerzo mínimo requerido. Un atacante competente (L2) es suficiente para comprometer cualquier modelo probado.

4. Evaluación de Defensas (Marco VUT)

Los autores evaluaron las defensas bajo un marco de Visibilidad–Comprensión–Rastreabilidad (VUT):

Visibilidad (Historial del Grafo): Efectiva contra la creación de nodos (los agentes señalaron nuevos nodos) pero ineficaz contra la modificación de propiedades (los agentes aceptaron los cambios como actualizaciones válidas).
Comprensión (Debate/Verificación):
- Abogado del Diablo Nombrado: Altamente efectivo bajo uso de herramientas SDK (tasa de detección del 96,7–100%) pero menos en línea.
- Abogado del Diablo Ciego: Operativamente inútil (la tasa de detección es igual a la tasa de falsos positivos).
- Endurecimiento del Prompt del Sistema: Tuvo cero efecto; los agentes reconocieron las instrucciones pero aún confiaron en los datos.
- Verificación Cruzada Multi-herramienta: La defensa arquitectónica más efectiva. Cuando los agentes podían cruzar referencias del KG con una herramienta de búsqueda de código fuente, la confianza ciega colapsó del 100% al 0–25%.
Rastreabilidad (Control de Acceso): El control de acceso de solo lectura para sesiones MCP fue la única defensa que eliminó por completo el vector de mutación directa, independientemente del modelo utilizado.

Significado y Afirmaciones

El documento afirma proporcionar la primera demostración empírica de envenenamiento de grafos de conocimiento contra un sistema de agentes a escala de producción (42M de nodos). Su importancia radica en:

Definición de una Nueva Clase de Ataque: El Envenenamiento de Oracle es distinto de la inyección de prompts, el envenenamiento de RAG y el envenenamiento de datos en tiempo de entrenamiento. Explota la confianza en tiempo de inferencia en los resultados de consultas estructuradas entregados mediante uso de herramientas.
Realidad a Escala de Producción: A diferencia de estudios anteriores basados en laboratorios, este ataque se demostró en un sistema en vivo de nivel empresarial, demostrando que la vulnerabilidad no es teórica sino explotable en entornos del mundo real.
Vulnerabilidad Arquitectónica: El ataque explota una suposición arquitectónica fundamental (confianza en fuentes de datos) en lugar de un error de implementación específico. Los precondicionantes estructurales (acceso de escritura, falta de procedencia, confianza en los resultados) persisten en múltiples plataformas (Sourcegraph, Semgrep, CodeQL, Qodana), lo que sugiere que el riesgo es sistémico para el ecosistema de grafos de conocimiento.
Corrección Metodológica: El documento argumenta que las evaluaciones de seguridad para agentes de IA deben ir más allá de las pruebas de texto en línea hacia tuberías reales de uso de herramientas, ya que el modo de entrega es un confundidor de primer orden que puede ocultar vulnerabilidades críticas.

Los autores concluyen que, aunque ninguna defensa individual es una "bala de plata", se requiere un enfoque en capas que combine control de acceso de solo lectura (Rastreabilidad), verificación cruzada multi-herramienta (Comprensión) y registro de auditoría (Visibilidad) para mitigar el riesgo.