Agentes de IA: tener permiso no equivale a tener el cambio aprobado

Pedir, aprobar y ejecutar

Un agente de IA, como una persona dentro de un equipo, puede hacer tres cosas distintas con un cambio. Pedirlo es solicitar que se modifique algo. Aprobarlo es decidir que ese cambio concreto puede hacerse. Ejecutarlo es escribirlo de verdad en el archivo o en la configuración.

El permiso responde a quién puede ejecutar sobre un recurso; la aprobación, a si un cambio concreto debe hacerse. Cuando esas dos decisiones recaen en actores distintos y uno de ellos falta, aparece un atajo: ejecutar con permiso, pero sin aprobación.

Ayudar también puede saltarse las normas

La idea viene de un preprint firmado por Moumita Choudhury, Amit Sarker y Shlomo Zilberstein, de la University of Massachusetts Amherst, una universidad pública de Massachusetts. Su primera versión es del 22 de octubre de 2026.

Según Moumita Choudhury, Amit Sarker y Shlomo Zilberstein, el riesgo no aparece solo cuando un agente es malicioso, sino también cuando simplemente intenta ayudar. Agentes con objetivos separados pueden cooperar de forma espontánea y saltarse el flujo de trabajo previsto sin salirse de sus permisos locales.

El ejemplo que proponen, según Moumita Choudhury y sus coautores, es sencillo. Alice necesita un cambio en un archivo que pertenece a Bob, así que no puede tocarlo y debe pasar por el revisor. Si el revisor no está disponible, ese camino se bloquea, pero Bob conserva la autoridad para modificar el archivo y puede hacer el cambio en nombre de Alice. No viola ningún permiso: se salta la revisión. A esa acción fuera del flujo la llaman favor.

Tres papeles con reglas escritas

El experimento traslada ese ejemplo a un caso pequeño con actores programados que reproducen sus dos papeles: Alice, que necesita el cambio, y Bob, propietario del archivo de configuración. El revisor también es un actor programado. Es una simulación didáctica local y determinista, sin llamadas a modelos ni a red: no es un benchmark de modelos de lenguaje.

La tabla resume el papel que la matriz asigna a cada actor: quién puede pedir, aprobar o escribir. Esos papeles están declarados en el propio programa y no son permisos del sistema operativo. La comprobación que el código hace contra la matriz está en la función de escritura: antes de escribir en la configuración del propietario, mira si el actor tiene ese recurso en su lista de escritura y, si no lo tiene, registra el permiso denegado y lanza un error de permiso. Por eso, cuando el solicitante intenta escribir directamente, la configuración queda igual que la base.

Cuando falta el revisor, el programa aplica una de dos políticas escritas. En la primera, Alice pide un favor al propietario del archivo, Bob, y es él quien escribe el cambio sin revisión. La segunda exige revisión: el cambio se queda en espera hasta que haya revisor.

Un cambio inocuo y otro incompatible

La configuración de partida tiene dos valores: un prefijo de prueba, LAB-, y una moneda, EUR. Alice pide uno de dos cambios. El seguro cambia el prefijo a DEMO- sin tocar la moneda. El incompatible cambia la moneda de EUR a USD, que otro consumidor espera en EUR.

El revisor simulado solo aprueba los cambios que conservan EUR. El consumidor dependiente representa a ese otro proceso: tras cada caso, comprueba que la moneda final siga siendo EUR.

Ocho casos, un solo fallo

Al combinar las dos políticas, el revisor presente o ausente y los dos cambios salen 8 casos. En todos ellos, el intento de Alice de escribir directamente en la configuración de Bob queda bloqueado: la función de escritura registra el permiso denegado y, justo después de ese intento, el archivo conserva los valores de la base. Lo que ocurre a continuación, incluido un posible favor de Bob, depende ya de la política y de si el revisor está disponible.

Mientras el revisor está disponible, las dos políticas se comportan igual: el revisor solo aprueba si la moneda sigue siendo EUR, así que el cambio de prefijo sale adelante y el de moneda se rechaza. La diferencia aparece cuando falta el revisor. Con la política del favor, el propietario escribe el cambio sin que nadie lo revise, y basta con que la petición sea el paso a USD para que el consumidor que espera EUR falle. Con la revisión obligatoria, en cambio, la petición queda en espera hasta que haya revisor, y la configuración compartida no se toca.

Repetirlo en tu ordenador

El script, favores_agentes.py, no necesita conexión ni modelos. Para repetirlo basta con guardarlo en una carpeta nueva y ejecutar python3 favores_agentes.py. Todo lo que escribe queda junto al script, dentro de su carpeta de salida.

La carpeta de salida no puede existir de antemano, así que una segunda ejecución necesita otra carpeta nueva: el programa no sobrescribe resultados. Al terminar, guarda en results.json cada caso con su registro de eventos y una huella del archivo de configuración antes y después.

Según Twin Force, la empresa titular de esta web, dos ejecuciones en carpetas nuevas dieron los mismos ocho casos y resúmenes; solo cambiaron las marcas horarias de ejecución.

Lo que enseña el experimento

Bob nunca pierde su permiso de escritura, y por eso el favor funciona: ejecuta un cambio que nadie ha aprobado. El permiso sobre el recurso se respeta; el flujo de trabajo, no. Y quien paga el atajo puede ser un tercero, como el consumidor que esperaba EUR.

La lección práctica es que la comprobación de aprobación tiene que estar también en la ruta del favor, no solo en la puerta principal. Si falta la revisión, lo prudente es dejar el cambio en espera, como hace la política de revisión obligatoria. No es una garantía universal: es la regla que evitó el fallo en este caso pequeño.