En el panorama tecnològic actual, els agents d'intel·ligència artificial han passat de ser assistents conversacionals a executors autònoms de tasques complexes. No obstant això, aquesta evolució comporta un repte de seguretat que moltes organitzacions subestimen: un agent amb accés a shell, credencials, capacitat d'instal·lació de paquets, connectivitat de xarxa i eines empresarials es comporta, a la pràctica, com un insider privilegiat. No és un simple procés d'aplicació, sinó una càrrega de treball adaptativa que pot explorar, combinar permisos i buscar camins alternatius per complir el seu objectiu, ja sigui legítim o malinterpretat. L'arquitectura de seguretat ha d'evolucionar cap a un model de confiança zero (zero-trust) que limiti la seva autoritat efectiva al mínim necessari a cada pas.
L'analogia amb un insider humà és útil: tots dos posseeixen eines administratives, accés a múltiples identitats, documentació interna i capacitat d'instal·lar programari. La diferència és que l'agent opera a velocitat màquina, sense fatiga i amb capacitat de reintentar enfocaments fallits una i altra vegada. Si el disseny de seguretat es basa únicament en la descripció de la tasca ('diagnostica aquesta fallada') o en les instruccions del prompt, s'està confiant que el model es comporti exactament segons l'esperat. Però la realitat és que un agent pot interpretar malament el seu objectiu, ser víctima d'injecció de prompts a través de dades no fiables, o descobrir rutes d'autoritat que els dissenyadors no van preveure. Per això, el perímetre de seguretat s'ha de definir per la màxima autoritat que el sistema complet pot exercir, no per la intenció declarada.
Per afrontar aquest repte, cal aplicar un enfocament de seguretat per capacitat (capability-based authorization). En lloc d'assignar un rol genèric com 'operador cloud', s'ha de concedir una capacitat específica: 'llegir la configuració d'aquests tres recursos de desenvolupament durant els pròxims deu minuts a través del broker d'inventari aprovat'. Cada capacitat ha de ser efímera, lligada a una identitat de tasca única, i revocable automàticament en finalitzar. Aquí entra el concepte de identitats de càrrega de treball efímeres (ephemeral workload identities), similars a les que proporciona SPIFFE/SPIRE en entorns Kubernetes. La clau és que l'agent mai tingui credencials ambientals (variables d'entorn, tokens muntats) que pugui enumerar i reutilitzar fora del seu context autoritzat.
Un altre pilar fonamental és l'accés intermediat a eines (brokered tool access). L'agent no s'ha de comunicar directament amb APIs empresarials o sistemes de producció. En lloc seu, envia una sol·licitud estructurada a un broker que valida l'operació contra la política de capacitat de la tasca, obté un token de curta durada, executa l'acció en nom de l'agent i registra tot l'esdeveniment. Això separa la capacitat de decisió (model) de la capacitat d'execució (infraestructura). Per exemple, si l'agent necessita reiniciar un servei, sol·licita l'operació 'restart_service' contra un destí concret, i el broker verifica si aquesta acció està permesa per a aquesta tasca, si hi ha pressupost d'accions disponible, i si requereix aprovació humana.
La xarxa de sortida (network egress) és un dels vectors més crítics. Un agent amb shell però sense connectivitat útil pot estar contingut; un amb accés a la xarxa interna pot convertir-se en una porta d'enllaç per a moviments laterals, exfiltració de dades o control remot. Per tant, la política de xarxa ha de començar amb denegació per defecte i concedir accés només a destinacions, protocols i ports explícitament aprovats, amb una porta d'enllaç autenticada que exigeixi identitat de tasca. També s'ha de controlar DNS per evitar túnels alternatius.
La instal·lació de paquets mereix un tractament especial. Un agent no s'hauria de connectar directament a repositoris públics. En lloc seu, ha de sol·licitar el paquet a un servei de recuperació que verifiqui signatures, digests immutables, procedència i llicències abans de lliurar-lo com a artefacte de només lectura. Això evita que l'agent introdueixi codi nou no revisat. A més, s'han d'establir pressupostos de temps, còmput i accions. Un agent que porta hores executant-se té més oportunitats d'explorar combinacions de permisos i descobrir camins febles. La plataforma ha de fixar un límit màxim de durada, nombre de crides a eines, operacions de shell i reintents. Quan el pressupost s'esgota, la tasca s'ha d'aturar i no prolongar-se silenciosament.
Les aprovacions humanes s'han de reservar per a accions que creuin fronteres de confiança: escriptura en producció, elevació de privilegis, creació de credencials, accés a dades de classificació superior o comunicació amb destinacions externes. Cada sol·licitud d'aprovació ha de mostrar clarament l'operació, el destí, la identitat, les dades afectades i el pla de reversió, i l'aprovació ha d'emetre una nova capacitat temporal, no desactivar la política.
El monitoratge independent és indispensable. L'agent no ha de poder desactivar ni modificar els sistemes que el supervisen. Les traces han d'incloure objectius, sortides del model, sol·licituds d'eines, decisions de política, esdeveniments d'identitat, processos, fitxers, DNS, connexions de xarxa i aprovacions humanes. L'anàlisi s'ha de basar en trajectòries completes, no en esdeveniments aïllats. Un únic llistat de fitxers pot ser normal; una seqüència de llistats seguida d'intents d'accés a canals de credencials pot indicar un comportament maliciós o una desviació de l'objectiu.
A més, es poden desplegar senyals i credencials canari (canary credentials) dins de l'entorn de l'agent. Fitxers amb aparença de token, claus d'API falses o registres de configuració instrumentats que, si són accedits o utilitzats, generen una alerta d'alta confiança. Aquests senyals permeten detectar exploracions de privilegis que les polítiques convencionals no capturarien.
A Q2BSTUDIO, entenem que l'adopció d'agents IA requereix un enfocament de seguretat per capes, similar al que apliquem als nostres projectes de ciberseguretat i cloud. Dissenyem arquitectures que integren brokers d'eines, identitats efímeres, controls de xarxa estrictes i monitoratge continu, adaptant-nos a entorns AWS, Azure i on-premise. La nostra experiència en el desenvolupament d'aplicacions a mida ens permet construir sistemes que maximitzen l'autonomia dels agents sense comprometre la seguretat empresarial. També ajudem a definir polítiques de capacitat i fluxos d'aprovació humana que s'alineen amb els objectius de negoci, garantint que la intel·ligència artificial operi dins dels límits de confiança establerts.
En conclusió, un agent autònom no és una aplicació més. És una càrrega de treball adaptativa que s'ha de tractar com un insider privilegiat les intencions del qual no es poden verificar contínuament. La confiança zero per a càrregues autònomes no és una opció, és una necessitat. En implementar identitats efímeres, accés intermediat, polítiques de capacitat, pressupostos estrictes i aprovacions humanes, les organitzacions poden aprofitar el poder dels agents IA sense exposar-se a riscos que podrien convertir-se en incidents greus. El proper pas és dissenyar un enclavament d'execució que combini tots aquests controls en un servei de plataforma repetible, on cada tasca comença en un entorn net i acaba amb l'autoritat completament revocada.
