ProvenanceGuard verifica si un agente MCP atribuye cada dato a la fuente correcta

Un agente que usa herramientas a través del Model Context Protocol ya no lee un único pasaje recuperado. Llama a un buscador, consulta el registro estructurado de un paciente o de una cuenta, pregunta a una base de datos y lo pega todo en una respuesta. Los verificadores de factualidad al uso, desde la fidelidad de RAGAS hasta comprobadores como MiniCheck, AlignScore o SummaC, miran si la afirmación está respaldada por la evidencia disponible una vez que esa evidencia se ha juntado. Lo que no dicen es qué salida de herramienta respalda cada afirmación, ni si esa es la fuente que la respuesta nombra.

El artículo ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents ataca ese hueco. El fallo que persigue tiene nombre: conflación entre fuentes, una afirmación que es cierta en algún punto de la evidencia pero que se atribuye a la fuente equivocada. El ejemplo es del propio trabajo. Un agente de soporte responde que, según el registro de la cuenta, el plan incluye 30 días de devolución. La ventana puede ser real, pero está en un documento de política, no en el registro que la respuesta señala. Si juntas ambos, la afirmación parece respaldada. Si los mantienes separados, la atribución es falsa. En un entorno sensible, una atribución errónea hace tanto daño como un dato erróneo.

Cómo funciona

ProvenanceGuard es una capa de verificación posterior a la generación que se coloca encima de un agente MCP tratado como caja negra. No reentrena nada: lee la traza capturada de las llamadas, con las salidas de cada herramienta y sus identificadores de fuente, y nunca colapsa la evidencia en un contexto anónimo. A partir de ahí hace cinco cosas en secuencia: parte la respuesta en afirmaciones concretas, localiza la fuente más relevante para cada una, comprueba si esa fuente la respalda de verdad, compara la fuente con la que la respuesta nombra o da a entender, y emite un veredicto por afirmación más una decisión global de permitir o bloquear.

En los experimentos del artículo todo corre en local: MiniLM busca la fuente, un verificador NLI basado en DeBERTa comprueba el respaldo y un modelo local trocea la respuesta en afirmaciones. Los autores insisten en que esa elección es la configuración que evaluaron, no un requisito; la misma secuencia se puede adaptar a modelos en la nube, aunque cada montaje necesita su propia calibración. La capa también vigila valores literales: un número, una fecha o un identificador que no aparezca en la fuente no pasa por sonar plausible. Si una respuesta se bloquea, un paso de reparación al estilo RARR intenta reescribirla con apoyo en la fuente y el verificador la revisa otra vez.

Resultados

La prueba se hizo con respuestas de un agente médico que había usado historiales de pacientes, artículos de investigación y otras herramientas: 281 trazas reales. Sobre 361 afirmaciones de 40 respuestas reservadas, los expertos humanos marcaron 139 como no válidas y el sistema cazó 138. Se le escapó una. Además retuvo 67 afirmaciones que los expertos consideraban respaldadas y las mandó a revisión o reparación, un sesgo conservador deliberado. Cuando la afirmación tenía una fuente identificable, acertó con la correcta en torno al 86% de los casos. Frente a otros cuatro comprobadores de respaldo, quedó arriba en la medida del artículo.

Lo relevante no es tanto el resultado como el requisito: ProvenanceGuard necesita que el agente guarde las salidas de sus herramientas y sus identificadores de fuente. Sin esa traza no hay nada que verificar. Para quien construye agentes sobre MCP, eso convierte el registro de procedencia en una decisión de arquitectura y no en un detalle de depuración.