Loopjacking: cuando la operación aprobada no es la que se ejecuta

¿De qué se trata?

La aprobación humana —el human-in-the-loop— es el control al que todo el mundo recurre. Cuando un agente está a punto de transferir dinero, borrar un bucket o ejecutar un comando de shell, la respuesta aceptada es: muéstreselo a una persona y espere su clic. Un artículo enviado a arXiv el 17 de septiembre de 2026 y anunciado en el listado cs.CR del 21 de septiembre de 2026 —Loopjacking: Hijacking Human-in-the-Loop Approval (arXiv:2609.21081), de Adithyan Arun Kumar— plantea la pregunta siguiente: ¿es la operación que revisó una persona la misma que el sistema ejecuta después?

En varios productos de agentes ya publicados, según informa el autor, no lo es. El artículo denomina a esta clase de fallo Loopjacking: una persona aprueba lo que entiende como la operación A, mientras la lógica del producto emplea esa decisión para autorizar una operación B materialmente distinta. La aprobación es real, el clic es auténtico, el registro de auditoría dice que un humano aceptó — y el efecto que llega al punto de ejecución es otro.

Cómo funciona

El artículo enuncia un invariante de vinculación de aprobación: una decisión solo puede autorizar una operación cuando la operación completa evaluada en el momento de uso es materialmente equivalente a la que la persona revisó, y mientras la decisión siga siendo válida para el principal, la tarea y el alcance actuales. «Operación completa» significa la acción, cada argumento material, el recurso de destino, el principal y el alcance de la tarea, y cualquier contexto de ejecución capaz de alterar el efecto. Se distinguen dos formas de romper ese invariante.

• Loopjacking por representación. B ya está codificado en la petición antes de la decisión, pero el producto muestra o canonicaliza un A materialmente incompleto. La aprobación es exacta — para el objeto equivocado. El caso del wrapper de shell lo ilustra con claridad: el evento de aprobación representaba únicamente la carga en línea, mientras que el vector completo de argumentos posicionales, preparado antes de la aprobación, contenía los argumentos adicionales que seleccionaban el comando y el destino reales.
• Sustitución de estado posterior a la aprobación. La persona ve y aprueba exactamente A. Antes de que la decisión se consuma, un actor con una capacidad estrecha de actualización de estado muta la tarea, el hilo o el estado de continuación pendiente hacia B. La ejecución evalúa entonces el B actual conservando la decisión tomada para A.

El modelo de atacante es deliberadamente modesto. Sin control del modelo, sin carrera contra quien aprueba, sin confirmación falsificada: solo autoridad asimétrica —un iniciador de tareas con pocos privilegios, un colaborador de repositorio o un agente remoto capaz de actualizar estado pendiente pero que nunca podría invocar B directamente—. El autor excluye explícitamente los casos en que B se ejecuta antes de cualquier decisión, aquellos en que se omite el diálogo de aprobación y aquellos en que una persona aprueba a sabiendas un B visible. Los experimentos miden la vinculación del sistema, no la susceptibilidad humana: el rol de aprobador está automatizado y solo avanza después de que la prueba ha comprobado y registrado la vista exacta de A en el producto.

Se evaluaron cuatro rutas de producto, como un conjunto deliberado y no como una muestra. La sustitución posterior a la aprobación se reprodujo en siete puntos de versión de Agno AgentOS hasta la 3.0.9, donde una ruta de continuación verifica la identidad de la llamada pero no compara los argumentos actuales de la herramienta con el descriptor del registro aprobado. También se reprodujo en doce versiones de una composición condicional en memoria de LangGraph Agent Server hasta la 0.14.0, a través de la superficie de actualización de comando A2A incluida, bajo una política de autorización en la que un iniciador puede actualizar un hilo pendiente compartido pero no reanudarlo. El desajuste de representación se reprodujo en OpenClaw 2026.2.23 y fue rechazado en la 2026.2.24, que añadió una verificación de consistencia sobre el vector completo de argumentos.

El resultado más útil es el control negativo. El SDK de OpenAI Agents 0.22.0 y 0.22.2 rechazó la mutación en todos los ensayos: la continuación serializada preserva una vinculación exacta por llamada, y una invocación con el mismo identificador modificada hacia B provocó un error, quedando el registro vacío. La continuación y la serialización no son, por sí mismas, la causa del fallo — la vinculación sí lo es.

Por qué importa

La aprobación es el control en el que las organizaciones se apoyan justo cuando lo que está en juego es mayor, y es el único que sobrevive a cualquier modelo de amenaza construido sobre la premisa de que «el modelo puede estar comprometido». El Loopjacking ataca la fontanería situada debajo. Se señalan tres atajos de vinculación como insuficientes: vincular únicamente un identificador de llamada, cuando un reductor puede sustituir los argumentos asociados a ese identificador; vincular únicamente una bandera «aprobado» a nivel de ejecución, cuando una continuación puede instalar una ejecución de herramienta distinta; y comprobar únicamente en el momento de la presentación, cuando el estado puede cambiar antes del despacho. Los tres son habituales, y los tres producen un sistema que parece correcto en una demostración.

Hay un segundo resultado convergente que conviene leer en paralelo. Silence Is Endorsement: Verification-Status Laundering in LLM Agent Pipelines (arXiv:2609.20211), enviado el 25 de julio de 2026 y anunciado en el listado del 18 de septiembre de 2026, examina la misma brecha un nivel más arriba, donde el guardián es un monitor LLM y no una persona. Cuando se elimina la indicación de que una afirmación de autorización estaba sin verificar —por un resumidor, un compresor de memoria, un simple traspaso—, la aprobación de acciones de riesgo pasó, en los experimentos publicados, del 5 % al 60 % en Llama-3.1-8B y del 9 % al 98 % en Qwen2.5-14B, alcanzando un pipeline completo proponente–resumidor–memoria–monitor entre el 57 % y el 81 % en tres monitores posteriores. Instruir explícitamente a los monitores para que rechacen una autorización no verificada no resulta, según el estudio, una corrección fiable entre modelos.

Ambos artículos apuntan en la misma dirección. Las decisiones de autorización en sistemas de agentes circulan hoy como texto y banderas por pipelines con pérdidas, cuando deberían circular como estado estructurado vinculado al efecto exacto.

Defensas

La prescripción del artículo cabe en una regla: conserve la operación que la persona aprobó, reconstruya la operación que realmente se ejecutará y compare sus descriptores canónicos completos en el último punto de autorización — después de todo el parseo, plantillado, reducción de estado, continuación, inserción de valores por defecto, expansión de wrappers y resolución de argumentos.

Haga canónico el registro de aprobación. Debe vincular la identidad de la acción o herramienta y cada argumento material, el recurso de destino y la clase de efecto secundario, el principal iniciador y el alcance de la tarea, el principal que aprueba, un nonce con fecha de creación, caducidad y estado de consumo, y un resumen criptográfico del mismo descriptor completo mostrado a la persona. La visualización debe generarse a partir de ese descriptor, no de una cadena de conveniencia mientras la ejecución usa un objeto más rico.

Haga la comprobación real en el momento de uso, no en el de renderizado. El procedimiento propuesto, justo antes de liberar el efecto: rechazar si la decisión falta, ha caducado, ha sido revocada, consumida o queda fuera de alcance; rechazar o solicitar una nueva aprobación si la operación actual difiere materialmente del descriptor aprobado; reevaluar la política vigente sobre el efecto resuelto; consumir la decisión de forma atómica junto con la liberación del efecto, o registrar un token de commit idempotente que impida la repetición; añadir descriptor aprobado, descriptor actual, decisión y efecto a un registro de auditoría.

Preste atención especial a los wrappers de shell y de comandos. Cargas en línea, argumentos posicionales, cambios de entorno, directorio de trabajo, banderas de intérprete y redirecciones alteran todos el efecto. Una vista condensada puede seguir siendo útil, pero la aprobación debe exponer los campos materiales ocultos o negarse a autorizarlos.

Trate la prevención de mutaciones como profundidad, no como la respuesta. Impedir que un no aprobador actualice un hilo pendiente compartido bloqueó la variante de sustitución de estado en la composición LangGraph evaluada, y merece la pena aplicarlo allí donde los roles de negocio lo permitan. Es específico de la composición y no sustituye a la vinculación exacta a la acción allí donde actualizaciones legítimas, reintentos o migraciones puedan cambiar el estado de la operación.

Pruébelo como regresión en cada versión. Capture la vista de aprobación y la petición completa, mute un campo material a través de cada superficie posterior a la revisión admitida y verifique la operación exacta en el punto de ejecución. Suite mínima: A sin cambios tiene éxito; una denegación no produce efecto; B directo no está disponible para el atacante; una sustitución de A a B se rechaza o se reautoriza; un alcance incorrecto falla; una aprobación consumida o caducada no puede repetirse.

Transporte la procedencia de la autorización como estado estructurado. La conclusión del estudio complementario se aplica tanto a los monitores LLM como a los humanos: si una afirmación fue verificada o no debe viajar adjunto a la afirmación, en un campo que un resumidor no pueda descartar en silencio.

Status

Aspecto	Detalle
Fuente principal	Loopjacking: Hijacking Human-in-the-Loop Approval (arXiv:2609.21081), enviado el 17 de septiembre de 2026, anunciado el 21 de septiembre de 2026
Clase	Fallo de vinculación de aprobación — la decisión no queda ligada a la operación evaluada en el momento de uso
Variantes	Por representación (vista incompleta en la aprobación); sustitución de estado posterior a la aprobación (estado pendiente mutado antes del consumo)
Reproducido	Sustitución posterior a la aprobación: siete puntos de versión de Agno AgentOS hasta 3.0.9; doce versiones de una composición condicional en memoria de LangGraph Agent Server hasta 0.14.0. Desajuste de representación: OpenClaw 2026.2.23
Corregido / rechazado	OpenClaw 2026.2.24 (verificación de consistencia sobre el vector completo de argumentos). SDK de OpenAI Agents 0.22.0 / 0.22.2 como control negativo — mutación rechazada en todos los ensayos
Sin corrección establecida	El artículo indica que no consta ninguna versión corregida de Agno ni versión de LangGraph corregida por el proveedor en su fecha de cierre; el control de acción exacta sobre Agno lo escribió el investigador, y el resultado seguro en LangGraph depende de una política admitida que deniega la actualización
Reservas de alcance	Conjunto deliberado, no aleatorio; resultados específicos de configuración y versión; sin estimación de prevalencia; sin CWE ni CVSS asignados; un solo investigador, sin reproducción independiente; despliegue Postgres de producción no evaluado
Trabajo relacionado	Silence Is Endorsement (arXiv:2609.20211), enviado el 25 de julio de 2026, anunciado el 18 de septiembre de 2026 — la misma brecha de vinculación donde el guardián es un monitor LLM
Cierre del estudio	Evidencias y revisión de fuentes públicas hasta el 10 de septiembre de 2026