Vercel eve: sandboxing i aprovacions per a agents d'IA

Vercel va presentar eve com a framework open-source per construir agents d'IA que executen accions reals sobre sistemes reals: escriure codi, cridar APIs, modificar bases de dades, desplegar serveis. La peça que el diferencia d'un SDK d'agents genèric és que resol de fàbrica dos problemes que gairebé cap equip intern resol bé pel seu compte: on corre l'agent quan executa alguna cosa (sandboxing) i qui decideix si una acció s'executa de veritat (aprovacions). La majoria d'automatitzacions amb IA que hem auditat en pimes espanyoles no tenen cap de les dues coses: l'agent corre amb les mateixes credencials que un desenvolupador senior i executa el que decideix sense que ningú ho revisi abans. Això funciona bé el 95% del temps, fins que l'agent interpreta malament una instrucció ambigua i esborra una taula, envia centenars d'emails de prova a clients reals o fa push directe a producció. No cal adoptar eve literalment perquè això serveixi d'alguna cosa: el que cal copiar és el patró, no l'eina.

El sandboxing aïlla l'entorn d'execució de l'agent —normalment un contenidor o microVM efímera que es destrueix en acabar la tasca— perquè un error de codi, un bucle infinit o un intent d'escalada de privilegis no toquin el sistema host ni altres processos. És la mateixa lògica que apliquem des de fa anys en pentest amb entorns rebutjables: si alguna cosa surt malament, es llença l'entorn i no ha passat res greu. El problema és que aquest aïllament no protegeix res fora del propi procés: si l'agent té una API key d'un CRM, un token de Slack o accés a una passarel·la de pagament, pot causar dany real i completament legítim des de dins de la sandbox. El contenidor pot estar perfectament aïllat i tot i així l'agent cobrar de més a un client, esborrar un canal sencer de Slack o llançar una campanya d'email a tota la base de dades. Aquí és on entra la segona peça —l'aprovació—, que no protegeix el sistema operatiu sinó les conseqüències del costat del negoci.

Què és realment una aprovació en aquests frameworks

Una aprovació ben dissenyada no és un pop-up genèric de 'estàs segur?': és un punt d'interrupció síncron que pausa l'execució de l'agent just abans d'una acció classificada com a irreversible o d'alt impacte, mostra el payload exacte que s'executarà i espera una confirmació humana explícita abans de continuar. La clau tècnica és que la classificació de quines accions requereixen aprovació no la decideix l'agent en temps real —seria com deixar la guineu decidir si entra al galliner—, sinó una política fixa definida per qui desplega el sistema. Llegir dades, generar un esborrany o consultar una API no necessita aprovació; esborrar registres, enviar comunicacions externes o modificar configuració de producció, sí. Aquest registre de decisions, a més, queda auditat: qui va aprovar quina acció, quan i amb quina justificació, cosa que en més d'una auditoria RGPD ens ha ajudat a demostrar control humà efectiu sobre el tractament automatitzat de dades.

Dels 12 projectes d'automatització amb agents d'IA que hem desplegat per a pimes catalanes en el primer semestre de 2026, en 9 el client no tenia definida cap llista de quines accions requerien aprovació humana abans de començar a treballar plegats —simplement no s'ho havien plantejat perquè l'agent 'de moment només feia coses petites'—. El patró es repeteix: es comença amb un agent que redacta esborranys o classifica tiquets, funciona bé, se li van donant més permisos sense revisar els anteriors, i en qüestió de mesos té accés d'escriptura a sistemes que ningú recorda haver autoritzat formalment. No cal el framework de Vercel per arreglar això. Cal, com a mínim, separar les credencials de l'agent de les credencials humanes amb permisos acotats per rol, definir per escrit quin tipus d'acció exigeix un OK humà abans d'executar-se, i registrar aquesta aprovació en un lloc que no sigui el xat de Slack que es perd en el scroll al cap de dues setmanes.

• Auditar quines credencials fa servir cada agent actiu i si tenen permisos superiors als necessaris
• Classificar per escrit les accions de l'agent en 'automàtiques', 'requereixen aprovació' i 'prohibides'
• Executar l'agent en un entorn aïllat (contenidor, sandbox o compte de servei separat) de la resta de la infraestructura
• Registrar cada aprovació humana amb qui, quan i per què — no en un xat efímer
• Revisar trimestralment si els permisos concedits continuen sent necessaris

On no compensa muntar aquesta infraestructura

Aquí ve la part que no tots els proveïdors de serveis d'IA diuen en veu alta: si la teva automatització interna són tres fluxos que llegeixen dades i generen un informe en PDF, muntar sandboxing dedicat i un sistema d'aprovacions amb auditoria és sobreenginyeria que costa més manteniment del que estalvia. La governança d'agents té sentit quan l'agent pot escriure, esborrar o comunicar cap a fora —no quan només llegeix i resumeix—. Nosaltres mateixos, en diversos projectes, hem recomanat al client NO afegir encara aquesta capa i esperar que l'agent passi de 'llegeix i suggereix' a 'executa directament', perquè construir la infraestructura de control abans de necessitar-la sol quedar obsoleta o mal calibrada quan finalment fa falta. La pregunta correcta no és 'tenim sandboxing i aprovacions?' sinó 'què pot fer el nostre agent avui que un humà no podria desfer en cinc minuts?'.

La majoria d'incidents amb agents d'IA que hem vist no venen de què la IA 'es tornés boja' — venen de permisos que ningú va revisar des del dia que se'ls van donar.

• L'agent té credencials amb permisos d'escriptura en producció, no només de lectura
• L'agent pot comunicar-se amb clients o tercers sense revisió prèvia (email, WhatsApp, tiquets)
• L'agent gestiona dades personals o financeres subjectes al RGPD
• Ningú de l'equip pot dir, sense mirar el codi, quines accions pot executar l'agent sense supervisió