Agents d'IA: tenir permís no vol dir tenir el canvi aprovat

Demanar, aprovar i executar

Un agent d'IA, com una persona dins d'un equip, pot fer tres coses diferents amb un canvi. Demanar-lo és sol·licitar que es modifiqui alguna cosa. Aprovar-lo és decidir que aquell canvi concret es pot fer. Executar-lo és escriure'l de debò al fitxer o a la configuració.

El permís respon a la pregunta de qui pot executar canvis en un recurs; l'aprovació, a la de si un canvi concret s'ha de fer. Quan aquestes dues decisions recauen en actors diferents i un d'ells falta, apareix una drecera: executar amb permís, però sense aprovació.

Ajudar també pot saltar-se les normes

La idea ve d'un preprint signat per Moumita Choudhury, Amit Sarker i Shlomo Zilberstein, de la University of Massachusetts Amherst, una universitat pública de Massachusetts. La primera versió és del 22 d'octubre de 2026.

Segons Moumita Choudhury, Amit Sarker i Shlomo Zilberstein, el risc no apareix només quan un agent és maliciós, sinó també quan simplement intenta ajudar. Agents amb objectius separats poden cooperar de manera espontània i saltar-se el flux de treball previst sense sortir dels seus permisos locals.

L'exemple que proposen, segons Moumita Choudhury i els seus coautors, és senzill. Alice necessita un canvi en un fitxer que pertany a Bob, de manera que no el pot tocar i ha de passar pel revisor. Si el revisor no està disponible, aquest camí queda bloquejat, però Bob conserva l'autoritat per modificar el fitxer i pot fer el canvi en nom d'Alice. No vulnera cap permís: se salta la revisió. Aquesta acció fora del flux l'anomenen favor.

Tres papers amb regles escrites

L'experiment trasllada aquest exemple a un cas petit amb actors programats que reprodueixen els seus dos papers: Alice, que necessita el canvi, i Bob, propietari del fitxer de configuració. El revisor també és un actor programat. És una simulació didàctica local i determinista, sense crides a models ni a xarxa: no és un benchmark de models de llenguatge.

La taula resumeix el paper que la matriu assigna a cada actor: qui pot demanar, aprovar o escriure. Aquests papers estan declarats en el mateix programa i no són permisos del sistema operatiu. La comprovació que el codi fa contra la matriu és a la funció d'escriptura: abans d'escriure a la configuració del propietari, mira si l'actor té aquest recurs a la seva llista d'escriptura i, si no el té, registra el permís denegat i llança un error de permís. Per això, quan el sol·licitant intenta escriure-hi directament, la configuració queda igual que la base.

Quan falta el revisor, el programa aplica una de dues polítiques escrites. En la primera, Alice demana un favor al propietari del fitxer, Bob, i és ell qui escriu el canvi sense revisió. La segona exigeix revisió: el canvi queda en espera fins que hi hagi revisor.

Un canvi innocu i un altre d'incompatible

La configuració de partida té dos valors: un prefix de prova, LAB-, i una moneda, EUR. Alice demana un de dos canvis. El segur canvia el prefix a DEMO- sense tocar la moneda. L'incompatible canvia la moneda de EUR a USD, que un altre consumidor espera en EUR.

El revisor simulat només aprova els canvis que conserven EUR. El consumidor dependent representa aquest altre procés: després de cada cas, comprova que la moneda final continuï sent EUR.

Vuit casos, una sola fallada

Si es combinen les dues polítiques, el revisor present o absent i els dos canvis, en surten 8 casos. En tots, l'intent d'Alice d'escriure directament a la configuració de Bob queda bloquejat: la funció d'escriptura registra el permís denegat i, just després d'aquest intent, el fitxer conserva els valors de la base. El que passa a continuació, inclòs un possible favor de Bob, ja depèn de la política i de si el revisor està disponible.

Mentre el revisor està disponible, les dues polítiques es comporten igual: el revisor només aprova si la moneda continua sent EUR, de manera que el canvi de prefix tira endavant i el de moneda es rebutja. La diferència apareix quan falta el revisor. Amb la política del favor, el propietari escriu el canvi sense que ningú el revisi, i n'hi ha prou que la petició sigui el pas a USD perquè el consumidor que espera EUR falli. Amb la revisió obligatòria, en canvi, la petició queda en espera fins que hi hagi revisor, i la configuració compartida no es toca.

Repeteix-ho al teu ordinador

L'script, favores_agentes.py, no necessita connexió ni models. Per repetir-lo, n'hi ha prou de desar-lo en una carpeta nova i executar python3 favores_agentes.py. Tot el que escriu queda al costat de l'script, dins de la seva carpeta de sortida.

La carpeta de sortida no pot existir abans, així que una segona execució necessita una altra carpeta nova: el programa no sobreescriu resultats. En acabar, desa a results.json cada cas amb el seu registre d'esdeveniments i una empremta del fitxer de configuració abans i després.

Segons Twin Force, l'empresa titular d'aquest web, dues execucions en carpetes noves van donar els mateixos vuit casos i resums; només van canviar les marques horàries d'execució.

Què ensenya l'experiment

Bob no perd mai el permís d'escriptura, i per això el favor funciona: executa un canvi que ningú no ha aprovat. El permís sobre el recurs es respecta; el flux de treball, no. I qui paga la drecera pot ser un tercer, com el consumidor que esperava EUR.

La lliçó pràctica és que la comprovació d'aprovació també ha de ser a la ruta del favor, no només a la porta principal. Si falta la revisió, el més prudent és deixar el canvi en espera, com fa la política de revisió obligatòria. No és una garantia universal: és la regla que va evitar la fallada en aquest cas petit.