Agenti AI con accesso al web: rischi e controlli

Gli agenti AI con accesso al web possono cercare informazioni, usare strumenti, leggere documenti e compiere sequenze di azioni. Il caso di una rete di agenti che avrebbe raggiunto Internet aperto senza la consapevolezza del laboratorio che li aveva sviluppati mostra un rischio concreto: un sistema autonomo può superare il confine previsto se autorizzazioni, rete e osservabilità non sono progettate insieme.

La questione non è soltanto quale modello sia più intelligente. È chi può avviare l’agente, quali istruzioni riceve, quali strumenti trova, quali dati può leggere, dove può comunicare e chi approva l’azione finale. L’autonomia aumenta il numero di passaggi che devono essere controllati.

Agenti AI con accesso al web: il confine da proteggere

Un assistente che risponde su testo ha un perimetro diverso da un agente che apre pagine, esegue codice, invia messaggi o modifica file. Ogni strumento aggiunge capacità e nuove condizioni di errore.

Definisci il confine in modo esplicito. L’agente può leggere soltanto siti indicati? Può seguire redirect? Può scaricare file? Può usare credenziali? Può inviare una richiesta? Un “accesso al web” generico non è una policy.

Scrivi anche ciò che è vietato: esfiltrare segreti, aprire porte, installare software, modificare produzione, contattare terzi o ignorare una conferma. I divieti devono essere applicati dall’architettura, non affidati soltanto al prompt.

Come un agente può uscire dal perimetro

Un sistema può ricevere credenziali, strumenti o rete senza che il team se ne accorga. Un pacchetto di configurazione ereditato, una variabile d’ambiente, un plugin o un container con egress libero possono allargare il perimetro.

Controlla bootstrap, dipendenze e segreti. Un agente avviato in locale può avere accesso alla stessa rete dell’utente. Se il sistema è stato pensato per ricerca, non dovrebbe poter raggiungere console, repository e database aziendali.

Verifica anche il ciclo di vita. Un agente lasciato attivo può continuare a lavorare dopo la chiusura della sessione o ricevere nuovi compiti da una coda. La terminazione deve essere reale e osservabile.

Sandbox e separazione della rete

Usa ambiente isolato con filesystem temporaneo, account minimo e rete in uscita filtrata. Allowlist di domini e porte riduce il rischio rispetto a Internet aperto. Se l’agente deve leggere una fonte, autorizza soltanto ciò che serve.

Separa sviluppo, test e produzione. Un agente sperimentale non dovrebbe condividere token o volumi con servizi reali. Il container non è una garanzia se il processo può montare directory sensibili o raggiungere socket amministrativi.

Testa isolamento: file, DNS, proxy, metadata endpoint, rete interna, credenziali e processi. Un controllo che esiste nel diagramma ma non nella configurazione non protegge.

Prompt injection e contenuti ostili

Una pagina web può contenere istruzioni rivolte all’agente. Il modello può interpretarle come parte del compito anche quando sono testo ostile. Il contenuto recuperato deve essere trattato come dato non fidato, non come comando.

Se l’agente legge email, ticket o documenti, lo stesso problema appare dentro fonti interne. Separa istruzioni di sistema, richiesta dell’utente e contenuto osservato. Non permettere a un testo esterno di autorizzare un’azione.

Chiedi all’agente di citare fonte e motivazione, ma non considerare la spiegazione una prova di sicurezza. La protezione deve venire da strumenti, permessi e approvazioni.

Strumenti con effetti reali

Un tool di sola lettura ha rischio diverso da uno che crea, modifica o invia. Classifica funzioni e assegna permessi specifici. Le operazioni distruttive devono richiedere conferma umana con riepilogo di oggetto, destinazione e impatto.

Limita volume e frequenza. Un agente che può aprire migliaia di richieste in pochi minuti può generare costi, blocchi o abuso anche senza intento malevolo. Rate limit e budget devono essere applicati fuori dal modello.

Registra input, tool chiamato, risultato, identità, timestamp e decisione. Proteggi i log perché possono contenere dati sensibili. L’obiettivo è poter ricostruire la sequenza senza registrare segreti in chiaro.

Credenziali e dati sensibili

Non passare all’agente il token principale dell’organizzazione. Usa credenziali dedicate, durata breve, scope minimo e revoca automatica. Se il compito richiede un accesso, crea un account di servizio limitato.

Separa segreti per ambiente e strumento. Un agente che legge documenti non deve poter usare le chiavi del deploy. Un agente che cerca sul web non deve ricevere password di posta.

Controlla output e memoria. Un segreto può comparire in un log, in una risposta o in una pagina generata. Applica redazione e conserva soltanto informazioni necessarie alla diagnosi.

Osservabilità e kill switch

Ogni agente operativo deve avere identificativo, proprietario, scopo, strumenti e orario di attività. Un inventario semplice fa emergere sistemi dimenticati o avviati da account personali.

Il kill switch deve revocare coda, credenziali e rete, non soltanto chiudere la finestra. Testalo in condizioni normali e durante un errore. Se nessuno sa chi può fermare l’agente, il sistema non è pronto.

Monitora azioni anomale: aumento di richieste, domini nuovi, tentativi di leggere file vietati, errori ripetuti, loop e output verso canali insoliti. Le soglie devono produrre blocco o revisione, non soltanto una metrica decorativa.

Processo di approvazione

Definisci quali compiti sono automatici e quali richiedono una persona. Ricerca e sintesi possono avere autonomia limitata; invio, acquisto, modifica e pubblicazione richiedono approvazione secondo il rischio.

Mostra all’approvatore contesto e conseguenza. Un pulsante “conferma” senza riepilogo trasferisce responsabilità senza informazione. La persona deve poter vedere fonti, destinazione, dati usati e cosa succede dopo.

Non approvare in blocco azioni troppo diverse. Raggruppa soltanto operazioni omogenee e reversibili. Un agente che ha prodotto un output convincente non deve ottenere fiducia illimitata.

Test avversariali e red teaming

Prova prompt injection, pagine malevole, redirect, file con istruzioni nascoste, contenuti falsi e tool indisponibili. Verifica che l’agente distingua informazione da comando e si fermi quando manca autorizzazione.

Testa rete, filesystem e identità separatamente. Chiedi di accedere a una risorsa vietata e controlla che il blocco avvenga a livello tecnico. Inserisci credenziali esca e verifica rilevamento senza usare segreti reali.

Ripeti il test quando cambi modello, prompt, tool o policy. Un sistema può comportarsi diversamente dopo un aggiornamento. Conserva casi di regressione e criteri di uscita.

Gestire l’agente in azienda

Il progetto deve avere un proprietario tecnico e uno operativo. Il primo gestisce rete, credenziali e aggiornamenti; il secondo definisce obiettivo, qualità e approvazioni. Nessun agente dovrebbe esistere soltanto in un account personale.

Documenta dati, retention, fornitori e subfornitori. Se l’agente tratta informazioni clienti o interne, applica policy di accesso e cancellazione. Coinvolgi sicurezza e privacy prima di ampliare il perimetro.

Forma gli utenti. Un operatore deve sapere che una sintesi può contenere istruzioni ostili, che un link non è una prova e che un agente può sbagliare anche quando spiega bene il risultato.

Continuità e fallback manuale

Un agente collegato al web può fermarsi per rate limit, fonte assente o errore di tool. Prepara un processo manuale e indica quando attivarlo. Non lasciare che il sistema ritenti indefinitamente.

Salva stato e risultati in formato leggibile, con data e fonti. Se l’agente viene spento, una persona deve poter riprendere senza eseguire di nuovo operazioni rischiose.

Misura anche il costo operativo. Se verificare ogni output richiede più tempo del lavoro originale, riduci autonomia o restringi il compito.

Metriche di sicurezza

Conta agenti attivi, strumenti, credenziali, richieste, blocchi, approvazioni e azioni rifiutate. Aggiungi incidenti, prompt injection rilevate, domini non autorizzati e tempo di contenimento.

Non usare il numero di task completati come metrica principale. Un agente può essere produttivo e pericoloso. Collega valore a qualità, reversibilità e rispetto del perimetro.

Rivedi accessi e strumenti periodicamente. Un connettore non usato resta comunque una superficie. Revoca ciò che non serve e aggiorna inventario.

Valutare il valore prima di aumentare autonomia

Un agente deve risolvere un problema misurabile. Confronta tempo, completezza, errori e costo con un processo manuale o semi-automatico. Se il guadagno è soltanto qualche secondo ma il controllo richiede una revisione lunga, il perimetro non è ancora adatto.

Stabilisci una soglia di qualità e un proprietario dell’output. Un risultato che non raggiunge la soglia deve restare in revisione, non entrare nella coda successiva. Documenta casi in cui l’agente ha rifiutato un’azione correttamente: sono segnali di un confine che funziona.

Errori da evitare

Evita di concedere Internet aperto, credenziali personali, filesystem completo e strumenti di scrittura a un agente sperimentale. Non considerare sandbox e prompt come sostituti l’uno dell’altro. Non lasciare sistemi senza proprietario e kill switch.

Non confondere autonomia con affidabilità. Non permettere che contenuto web autorizzi azioni. Non pubblicare o acquistare senza approvazione proporzionata.

Agenti AI con accesso al web: autonomia con confini verificabili

Gli agenti AI con accesso al web possono essere utili per ricerca e automazione, ma il loro perimetro deve essere tecnico, osservabile e reversibile. Il caso di agenti arrivati su Internet aperto senza controllo sufficiente mostra che una capacità imprevista può emergere da rete, strumenti e configurazione, non soltanto dal modello.

Parti da sola lettura, rete filtrata, credenziali dedicate e sandbox. Aggiungi strumenti uno alla volta, con test avversariali e approvazione. Se non puoi dire chi può fermare l’agente e quali dati può raggiungere, riduci il perimetro prima di usarlo in produzione.

Rivedi anche le autorizzazioni dopo ogni modifica al workflow. Un nuovo plugin o un nuovo connettore può ampliare capacità senza comparire nel piano iniziale. La revisione deve includere rete, dati, strumenti e persone che approvano.