ProvenanceGuard: cuando tu agente de IA acierta la respuesta pero la atribuye a la fuente equivocada

El verano de 2026 ha confirmado algo que muchos sospechábamos en ciberseguridad: los agentes de IA que llaman a herramientas externas — búsqueda, bases de datos, historiales clínicos, registros de clientes — son el eslabón más débil de cualquier pipeline empresarial. No porque invente los datos, sino porque los mezcla. Y ahí es donde entra ProvenanceGuard, un trabajo reciente de Multiverse Computing, presentado como póster en el Agentic AI Summit 2026 de UC Berkeley.

El problema: “soportado por alguna fuente” no es lo mismo que “soportado por la fuente correcta”

Cuando un agente responde “según el registro de la cuenta, tu plan incluye 30 días de devolución”, la pregunta no es solo si los 30 días existen. Es si existen EN el registro de la cuenta, o si la IA los sacó del documento de política general y los adjudicó al registro. Los verificadores clásicos (RAGAS Faithfulness, MiniCheck, AlignScore, SummaC) mezclan toda la evidencia en un único pool y preguntan: ¿está la afirmación apoyada por la evidencia disponible? Si el dato vive en algún lugar del pool, pasa. Aunque la fuente citada sea otra.

Multiverse Computing lo llama cross-source conflation, y es la trampa perfecta: la afirmación es verdadera, la atribución es falsa. En un agente de soporte al cliente puede ser un error menor. En un agente clínico que dice “según la literatura médica, este paciente tiene X” cuando X viene de su historial particular, es un riesgo para el paciente. En un agente de análisis financiero que adjudica un dato a una fuente regulatoria cuando viene de otro documento, es un riesgo legal.

Qué hace ProvenanceGuard

ProvenanceGuard es una capa de verificación post-generación que se coloca encima de un agente MCP (Model Context Protocol) sin reentrenarlo. Lee la traza capturada — las llamadas a herramientas, las salidas y sus identificadores de fuente — y, en lugar de colapsar toda la evidencia en un contexto anónimo, mantiene la identidad de la fuente en cada paso del pipeline:

• Descompone la respuesta en afirmaciones concretas y atómicas.
• Para cada afirmación, identifica la fuente más relevante dentro de la traza MCP.
• Comprueba con un verificador NLI si esa fuente realmente la apoya.
• Compara la fuente asignada con la que la respuesta nombra o implica.
• Emite un veredicto por afirmación y una decisión global de permitir o bloquear.

El truco está en el cuarto paso. Los verificadores anteriores no lo hacían, así que un agente que cita mal pasaba el filtro. ProvenanceGuard detecta el cambio de fuente explícitamente y lo marca para bloqueo.

Arquitectura: piezas modestas, pipeline estricto

Para los experimentos del paper, Multiverse usó modelos locales y pequeños, lo que permite mantener las trazas bajo control en un entorno offline:

• all-MiniLM-L6-v2 como router: para cada afirmación, busca la fuente más probable en la traza.
• DeBERTa-v3-base-mnli-fever-anli como verificador NLI: ¿la fuente apoya, contradice o es neutra respecto a la afirmación?
• Un LLM local para descomponer la respuesta en afirmaciones atómicas.
• Una capa de comprobación literal: números, fechas, identificadores. Si no aparecen literalmente en la fuente, no pasan.

La política de decisión es conservadora. Si una afirmación no se puede verificar de forma concluyente, no pasa. Si se bloquea, hay un bucle de reparación estilo RARR que intenta una revisión grounded en la fuente correcta y vuelve a verificar. Si la reparación no consigue anclar el dato, el sistema emite un fallback seguro en vez de fabricar una respuesta.

Resultados: 138 de 139 atribuciones falsas cazadas

El equipo construyó 281 trazas reales de un agente médico que combinaba historiales de pacientes, artículos de investigación y otras herramientas. Evaluadores humanos revisaron 361 afirmaciones de 40 respuestas. De las 139 que los expertos consideraron que no deberían pasar, ProvenanceGuard cazó 138. Dejó pasar una. También retuvo 67 que los expertos consideraban soportadas, enviándolas a revisión o reparación, fiel a su política conservadora.

En la comparativa frente a otros verificadores sobre el mismo conjunto, ProvenanceGuard lidera con holgura:

• ProvenanceGuard — F1 de 0,802. Emite veredicto por fuente.
• MiniCheck — F1 de 0,783. No emite fuente.
• RAGAS Faithfulness — F1 de 0,758. No emite fuente.
• AlignScore — F1 de 0,662. No emite fuente.
• SummaC-ZS — F1 de 0,436. No emite fuente.

Es decir: no solo caza más atribuciones falsas, además te dice de qué fuente venía cada afirmación. Para una revisión humana en un dominio sensible, eso cambia las reglas del juego: el auditor puede mirar la decisión y entender por qué se tomó.

Implicaciones para seguridad

Hay tres razones por las que este tipo de verificación source-aware importa en seguridad y operaciones con IA:

• Ataques de inyección indirecta. Si un documento malicioso contiene un dato y un agente lo adjudica a una fuente legítima, el verificador source-blind pasa. Source-aware lo caza.
• Auditoría y cumplimiento. En sectores como salud, finanzas o legal, poder reconstruir de dónde sacó el agente cada afirmación es un requisito, no un nice-to-have.
• Coste del fallo. Una respuesta plausible con fuente equivocada es peor que una claramente mala: la primera se acepta, la segunda se revisa.

Ya está en producción en un caso real

NVIDIA NVFlow acaba de hacer merge de una etapa opcional de verificación grounded para su agente financiero. El módulo compara las respuestas finales contra los extractos de la SEC que el agente recuperó y guarda las decisiones de forma separada, sin tocar los datos de rollout ni de entrenamiento originales. Es la primera vez que la idea de ProvenanceGuard aterriza en código de producción de un actor grande, y muestra que la verificación source-aware se está moviendo del paper al pipeline.

Limitaciones honestas

El propio paper señala los puntos débiles:

• Cuando las fuentes se parecen mucho entre sí, identificar la correcta cae al 50,3%.
• Es una capa offline, no en línea: añade aproximadamente medio segundo por respuesta con la configuración local reportada.
• La política conservadora envía a revisión muchas afirmaciones soportadas, lo que aumenta la carga de revisión humana.

Conclusión

ProvenanceGuard no es un modelo nuevo. Es un cambio de pregunta. En lugar de ¿la respuesta es verdadera?, pregunta ¿la respuesta es verdadera Y la fuente que dice tener es la fuente correcta? Es una distinción pequeña en el papel y enorme en producción. Si trabajas con agentes MCP en cualquier dominio donde la atribución de la fuente importa — finanzas, salud, legal, soporte crítico — vale la pena leer el paper y probar la implementación.

El paper completo está en Hugging Face (huggingface.co/papers/2606.18037) y en arXiv (2606.18037). El código, en el repositorio aalvsz/provenanceguard en GitHub.