Ghost tool calls: la ejecución especulativa de los agentes filtra la intención del usuario

¿Qué es esto?

«Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools» es un artículo publicado en arXiv el 1 de junio de 2026 (2606.02483) por Bardia Mohammadi, Lars Klein, Akhil Arora y Laurent Bindschaedler. Estudia un efecto secundario sobre la privacidad de una optimización de rendimiento que se está generalizando en los runtimes de agentes: la ejecución especulativa de herramientas.

Para ocultar la latencia de un viaje de ida y vuelta a una herramienta, algunos frameworks de agentes predicen las llamadas a herramientas que el modelo probablemente hará a continuación y las despachan por adelantado, en paralelo al razonamiento, antes de que el agente haya confirmado realmente esa rama. La observación del artículo es simple e incómoda: cuando el agente abandona después la rama especulativa, la predicción se descarta — pero no la petición de red que disparó. Los autores llaman a estas invocaciones abandonadas-pero-ya-enviadas ghost tool calls (llamadas fantasma a herramientas).

Cómo funciona

Un despacho especulativo envía argumentos reales a un servicio externo real. Esos argumentos codifican la intención inferida del usuario: qué archivo creía el agente que usted quería, a qué contacto se disponía a escribir, qué consulta iba a lanzar contra una API de terceros. El servicio destinatario recibe y registra esa petición en el instante en que llega.

El hallazgo central: el problema es la temporización, no la autorización. El artículo lo afirma sin rodeos: «ninguna limpieza en el momento del commit, restricción de solo lectura o allow-list de control de acceso deshace lo que un observador ya posee». Una vez que una petición ha llegado a un observador externo, este conserva la divulgación sin importar lo que el agente decida después. Revertir la rama revierte el estado del agente, no los registros del tercero.

Los autores reformulan el problema tratando la observación antes de la confirmación como un efecto de primera clase, distinto de la mutación de estado, y proponen los Speculative Tool Privacy Contracts — una abstracción de runtime que gobierna lo que una llamada especulativa está autorizada a revelar en el momento en que se emite. Lo implementan en un runtime prototipo y evalúan doce políticas en tres corpus.

Los resultados son la parte más útil en la práctica. El despacho especulativo aumenta de forma medible lo que un observador externo puede inferir sobre la intención del usuario en comparación con una ejecución no especulativa. Sobre todo, las defensas a las que los operadores suelen recurrir no ayudan: los filtros a posteriori, las restricciones de solo lectura y las allow-lists de control de acceso dejan esa inferencia intacta, porque actúan después de que los bytes ya están en la red. Solo las políticas en el momento de la emisión — las que alteran o suprimen la proyección de los argumentos o del destino de la llamada especulativa antes del despacho — reducen realmente lo que el observador aprende.

Por qué importa

Es un modo de fallo más silencioso que la prompt injection o el abuso de herramientas, y no requiere ningún atacante dentro de su prompt. El «observador» puede ser simplemente el servicio de terceros ordinario con el que su agente dialoga: una API de búsqueda, un CRM, una pasarela de correo, un servidor de herramientas MCP. Cada rama especulativa que nunca se ejecuta entrega de todos modos a ese servicio una instantánea de lo que su usuario probablemente intentaba hacer.

Esto remite directamente a LLM02:2025 Sensitive Information Disclosure de OWASP (exposición no intencionada de datos de usuario a través del comportamiento dirigido por el modelo) y se ve amplificado por LLM06:2025 Excessive Agency — cuantas más herramientas pueda alcanzar un agente por especulación, más amplio es el conjunto de partes externas que reciben la fuga de intención. Para datos regulados, una consulta especulativa abandonada contra un endpoint externo puede constituir una divulgación notificable, aunque, desde el punto de vista del agente, «no haya pasado nada».

Defensas

La lección central del artículo: no se puede corregir esto después del envío, así que las defensas deben actuar antes en el pipeline.

• Controle la especulación en el momento de la emisión. Aplique el marco del artículo: decida lo que una llamada especulativa puede revelar antes de que abandone el runtime, no después de que se resuelva la rama. Suprima o reescriba la proyección de los argumentos y del destino de las llamadas especulativas de baja confianza.
• No confíe en el rollback ni en las allow-lists para la privacidad. La limpieza en el commit, los modos de solo lectura y las allow-lists de control de acceso son controles de integridad válidos pero, según los resultados, no deshacen en absoluto una divulgación que un observador externo ya ha recibido.
• Reserve la especulación a herramientas de confianza, idempotentes y poco sensibles. Las herramientas locales o de primera parte no filtran a ningún tercero; reserve la pre-emisión especulativa para esas y desactívela para las herramientas que transportan contenido del usuario a endpoints externos.
• Minimice lo que llevan los argumentos especulativos. Envíe valores de marcador de posición o argumentos engrosados de forma especulativa y sustituya los valores reales solo en el commit, de modo que una rama abandonada revele poco.
• Trate el despacho especulativo como un evento registrado y auditable. Aplique el mínimo privilegio de agencia (OWASP LLM06) y registre qué partes externas recibieron llamadas especulativas, para que la fuga de intención sea al menos observable.

Estado

Se trata de investigación académica publicada que describe una debilidad estructural de privacidad en la ejecución especulativa de los agentes y una mitigación de runtime propuesta, no de una vulnerabilidad en un producto concreto con nombre; no hay código de explotación involucrado. Fecha clave: preprint de arXiv 2606.02483, versión 1, enviado el 1 de junio de 2026 (cs.CR / cs.AI / cs.CL). Los Speculative Tool Privacy Contracts descritos son un prototipo de investigación; retenga el principio de mitigación en el momento de la emisión como la enseñanza accionable, más que como una biblioteca lista para usar.