In breve
Al Black Hat 2026 Snowflake ha lanciato il Cortex AI Gateway, uno strato centralizzato che regola l'accesso degli agenti IA a modelli, dati, server MCP e strumenti aziendali, applicando identità, autorizzazioni, audit e limiti di costo a ogni chiamata. Si basa sulla tecnologia di Natoma, acquisita a maggio 2026, copre gli agenti di terze parti su Amazon Bedrock, Azure AI Foundry, ChatGPT, Cursor, LangChain e LlamaIndex oltre a quelli di Snowflake, ed esce per lo più in private preview, con identità degli agenti e ambito di sessione ristretto già disponibili o quasi.
Per chi guida l'ingegneria il segnale va oltre un singolo fornitore. Insieme alle acquisizioni di Cyera e Okta nell'identità degli agenti nella stessa settimana, il lancio mostra che il «gateway MCP» si sta consolidando da strumento di nicchia a infrastruttura standard. Se nella vostra roadmap ci sono agenti autonomi, uno strato di governance – chi ha chiesto, a cosa può accedere, era consentito, quanto è costato – diventa un componente da progettare fin dall'inizio, non da aggiungere dopo.
Che cosa ha lanciato esattamente Snowflake?
Alla conferenza di sicurezza Black Hat 2026 Snowflake ha presentato il Cortex AI Gateway, descritto come uno strato di controllo centralizzato che regola l'accesso degli agenti IA a modelli, dati, server MCP e strumenti aziendali. Punto decisivo: non si limita agli agenti di Snowflake, ma è pensato per governare da un unico punto anche ecosistemi di terze parti – Amazon Bedrock, Azure AI Foundry, ChatGPT, Claude Code, Cursor e applicazioni personalizzate basate su LangChain o LlamaIndex. Le funzionalità annunciate comprendono autorizzazioni e controllo degli accessi granulari, audit trail in tempo reale delle azioni degli agenti, supporto per oltre 100 server MCP, individuazione e monitoraggio automatici della «shadow AI» e instradamento dei costi con limiti di budget. La maggior parte delle funzionalità arriva in private preview; identità degli agenti e ambito di sessione ristretto sono indicati come disponibili o imminenti.
La tecnologia viene da un'acquisizione. Snowflake ha costruito il gateway su quella di Natoma, startup specializzata in gateway MCP centralizzati acquisita a maggio 2026, nata proprio per applicare identità, policy e audit a livello di chiamata. Significativa la lettura di Mayank Upadhyay, Chief Security and Trust Officer di Snowflake: secondo lui l'IA aziendale si sta spostando dall'interoperabilità dei dati all'interoperabilità degli agenti, e la sicurezza deve stare al centro di questo passaggio. In altre parole, il problema difficile non è più far condividere dati ai sistemi, ma far agire in sicurezza agenti autonomi attraverso quei sistemi. Chi sviluppa seriamente sistemi di agenti IA riconosce il cambiamento: nel momento in cui un agente può fare qualcosa invece di limitarsi a rispondere, il controllo degli accessi smette di essere un dettaglio e diventa la questione centrale.
Perché un agente ha bisogno di un gateway?
Per capire perché si tratta di più di una notizia di prodotto, basta guardare a come la maggior parte dei team collega i primi agenti. Ogni agente riceve delle credenziali e si connette direttamente agli strumenti che gli servono: un database, un'API interna, un'applicazione SaaS, uno o due server MCP. In demo funziona. Come governance smette di funzionare appena gli agenti diventano una dozzina, perché ognuna di quelle connessioni dirette è un percorso separato con chiavi proprie, un proprio raggio d'impatto e spesso nessun log centrale. Alla domanda «quale agente ha letto la tabella clienti stanotte, ed era autorizzato?» spesso non c'è una risposta chiara.
Il gateway ribalta lo schema. Invece di agenti che custodiscono credenziali e chiamano direttamente gli strumenti, ogni chiamata passa da un unico punto di controllo che a ogni richiesta verifica tre cose: chi ha richiesto l'azione, quali permessi ha e se l'azione è consentita – e poi la registra. È questo collo di bottiglia unico a rendere possibili privilegio minimo, revoca pulita, audit in tempo reale e limiti di spesa. Ed è sempre lui a far emergere la shadow AI: agenti e integrazioni non autorizzati, attivati in sordina, che non si possono governare perché nessuno li vede. Il modello del gateway riprende di proposito un'idea che il settore accetta già per API e identità – un ingresso che applica le policy – adattata a una nuova realtà: a chiamare ora sono agenti semi-autonomi, non applicazioni guidate da persone.
Perché è una tendenza e non un singolo prodotto?
A fare di questo lancio un cambiamento architetturale, più che un titolo su Snowflake, è il tempismo. Il Cortex AI Gateway non è arrivato da solo: gli analisti hanno notato nello stesso periodo una concentrazione di operazioni sull'identità degli agenti, tra cui l'acquisizione di Oasis da parte di Cyera per circa 1 miliardo di dollari e l'acquisizione di Permiso da parte di Okta, mentre Snowflake schierava al lancio una serie di partner per l'identità – 1Password, Aembit, Cyera, Okta, SailPoint, Saviynt e altri. Quando più grandi fornitori puntano sulla stessa capacità nel giro di pochi giorni, di solito è perché una categoria si sta consolidando, non perché un'azienda ha avuto un'idea brillante.
Ciò che si consolida è il gateway MCP come strato orizzontale. Un anno fa il Model Context Protocol era discusso soprattutto come modo per collegare un agente agli strumenti. Ora il dibattito è salito di un livello: dato che gli agenti saranno collegati a molti strumenti, chi sta nel mezzo a far rispettare identità, policy, audit e costi? Quello strato intermedio è il gateway, e somiglia sempre meno a un prodotto di sicurezza facoltativo e sempre più all'equivalente di un API gateway o di un identity provider: un'infrastruttura che si dà per scontata in ogni adozione seria di agenti. Per questo la lezione vale anche se non userete mai Snowflake: la forma dello stack si sta assestando e la governance vi compare come un blocco a sé.
Cosa significa per i team software in Italia e in Europa?
La prima conseguenza: la governance degli agenti si decide in fase di progettazione, non è un lavoro di pulizia. Aggiungere a posteriori identità e audit ad agenti che toccano già i dati di produzione è faticoso e quasi mai completo. I team che adottano presto il modello del gateway – un'identità limitata per agente, chiamate instradate verso un unico punto di policy, tutto registrato – ottengono la governance quasi gratis; chi rimanda eredita una rete di connessioni dirette non tracciabile e costosa da sbrogliare.
La seconda: tutto questo si sovrappone a obblighi di conformità che avete già. Un audit trail in tempo reale a livello di chiamata è esattamente l'evidenza che i revisori chiedono per SOC 2, e lo stesso vale per DORA e per l'AI Act europeo, che chiedono sempre più di dimostrare chi o che cosa ha avuto accesso ai dati e se l'azione era autorizzata. Nei progetti regolamentati in ambito FinTech e sanità digitale, un agente in grado di leggere dati regolamentati senza un'identità governata e revocabile è una lacuna di controllo, non una comodità. Il gateway trasforma l'affermazione «i nostri agenti sono sotto controllo» in un'evidenza concreta.
La terza è una questione di costi facile da sottovalutare: gli agenti possono spendere in fretta. Un agente che ripete le chiamate, moltiplica i sotto-agenti o resta in loop su un compito difficile può far lievitare i costi di token e strumenti senza alcuna persona nel flusso di approvazione. Limiti di budget e instradamento dei costi nel gateway fanno la differenza tra accorgersene con un alert e scoprirlo in fattura. Che costruiate lo strato di controllo in casa o lo acquistiate, la governance da ottenere è la stessa: identità, policy, audit e limiti di spesa, applicati in un unico punto di cui il vostro team piattaforma e DevOps sia davvero responsabile.
Cosa fare adesso
Non serve adottare un gateway specifico in questo trimestre. Serve però smettere di trattare la governance degli agenti come qualcosa da «aggiungere più avanti». Ecco la versione concreta.
- Censite agenti e integrazioni. Elencate ogni agente e ogni collegamento a uno strumento, compresi quelli non ufficiali: non si governa una shadow AI che non si vede.
- Date a ogni agente un'identità propria. Sostituite le chiavi condivise con identità limitate al privilegio minimo, una per agente, così che gli accessi siano attribuibili e revocabili.
- Instradate le chiamate attraverso un unico punto di controllo. Anche un gateway interno leggero è meglio di una dozzina di connessioni dirette; ogni azione deve passare da un punto in grado di consentirla, negarla e registrarla.
- Attivate l'audit e trattatelo come evidenza di conformità. Conservate log a livello di chiamata e collegateli fin da ora agli obblighi SOC 2, DORA, GDPR e AI Act, non il giorno dell'audit.
- Aggiungete limiti di spesa. Fissate budget e alert per agente, così che un agente in loop faccia scattare un limite invece di una fattura a sorpresa.
- Progettatelo fin dall'inizio nei nuovi progetti. Se siete all'inizio, inserite lo strato di governance nell'architettura da subito; aggiungerlo dopo costa molto di più.
Niente di tutto questo è un giudizio sul Cortex AI Gateway in sé; è una solida implementazione di un modello che sta rapidamente diventando lo standard. L'insegnamento duraturo è architetturale: mentre gli agenti passano dal rispondere all'agire, l'ingresso governato davanti a loro sta diventando infrastruttura – e i team che lo inseriscono ora nella progettazione faticheranno molto meno, in seguito, a dimostrare di avere il controllo.
Domande frequenti
Che cos'è un gateway MCP?
Un gateway MCP è un punto di controllo centralizzato che si colloca tra gli agenti IA e i modelli, i dati, gli strumenti e i server Model Context Protocol (MCP) che richiamano. Invece di collegare ogni agente direttamente a ogni strumento con credenziali proprie, le chiamate passano dal gateway, che applica identità, autorizzazioni, policy e audit a livello della singola chiamata. Per ogni azione di un agente risponde a tre domande: chi l'ha richiesta, quali permessi ha e se l'azione è consentita. Il Cortex AI Gateway di Snowflake, presentato al Black Hat 2026, ne è un esempio di rilievo, costruito sulla tecnologia della startup Natoma acquisita da Snowflake.
Che cosa ha annunciato Snowflake al Black Hat 2026?
Snowflake ha lanciato il Cortex AI Gateway, uno strato di controllo che regola l'accesso degli agenti IA a modelli, dati, server MCP e strumenti aziendali. Copre sia gli agenti di Snowflake sia ecosistemi di terze parti come Amazon Bedrock, Azure AI Foundry, ChatGPT, Claude Code, Cursor e applicazioni personalizzate basate su LangChain o LlamaIndex. Tra le funzionalità: autorizzazioni granulari, audit trail in tempo reale, supporto per oltre 100 server MCP, individuazione automatica della shadow AI e instradamento dei costi con limiti di budget. La maggior parte delle funzionalità è in private preview; l'identità degli agenti e l'ambito di sessione ristretto sono disponibili o in arrivo a breve. Il gateway si basa sulla tecnologia di Natoma, startup specializzata in gateway MCP acquisita da Snowflake a maggio 2026.
Perché gli agenti IA hanno bisogno di uno strato di governance?
Perché un agente autonomo non si limita a rispondere: agisce con credenziali reali, richiama strumenti, legge dati e avvia flussi di lavoro su molti sistemi. Senza un gateway centrale, ogni collegamento tra agente e strumento è un percorso separato, spesso non registrato, con permessi propri. Diventa impossibile sapere chi ha fatto cosa, è difficile revocare un accesso in modo pulito ed è facile che compaiano agenti ombra non autorizzati. Un gateway di governance offre un unico punto per imporre il privilegio minimo, mantenere un audit trail in tempo reale a livello di chiamata, limitare la spesa fuori controllo e dimostrare il controllo ai revisori secondo SOC 2, DORA, GDPR e AI Act.
Riguarda solo chi usa Snowflake?
No. Il lancio di Snowflake è l'esempio più evidente, ma il modello è indipendente dal fornitore. Nella stessa settimana Cyera e Okta hanno concluso acquisizioni nel campo dell'identità degli agenti, e il gateway stesso è pensato per governare agenti esterni a Snowflake, costruiti su Bedrock, Azure AI Foundry, ChatGPT, Cursor, LangChain e LlamaIndex. La lezione è architetturale: se sviluppate o acquistate IA agentica, uno strato di governance in stile gateway MCP – identità, policy, audit e controllo dei costi a livello di chiamata – sta diventando un componente standard e non un'aggiunta facoltativa, qualunque sia la piattaforma scelta.
Cosa dovrebbero fare subito i team di sviluppo?
Censite gli agenti e le integrazioni con gli strumenti già in uso, comprese quelle non ufficiali: non si può governare ciò che non si vede. Assegnate a ogni agente un'identità propria con permessi minimi invece di chiavi condivise e instradate le chiamate agli strumenti attraverso un unico gateway, così che ogni azione sia registrata e revocabile. Aggiungete limiti di budget per intercettare presto la spesa fuori controllo e trattate l'audit trail come evidenza di conformità per SOC 2, DORA, GDPR e AI Act. Se siete all'inizio, progettate lo strato di governance fin da subito invece di aggiungerlo dopo, quando gli agenti toccano già i dati di produzione.
Fonti
Snowflake — Enterprise AI security and agentic MCP governance with Cortex AI Gateway
VentureBeat — Snowflake launches Cortex AI Gateway to control AI agents and prevent runaway enterprise costs
Yahoo Tech — Snowflake's Cortex AI Gateway signals MCP gateways are crystallizing as infrastructure
Cybersecurity Magazine — Snowflake launches Cortex AI Gateway to govern agentic AI