Qualche settimana fa, durante una call con il CTO di una media azienda manifatturiera, ho visto qualcosa che mi ha fatto fermare un attimo. Sul suo schermo c’era un file .env aperto. Dentro, in chiaro, la password dell’account Microsoft 365 del CEO. Accanto, le API keys di Salesforce con permessi di scrittura su tutto il pipeline commerciale. Sotto, un token di accesso all’ERP con privilegi amministrativi.
“Serve all’agente per fare le cose,” mi ha detto, con quella tranquillità che hanno le persone che non hanno ancora capito bene cosa sta succedendo. L’agente in questione era uno script Python che girava su un Mac Mini in ufficio, lanciato da un launchd job, e aveva il compito di sincronizzare email, aggiornare opportunità commerciali e generare report settimanali.
Quel file .env era letteralmente le chiavi del regno, in plain text, su una macchina che non aveva neanche il disco cifrato.
Questa non è una storia isolata. È quello che sta succedendo in centinaia di aziende proprio adesso, mentre tutti corrono a implementare agenti AI per automatizzare processi. E il problema non è tecnologico. È culturale, architetturale, e affonda le radici in un’abitudine che ci portiamo dietro da vent’anni di scripting: dare a un processo automatico tutti i permessi che gli servono, più un po’, giusto per stare tranquilli.
Il problema non è l’AI, è come la integriamo
Prima di tutto, mettiamo una cosa in chiaro. Un agente AI che gira in locale e accede alla tua email non è intrinsecamente pericoloso. Il pericolo nasce dal modo in cui gli diamo i permessi.
Quando uno sviluppatore scrive un’integrazione tradizionale, tipicamente crea un service account dedicato, con un ruolo limitato, log di audit attivi, e un processo di rotazione delle credenziali almeno annuale. Non sempre succede, ma è la prassi per chi fa le cose per bene.
Con gli agenti AI sta emergendo un pattern diverso. Lo sviluppatore (o, peggio, il business owner che segue un tutorial) prende le proprie credenziali personali, le infila in un file di configurazione, e lancia l’agente. Funziona. Fa quello che deve fare. E nessuno si pone il problema di cosa succede se quell’agente sbaglia, se viene compromesso, se qualcuno accede alla macchina su cui gira.
Il risultato è che oggi abbiamo agenti AI con permessi di account umani, spesso di ruoli senior, che girano su macchine mal configurate, senza monitoring, senza limiti di rate, senza circuit breaker. E tutti si stupiscono quando succede qualcosa.
Cosa può andare storto
Proviamo a essere concreti. Ho visto questi scenari nell’ultimo anno, e nessuno è un esperimento teorico.
Il prompt injection via email
Un agente AI di customer support leggeva le email in arrivo, le classificava, e per alcune categorie rispondeva in autonomia. Usava le credenziali OAuth del responsabile del servizio clienti. Un attaccante ha inviato un’email con un payload di prompt injection nel corpo, istruendo l’agente a cercare nelle email passate qualsiasi messaggio con allegato contenente “contratto” e inoltrarlo a un indirizzo esterno. L’agente ha eseguito. Non ha trovato nulla di critico per fortuna, ma il meccanismo ha funzionato perfettamente. La fuga è stata rilevata solo perché qualcuno ha notato email inviate a orari strani.
Il workflow ricorsivo
Un agente di automazione commerciale aveva accesso in scrittura al CRM. Doveva creare task di follow-up basati sullo stato delle opportunità. Un bug nel prompt ha fatto sì che, in certe condizioni, l’agente interpretasse il task appena creato come una nuova opportunità da processare. Risultato: 40.000 task creati in due ore, con l’API del CRM che ha iniziato a rigettare chiamate, il pipeline commerciale completamente illeggibile, e tre giorni di lavoro per ripulire.
La credenziale trapelata
Classico scenario. Uno sviluppatore committa per sbaglio il file di configurazione con le API keys. GitHub rileva il problema, ma il repository era pubblico per sei minuti. Sei minuti sono sufficienti. Qualcuno ha estratto la chiave, ha fatto richieste all’API di un LLM consumando 3.000 euro di credito prima che qualcuno se ne accorgesse. In questo caso il danno era contenuto perché la chiave era solo per il modello AI, non per sistemi aziendali. Ma se fosse stata la chiave di Stripe? Di AWS?
Il pattern comune di tutti questi casi è lo stesso: troppa fiducia nell’agente, troppi permessi concessi, troppo poco monitoring.
Il modello mentale corretto: l’agente come junior intern
Voglio proporti un modello mentale che uso quando progetto architetture per agenti AI. Pensa all’agente come a uno stagista al primo giorno di lavoro. È sveglio, vuole fare bene, ma non conosce l’azienda, non sa quali informazioni sono sensibili, e ha una certa tendenza a eseguire istruzioni senza chiedere troppe domande.
A uno stagista daresti la password del CEO? No.
Gli daresti accesso in scrittura a tutto il CRM senza supervisione? No.
Lo lasceresti operare senza che qualcuno possa vedere cosa sta facendo? Assolutamente no.
E allora perché lo fai con un agente AI?
La risposta onesta è: perché è più facile. Configurare un agente con le credenziali di un admin è questione di copia-incolla. Configurarlo con un service account dedicato, permessi minimi, audit log attivi e monitoring richiede tempo e competenze. E le aziende hanno fretta di mostrare risultati.
Ma questa fretta sta creando debito tecnico di sicurezza che prima o poi presenterà il conto. E il conto sarà salato.
Principi di progettazione: il least privilege applicato davvero
Il principio del minimo privilegio esiste da cinquant’anni. Lo conosciamo tutti. Eppure quando si tratta di agenti AI, sembra che lo dimentichiamo. Vediamo come applicarlo in pratica.
Ogni agente dovrebbe avere il proprio service account, dedicato, non condiviso con altri sistemi né con utenti umani. Questo account dovrebbe avere solo i permessi strettamente necessari per il suo compito specifico. Se l’agente legge email ma non deve inviarle, non dargli il permesso di inviare. Se aggiorna opportunità commerciali ma non deve toccare i contatti, limita il ruolo.
Questo sembra ovvio quando lo leggi, ma nella pratica si scontra con la realtà delle API aziendali. Molte API non supportano granularità fine nei permessi. Salesforce è abbastanza bravo, Microsoft Graph è decente, molti ERP italiani sono drammatici. Quando l’API non supporta la granularità che vorresti, devi costruire un proxy layer tu.
Il pattern del proxy di policy
Uno dei pattern più efficaci che abbiamo implementato per i nostri clienti è quello che chiamo il “policy proxy”. Invece di far chiamare l’API target direttamente all’agente, l’agente chiama un servizio intermedio. Questo servizio applica le policy, valida le richieste, logga tutto, e solo dopo inoltra la chiamata al sistema vero.
Il proxy può fare cose che l’API originale non fa. Può rifiutare chiamate fuori orario lavorativo. Può richiedere conferma umana per operazioni sopra una certa soglia. Può rate-limitare in modo granulare per tipo di operazione. Può bloccare pattern sospetti, come migliaia di letture seguite da esfiltrazione.
L’overhead è minimo se fatto bene. Un proxy ben scritto aggiunge 10-30 millisecondi alla chiamata. Per un agente che opera in modo non-realtime è completamente irrilevante.
Architettura zero-knowledge: il santo Graal
Ora entriamo nel cuore della questione. Come possiamo dare a un agente AI la capacità di operare su sistemi sensibili senza che l’agente stesso debba mai vedere le credenziali in chiaro?
La risposta è un pattern chiamato zero-knowledge credential management. L’idea è semplice da descrivere, più complessa da implementare: l’agente non possiede mai le credenziali. Le richiede a un broker al momento del bisogno, e il broker gli fornisce un token temporaneo, di scope limitato, che scade in pochi minuti.
Il credential broker
Il componente centrale è il credential broker. È un servizio, idealmente deployato in un ambiente ad alta sicurezza, che detiene le credenziali reali e le espone solo sotto forma di token derivati. Pensa a AWS STS (Security Token Service) ma applicato a qualsiasi sistema aziendale.
Quando l’agente vuole fare un’operazione, chiede al broker un token per quella specifica operazione. Il broker verifica l’identità dell’agente (tipicamente tramite mTLS o OIDC), controlla le policy, e se tutto è a posto genera un token JWT firmato con un claim che descrive esattamente cosa il token può fare e per quanto tempo.
L’agente presenta questo token al policy proxy, che lo verifica, lo decodifica, e usa le credenziali reali (che non lascia mai la propria memoria) per chiamare l’API target.
Se il token viene rubato, il danno è limitato. Ha uno scope ridottissimo, scade presto, e tutti i suoi utilizzi sono loggati.
Implementazione pratica
Per un’implementazione realistica in un contesto PMI italiana, non serve costruire tutto da zero. Puoi usare HashiCorp Vault come credential store, scrivere un broker in Node o Python che espone un’API REST semplice, e mettere davanti un proxy scritto con il tuo framework preferito.
Il design che tipicamente consigliamo per i nostri progetti a Bajara prevede tre layer. Al fondo c’è il vault delle credenziali, accessibile solo dal broker tramite network policy stringenti. In mezzo il broker, che espone un’API autenticata per richiedere token temporanei. In alto i policy proxy, uno per ogni sistema target, che ricevono le richieste dagli agenti e le inoltrano usando il token.
Gli agenti AI non vedono mai nulla di tutto questo. Vedono solo un’API REST interna, autenticata con il loro certificato, che espone operazioni specifiche. L’agente fa POST /crm/update-opportunity con i dati, e il sistema dietro si occupa di tutto il resto.
Il costo di questa architettura
Sarei disonesto se dicessi che implementare questo è semplice. Richiede tempo, competenze, e un po’ di investimento infrastrutturale. Per un’azienda piccola con un solo agente AI probabilmente è overkill. Ma quando inizi ad avere cinque, dieci, venti agenti che operano su sistemi diversi, l’architettura si ripaga in termini di riduzione del rischio e semplicità operativa.
Il punto di svolta, secondo la mia esperienza, è quando un’azienda ha almeno tre agenti in produzione con accesso a dati business-critical. Sotto quella soglia, probabilmente puoi cavartela con service account dedicati e un buon secret manager. Sopra, inizia a pensare seriamente all’architettura zero-knowledge.
Monitoring e audit: vedere quello che fa l’agente
Anche la migliore architettura è cieca se non la monitori. E monitorare gli agenti AI è diverso dal monitorare un’applicazione tradizionale.
Le metriche che contano sono alcune. Il volume di chiamate per tipo di operazione, e come varia rispetto al baseline. I pattern di accesso, che per un agente dovrebbero essere prevedibili. Gli errori, che per un agente LLM possono essere sintomo di prompt injection o di edge case non previsti. I tempi di risposta del modello AI sottostante, che possono rivelare attacchi o degradazione del servizio.
Ma la metrica più importante, quella che ti salva la vita, è il delta comportamentale. Cosa sta facendo oggi l’agente che non ha mai fatto prima? Se un agente che tipicamente fa 200 chiamate al giorno improvvisamente ne fa 20.000, qualcosa sta succedendo. Se inizia ad accedere a risorse a cui non aveva mai acceduto, qualcosa sta succedendo.
Noi a Bajara implementiamo tipicamente un layer di anomaly detection sopra gli audit log. Non serve essere molto sofisticati, bastano controlli statistici semplici su finestre temporali. L’importante è che qualcuno venga avvisato quando qualcosa esce dal normale.
Log che ti serviranno davvero
Su cosa loggare, il mio consiglio è: tutto, ma in modo strutturato. Per ogni chiamata dell’agente, devi sapere chi (quale agente, quale versione), cosa (quale operazione, su quali dati), quando (timestamp al millisecondo), perché (quale prompt l’ha generata, se disponibile), e con quale risultato.
Il “perché” è la parte più delicata. Salvare l’intero prompt può essere un problema di privacy o di sicurezza. Salvare solo un hash del prompt permette correlazione senza esporre dati. Un hash deterministico dello stesso prompt produce sempre lo stesso valore, quindi puoi identificare quando l’agente sta rispondendo a input simili ripetuti, che è un segnale tipico di attacchi.
La governance umana
Tutta questa tecnologia non serve a niente se non c’è un processo umano dietro. E qui le aziende italiane faticano parecchio, perché non esiste ancora una figura standard di “AI security officer” e le responsabilità finiscono spesso in un limbo tra CISO, CTO, e il responsabile dell’innovazione.
La mia raccomandazione pratica è di istituire un comitato ristretto, tre o quattro persone al massimo, che si occupi specificamente degli agenti AI in produzione. Non deve essere un comitato pesante, deve essere agile. Si incontra una volta al mese (o quando serve), rivede i nuovi agenti prima che vadano in produzione, valuta le richieste di ampliamento dei permessi, e analizza gli incidenti.
Questo comitato deve avere potere di veto. Senza potere di veto è solo teatro. Deve poter dire “no, questo agente non va in produzione finché non implementate X, Y e Z”. E l’organizzazione deve rispettarlo.
Policy documentate, non solo implementate
Un aspetto che spesso viene trascurato: le policy di sicurezza degli agenti AI devono essere documentate, non solo implementate nel codice. Deve esistere un documento che dice “in questa azienda, un agente AI può mai avere credenziali di un account umano? No. Un agente AI può mai operare senza audit log? No. Un agente AI può mai fare operazioni irreversibili sopra la soglia X senza approvazione umana? No.”
Questo documento serve per onboarding, per audit, per conformità normativa futura (che arriverà), e per resistere alle pressioni di chi vuole saltare i controlli “solo per questa volta”.
Cosa fare lunedì mattina
Se stai leggendo questo e hai agenti AI in produzione, ecco una checklist concreta di cose da fare la prossima settimana.
Prima cosa, fai un inventario. Quanti agenti AI hai in produzione, anche informalmente? Chi li ha creati? Con quali credenziali girano? Dove sono memorizzate queste credenziali? Se non riesci a rispondere a queste domande in mezza giornata, hai un problema.
Seconda cosa, guarda ogni agente e chiediti: se questo agente venisse compromesso adesso, qual è il danno massimo possibile? Non il danno probabile, il massimo. Se la risposta include cose come “accesso a dati di tutti i clienti” o “capacità di fare bonifici”, stai ferendo il sonno tuo e dell’azienda.
Terza cosa, priorizza. Non devi rifare tutto in una settimana. Ma dovresti avere, entro 30 giorni, almeno tutti gli agenti con service account dedicati. Le credenziali personali usate dagli agenti devono essere revocate e sostituite. Questo è il minimo sindacale.
Quarta cosa, implementa logging. Se non hai visibilità su cosa fanno gli agenti, non puoi rilevare problemi. Anche un logging semplice su file, ruotato e salvato in un posto sicuro, è infinitamente meglio di nessun logging.
Quinta cosa, pianifica. Progetta dove vuoi essere tra sei mesi. Probabilmente vorrai un credential broker, policy proxies per i sistemi più critici, anomaly detection sugli audit log. Fai una roadmap realistica e iniziala.
Il futuro prossimo
Gli agenti AI continueranno a diffondersi, a diventare più potenti, a operare su più sistemi. Questo è inevitabile. Quello che non è inevitabile è che continuino a essere gestiti come giocattoli.
Le aziende che costruiscono ora un’infrastruttura di governance seria avranno un vantaggio competitivo nei prossimi anni. Potranno scalare l’adozione dell’AI senza esporsi a rischi catastrofici, potranno conformarsi alle normative che arriveranno (l’AI Act europeo è solo l’inizio), e potranno dormire la notte.
Le aziende che continuano a fare copia-incolla delle password nei file di configurazione prima o poi avranno un incidente. Non è una questione di se, ma di quando. E l’incidente sarà costoso, pubblicamente imbarazzante, e probabilmente conterrà un elemento di banalità che farà sentire tutti stupidi col senno di poi.
Non essere in quella seconda categoria. Inizia oggi, anche con passi piccoli. Un agente AI è uno strumento potente, e gli strumenti potenti richiedono rispetto.
Se stai affrontando questi problemi nella tua azienda e hai bisogno di supporto per progettare un’architettura di governance seria per i tuoi agenti AI, a Bajara.it ci occupiamo proprio di questo: sviluppo di soluzioni AI enterprise con particolare attenzione alla sicurezza, credential management e integrazione con sistemi esistenti. Scrivici, raccontaci cosa stai costruendo, e vediamo insieme come renderlo sicuro senza rallentarlo.