Un agente non produce soltanto una risposta. Apre strumenti, usa identità, legge dati e può concatenare attività che acquistano significato soltanto nel tempo. Per questo il monitoraggio di sicurezza ha bisogno di una finestra di eventi: la stessa anomalia, osservata in una sola interazione, potrebbe sembrare innocua; ripetuta su più sessioni può indicare credenziali sottratte o un uso fuori perimetro. Enterprise Frontier Safeguards, annunciato da Anthropic il 1° settembre 2026 e previsto in rollout graduale dall’autunno, separa due responsabilità. I dati di attività possono restare in S3, Azure Blob Storage o Google Cloud Storage del cliente, sotto chiavi di cifratura, policy di accesso e audit log dell’organizzazione. Il rilevamento automatico invia segnali al cliente; la revisione umana non deve essere svolta da personale Anthropic. È un riferimento architetturale, non una funzione già disponibile per tutti e non una garanzia automatica di conformità. Le opzioni di storage controllato dal cliente, chiavi gestite dal cliente e revisione automatica sono indipendenti e facoltative. Anthropic non applica un sovrapprezzo EFS, mentre restano i costi del cloud per conservazione, letture, scritture ed eventuale traffico.
Perché è importante
- Gli agenti distribuiscono azioni tra sessioni e account: un singolo prompt non basta a ricostruire abusi, credenziali compromesse o decisioni anomale.
- Anthropic ha annunciato il 1° settembre 2026 un’architettura opzionale che può mantenere i dati di attività nel cloud del cliente, sotto chiavi, policy e audit log controllati dall’organizzazione.
- Possedere il bucket non risolve il problema: senza minimizzazione, ruoli separati, tempi di conservazione e prova di cancellazione si sposta soltanto il rischio da un fornitore all’altro.
Il modello nuovo: rilevare senza consegnare i log al fornitore
Parti da un caso d’uso limitato, per esempio un agente che prepara risposte ai ticket ma non può inviarle. Elenca gli eventi che servono a ricostruire l’azione: identità tecnica, strumento chiamato, orario, esito, oggetto interessato, approvazione e codice di errore. Non copiare automaticamente prompt completi, allegati, token, password o dati personali se il controllo funziona con un riferimento, un hash o una categoria. Scrivi poi gli scopi. Un evento può servire a diagnosticare un guasto, provare un’approvazione o correlare un comportamento sospetto: sono finalità diverse, con persone e durate diverse. NIST raccomanda una vera infrastruttura di log management e processi robusti in tutta l’organizzazione; un deposito senza responsabilità, revisione e manutenzione è soltanto un archivio costoso. Per ogni campo annota origine, sensibilità, proprietario, destinatari autorizzati e tempo minimo necessario. Aggiungi una regola di esclusione per i segreti e una verifica automatica su campioni. Se non sai spiegare quale controllo richiede un dato, non inserirlo nel primo pilota. La minimizzazione riduce sia l’esposizione sia il rumore che rende inutili gli alert.
Crea una destinazione dedicata nel cloud aziendale, non una cartella condivisa con il team di progetto. Blocca l’accesso pubblico, cifra a riposo e in transito e usa una chiave gestita dall’organizzazione quando il rischio lo richiede. Le policy della chiave e dello storage devono essere lette insieme: poter scaricare un oggetto non deve implicare automaticamente poter amministrare o disattivare la chiave che lo protegge. Assegna ruoli distinti. Il servizio che scrive i log non deve cancellarli; chi gestisce la chiave non deve avere per default accesso ai contenuti; il revisore vede soltanto il perimetro necessario all’indagine. Usa identità nominative, autenticazione forte e accessi temporanei. Registra anche le letture dei log: il sistema di controllo contiene spesso nomi, progetti e percorsi che meritano la stessa protezione dei dati operativi. Definisci conservazione e cancellazione prima del primo evento. Il periodo deve essere abbastanza lungo da correlare i segnali previsti, non infinito per comodità. Prevedi eccezioni documentate per un incidente aperto, poi scadenza automatica e prova verificabile dell’eliminazione. Conserva separatamente configurazioni, modifiche alle policy e rotazione delle chiavi, così un audit può ricostruire chi era autorizzato in quel momento.
Cosa puoi farci concretamente
- Inventariare gli eventi realmente necessari, escludendo contenuti e segreti che non servono al controllo.
- Separare proprietario dello storage, amministratore della chiave e revisore degli alert, con accessi minimi e registrati.
- Provare un falso positivo, una chiave revocata e la cancellazione a fine conservazione prima di collegare il primo flusso reale.
Passo 3 — Collauda alert, accesso e uscita prima dei dati reali
Costruisci cinque eventi sintetici: azione normale, tentativo bloccato, credenziale revocata, sequenza sospetta su due sessioni e falso positivo. Verifica che ogni evento arrivi una volta, con orario coerente e identificatore stabile. L’alert deve indicare perché è scattato e dove trovare la prova, senza trasformare una correlazione in una colpa. Il revisore deve poter chiudere il caso e registrare la motivazione. Prova i guasti. Revoca la chiave al servizio sbagliato, rimuovi il ruolo del revisore e interrompi temporaneamente la destinazione. Il sistema deve fallire in modo visibile, accumulare o scartare secondo una regola esplicita e non tornare a una destinazione meno protetta. Esegui una richiesta di cancellazione e controlla che oggetto, replica e indice di ricerca seguano la stessa politica. Misura quattro numeri per trenta giorni: eventi acquisiti senza duplicati, tempo dall’alert alla prima revisione, percentuale di falsi positivi e costo per agente monitorato. Aggiungi incidenti ricostruibili e accessi non necessari rimossi. Adotta il modello se aumenta la capacità di capire e intervenire senza moltiplicare dati e privilegi. Il cloud del cliente è il punto di partenza; il risultato è una catena di custodia comprensibile.
Una guida tecnica produce valore quando trasforma un concetto in una sequenza applicabile. Ogni passaggio deve indicare input, controllo ed esito, così il lettore può adattarlo al proprio contesto senza affidarsi a una ricetta opaca. Nel caso di “Dove conservare i log di un agente AI: guida a chiavi, accessi e controlli”, questo significa leggere la novità oltre l’annuncio e capire quali parti del lavoro vengono realmente modificate. Il rischio è saltare direttamente allo strumento. Dati disordinati, obiettivi vaghi e responsabilità assenti non vengono risolti dall’AI. Prima dell’automazione occorre rendere osservabile il lavoro e stabilire cosa significa un risultato accettabile. Le pratiche migliori convergono su valutazioni ripetibili, fonti tracciabili e supervisione proporzionata. Strumenti e modelli cambieranno; un metodo documentato rimarrà riutilizzabile e permetterà di confrontare alternative con criteri coerenti. La notizia è quindi un indicatore di una trasformazione più ampia, che va seguita attraverso risultati e condizioni operative anziché con la sola successione degli annunci.
Quello che conta adesso
Inventariare gli eventi realmente necessari, escludendo contenuti e segreti che non servono al controllo. Questo primo passo serve a trasformare il tema in un perimetro verificabile: un responsabile, un input conosciuto, un risultato atteso e una misura precedente con cui confrontarsi. Senza questi elementi il progetto rimane una dimostrazione difficile da valutare. Separare proprietario dello storage, amministratore della chiave e revisore degli alert, con accessi minimi e registrati. L’azione deve essere documentata insieme ai criteri di controllo, indicando quali casi possono procedere e quali devono fermarsi. È così che l’esperienza delle persone diventa una regola applicabile e migliorabile nel tempo. Provare un falso positivo, una chiave revocata e la cancellazione a fine conservazione prima di collegare il primo flusso reale. Prima di estendere il metodo è utile raccogliere correzioni, tempi e costi per alcune settimane. Gli errori vanno raggruppati per causa: dati, istruzioni, strumenti o eccezioni del processo. Ogni categoria richiede un intervento diverso. Gli agenti distribuiscono azioni tra sessioni e account: un singolo prompt non basta a ricostruire abusi, credenziali compromesse o decisioni anomale. È il punto da cui partire perché definisce l’effetto più immediato per professionisti e imprese. La sua importanza va misurata sul lavoro quotidiano: quante attività coinvolge, quali persone tocca e cosa accade quando il risultato non è corretto.
Anthropic ha annunciato il 1° settembre 2026 un’architettura opzionale che può mantenere i dati di attività nel cloud del cliente, sotto chiavi, policy e audit log controllati dall’organizzazione. Questo secondo elemento chiarisce perché non basta scegliere un prodotto. Servono un processo, dati affidabili e una responsabilità finale. L’adozione diventa sostenibile quando la tecnologia può essere osservata e corretta senza interrompere l’operatività. Possedere il bucket non risolve il problema: senza minimizzazione, ruoli separati, tempi di conservazione e prova di cancellazione si sposta soltanto il rischio da un fornitore all’altro. Il terzo punto indica la prospettiva di medio periodo. La decisione migliore non è necessariamente quella con più funzioni, ma quella che mantiene valore, controllo e possibilità di evoluzione quando cambiano modelli, prezzi o requisiti.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
