Le tue API sono già gli strumenti dei tuoi agenti: l’AI Gateway come proxy MCP

Nei primi tre articoli di questa serie abbiamo seguito una traiettoria precisa: l’AI Gateway come evoluzione naturale dell’API Gateway per governare il traffico verso i modelli, l’AI sprawl come nuovo capitolo di una storia che il mondo API conosce già, la governance operativa necessaria quando i sistemi AI smettono di rispondere e cominciano ad agire. Resta una domanda che nei progetti reali arriva sempre per prima: gli agenti agiscono attraverso strumenti — ma questi strumenti da dove vengono?

La risposta, per la maggior parte delle aziende che seguiamo, è meno esotica di quanto ci si aspetti: esistono già. Sono le API che quelle stesse aziende hanno passato anni a progettare, documentare, mettere in sicurezza e governare. L’API che verifica una copertura, quella che apre un sinistro, quella che interroga il portafoglio di un cliente: ognuna è, potenzialmente, una funzione che un agente autonomo può invocare per portare a termine un compito. Il problema non è costruire nuove capacità, è renderle utilizzabili da un consumatore che non è più un’applicazione ma un modello — senza smontare l’infrastruttura di governo costruita per il consumatore precedente.

È lo spazio in cui si sta muovendo l’ultima generazione di AI Gateway, con un meccanismo che merita di essere capito: il proxy MCP.

Il protocollo che ha vinto la gara della standardizzazione

Fino a due anni fa collegare un modello a un sistema aziendale significava scrivere codice di integrazione dedicato per ogni combinazione di framework e sistema: un lavoro N×M che ricordava molto le integrazioni punto-punto pre-API. Poi è arrivato il Model Context Protocol (MCP), uno standard aperto che definisce come un agente scopre gli strumenti disponibili, ne legge la descrizione, li invoca e ne riceve i risultati — trasformando quel problema N×M in un problema N+M, esattamente come le API avevano fatto per l’integrazione applicativa.

La velocità di adozione è tra le più rapide mai viste per uno standard infrastrutturale: gli SDK ufficiali hanno superato i 97 milioni di download mensili e i 10.000 server MCP pubblici censiti, e il 41% delle organizzazioni software dichiara di avere server MCP in produzione (studio MCP Adoption Statistics 2026 di Digital Applied). Sul fronte del traffico la pressione è già misurabile: le piattaforme API registrano un +40% anno su anno di chiamate generate da AI (report Postman’s State of the API), coerentemente con la previsione Gartner secondo cui oltre il 30% della crescita di domanda di API entro fine 2026 arriverà da strumenti AI.

Il dato più interessante è però quello che racconta il divario: due terzi degli sviluppatori conoscono MCP, ma solo il 10% lo usa regolarmente e appena il 24% progetta API pensando che a consumarle sarà un agente (report Postman’s State of the API). È la fase in cui conviene muoversi: abbastanza matura perché lo standard sia stabile, abbastanza precoce perché le scelte fatte adesso decidano chi, tra due anni, si troverà con una piattaforma e chi con un altro sprawl da riordinare.

La scorciatoia che ricrea il problema

Di fronte alla necessità di dare strumenti agli agenti, la strada apparentemente più breve è scrivere un server MCP per ogni sistema da esporre. È tecnicamente semplice, esistono librerie che la automatizzano, e ogni team può farla da solo in pochi giorni. Chi ha letto il secondo articolo di questa serie riconoscerà il pattern — ed è esattamente ciò che sta accadendo.

Che si tratti in larga parte di lavoro duplicato lo dice la ricerca: l’88,6% è interamente o parzialmente costruito sopra API REST già esistenti, e che il 92% dei tool esposti è un wrapper diretto di un endpoint, senza logica di integrazione aggiuntiva (studio empirico Arxiv sui server MCP). Nella quasi totalità dei casi, cioè, non si sta costruendo una nuova capacità: si sta costruendo una seconda porta d’ingresso verso una capacità che l’azienda espone già.

E una seconda porta è una seconda superficie da proteggere. I primi assessment di sicurezza lo documentano senza diplomazia: su un campione di server MCP testati, il 43% presentava difetti di command injection, il 30% era vulnerabile a SSRF e il 22% consentiva path traversal (analisi Equixly sui server MCP). Non perché MCP sia un protocollo insicuro, ma perché quei server sono componenti scritti in fretta, spesso fuori dai processi di sviluppo sicuro, che custodiscono credenziali privilegiate verso i sistemi a valle e che — qui sta il punto architetturale — stanno fuori dal percorso su cui l’azienda ha investito i propri controlli.

Autenticazione, autorizzazione, quote, logging: tutto ciò che il gateway applicava alle API viene aggirato nel momento in cui l’agente parla con un server MCP che chiama il backend per conto proprio. Lo chiameremo MCP sprawl, e la traiettoria è già scritta. La differenza, rispetto alla stagione dell’API sprawl, è che questa volta sappiamo come va a finire — e abbiamo lo strumento per evitarlo.

Il proxy MCP: lo stesso percorso, un protocollo in più

L’alternativa è la logica conseguenza di tutto ciò che abbiamo raccontato finora: se il gateway è già il punto da cui passa il traffico verso le API, è lì che va tradotto il protocollo degli agenti. Non un componente nuovo accanto all’infrastruttura, ma una capacità in più dell’infrastruttura esistente.

Su Kong questa capacità ha un nome preciso: il plugin AI MCP Proxy, disponibile da Kong Gateway 3.12 nell’edizione AI Gateway Enterprise. Funziona come un ponte protocollare: riceve la chiamata MCP dal client agentico, la mappa sull’operazione OpenAPI corrispondente, la traduce in una normale richiesta HTTP verso il servizio upstream e riveste la risposta nel formato che l’agente si aspetta. Il servizio a valle non viene toccato: non sa nulla di MCP e non deve saperne nulla. Le modalità operative coprono i tre scenari che si incontrano sul campo:

• conversione REST → MCP: le rotte di un servizio già gestito da Kong diventano tool MCP a partire dal suo schema OpenAPI, senza scrivere codice. È il caso della grande maggioranza delle aziende con un catalogo API consolidato;
• passthrough verso server MCP esistenti: quando un server MCP c’è già — sviluppato internamente o fornito da terze parti — il gateway gli si mette davanti come punto di accesso autenticato, osservabile e sottoposto a policy. Nessuno strumento resta fuori dal perimetro;
• aggregazione: tool provenienti da servizi diversi vengono raccolti dietro un unico endpoint MCP, così che un agente veda un catalogo coerente invece di una collezione di indirizzi da configurare uno per uno.

È l’idea di sempre — disaccoppiare chi consuma da chi eroga — applicata a un consumatore nuovo. E come per l’AI Gateway non è un caso che a proporla siano i vendor di API management: la categoria “MCP gateway” si sta affermando come control plane del traffico agentico, e chi ha già un data plane in produzione parte con un vantaggio strutturale.

La governance non si rifà: si eredita

Il valore di questa scelta si vede guardando cosa succede alla singola invocazione di tool. Passando dal gateway, quella chiamata attraversa lo stesso percorso — e quindi gli stessi controlli — di qualunque altra chiamata API:

Il risultato è che l’organizzazione non costruisce una seconda governance per gli agenti: estende quella che ha. Le API restano la fonte unica della logica di business, il gateway resta il punto di enforcement, il catalogo resta uno solo. Cambia il protocollo con cui si presenta il consumatore.

Esporre tutto non è una strategia

Un avvertimento è però necessario, perché la facilità della conversione automatica nasconde una trappola di progettazione. Riversare l’intero schema OpenAPI di un sistema in un catalogo di tool è ciò che gli architetti chiamano ormai API Wrapper Anti-Pattern: l’agente si trova davanti decine di operazioni granulari, deve capire da solo come concatenarle e recuperare identificativi tecnici, e finisce per fare il lavoro dell’integratore invece di quello dell’operatore. Il risultato tipico è un agente lento, costoso in token e imprevedibile.

Non è un’osservazione teorica: lo stesso studio empirico citato sopra rileva che i server MCP reali espongono una mediana del 19% delle operazioni disponibili, filtrando sistematicamente quelle deprecate, quelle distruttive e quelle che non corrispondono a un compito riconoscibile. Il messaggio implicito in quel numero è che una selezione avviene sempre: chi costruisce strumenti per gli agenti finisce comunque per scegliere a mano cosa esporre, spesso senza dichiararlo e senza un criterio condiviso. Tanto vale trasformarla in una scelta di progettazione esplicita, partendo dal compito che l’agente deve svolgere invece che dall’elenco degli endpoint disponibili. Anche qui il gateway aiuta, per un motivo pratico: la selezione dei tool, i loro nomi e i loro confini sono configurazione dichiarativa, versionabile e rivedibile come qualunque altra policy, non codice sparso in un server separato. Si può partire da pochi strumenti ben scelti, osservarne l’uso reale nelle metriche e ampliare il catalogo con evidenza, invece che per accumulo.

Nel concreto: l’agente che istruisce un sinistro

Riprendiamo il caso d’uso con cui si chiudeva il secondo articolo — l’agente che istruisce autonomamente un sinistro semplice — e guardiamolo con questa lente.

La compagnia dispone già di un ecosistema API governato: verifica della copertura, anagrafica assicurato, apertura e aggiornamento della pratica, calcolo dell’indennizzo, notifica al cliente. Sono le stesse API che alimentano il portale, l’app e i servizi verso la rete distributiva. Attivando la conversione MCP sul gateway, quelle operazioni diventano strumenti per l’agente senza una riga di codice nei sistemi a valle e senza nuove credenziali in circolazione.

Ciò che rende il caso esercibile in produzione è però la configurazione delle policy attorno a quei tool: l’agente di primo livello riceve in allowlist gli strumenti di lettura e di proposta, mentre la liquidazione — irreversibile — resta fuori dal suo perimetro e richiede il checkpoint umano; le quote impediscono che un ciclo di ragionamento anomalo interroghi mille volte l’anagrafica; l’audit trail registra ogni passo con l’identità dell’agente che lo ha compiuto. La stessa infrastruttura, con un profilo di permessi diverso, serve l’agente del contact center e quello del back office.

Nel mondo B2B: lo scenario si estende naturalmente alla rete distributiva. Se una compagnia espone già API di quotazione ed emissione a broker e comparatori, quegli stessi servizi possono diventare tool per gli agenti dei partner, con quote, contrattualistica e monitoraggio per partner — esattamente come per i piani API descritti nel primo articolo. Il catalogo di tool diventa un prodotto, con la stessa logica commerciale del catalogo di API. Ed è, molto probabilmente, il primo canale attraverso cui l’ecosistema agentico entrerà in azienda dall’esterno: tanto vale che entri dalla porta principale.

L’API-first paga un secondo dividendo

C’è un aspetto che riguarda chi ha investito negli anni nella qualità delle API, e vale la pena esplicitarlo: la qualità di un tool per agenti è la qualità della API sottostante. Uno schema OpenAPI completo, operazioni con nomi parlanti, parametri tipizzati, errori descritti, documentazione che spiega il quando e non solo il come sono esattamente gli attributi che rendono un endpoint comprensibile a un modello che deve decidere da solo se e come invocarlo. Le pratiche di API design, linting e APIOps di cui abbiamo scritto su questo Journal non sono un prerequisito burocratico dell’agentic readiness: ne sono la sostanza.

È anche il motivo per cui, negli assessment, la conversazione parte dagli agenti e finisce quasi sempre davanti al catalogo API del cliente: è lì che si decide la fattibilità del progetto. Dove le API sono documentate, coerenti e già governate, il primo agente in produzione è questione di settimane, perché il lavoro difficile è stato fatto anni prima. Dove non lo sono, il progetto si ferma — e non sulla scelta del modello, ma sulla necessità di rimettere in ordine le API che l’agente dovrebbe usare.

Il nostro approccio

In Intesys accompagniamo le aziende — in particolare nei settori regolamentati — lungo questo percorso con la stessa metodologia che applichiamo da anni all’API Management: un assessment del catalogo API e dei casi d’uso agentici realmente prioritari, la selezione curata dei primi tool da esporre, la configurazione del gateway come punto di controllo del traffico MCP (identità, allowlist, quote, audit) e un proof of concept su uno scenario ad alto valore che collauda l’infrastruttura prima di scalarla.

Perché la conclusione di questa serie è la stessa da cui era partita: l’investimento fatto sull’API management non si duplica, si estende. Le API sono già il modo in cui l’azienda espone ciò che sa fare. Trasformarle negli strumenti degli agenti non richiede una nuova architettura — richiede di riconoscere che quella giusta, probabilmente, è già in produzione.