MCP ai bordi della rete: cosa cambia quando MCP viene eseguito in sicurezza in ogni POP

I server MCP (Model Context Protocol) offrono agli agenti IA un modo standard per chiamare strumenti, leggere risorse e importare prompt in blocco. 

La maggior parte dei server MCP viene eseguita in un’architettura cloud legacy: un’unica regione, dietro un load balancer, mantenendo una sessione per cliente. Questo è ragionevole finché un agente dall’altra parte del mondo non esegue quaranta chiamate a strumenti per completare un’attività e ogni chiamata sconta un’andata e ritorno transcontinentale all’interno del proprio ciclo di ragionamento. Questi viaggi di andata e ritorno su lunga distanza si accumulano rapidamente e compromettono le prestazioni della tua app.

Eseguire il tuo server MCP su Fastly Compute come WebAssembly binario in tutti i nostri data center, alimentato e protetto dalla nostra piattaforma globale da oltre 620 Tbps, cambia la natura di quello che può fare un MCP per gli agenti e le persone che li controllano. Abbiamo appena rilasciato un progetto di esempio che fa esattamente questo, pronto per essere utilizzato come riferimento dai tuoi agenti programmatori mentre modernizzano il tuo stack MCP. 

Non devi più pagare per un hosting di nicchia o isolare il tuo server in una singola regione geografica. Inoltre, puoi testare l’intero progetto in locale con Viceroy, il runtime locale di Compute di Fastly, prima di distribuirlo sulla rete. Di seguito analizzeremo come funziona dietro le quinte l’esecuzione di MCP stateless ai bordi della rete.

Risolvere la latenza dove conta: all'interno del loop dell'agente

Gli agenti non fanno una sola chiamata per poi fermarsi. Individuano gli strumenti, ne chiamano uno, leggono il risultato, ne chiamano un altro, a volte ripetono il ciclo una dozzina di volte prima di rispondere. Ciascuno di questi hop si trova nel percorso critico del flusso di lavoro dell’agente. Se ospiti il tuo server MCP in un’architettura tradizionale, un utente sviluppatore finale dall’altra parte del mondo che si affida al tuo server MCP potrebbe riscontrare fino a 500 ms di ritardo totale per ogni chiamata: il suo agente potrebbe effettuare decine di chiamate per azione. Quel ritardo si accumula rapidamente e produce una pessima esperienza per l’utente finale. 

Ai bordi della rete, il server si trova a pochi millisecondi da qualsiasi punto di origine della richiesta. Non vi è alcuna limitazione a una singola regione di origine né alcun backhaul verso un data center principale. Il catalogo degli strumenti, l’instradamento delle chiamate, la verifica dell’autenticazione: tutto viene gestito dal POP più vicino. Per un carico di lavoro di un agente con molte chiamate, risparmiare centinaia di millisecondi su ogni chiamata si traduce cumulativamente in un ciclo agentico sensibilmente più rapido.

Stateless per progettazione: qualsiasi POP può rispondere

La revisione MCP più recente (2026-07-28) è costruita per essere stateless. Oltre ad essere più in linea con le best practice HTTP, supportiamo la Agentic AI Foundation nella sua ricerca su questa innovazione e su quelle future.

La differenza notevole in questa revisione è che non c’è alcun handshake di inizializzazione. Ogni richiesta trasporta la propria identità e le funzionalità negoziate in un blocco _meta, e qualsiasi stato che deve persistere tra le chiamate viaggia con la richiesta piuttosto che risiedere sul server.

Poiché non c’è alcuna sessione associata a una macchina, una distribuzione edge stateless è ora molto più vantaggiosa rispetto alle specifiche precedenti. Con questa implementazione su una piattaforma moderna come quella di Fastly: 

• Il tuo server MCP viene distribuito istantaneamente ovunque. Una richiesta può raggiungere qualsiasi datacenter Fastly in tutto il mondo ed essere gestita correttamente.

• La scalabilità è orizzontale e automatica senza alcuna latenza da avvio a freddo. Fastly avvia il tuo server MCP in meno di 50 microsecondi.

• Ogni richiesta viene isolata in modo sicuro all'interno del nostro runtime basato su WebAssembly, eliminando qualsiasi rischio di sicurezza legato al fenomeno del "noisy neighbor".

Ottieni la semplicità operativa di una piattaforma distribuita a livello globale con una singola distribuzione.

Attività di lunga durata e in più passaggi senza mantenere aperta una connessione

"Stateless" di solito sembra incompatibile con "di lunga durata". I due meccanismi di continuazione della specifica ne consentono il funzionamento e la nostra implementazione si basa su entrambi:

• Richieste con più viaggi di andata e ritorno (MRTR): uno strumento può mettersi in pausa a metà chiamata per chiedere l’input al client e riprendere in seguito. Lo stato in corso viene sigillato in un token opaco che il client rimanda alla chiamata successiva. Non viene mantenuta aperta alcuna connessione; un'istanza disponibile riprende il lavoro.

• L’estensione Tasks: uno strumento in grado di avviare operazioni di lunga durata e restituire un task handle. Il client effettua il polling per verificare il completamento invece di mantenere aperto un socket per l’intera durata. Questo si adatta bene al modello di richiesta di Fastly.

Entrambi i token di continuazione sono sigillati crittograficamente con crittografia autenticata e vincolati all’identità del chiamante, in modo che il modello "lo stato viaggia con la richiesta" non diventi un modo per falsificare o dirottare il lavoro.

Il catalogo degli strumenti, servito dalla cache

Le chiamate di individuazione ed elenco (server/discover, tools/list, prompts/list, resources/list) restituiscono la stessa risposta a ogni chiamante e cambiano raramente. Sono perfette da memorizzare nella cache ai bordi della rete tramite la funzionalità di caching di dati di Fastly.

Il server contrassegna queste risposte con indicazioni sulla freschezza e sull'ambito della cache, in modo che la cache possa servire il catalogo degli strumenti agli agenti di tutto il mondo senza rieseguire l'handler ogni volta. Tutto ciò che dipende da chi effettua la richiesta viene automaticamente escluso dalla cache e non viene mai condiviso tra richieste diverse.

Sicurezza applicata prima che qualcosa raggiunga il tuo server di origine

Poiché Fastly si trova davanti a tutto ciò con cui i tuoi strumenti comunicano effettivamente, è il punto giusto in cui applicare il controllo degli accessi. Ci siamo assicurati di costruire la seguente funzionalità nel prototipo:

• L’autenticazione è fail-closed per impostazione predefinita:  una configurazione errata comporta un endpoint bloccato o non disponibile, mai uno aperto in modo silenzioso.

• I token bearer vengono verificati ai bordi della rete:  JWT ES256 vengono convalidati rispetto a un JWKS in cache, in modo che le richieste non autenticate o non valide vengano rifiutate prima che ti costino qualcosa a valle.

• L’autorizzazione è di tipo default-deny e con ambito limitato: un chiamante deve disporre degli ambiti specifici dichiarati da uno strumento; uno strumento che non ne dichiara alcuno non è chiamabile con l’autorizzazione.

• I corpi delle richieste sono limitati prima del parsing: i recuperi JWKS sono protetti da SSRFe gli errori interni vengono oscurati con ID di correlazione per il debug.

Una richiesta non autorizzata o abusiva viene bloccata all'interno di Fastly e non raggiunge mai il tuo backend.

Potenziato da tutta la potenza della piattaforma Fastly

Il prototipo MCP viene eseguito all'interno di Fastly Compute. Ciò significa che beneficia di tutta la resilienza e delle capacità della piattaforma come fattori favorevoli, quali:

• avvii a freddo in meno di 50 microsecondi

• isolamento sicuro tramite il nostro runtime WebAssembly

• Protezione DDoS con un clic

• Oltre 620 Tbps di capacità quando ne hai bisogno

• compressione delle richieste per prevenire un problema di thundering herd quando il tuo prodotto diventa virale

La specifica MCP stateless e il runtime di Fastly si rafforzano a vicenda: il protocollo è stato progettato in modo che lo stato possa viaggiare con la richiesta; l’edge è il contesto in cui questa architettura dà il meglio di sé. Ciò che in precedenza trasformava quello che normalmente è un servizio a singola regione, vincolato alla sessione, in qualcosa che si trova ovunque, vicino a ogni agente che lo chiama.

Governa il traffico IA e degli agenti con ARC utilizzando rate limit per chiave, controlli di spesa, logging dettagliato e failover automatico dei provider.

Esplora come Fastly per l’IA aiuta i team a costruire, proteggere e gestire applicazioni agentiche ai bordi della rete.

Per provarlo, dai un’occhiata al progetto su GitHub.