L'errore del giorno zero: dare all'agente l'account di Marta
Quasi tutti gli agenti che abbiamo visto andare in produzione sono partiti allo stesso modo: qualcuno aveva bisogno che la cosa leggesse la posta e scrivesse nel CRM, e la via rapida era usare le credenziali di una persona che l'accesso ce l'aveva già. Marta, operations. Il primo giorno funziona. Il problema arriva il secondo, e non è tecnico: da quel momento nessuno in azienda sa rispondere a due domande elementari. Chi ha fatto questa modifica, Marta o l'agente. E cosa può toccare esattamente questa cosa.
La risposta alla seconda è sempre la stessa e sempre scomoda: tutto quello che può toccare Marta. Dieci anni di anzianità, tre cambi di reparto e i permessi accumulati in ciascuno. L'agente non ha ereditato un compito; ha ereditato una carriera intera. E a differenza di Marta non ha il criterio che gli dice che la cartella delle buste paga non si apre, nemmeno se qualcosa nel contesto glielo chiede con molta educazione.
OWASP ha dato un nome a tutto questo a dicembre 2025, pubblicando la sua Top 10 per le applicazioni agentiche. La categoria ASI03 si chiama Identity & Privilege Abuse e la descrive esattamente così: credenziali ereditate o trafugate che lasciano l'agente operare ben oltre il perimetro previsto. Non è un'ipotesi da laboratorio — la lista è stata costruita su incidenti reali della prima generazione di adottanti.
La matrice a quattro colonne da compilare prima di collegare qualsiasi cosa
La progettazione dei permessi di un agente sta in una tabella che si compila in una riunione di quaranta minuti, e va compilata prima di creare la prima credenziale. Non dopo: dopo c'è già qualcosa che gira e nessuno vuole essere quello che la rompe. Quattro colonne di permesso, un sistema per riga.
| Sistema | Cosa LEGGE | Cosa SCRIVE | Cosa ESEGUE | Cosa non tocca mai |
|---|---|---|---|---|
| CRM | Opportunità aperte del suo portafoglio | Note e prossimo passo | Niente | Importo, fase di chiusura, cancellazione di record |
| Posta | Casella di un alias suo | Bozze in cartella di revisione | Niente | Inviare senza revisione, inoltrare fuori dal dominio |
| ERP / fatturazione | Stato degli ordini | Niente | Niente | Tutto il resto |
| Archiviazione | Cartella del progetto | Sottocartella di output | Niente | Buste paga, legale, cartelle della direzione |
La colonna su cui tutti discutono è la terza, eseguire, ed è quella che conta di più. Leggere è reversibile. Scrivere di solito lo è, con uno storico decente. Eseguire — lanciare un pagamento, mandare una mail a un cliente, chiudere un ticket, cancellare — quasi mai. Regola pratica: un'azione entra nella colonna eseguire solo se qualcuno sa descrivere in una frase come si disfa. Se la frase non esiste, l'azione resta a «propone e aspetta».
E la quarta colonna, quello che non tocca mai, non è decorativa. È l'unica scritta in positivo fin dall'inizio e l'unica che sopravvive ai cambi di perimetro: fra sei mesi, quando qualcuno vorrà «allargargli un po' i permessi così fa anche questo», è lei che obbliga ad avere la conversazione invece di sbrigarla con un clic in console.
Identità propria: l'agente non è il plugin di qualcuno
Un account di servizio non è burocrazia di sicurezza. È ciò che rende possibili le tre cose seguenti, e senza di esso nessuna lo è.
- Auditabilità. Il log dice «agente-vendite-01» e non «marta.g». Quando qualcosa non torna, l'indagine dura dieci minuti invece di un pomeriggio a chiedere alle persone se sono state loro.
- Revoca pulita. Si taglia l'accesso all'agente senza lasciare una persona senza lavorare, e si disattiva una persona senza tagliare l'agente. Ovvio, finché non condividi la credenziale e scopri di non poter fare né l'una né l'altra cosa.
- Perimetro reale. Puoi dargli meno permessi di un umano solo se ha un account diverso da quello dell'umano. Con credenziale condivisa, «privilegio minimo» è un'intenzione, non una configurazione.
L'obiezione classica è il costo: in molti strumenti SaaS un account in più sono trenta o cinquanta euro al mese. Obiezione legittima, e con una buona risposta quasi ovunque: account di servizio, di integrazione o di API, non fatturati come postazione utente. La risposta sbagliata — quella che si prende per default quando nessuno chiede — è condividere l'account di Marta per risparmiare quaranta euro e restare senza audit, senza revoca e senza perimetro. Quando colleghi un agente a un CRM specifico la conversazione si fa molto concreta: collegare un agente IA al tuo CRM scende a oggetti, campi e sincronizzazione.
Perimetro per compito, non per persona
Il modello mentale che portiamo dall'IAM è il ruolo: «commerciale», «supporto», «amministrazione». Funziona con gli umani perché un umano fa molte cose e il suo criterio riempie i vuoti. Con un agente il ruolo è troppo grande, perché l'agente fa una cosa e non ha criterio per riempire niente.
Quindi il permesso si ritaglia sul compito. Non «accesso al supporto», ma «leggere i ticket aperti della coda fatturazione e scrivere una risposta in bozza». Tutto ciò che eccede quella frase eccede la credenziale. È più lavoro di configurazione iniziale, e in cambio la domanda «cosa può fare questa cosa?» ha una risposta scritta invece di un'indagine.
C'è un effetto collaterale che ripaga il lavoro: quando il perimetro è un compito e non un ruolo, ampliare l'agente impone un cambio di permessi esplicito, e quel cambio lascia traccia. L'agente che cresce senza che nessuno se ne accorga è quello partito da un ruolo ampio. E quando hai già più agenti che crescono per conto loro, il problema smette di essere di progettazione e diventa di salvataggio: se ne parla in mettere un freno agli agenti IA fuori controllo.
Contro la prompt injection, il permesso che non hai dato
La prompt injection è la via per cui un contenuto che l'agente legge — una pagina, una mail, un documento, un ticket — gli infila istruzioni che non vengono da te. E lo stato dell'arte, detto da chi costruisce i modelli, è che non è risolta. A novembre 2025 Anthropic ha pubblicato i suoi risultati di robustezza nella navigazione con Claude Opus 4.5, accompagnati da una frase da leggere piano: un tasso di successo dell'1 % contro un attaccante adattivo resta un rischio reale, nessun agente da browser è immune, e i dati si pubblicano per mostrare progresso, non per dichiarare chiuso il problema.
Da lì esce l'unica conclusione pratica che regge: non puoi impedire che l'agente venga manipolato; puoi decidere di cosa è capace un agente manipolato. La difesa non abita nel prompt di sistema — è esattamente quello che l'attaccante sta attaccando. Abita nella credenziale, che l'attaccante dal contenuto non può toccare.
Tradotto nella matrice qui sopra: ogni permesso della colonna «esegue» è una capacità che un attaccante eredita se riesce a infilare un'istruzione. Un agente che solo legge e propone, se iniettato, produce una proposta strana che qualcuno scarta. Lo stesso agente con permesso di invio produce una mail già partita. La differenza non l'ha fatta il modello. L'ha fatta una casella che qualcuno ha deciso di non spuntare.
Il pulsante di revoca da provare PRIMA di partire
Tutti danno per scontato di poter staccare il proprio agente. Pochissimi l'hanno verificato. E il momento per verificarlo non è quando l'agente sta facendo qualcosa di strano un venerdì pomeriggio: è prima della prima esecuzione reale, a freddo, con tempo e senza nervi.
La prova è breve. Si lancia un compito normale, si revoca la credenziale mentre gira, e si guardano tre cose: quanto ci mette davvero a smettere di avere effetto — i token in corso e le sessioni aperte non muoiono sempre con il pulsante —, in che stato resta il lavoro a metà, e se qualcuno si accorge che è successo. Poi si riconcede e si verifica che riparta. Mezz'ora.
- Chi può premerlo. Almeno due persone, e una non può essere chi ha costruito l'agente. Se il pulsante dipende da una sola persona, non c'è un pulsante: c'è una telefonata.
- Dov'è. Scritto, con il link esatto alla console e il nome esatto della credenziale. Cercarlo a caldo è metà del tempo di reazione.
- Cosa succede dopo. Con cosa si sostituisce il lavoro dell'agente mentre è staccato. Se la risposta è «niente», staccare ha un costo che qualcuno esiterà a pagare, e quell'esitazione è ciò che allunga gli incidenti.
Lo stesso apparato — chi risponde, dov'è scritto, con cosa si sostituisce — regge qualsiasi automazione in produzione, non solo gli agenti; è sviluppato in chi risponde quando un'automazione si ferma. E se quello che cerchi è la mappa completa dei rischi prima di decidere qualsiasi cosa, il catalogo è in i rischi degli agenti IA che non si vedono nella demo.
Cosa fai questa settimana
- Compila la matrice a quattro colonne per l'agente che hai più vicino alla produzione. Un sistema per riga. Quaranta minuti con chi conosce il processo, non con chi conosce lo strumento.
- Crea la credenziale propria dell'agente prima di collegarlo a qualsiasi cosa. Se il tuo strumento fattura a postazione, chiedi dell'account di servizio o di API prima di rassegnarti a condividere.
- Ritaglia il perimetro dal ruolo al compito: leggi ad alta voce la descrizione dell'agente e togli dalla credenziale tutto ciò che non compare in quella frase.
- Applica il test della casella a ogni permesso di scrittura ed esecuzione. Ciò che ti mette a disagio scende a «propone e un umano conferma».
- Prova la revoca a freddo, con due persone che sanno premerla, e lascia scritto dov'è il pulsante e con cosa si sostituisce il lavoro.
Nessuno dei cinque passi richiede di scegliere piattaforma, modello o fornitore. Si fanno prima, e si fanno una volta. Quello che decidi qui è ciò che limiterà il danno di tutto quello che verrà dopo — e ciò che ti permetterà di dire sì, più avanti, a cose che oggi ti darebbero le vertigini. Perché i permessi definiscono che cosa l'agente può toccare; quanta libertà ha per usarli è la decisione successiva, e non si concede tutta insieme: i cinque gradini dell'autonomia si salgono con le prove in mano — casi visti, tasso di correzione umana e reversibilità dell'azione.
Noi montiamo la parte che nessuno vuole montare: identità di servizio, perimetri per compito, revoca provata e il registro di chi ha fatto cosa. È l'infrastruttura IA aziendale su cui poi si appoggia qualsiasi agente che lavori davvero. Non vendiamo il permesso. Fatturiamo il fatto che sia quello giusto.