Por qué la privacidad de un agente no se protege en la respuesta final

¿De qué se trata?

Cuando un modelo de lenguaje era solo un chatbot, la privacidad tenía un único punto de aplicación: la respuesta final. Se filtraba lo que el modelo estaba a punto de decir, y esa era la superficie a defender. Ese esquema ya no describe cómo se despliegan estos sistemas. Un agente LLM traduce hoy una petición en una consulta a una base de datos, recupera pasajes de una colección de documentos privados, cruza resultados de varias fuentes, escribe hallazgos intermedios en memoria y actúa sobre el resultado, a menudo con permisos delegados más amplios de los que exige la tarea concreta.

Un estudio publicado en arXiv el 25 de junio de 2026 por Nada Lahjouji y Ashwin Gerard Colaco (University of California, Irvine) — «Agents That Know Too Much» — plantea la idea central con precisión: para lo que los autores llaman un data agent, la privacidad no es una propiedad de una salida aislada. Es una propiedad de una ejecución que abarca fuentes de datos, canales intermedios, memoria y acciones. Los autores revisan un campo activo pero disperso — generación aumentada por recuperación (RAG), text-to-SQL, memoria de agente, inyección de prompts, control de acceso — y lo reorganizan en torno a los datos que el agente manipula, no por tipo de ataque.

Cómo funciona

La idea rectora es que un data agent elimina el punto de aplicación único por cinco razones estructurales, cada una de las cuales abre un canal donde la información sensible puede filtrarse antes incluso de producir una respuesta.

Primero, el agente toca simultáneamente muchas fuentes heterogéneas — bases relacionales, índices vectoriales sobre documentos privados, archivos, API externas y su propia memoria —, cada una exponiendo los datos de forma distinta. Segundo, ejecuta flujos de trabajo multipaso en los que la información sensible transita por artefactos intermedios: el SQL generado, las filas recuperadas, los argumentos pasados a una herramienta, el texto escrito en un bloc de notas. Cualquiera de ellos puede exponer datos mucho antes de la respuesta visible para el usuario. Tercero, conserva un estado persistente: un dato escrito en memoria en una sesión puede reaparecer en otra, potencialmente para un usuario distinto. Cuarto, actúa con autoridad delegada, con frecuencia con permisos más amplios de los que requiere la petición en curso, de modo que un agente desviado o comprometido puede alcanzar mucho más de lo que debería. Quinto, cada transformación protectora se paga en utilidad: cuanto más redacta o retiene el agente, menos útiles son sus respuestas, y esa tensión debe gestionarse de forma continua en lugar de resolverse una sola vez.

Dos hallazgos se repiten en el estudio. Entre los mecanismos de gobernanza, solo el control de flujo de información (information-flow control) cubre a la vez la filtración composicional (datos sensibles reconstruidos a través de varios pasos inocuos) y la filtración por inferencia entre sesiones, y esos son los dos riesgos menos protegidos en la literatura actual. Y ningún benchmark existente recorre con un agente todas sus superficies de datos bajo una única política de privacidad, lo que los autores identifican como el instrumento que más le falta al campo.

Por qué importa

Es el mismo problema estructural que la «lethal trifecta» descrita por Simon Willison desde el lado de la exfiltración — acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse hacia el exterior —, pero visto desde la superficie de datos y no desde el ataque. Los agentes de analítica empresarial sobre almacenes de datos, los asistentes clínicos que leen historiales de pacientes y los asistentes personales que leen el correo y los archivos de un usuario comparten esta propiedad: el canal de filtración es la ejecución, no la respuesta. Un equipo que solo endurece el filtro de salida defiende un canal de cinco.

La salvedad honesta: se trata de un estudio, no de una nueva defensa ni de una vulnerabilidad medida. Su valor es el mapa: una taxonomía compartida que vincula cada superficie con su riesgo, y un enunciado explícito de las zonas mal cubiertas. No entrega un control listo para desplegar, y sus veredictos de «riesgo menos protegido» son juicios sobre el estado de la literatura a mediados de 2026, no cifras de benchmark.

Defensas

La conclusión accionable: tratar cada superficie de datos que el agente toca como un punto de aplicación, no solo la respuesta final. Aplique el mínimo privilegio en la frontera herramienta/datos para que el agente solo posea los permisos necesarios para la tarea en curso, con granularidad de tarea en lugar de sesión. Aísle la memoria por usuario y por finalidad para que un estado escrito en una sesión no reaparezca en otra, y hágala expirar de forma deliberada. Restrinja y registre los canales intermedios — consultas generadas, filas recuperadas, argumentos de herramientas —, porque ahí es donde se acumulan las filtraciones composicionales antes de que un filtro de salida las vea.

Cuando sea posible, prefiera el control de flujo de información a las comprobaciones puntuales: el hallazgo recurrente del estudio es que es el único mecanismo que cubre a la vez la filtración composicional y la que ocurre entre sesiones, los dos puntos ciegos de la mayoría de las defensas. Y considere la ausencia de un benchmark entre superficies como una carencia de pruebas que le corresponde a usted: construya casos de red team que hagan recorrer a un agente base de datos, recuperación, memoria y mensajería entre agentes bajo una única política, en lugar de probar cada superficie por separado.

Estado

Se trata de un estudio de investigación, no de una vulnerabilidad de producto con identificador asignado.

Elemento	Detalle
Fuente	«Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents» (arXiv:2606.26627)
Afiliación	University of California, Irvine
Publicación	25 de junio de 2026
Tipo	Estudio / taxonomía (privacidad centrada en datos)
Alcance	RAG, text-to-SQL, memoria de agente, inyección de prompts, control de acceso, integridad contextual
Carencias señaladas	El control de flujo de información es el único mecanismo que cubre la filtración composicional y entre sesiones; ningún benchmark recorre todas las superficies bajo una política única
Estado	Síntesis de investigación; ningún control o exploit aislado

La fuente principal es de los últimos 30 días. La lección supera al estudio: para un agente que lee datos y actúa sobre ellos, la privacidad se protege a lo largo de todo el camino de ejecución — la consulta, la recuperación, la memoria, la transferencia — y no en la frase que finalmente imprime.