Sicurezza dei dati degli agenti AI: cosa succede quando si connettono ai sistemi?

L'IA sta passando dalla generazione di risposte all'esecuzione di azioni in sistemi reali. Questo cambiamento ridisegna la domanda centrale sulla sicurezza. Non è più sufficiente chiedersi se il modello sia accurato o affidabile: bisogna anche verificare come si comporta il sistema circostante quando il modello fraintende un'istruzione, riceve un input malevolo o ottiene più autorità del necessario per il compito. Protocolli come MCP facilitano la creazione di connessioni tra agenti e sistemi, ma rendono anche impossibile ignorare la progettazione di quelle connessioni.

Collegare un agente IA a un sistema aziendale può esporre diverse categorie di dati a componenti differenti, tra cui l'host dell'IA, il server degli strumenti, il provider di identità e l'applicazione downstream. MCP definisce come comunicano le parti di quella connessione, ma non stabilisce quali dati ogni implementazione archivia, espone o conserva.

Dalle risposte alle conseguenze

Collegare un agente non crea un unico confine di fiducia: genera una catena di confini. L'host dell'IA interpreta la richiesta, un client di protocollo seleziona una capacità, un server degli strumenti convalida e traduce la chiamata, un provider di identità stabilisce chi sta agendo e il sistema downstream applica le autorizzazioni e registra il risultato. MCP standardizza una parte di quella comunicazione, ma da solo non rende sicura l'intera catena: la sicurezza dipende dalle decisioni prese a ogni livello.

La prima generazione di IA generativa, ampiamente diffusa, produceva soprattutto contenuti destinati alla revisione umana: testo, immagini, riassunti e codice. Oggi gli agenti operano sempre più spesso degli strumenti: inviano messaggi, modificano record, attivano flussi di lavoro, spostano denaro e controllano processi fisici. Una risposta plausibile ma errata è un inconveniente; un'azione plausibile ma errata può avere conseguenze immediate.

Standard come MCP rendono gli strumenti individuabili e richiamabili tramite interfacce strutturate. È un miglioramento importante rispetto allo screen scraping o alle integrazioni improvvisate, ma la struttura da sola non è un criterio di sicurezza. Il progettista dello strumento decide comunque quali azioni esistono, quali input accettano, quale identità utilizzano e quali evidenze restituiscono.

Abbiamo riscontrato questa distinzione durante lo sviluppo del server MCP di ezeep. La stampa rende il problema tangibile, perché la decisione di un agente può tradursi in un output fisico in pochi secondi. La lezione, tuttavia, si applica a qualsiasi sistema che esegua operazioni.

Dove vanno realmente i dati

L'affermazione «Il modello non vede mai la vostra password» è utile, ma non descrive completamente il flusso dei dati. Una tipica connessione di un agente coinvolge varie categorie di informazioni: credenziali gestite da un livello di autenticazione, argomenti dello strumento costruiti a partire dalla richiesta dell'utente, risultati operativi restituiti al modello, payload aziendali trasferiti al servizio downstream e log conservati da uno o più componenti. Di norma il modello riceve la conversazione, le descrizioni degli strumenti disponibili, gli argomenti necessari per richiamare lo strumento selezionato e il risultato restituito da quel tool.

Queste categorie non seguono necessariamente lo stesso percorso. OAuth può mantenere una password e un bearer token al di fuori del contesto del modello, mentre il risultato dello strumento può comunque esporre nomi di clienti, posizioni dei dispositivi, valori finanziari o metadati interni del sistema. Un documento può transitare direttamente tra servizi, mentre il nome del file, la destinazione e lo stato compaiono nella conversazione. L'host dell'IA, il server degli strumenti, il provider di identità e il sistema di destinazione possono inoltre avere criteri di registrazione e di conservazione dei dati diversi.

Non esiste quindi un'affermazione universale e responsabile del tipo «l'IA non vede i dati». Le domande giuste sono: quali dati riceve ogni livello, perché ne ha bisogno, per quanto tempo li conserva e se gli utenti comprendono questo confine. La nostra implementazione di MCP offre esempi concreti di queste distinzioni, ma il problema di progettazione riguarda ogni sistema connesso a un agente.

L'identità determina il raggio d'impatto

Un agente non dovrebbe avere autorità indipendente. Può agire tramite un'identità di servizio condivisa o per conto di un singolo utente: nessuno dei due modelli è universalmente corretto. Un'identità condivisa è adatta ai flussi di lavoro non presidiati, ma ogni azione eredita l'ambito di quell'account. L'autorizzazione per singolo utente offre un accesso più limitato e un'attribuzione più chiara, ma richiede che ogni utente si autentichi e che l'applicazione gestisca correttamente le singole sessioni. L'interpretazione di una richiesta da parte dell'agente non deve mai sostituire l'autorizzazione applicata dal sistema di destinazione.

La decisione ingegneristica importante non è quale modello sembri più sicuro in astratto, ma se l'identità si adatti al flusso di lavoro e se le sue autorizzazioni siano più limitate delle conseguenze di un errore. Nel nostro lavoro su ezeep MCP supportiamo entrambi i modelli, perché un servizio di magazzino automatizzato e un dipendente che stampa in modo interattivo hanno requisiti di identità sostanzialmente diversi.

Chi è responsabile quando un agente AI compie un'azione?

Questo è un problema di progettazione del sistema, non soltanto un problema di fiducia nel modello. Un'architettura più sicura combina diversi controlli: identità a privilegi minimi, capacità ristrette e tipizzate, convalida nel sistema a valle, conferma per le azioni con conseguenze importanti, separazione tra istruzioni attendibili e contenuti non attendibili, e una traccia di audit che mostri cosa è realmente accaduto. La definizione dell'ambito limita i danni potenziali; osservabilità e attribuzione stabiliscono la responsabilità dopo che un'azione è stata eseguita.

Progettare per la reversibilità

Un test utile per qualsiasi capacità di un agente non è soltanto se l'azione sia permessa, ma cosa succede quando è sbagliata. Le operazioni di lettura, le modifiche ripristinabili, gli impegni finanziari, le comunicazioni esterne e le operazioni amministrative distruttive richiedono controlli differenti. Alcune azioni dovrebbero richiedere una conferma. Alcune dovrebbero prevedere il ripristino. Altre non dovrebbero essere esposte all'agente in alcun caso.

Durante lo sviluppo del server MCP di ezeep abbiamo scelto di non esporre l'eliminazione di utenti, gruppi o stampanti, anche se esistono API REST correlate. Questo non rende innocui gli altri strumenti — la stampa produce output fisico e gli strumenti amministrativi possono modificare gli accessi — ma elimina una categoria di errori irreversibili. Il principio è più ampio della stampa: la progettazione delle capacità dovrebbe rispecchiare le conseguenze, non solo la disponibilità tecnica.

L'iniezione di prompt può indurre un agente AI a compiere l'azione sbagliata?

Sì. Un agente può incontrare istruzioni nascoste in documenti, pagine web, e‑mail, ticket di supporto o risultati degli strumenti. Questo fenomeno è comunemente chiamato iniezione di prompt indiretta: contenuti che avrebbero dovuto essere trattati come dati tentano invece di influenzare ciò che l'agente farà dopo.

Quel rischio non si risolve chiedendo al modello di «fare attenzione». I contenuti non attendibili non dovrebbero poter concedere autorizzazioni, modificare l'obiettivo dell'utente, scegliere un'identità più privilegiata o aggirare la conferma. Gli input degli strumenti richiedono convalida deterministica, le azioni con conseguenze rilevanti necessitano di controlli basati su criteri esterni al modello e i flussi di lavoro sensibili dovrebbero separare chiaramente le istruzioni attendibili dal materiale non attendibile.

Anche la catena di fornitura degli strumenti conta. Le descrizioni degli strumenti influenzano il comportamento del modello, quindi connettere un nuovo server è di per sé una decisione di sicurezza — non una semplice impostazione di comodo.

La sicurezza si decide a ogni livello

Connettere un agente a un sistema reale è una decisione di progettazione che si prende a ogni livello: quali azioni esistono, quale identità usano, quali dati vede ogni componente, cosa può essere annullato e cosa viene registrato. L'MCP standardizza una parte di questa conversazione. Il resto spetta a chi realizza la connessione. Nel server MCP di ezeep questo ha significato supportare sia identità di servizio sia identità per utente e non esporre l'eliminazione di utenti, gruppi o stampanti. Ogni agente prima o poi sbaglierà, quindi la connessione deve essere progettata per quel momento — ed è così che abbiamo costruito il server MCP di ezeep.

Volete usare ezeep MCP?

Collegate oggi stesso il nostro MCP ai vostri agenti.

Provate gratuitamente