I gateway per agenti concentrano il potere sull'intera IA aziendale
Esiste uno schema che si ripete ogni volta che una tecnologia passa dall'essere un esperimento a diventare infrastruttura critica: a un certo punto emerge uno strato di controllo che nessuno aveva pianificato formalmente, ma che finisce per essere il luogo in cui si prendono le decisioni più importanti. È accaduto con i bilanciatori di carico nel web, con i piani di controllo nel cloud e con i service mesh nell'era dei microservizi. Ora sta accadendo con gli agenti di intelligenza artificiale, e il nome che sta prendendo quello strato è quello di gateway per agenti.
Nella prima settimana di luglio 2026, due distinte mosse aziendali hanno confermato che questa categoria non è più un concetto in costruzione. Arcade ha messo il suo motore di autorizzazione ed esecuzione degli strumenti a disposizione diretta dei marketplace di Microsoft Azure e AWS, consentendo alle aziende di distribuirlo all'interno del proprio cloud con un solo clic. Un giorno prima, Manufact aveva aperto il suo cloud di hosting MCP — basato sul Model Context Protocol — per portare un server da un repository di codice a un punto di produzione monitorato. Nessuno dei due ha fatto un annuncio straordinario. Ma insieme segnalano qualcosa di preciso: il mercato sta installando le strutture di governance per l'IA agentiva prima che le organizzazioni abbiano finito di capire cosa hanno effettivamente distribuito.
Nutanix aveva già fissato la geometria di questa categoria a maggio, quando aveva lanciato come prodotto disponibile in modo generale il suo gateway per agenti all'interno della versione 2.7 di Nutanix Enterprise AI. La soluzione funziona come un punto centralizzato di controllo che gestisce il traffico dagli agenti verso i modelli linguistici e dagli agenti verso gli strumenti aziendali che questi invocano. Instradata le richieste, applica l'autenticazione, gestisce i permessi per strumento, registra ogni chiamata a fini di audit e misura il consumo di token per agente e per team. L'agente del servizio clienti può ottenere accesso in sola lettura al database; l'agente DevOps può avere permessi di scrittura completa su GitHub. Se il fornitore principale si guasta o raggiunge un limite, il traffico ricade automaticamente sul fornitore di backup configurato.
Ciò che rende questo momento strategicamente rilevante non è la funzionalità in sé. È che per la prima volta il mercato sta nominando e confezionando il luogo in cui si concentra il potere sull'IA aziendale.
Chi era nella stanza quando è stato progettato il governo
Per comprendere l'importanza di questo strato, conviene osservare come funziona un agente di IA in produzione senza di esso. Un agente non agisce mai da solo per molto tempo: chiama un modello per ragionare, poi chiama degli strumenti — GitHub, Stripe, un database, un'API interna — per eseguire. Frequentemente genera sotto-agenti che ripetono lo stesso ciclo. Ogni chiamata consuma token e tocca un sistema con i propri permessi. Senza un punto centralizzato di controllo, un'organizzazione finisce con decine di agenti connessi direttamente ai sistemi di produzione, senza un luogo unico da cui vedere il traffico, bloccarlo o verificarlo.
Questa architettura distribuita senza governance non è solo un rischio operativo. È anche una questione di potere e di progettazione. Quando non esiste un piano di controllo esplicito, la governance degli agenti non scompare: si frammenta e diventa implicita. Le decisioni su quali strumenti può invocare ciascun agente, con quale identità, in quali condizioni e con quale portata di permessi vengono prese dai team che hanno costruito ciascun agente separatamente, con una coerenza minima tra di loro.
Il risultato strutturale è prevedibile: l'intelligenza periferica rimane invisibile. I team che operano ai margini del sistema — quelli che conoscono i casi d'uso atipici, quelli che lavorano con dati sensibili dei clienti, quelli che vedono gli effetti di secondo ordine delle automazioni — non hanno rappresentanza nella progettazione di ciò che gli agenti possono e non possono fare. Le decisioni su permessi, portata e accesso vengono prese una volta sola, al momento del dispiegamento iniziale, dal team tecnico che ha costruito l'agente, senza meccanismi di revisione centralizzata né di incorporazione di prospettive diverse.
Il gateway per agenti cambia questo, almeno potenzialmente. Centralizza la governance in un unico punto in cui le politiche di accesso, autenticazione e audit possono essere riviste, aggiornate e applicate in modo coerente. Ma la domanda che questo progetto apre non è tecnica: è chi controlla quel punto centrale e con quali criteri.
Il consolidamento che è già in atto
Il mercato sta dando due risposte simultanee e opposte a quella domanda, ed entrambe rivelano una tensione di fondo su chi dovrebbe essere il custode dello strato di controllo.
La prima risposta è l'integrazione all'interno di piattaforme di sicurezza proprietarie. Palo Alto Networks ha completato nel maggio 2026 l'acquisizione di Portkey, un gateway di IA autonomo orientato alla governance degli agenti, per incorporarlo nella sua piattaforma di sicurezza. L'argomento è coerente: se gli agenti con privilegi elevati sono il nuovo vettore di rischio aziendale, il controllo su ciò che possono fare è un'estensione naturale del perimetro di sicurezza. La governance degli agenti diventa così parte del portfolio di zero-trust e accesso privilegiato che i grandi venditori di cybersicurezza già amministrano.
La seconda risposta è la governance aperta. Solo.io ha donato il suo progetto agentgateway all'Agentic AI Foundation sotto l'egida della Linux Foundation, trasformandolo nel quarto progetto ospitato del gruppo. Il progetto, scritto in Rust, gestisce traffico MCP, da agente ad agente, HTTP e gRPC attraverso un unico piano dati, e conta già oltre 300 contributori provenienti da 60 organizzazioni, tra cui CoreWeave, Red Hat, Adobe, Salesforce e Microsoft. La logica qui è altrettanto coerente ma punta nella direzione opposta: se il gateway per agenti è l'infrastruttura centrale di tutta l'IA aziendale, nessun singolo fornitore dovrebbe esserne il proprietario.
Queste due mosse non sono semplicemente strategie commerciali diverse. Sono due teorie differenti su dove dovrebbe risiedere il potere sull'infrastruttura di IA. La prima colloca quel potere nel perimetro di sicurezza di grandi corporation tecnologiche. La seconda lo distribuisce verso una comunità di contributori sotto una governance neutrale.
Ciò che l'analisi strutturale rivela è che la scelta tra queste due opzioni non è in primo luogo tecnica né finanziaria: è una decisione sulle architetture di potere. Un'azienda che sceglie di integrare il suo gateway all'interno della piattaforma di un fornitore di sicurezza sta delegando la progettazione delle proprie politiche di governance degli agenti alla roadmap di quel fornitore. Un'azienda che adotta il progetto sotto Linux Foundation assume una maggiore responsabilità tecnica ma mantiene la capacità di influenzare collettivamente il modo in cui evolve lo strato di controllo.
I tre punti ciechi che il mercato non risolve ancora
L'articolo originale di Forbes formula tre domande di due diligence per gli acquirenti aziendali, e tutte e tre condividono una caratteristica comune: sono tecniche nella formulazione ma organizzative in ciò che rivelano.
La prima domanda riguarda la proprietà: quali parti della governance sono proprie del fornitore e quali sono involucri sottili attorno ai primitivi di AWS o Azure che l'azienda paga già. Questa domanda sembra finanziaria, ma nel suo fondo riguarda la dipendenza di progettazione. Se la governance degli agenti è esternalizzata in strati che il team interno non può verificare né modificare, l'organizzazione non controlla la propria IA, anche se nominalmente la gestisce.
La seconda domanda riguarda il comportamento dei costi: cosa succede alla fattura quando il volume delle chiamate agli strumenti raddoppia o quando gli agenti distribuiti non raggiungono le assunzioni del fornitore. Gartner ha proiettato che più del 40% dei progetti di IA agentiva verranno cancellati prima del 2027 a causa di costi crescenti e controlli del rischio insufficienti. L'ironia strutturale è che gli stessi gateway che si posizionano come soluzione a quel rischio possono diventare uno strato di costi opaco se il loro modello di prezzi scala insieme al volume degli agenti.
La terza domanda riguarda la consistenza del controllo: se l'autenticazione viene applicata per ogni strumento e ogni metodo del protocollo MCP, o solo per i più evidenti. CyCognito ha documentato sistematicamente che il fallimento più comune negli ambienti di produzione non è l'assenza totale di controlli, ma l'applicazione inconsistente di quelli esistenti. Un agente che ha accesso non autenticato a un server MCP esposto è, nei termini di CyCognito, un catalogo pubblico delle operazioni aziendali.
Ma c'è un quarto punto cieco che nessuna di queste domande cattura direttamente, ed è quello che interessa maggiormente da una prospettiva di progettazione organizzativa. I gateway per agenti centralizzano la governance, ma non garantiscono che quella governance sia intelligente. Un punto centrale di controllo può replicare e amplificare gli stessi pregiudizi e punti ciechi che avevano i team che hanno progettato le politiche originali, ora con maggiore velocità e portata. La governance centralizzata senza diversità di prospettive nella progettazione delle politiche non è governo: è omogeneità con una copertura migliore.
Il piano di controllo è anche un piano di potere
Il paragone storico che gli analisti usano solitamente è quello dei service mesh nell'era dei microservizi. Quando Envoy e Istio emersero come piani di controllo per il traffico tra servizi, trasformarono l'architettura di rete aziendale e definirono chi poteva osservare e governare le comunicazioni tra componenti. Il parallelismo con i gateway per agenti è tecnicamente preciso, ma omette una dimensione che nel caso dell'IA agentiva risulta più significativa.
I microservizi spostavano dati e logica di business. Gli agenti di IA prendono decisioni, eseguono azioni e generano conseguenze nei sistemi di produzione con o senza supervisione umana diretta. Il piano di controllo che si sta costruendo ora non gestisce solo traffico: definisce cosa può fare l'IA di un'organizzazione, con quale autorità, su quali sistemi e in quali condizioni di revisione. Questa non è solo una decisione di infrastruttura.
Quando Nutanix, Arcade o Manufact parlano di filtraggio per strumento, autenticazione centralizzata e registrazione degli audit, stanno descrivendo il meccanismo tecnico. Ma la politica che gira su quel meccanismo — chi può invocare cosa, con quale portata, in quali condizioni di override — è una decisione organizzativa che nella maggior parte delle aziende viene ancora presa senza un framework di governance esplicito, dai team che hanno accesso tecnico al sistema nel momento in cui viene distribuito.
Il gateway per agenti è l'infrastruttura che rende possibile una governance centralizzata dell'IA agentiva. Se le organizzazioni lo adottano come soluzione tecnica senza rivedere chi progetta le politiche che vi vengono eseguite, avranno costruito un piano di controllo molto efficiente per automatizzare gli stessi punti ciechi che avevano prima di installarlo.
L'architettura di potere che questo mercato sta costruendo è sofisticata e sta maturando rapidamente. Ciò che non è ancora risolto è se le organizzazioni che la adotteranno progetteranno le proprie politiche di governance con una diversità di prospettive sufficiente affinché quel controllo sia qualcosa di più della semplice velocità aggiunta ai pregiudizi esistenti.
