Blanqueo de causalidad: cuando una llamada de herramienta denegada igual filtra datos

¿Qué es esto?

En abril de 2026, el investigador independiente Mohammad Hossein Chinaei publicó Causality Laundering: Denial-Feedback Leakage in Tool-Calling LLM Agents (arXiv 2604.04035). El artículo nombra un punto ciego compartido por la mayoría de las defensas en tiempo de ejecución para agentes con herramientas: la suposición implícita de que una vez denegada una llamada de herramienta, la amenaza ha terminado. Chinaei sostiene lo contrario. Una acción denegada no produce datos, pero sigue siendo un evento observable: lo que el agente infiere de esa denegación puede exfiltrarse después mediante una llamada de herramienta de apariencia inocua.

El autor llama a este patrón blanqueo de causalidad y propone una defensa —el Agentic Reference Monitor (ARM)— que trata las acciones denegadas como eventos de procedencia de primera clase. Es un estudio de arquitectura controlado, no el reporte de un exploit observado en producción, pero formaliza una superficie de ataque que el rastreo de taint plano y las defensas por flujo de datos no modelan actualmente.

Cómo funciona

Considere un agente con las herramientas read_file y send_email. Una carga de inyección de prompt oculta en contenido no confiable (un correo envenenado, una página web extraída) le ordena al agente exfiltrar /etc/shadow. El motor de políticas deniega correctamente la llamada read_file("/etc/shadow"): no se devuelve ningún byte sensible.

Un sistema de rastreo de taint plano da el ataque por bloqueado. Pero el agente aún puede inferir que el archivo existe si el motivo de la denegación es «permiso denegado» en vez de «archivo no encontrado». La carga le indica entonces llamar a send_email(body="[REDACTED: un hecho inferido de la denegación]") hacia una dirección externa. Para una defensa por flujo de datos, esa segunda llamada parece inocua: no lleva bytes contaminados, no coincide con ningún valor sensible devuelto por una herramienta y no tiene linaje que la conecte con la lectura denegada. Sin embargo, transmite información derivada del bloqueo.

El artículo formaliza el patrón: una acción denegada a_d es seguida por una acción con efecto secundario a_s, ningún camino exitoso de flujo de datos las conecta, pero a_s está causalmente influida por la denegación: el agente se habría comportado de otra forma sin el bloqueo. Dos amplificaciones lo empeoran. En el fingerprinting multi-sonda, el atacante emite muchas sondas y exfiltra el vector de veredictos permitir/denegar para mapear una configuración de control de acceso; cada denegación filtra poco, la secuencia filtra mucho. En la composición blanqueada, una herramienta intermedia permitida (una calculadora, un formateador) recodifica la señal de denegación para que ya no correlacione textualmente con la llamada bloqueada.

No es algo puramente teórico. El artículo cita resultados recientes (Jiralerspong, Kondrup y Bengio, marzo de 2026) que muestran que agentes de vanguardia pueden inferir la presencia de monitoreo oculto solo a partir de la señal de bloqueo, aunque nunca se les haya dicho que hay monitoreo.

Por qué importa

Tres clases de defensa en tiempo de ejecución pierden este canal por construcción. El rastreo de flujo de información plano (p. ej. FIDES) propaga etiquetas solo a través de salidas exitosas de herramientas: una llamada denegada no produce ninguna que etiquetar. Los grafos de dependencias sobre ejecuciones exitosas no registran ningún nodo para una acción bloqueada, así que no hay arista entre la lectura denegada y el envío posterior. Las defensas por atribución causal con repetición ablacionan el contenido controlado por el atacante, mientras que aquí la señal disparadora la genera la propia capa de aplicación, no una entrada externa.

La conclusión práctica: un veredicto «denegado» no es una parada limpia. Si su modelo de amenazas considera neutralizadas las acciones bloqueadas, tiene un canal lateral sin medir. A medida que los agentes operan más tiempo y con más autonomía, el número de eventos de denegación —y la información que codifican— crece.

Defensas

ARM es una capa de aplicación que se interpone en la frontera de las llamadas de herramientas (descrita como un proxy MCP, pero aplicable a cualquier runtime de llamadas de herramientas centralizado). Sus principios de diseño se generalizan más allá del prototipo:

1. Hacer de las acciones denegadas objetos de primera clase. Registrar cada DENY como un nodo del grafo de procedencia y añadir aristas contrafácticas hacia las acciones posteriores que pudieran haber sido influidas por él. Una llamada hacia un sumidero alcanzable desde un nodo de denegación hereda ese contexto de seguridad y puede a su vez bloquearse. Esta es la defensa central contra el blanqueo de causalidad.

2. Propagar la confianza mediante un retículo de integridad. ARM ordena las fuentes ToolDesc < ToolUntrusted < ToolTrusted < UserInput < SysInstr y asigna a todo dato derivado el mínimo de la confianza de sus fuentes. Combinado con procedencia a nivel de campo, esto detiene los abusos de procedencia mixta donde un objeto confiable cuela un único campo no confiable (p. ej. una dirección de correo controlada por el atacante dentro de una ficha de contacto por lo demás confiable).

3. Mantener una aplicación determinista. Todas las decisiones son recorridos de grafo y reglas explícitas: ninguna llamada extra al LLM juzga al agente bajo escrutinio. El prototipo ejecuta el grafo sobre un backend rustworkx con latencia submilisegundo (despreciable frente a 100 ms–10 s de inferencia) en ~910 líneas de Python.

4. Estratificarlo y registrarlo. ARM apila una capa de frontera dura, la capa de procedencia, una capa de esquema y un token de capacidad inmutable (congelado al iniciar la sesión, atenuable pero nunca amplificable). Cada veredicto se escribe en un registro de auditoría encadenado por hash, lo que hace detectable cualquier manipulación.

5. Combinarlo con prevención. ARM limita el daño una vez que la inyección tiene éxito; complementa, sin reemplazarlas, defensas de diseño como CaMeL, la jerarquía de instrucciones y la disciplina del trío letal de nunca reunir datos privados, entrada no confiable y un sumidero de exfiltración. Trate la procedencia sensible a denegaciones como una capa más, no como una solución milagrosa.

Estado

Elemento	Referencia	Fecha	Notas
Artículo Causality Laundering (arXiv 2604.04035)	arXiv	2026-04	Nombra la clase de ataque; propone la defensa ARM
Evaluación de ARM	ídem	2026-04	Diferencial controlado en 3 escenarios; la capa orientada a grafo bloquea los tres que una base plana pierde
Corroboración (arXiv 2603.16928)	arXiv	2026-03	Los agentes infieren monitoreo oculto solo a partir de la señal de bloqueo
Madurez	—	—	Estudio de arquitectura; escenarios manuales, aún sin banco de pruebas con LLM de vanguardia en el bucle

La lectura correcta no es «los veredictos de denegación son inútiles». Es que un bloqueo es un evento, no un borrado — y toda arquitectura de agente que olvida la denegación que acaba de emitir deja abierto, tras de sí, el canal de inferencia.