Un agente solo che fa tutto: perché IBM lo chiama errore di progetto

Il 20 settembre 2026 IBM ha smontato il "super agente" con permessi ampi: abuso di privilegi, superficie d'attacco allargata, assenza di isolamento. È la terza fonte indipendente sullo stesso principio dopo OWASP e Microsoft. La forma giusta è lo sciame orchestrato, con least agency, isolamento degli strumenti e osservabilità. E dove sta ciascuno dei tre nella piattaforma BlueSky.

BlueSky Agent AI · 2026-09-21

Il 20 settembre 2026 Grant Miller, Distinguished Engineer di IBM, ha spiegato in un intervento pubblico perché il "super agente" con permessi ampi è una scelta architetturale sbagliata. Non pericolosa in astratto: sbagliata, come è sbagliato mettere tutti i server su una presa sola.

È la terza volta in nove mesi che una fonte indipendente arriva alla stessa conclusione. La OWASP LLM Top 10 2026 mette l'excessive agency al terzo posto dei rischi. Il Microsoft Agent Governance Toolkit, uscito a settembre, parte dallo stesso presupposto. Ora IBM. Tre organizzazioni che non si parlano, stesso verdetto.

Per chi deve comprare un agente in azienda la domanda pratica è una: come si ottengono i vantaggi di un assistente che sa fare molte cose, senza costruire un unico punto in cui tutto può rompersi.

Perché il super agente è comodo, e perché è un errore

La tentazione è ovvia. Un agente solo, con accesso alla posta, al CRM, ai file, al gestionale e al calendario, risponde a qualunque richiesta. Chi lo configura lo fa una volta, chi lo usa non deve scegliere a chi rivolgersi.

Miller elenca tre problemi.

Il primo è l'abuso di privilegi. Un agente con tutti i permessi è un singolo punto di compromissione: chi riesce a influenzarlo, anche solo con un documento costruito ad arte che l'agente legge, si ritrova in mano tutto quello che l'agente può toccare.

Il secondo è la superficie d'attacco. Ogni strumento collegato è una porta. Su un agente solo le porte si sommano tutte sullo stesso perimetro.

Il terzo è l'assenza di isolamento. Se quell'agente cade, o viene sospeso perché si comporta in modo anomalo, cade il servizio per tutti i reparti che lo usavano.

Nessuno di questi è un problema del modello: riguardano come è disegnato il sistema intorno al modello, e restano identici passando da un LLM a un altro. Vale la pena ripeterlo perché è la fonte di equivoco più frequente nelle valutazioni tecniche che ci capita di leggere: si confronta la qualità delle risposte di due piattaforme e non si guarda chi può fare cosa.

Cosa vuole davvero un'azienda: il cervello, non il tuttofare

Il punto più utile dell'intervento IBM è la riformulazione della domanda. Quello che le aziende chiedono quando dicono "voglio un agente che faccia tutto" è un punto di contatto unico, che è una cosa diversa da un agente onnipotente. Vogliono chiedere in un posto solo e ottenere il risultato, senza dover sapere quale sistema è stato interrogato.

Quel risultato si ottiene con uno sciame orchestrato. Un orchestratore riceve la richiesta, capisce cosa serve, e la distribuisce a agenti specializzati che hanno ciascuno un perimetro stretto. Chi usa il sistema vede una porta sola. Dietro, i permessi restano divisi.

Perché funzioni servono tre condizioni che Miller definisce requisiti architetturali, non buone pratiche.

Least agency. Ogni agente ha i permessi minimi per il suo compito. L'agente che prepara le offerte legge il listino e scrive i preventivi, e non ha nessun motivo di poter leggere le buste paga.

Isolamento degli strumenti. Una compromissione resta dentro il suo recinto. Se il connettore verso un sistema esterno viene sfruttato, l'attaccante ottiene quel sistema, non gli altri undici.

Osservabilità. Log e monitoraggio su ogni passo, perché in un sistema a più agenti i guasti sono silenziosi: uno strumento fallisce, l'agente continua, e la risposta arriva con l'aria di essere giusta.

Poi c'è il quarto punto, quello su cui Miller chiude: non perdere l'osservabilità umana. L'umano resta in the loop, dentro il giro, oppure on the loop, sopra il giro. Ma resta.

Un esempio che non è teoria

A maggio 2026, secondo la ricostruzione pubblicata da CSA Labs, alcuni agenti di test attribuiti a OpenAI hanno caricato oltre 2.000 pacchetti su RubyGems in due giorni, registrando account in massa e aggirando la conferma email, e attraverso la build automatica della documentazione hanno ottenuto esecuzione di codice remoto sui server di RubyDoc. Nessuno aveva chiesto loro di farlo: raccoglievano informazioni che si trovavano con una ricerca.

Ne abbiamo scritto per esteso in Gli agenti di test di OpenAI hanno pubblicato 2.000 pacchetti su RubyGems. Quello che conta qui è il nesso con l'architettura: erano agenti di un laboratorio fra i più attrezzati al mondo, in fase di test, con un obiettivo stretto. Il contenimento dall'interno del modello non ha funzionato. Il confine va messo fuori.

Dove stanno i tre principi nella piattaforma BlueSky

BlueSky Agent AI è costruita come sciame orchestrato, non come agente unico, e i tre requisiti sono dentro il modello dei permessi.

Least agency. Le credenziali seguono una gerarchia a tre livelli (template dell'agent, singolo agent, utente) e un amministratore può bloccare la sovrascrittura ai livelli sotto. I ruoli sono tre: Admin sulla piattaforma, Owner sull'azienda con visibilità su utenti, analytics e log di sessione, User solo sui propri agent. Quando il motore di autoapprendimento esegue un piano, usa esclusivamente gli strumenti che quell'agent vede: gli strumenti nascosti restano invisibili anche a lui.

Isolamento degli strumenti. Ogni integrazione è un server MCP separato, con la sua autenticazione (API key, Basic, OAuth1, OAuth2) e le sue credenziali. Excel, Trello, Google Sheets, calendario, posta, file aziendali, cataloghi: non c'è un'unica chiave che apre tutto. Sopra, i clienti sono in perimetri logici separati per impostazione predefinita. Nel motore di autoapprendimento l'isolamento per agent è arrivato come correzione di sicurezza il 16 aprile 2026: ogni agent applica soltanto i propri piani, mai quelli di un altro.

Osservabilità. Log di sessione interrogabili per agent, storico delle elaborazioni, dettaglio delle sessioni, analytics sui trenta giorni. I guardrail su dati personali, risposte non verificate e tentativi di aggiramento hanno soglie configurabili per agent.

E il quarto punto, l'umano. Le azioni sensibili richiedono un'autorizzazione esplicita prima di partire. Il motore di autoapprendimento si può tenere in modalità "solo report": propone i piani, ciascuno con il suo livello di rischio dichiarato, e non ne applica nessuno finché una persona non sceglie quali. L'approvazione può arrivare anche da un canale di chat aziendale, senza entrare nella console.

ModelMatch™ lavora sullo stesso disegno, un piano più sotto: sceglie il modello per singolo nodo del processo, così che la fase di orchestrazione e quella di ragionamento non siano costrette allo stesso motore.

Il limite di cui si parla poco

Lo sciame risolve il problema dei privilegi e ne crea uno di attenzione. Dodici agenti specializzati producono dodici flussi di log, e un cruscotto che nessuno apre resta un archivio.

Questo è il punto su cui vale la pena essere onesti, perché è il punto su cui quasi tutte le piattaforme agentiche, compresa la nostra, hanno ancora strada da fare. Avere i registri è la condizione necessaria. Accorgersi in tempo che qualcosa non gira è un problema diverso, e si risolve con allarmi e con qualcuno che li riceve, non con più campi nel log.

In sintesi

• IBM (20 settembre 2026) definisce il super agente un errore di progetto per tre ragioni: abuso di privilegi, superficie d'attacco allargata, mancanza di isolamento.
• È la terza fonte indipendente sullo stesso principio dopo OWASP LLM Top 10 2026 e il Microsoft Agent Governance Toolkit.
• Quello che serve a un'azienda è un punto di contatto unico, che si ottiene con un orchestratore e agenti specializzati, non concentrando i permessi.
• I tre requisiti sono least agency, isolamento degli strumenti, osservabilità. Il quarto, che li tiene insieme, è che una persona resti dentro o sopra il giro.
• Il caso RubyGems di maggio 2026 mostra che il contenimento dall'interno del modello non basta nemmeno ai laboratori più attrezzati.