Zero Trust per a agents IA: per què les API keys fixes són el risc

Una API key estàtica connectada a un agent d'IA autònom és perillosa perquè no caduca, es propaga per cada log i transcript que l'agent genera sol, i sol donar accés a tot el sistema encara que la tasca real només necessiti llegir una dada. Zero Trust aplicat a agents significa emetre credencials de curta durada, específiques per a cada tasca i verificades a cada crida, en lloc de guardar una clau fixa en un .env que viu mesos sense que ningú la miri.

Un desenvolupador fa servir una API key unes quantes vegades al dia; un agent autònom en fa centenars sense que ningú revisi cap crida abans de sortir cap al proveïdor extern. La clau viu en una variable d'entorn que l'agent pot llegir, imprimir o passar a qualsevol eina que decideixi invocar, fins i tot una shell que ell mateix genera per depurar un error. L'agent no protegeix secrets per instint: els tracta com qualsevol altre string del seu context tret que algú hagi construït explícitament una capa de redacció. Una injecció de prompt o un error de parseig pot filtrar la clau sense cap intenció maliciosa.

El transcript de l'agent és l'endpoint sense protegir que ningú audita

El canal de fuga que gairebé ningú revisa és la plataforma d'observabilitat (LangSmith, Langfuse, Helicone, logs propis), que guarda l'historial complet de peticions, sovint amb les capçaleres HTTP i la clau dins. Aquestes plataformes solen tenir un control d'accés molt més laxe que el gestor de secrets original. A més, quan alguna cosa falla, algú copia el traceback de l'agent i el enganxa en un tiquet o un canal de Slack, i aquest traceback pot contenir la clau en text pla.

La política de rotació trimestral està pensada per a un ritme humà. Un agent opera a un ritme molt diferent: si la clau es filtra en la crida número quaranta del dia, segueix sent vàlida fins la propera rotació programada. La finestra d'exposició real es mesura en la durada d'una sessió o d'una sola tasca, no en mesos. La solució no és rotar més ràpid, és que la credencial caduqui sola en minuts.

El marc Zero Trust Architecture del NIST (SP 800-207, 2020) parteix d'un principi simple: no confiar mai per defecte, verificar cada petició de forma independent. Aplicat a un agent, la unitat de confiança hauria de ser cada crida individual a cada eina, no la sessió completa.

Identitat de càrrega de treball en lloc de secrets estàtics

L'alternativa tècnica real és el workload identity: l'agent s'autentica com ell mateix mitjançant un token signat i de curta durada. AWS STS AssumeRole, Workload Identity Federation de Google Cloud o Managed Identity d'Azure ja ho permeten. El límit honest és que moltes APIs de tercers encara només ofereixen API keys clàssiques.

Muntar un stack complet de Zero Trust és desproporcionat per a una pime amb un agent que només llegeix dades i té un radi d'impacte baix. Una clau de només lectura, amb una llista d'endpoints permesos i alertes de volum anòmal, sol ser suficient. El Zero Trust complet es justifica quan l'agent té permisos d'escriptura o toca dades financeres.

La pregunta que importa no és «quina API key li dono a l'agent», és «què pot fer algú amb aquesta clau si la troba dins d'un log d'aquí tres mesos».

• Inventariar quines credencials té cada agent actiu i què pot fer realment amb elles
• Substituir claus estàtiques per tokens de curta durada quan el proveïdor ho permeti
• Aplicar permisos de mínim abast per tasca, no un rol ampli per servei complet
• Treure els logs de l'agent del mateix nivell d'exposició que la clau original
• Configurar alertes de volum anòmal de crides, no només de fallades d'autenticació
• Revisar qui pot llegir l'historial complet de converses de l'agent