Fastly AI Firewall viene lanciato con controlli runtime, ma la vera prova è la sicurezza edge
Il 21 settembre Fastly ha lanciato tre controlli AI collegati tra loro, tra cui Fastly AI Firewall, AI Runtime Control e API Security ampliata. Il rilascio congiunto introduce instradamento dei modelli, ispezione dei prompt, limiti di spesa e restrizioni sugli agenti nell'attuale percorso delle richieste edge di Fastly.
Questo posizionamento crea la tensione centrale. Fastly non vende un altro filtro per modelli isolato. Vuole che i clienti rendano la sua infrastruttura il punto di controllo tra applicazioni, fornitori di AI, utenti e API aziendali.
Cloudflare e Palo Alto Networks competono già per parti di quella posizione. Fastly deve quindi dimostrare che la sua architettura edge offre un controllo utile senza aggiungere latenza, costi, esposizione della privacy o complessità di implementazione inaccettabili.
Il lancio arriva mentre il traffico delle macchine occupa una quota maggiore della rete Fastly. Fastly afferma che le richieste generate dalle macchine hanno superato la metà del traffico di rete nei mesi di luglio e agosto 2026. Afferma inoltre che il traffico AI è cresciuto 6,5 volte più velocemente del traffico umano da gennaio a maggio.
Questi dati derivano dalle osservazioni della rete Fastly, non da una misurazione indipendente dell'intera internet. Spiegano comunque perché un fornitore edge consideri la governance dell'AI un'opportunità infrastrutturale anziché una categoria di sicurezza separata.
Fastly AI Firewall trasforma l'edge in un punto di controllo per l'AI
Il rilascio di Fastly combina tre controlli che affrontano parti diverse di una richiesta AI in produzione.
AI Runtime Control si colloca tra un'applicazione e i suoi fornitori di modelli. Le applicazioni inviano richieste ai modelli tramite un endpoint Fastly anziché chiamare direttamente ogni fornitore.
Fastly utilizza chiavi virtuali per proteggere le credenziali sottostanti dei fornitori. Gli amministratori possono associare queste chiavi a modelli, utenti, budget e limiti di traffico, mantenendo al contempo l'accesso a fornitori pubblici o self-hosted.
Questa architettura offre agli operatori una visione centralizzata del volume delle richieste, del consumo di token, della selezione dei fornitori e delle risposte dei modelli. Supporta inoltre il failover dei fornitori quando un servizio configurato diventa indisponibile.
Fastly AI Firewall aggiunge l'ispezione di sicurezza a quel piano di controllo. Controlla i prompt prima di inoltrarli ed esamina le risposte idonee prima di restituirle a un'applicazione.
L'azienda afferma che il firewall cerca schemi noti di prompt injection e jailbreak. Il prompt injection si verifica quando un input non attendibile tenta di sostituire o sovrascrivere istruzioni che dovrebbero governare un modello.
I clienti possono eseguire il firewall in modalità di registrazione o di blocco. La registrazione preserva la richiesta annotando un rilevamento, mentre il blocco rifiuta una richiesta corrispondente prima che raggiunga il fornitore.
Il terzo componente affronta gli agenti che chiamano API aziendali. L'API Security ampliata di Fastly può confrontare le richieste in arrivo con un contratto API pubblicato, che definisce le operazioni e i formati di dati accettati da un servizio.
Le organizzazioni possono osservare o bloccare le richieste che violano tali contratti. Il controllo si applica alle applicazioni convenzionali, ai flussi di lavoro assistiti e agli agenti autonomi.
Questa distinzione conta perché un agente può produrre traffico di rete sintatticamente valido tentando al contempo un'operazione non supportata. Un controllo tradizionale della disponibilità non stabilisce se l'azione richiesta rientri nell'autorità dell'agente.
Fastly presenta i tre componenti come un unico sistema nel percorso delle richieste. Le chiamate ai modelli possono essere instradate e misurate, i prompt possono essere ispezionati e le azioni degli agenti possono essere limitate a un confine API.
Secondo l'annuncio di lancio, tutte e tre le funzionalità sono diventate disponibili quando Fastly le ha annunciate. Il rilascio non descriveva un'anteprima futura né un progetto di ricerca su invito.
Fastly afferma inoltre che i controlli operano sulla sua piattaforma globale esistente. Secondo l'azienda, tale rete disponeva di una capacità di 622 terabit al secondo al 30 giugno 2026.
Al 31 marzo, Fastly afferma che gestiva oltre cinque trilioni di richieste al giorno. Questi numeri descrivono la scala della piattaforma, ma non stabiliscono le prestazioni dei nuovi prodotti AI.
Il cambiamento strategico resta chiaro. Fastly ha esteso la propria posizione nella distribuzione e nella sicurezza delle applicazioni al percorso delle richieste ai modelli, dove spesa AI e policy di sicurezza possono essere applicate insieme.
Ciò crea una proposta commerciale più ampia rispetto a un filtro per prompt autonomo. Chiede anche ai clienti di collocare interazioni sensibili con i modelli all'interno di un ulteriore livello operativo.
Perché AI Runtime Control sta diventando una competizione infrastrutturale
L'AI aziendale crea contemporaneamente un problema di instradamento, un problema di costi e un problema di autorizzazione.
Una prima applicazione AI spesso si collega direttamente a un fornitore di modelli con una sola credenziale. I sistemi di produzione sono più complessi perché i team utilizzano più modelli, account, regioni e percorsi di failover.
Gli agenti ampliano questa complessità. Possono selezionare strumenti, inviare richieste, recuperare dati e attivare operazioni senza che una persona approvi ogni chiamata di rete.
Fastly AI Runtime Control tenta di standardizzare queste interazioni prima che raggiungano un fornitore. Una chiave virtuale identifica il chiamante, mentre Fastly sostituisce la credenziale effettiva del fornitore più avanti nel percorso della richiesta.
Questo può ridurre la diffusione delle chiavi dei fornitori tra applicazioni e ambienti di sviluppo. Offre inoltre a un'organizzazione un punto coerente in cui applicare policy di frequenza e budget.
La documentazione runtime di Fastly afferma che i limiti di frequenza possono operare sulle richieste o sui token al minuto. Le regole di budget possono avvisare gli amministratori o bloccare attività aggiuntive dopo una soglia configurata.
L'applicazione basata sui token presenta una qualifica importante. Fastly dichiara che i conteggi finali dei token restano sconosciuti finché la risposta non è completata, quindi i limiti sui token operano secondo il principio del best effort.
Ciò significa che il piano di controllo può limitare l'utilizzo senza garantire un'applicazione perfettamente esatta dei limiti di token. Una risposta costosa può completarsi prima che il suo conteggio finale di token entri nel record contabile.
La stessa documentazione afferma che gli amministratori possono ispezionare i record di richieste e risposte. I log possono includere nomi dei modelli, chiavi virtuali, dati di sessione, timestamp e conteggi di token.
Questa visibilità offre valore operativo, ma solleva una questione di governance. Prompt e completamenti possono contenere documenti interni, dati dei clienti, credenziali o informazioni personali.
I team di sicurezza avranno bisogno di policy chiare per conservazione, controllo degli accessi ed elaborazione regionale prima di centralizzare questi record. Un log unificato è utile solo quando l'organizzazione disciplina anche chi può ispezionarlo.
La decisione di Fastly di combinare gestione del traffico e sicurezza riflette un più ampio cambiamento del mercato. I gateway AI stanno diventando punti di applicazione delle policy, anziché semplici proxy.
Cloudflare, ad esempio, combina il monitoraggio di AI Gateway con controlli di sicurezza delle applicazioni sulla propria rete. I suoi controlli contro il prompt injection assegnano alle richieste un punteggio che i clienti possono utilizzare nelle regole di firewall o limitazione della frequenza.
Palo Alto Networks affronta il tema dalla prospettiva della sicurezza aziendale. La sua sicurezza runtime ispeziona le interazioni in tempo reale tra modelli, applicazioni, agenti, plugin, dati e servizi esterni.
Questi prodotti non hanno architetture o copertura identiche. Tuttavia, competono per lo stesso punto di grande valore: il luogo in cui un'interazione AI può ancora essere osservata e fermata.
Il vantaggio di Fastly è il suo ruolo esistente nella distribuzione e protezione del traffico applicativo. I clienti che già utilizzano la sua rete edge potrebbero preferire estendere un piano di controllo consolidato anziché implementare un altro gateway indipendente.
Il suo svantaggio è altrettanto diretto. Gli acquirenti possono scegliere una piattaforma cloud, un fornitore di sicurezza o un gateway specializzato già più vicino ai loro modelli, alle loro identità o ai loro controlli sui dati.
Questa competizione mette sotto pressione sia i fornitori di infrastrutture sia gli acquirenti aziendali. I fornitori devono collegare prestazioni, sicurezza, osservabilità e governance dei costi senza produrre sistemi di policy in conflitto.
Gli acquirenti devono decidere dove debba risiedere l'autorità. Il perimetro di rete offre un'ampia visibilità, mentre il codice applicativo può preservare un contesto aziendale più dettagliato.
Nessun singolo livello vede tutto. Un gateway può ispezionare una richiesta, ma l'applicazione può sapere se l'azione richiesta sia appropriata per un determinato cliente o flusso di lavoro.
Fastly scommette che l'edge possa diventare il livello comune di applicazione, mentre le applicazioni mantengono la propria logica di autorizzazione. Il valore di AI Runtime Control dipende da quanto bene questi due livelli cooperino.
Il meccanismo del prodotto ne definisce anche i limiti
Fastly AI Firewall riduce l'esposizione nel percorso delle richieste, ma non elimina il prompt injection o i comportamenti non sicuri degli agenti.
Fastly descrive la propria ispezione come deterministica. Il firewall controlla le richieste rispetto a firme note di injection e jailbreak, anziché inviare ogni prompt attraverso un altro modello generativo.
Questa scelta presenta un'attrattiva pratica. I controlli deterministici possono offrire un comportamento prevedibile ed evitare il costo di eseguire un secondo modello per ogni interazione.
Fastly racchiude inoltre gli input non attendibili in token di confine crittografici. Le istruzioni di accompagnamento indicano al modello di trattare il materiale racchiuso come dati, non come comandi autorevoli.
Questa tecnica affronta una debolezza fondamentale delle applicazioni basate su modelli linguistici. Le istruzioni di sistema e il testo non attendibile raggiungono infine un modello come flussi correlati di token, nonostante la loro diversa autorità prevista.
Un documento dannoso può quindi contenere istruzioni rivolte al modello che lo legge. L'attacco diventa indiretto quando il payload entra tramite contenuti recuperati, email, un sito web o un'altra fonte esterna.
Fastly controlla l'output idoneo alla ricerca di prove che un attacco abbia influenzato il modello. Gli amministratori possono esaminare tag di rilevamento, classificazioni delle minacce e risultati canary insieme ad altre informazioni sulle richieste.
Questi controlli aggiungono attrito agli attacchi noti, ma gli aggressori possono variare formulazione, codifica, lingua o contesto. Un sistema basato su firme deve continuare a cambiare con la comparsa di nuovi metodi di elusione.
OWASP colloca il prompt injection al primo posto nella sua lista 2025 dei principali rischi per le applicazioni basate su modelli linguistici di grandi dimensioni. La sua guida alla prevenzione raccomanda difese stratificate anziché affidarsi a un solo filtro.
Tali difese includono la separazione delle istruzioni dai dati, la limitazione dei privilegi del modello, la convalida degli output, la richiesta di approvazione umana per azioni importanti e il monitoraggio del comportamento.
La documentazione di Fastly espone un altro limite. L'ispezione delle risposte richiede una risposta completa, quindi le richieste in streaming passano senza ispezione dell'output.
Lo streaming consegna il testo generato in modo incrementale anziché attendere la risposta completa. Supporta interfacce chat reattive, ma il firewall non può valutare la risposta completata prima che l'applicazione inizi a riceverla.
L'isolamento strutturale aggiunge inoltre token alle richieste. Fastly afferma che i fornitori di modelli dei clienti fatturano tali token aggiuntivi secondo il normale utilizzo.
Ciò non rende la protezione impraticabile. Significa però che i clienti devono misurare se il costo aggiuntivo in token rimane accettabile ai loro volumi di produzione.
La latenza richiede un esame analogo. L'ispezione inline aggiunge elaborazione a un percorso in cui gli utenti attendono già l'inferenza del modello, l'esecuzione degli strumenti e il recupero dei dati.
La presenza edge di Fastly dovrebbe ridurre la distanza di rete per molte richieste. L'annuncio non fornisce benchmark indipendenti sulla latenza per l'intera sequenza di firewall e control plane.
I falsi positivi rappresentano un compromesso distinto. Discussioni sulla sicurezza, prompt di debugging e contenuti di ricerca possono legittimamente includere le stesse frasi presenti in un attacco.
La modalità di registrazione consente ai team di osservare tali rilevamenti prima di bloccarli. Tuttavia, lascia attive le richieste corrispondenti durante il periodo di valutazione.
La modalità di blocco riduce questa esposizione, ma rischia di rifiutare traffico valido. I clienti dovranno effettuare test specifici per ciascun carico di lavoro, anziché considerare una singola policy adatta a ogni applicazione.
Il componente di applicazione delle API dipende inoltre da contratti accurati. Uno schema obsoleto o incompleto può bloccare attività valide dell'agente oppure consentire operazioni il cui rischio emerge solo nel contesto aziendale.
La conformità al contratto non equivale all'autorizzazione. Un agente può chiamare un endpoint consentito con dati validi perseguendo comunque un obiettivo inappropriato.
Il prodotto funziona quindi al meglio come uno strato di un sistema più ampio. Restano necessari permessi applicativi, controlli dell'identità, restrizioni sugli strumenti, log di audit e approvazione umana.
Il lancio è significativo perché integra questi controlli nell'infrastruttura esistente. La sua importanza non va confusa con l'affermazione che l'ispezione di rete risolva l'intero problema della sicurezza degli agenti.
Fastly affronta Cloudflare e i fornitori di sicurezza sullo stesso percorso delle richieste
La principale battaglia competitiva riguarda il controllo del traffico AI, non la proprietà del modello sottostante.
Fastly non richiede ai clienti di standardizzarsi su un unico fornitore di modelli. AI Runtime Control è progettato per instradare richieste tra modelli pubblici e self-hosted attraverso un endpoint comune.
L'indipendenza dal fornitore può attrarre team preoccupati da interruzioni, variazioni nelle prestazioni dei modelli o dipendenza da un solo vendor. Crea inoltre un intermediario centrale che i clienti devono gestire e di cui devono fidarsi.
Cloudflare adotta una strategia edge correlata. Il suo AI Gateway gestisce osservabilità e controllo dei modelli, mentre AI Security for Apps aggiunge rilevamenti relativi a prompt, argomenti e dati tramite il suo web application firewall.
Il sistema di rilevamento delle injection pubblicato da Cloudflare utilizza un punteggio graduato da 1 a 99. Fastly enfatizza firme deterministiche, token di delimitazione, tag di rilevamento e un comportamento di registrazione o blocco selezionato dal cliente.
La documentazione disponibile descrive superfici di controllo diverse, ma non supporta un confronto definitivo sull'accuratezza. Test indipendenti richiederebbero dataset, configurazioni, modelli e metodi di attacco comuni.
Palo Alto Networks offre un inquadramento della sicurezza più ampio. Il suo prodotto runtime descrive protezioni contro injection, contenuti avvelenati, link malevoli, fuga di dati, interazioni con i modelli e attività degli agenti.
Questa ampiezza può adattarsi alle organizzazioni che già standardizzano le operazioni di sicurezza su Palo Alto Networks. Fastly può rispondere con la vicinanza alla distribuzione delle applicazioni e un'architettura familiare ai suoi clienti esistenti.
Le aziende specializzate nella sicurezza AI creano un'altra fonte di pressione. Possono concentrarsi strettamente sulla valutazione dei modelli, sul red teaming, sui guardrail o sul comportamento degli agenti senza mantenere una rete generale di distribuzione.
Gli specialisti possono innovare rapidamente all'interno di una categoria di minacce. Possono anche costringere i clienti ad aggiungere un altro fornitore, proxy, linguaggio di policy e archivio di telemetria.
La decisione d'acquisto dipenderà quindi da più di una checklist di funzionalità. I team devono confrontare posizione di deployment, gestione dei dati, copertura dei modelli, espressività delle policy, osservabilità e comportamento in caso di errore.
Il comportamento in caso di errore merita particolare attenzione. Un controllo inline deve decidere se il traffico prosegue quando i servizi di ispezione, registrazione o policy diventano indisponibili.
Il comportamento fail-open protegge la disponibilità ma consente traffico non ispezionato. Il comportamento fail-closed preserva l'applicazione delle policy ma può trasformare una dipendenza di sicurezza in un'interruzione dell'applicazione.
Fastly evidenzia il failover dei fornitori all'interno di AI Runtime Control. Gli acquirenti dovrebbero verificare separatamente come la piattaforma gestisce i guasti nell'ispezione firewall, nella registrazione, nella valutazione delle policy e nella validazione delle API.
Il consolidamento dei fornitori crea una tensione propria. L'uso di un'unica piattaforma per delivery, sicurezza applicativa, instradamento AI e controlli degli agenti può ridurre la frammentazione operativa.
Può anche aumentare la dipendenza da un unico percorso delle richieste. Un errore di configurazione, un incidente della piattaforma o la compromissione dell'account potrebbero influire su più livelli simultaneamente.
Le organizzazioni con requisiti di isolamento rigorosi possono preferire fornitori o punti di applicazione separati. Altre accetteranno la concentrazione in cambio di operazioni più semplici e telemetria unificata.
Fastly deve inoltre dimostrare che i clienti edge esistenti desiderano affidare all'azienda la gestione delle interazioni con i modelli. La distribuzione di asset web e l'ispezione di conversazioni AI complete generano aspettative diverse in materia di privacy e conformità.
Il percorso di adozione più forte nel breve termine probabilmente passa dagli attuali clienti Fastly. Essi inviano già il traffico applicativo attraverso la rete e comprendono il suo modello di configurazione.
I nuovi clienti devono affrontare un confronto più difficile. Fastly deve mostrare una profondità di sicurezza sufficiente per competere con i fornitori dedicati e un valore operativo sufficiente a giustificare il reindirizzamento delle chiamate ai modelli.
Ecco perché il rilascio è più di un annuncio di funzionalità. Fastly sta cercando di espandersi dalla protezione delle applicazioni alla governance dell'attività AI generata da tali applicazioni.
Tre segnali mostreranno se la scommessa di Fastly sulla sicurezza AI funziona
Le prove di adozione, i test di sicurezza indipendenti e le risposte della concorrenza riveleranno se l'edge diventerà un livello di controllo AI duraturo.
Il primo segnale è l'adozione in produzione. Fastly dovrebbe infine divulgare esempi di clienti che spieghino quali modelli, carichi di lavoro e policy vengono eseguiti tramite AI Runtime Control.
Casi di studio utili riporterebbero ambito di deployment, impegno di migrazione, attività bloccate, gestione dei falsi positivi e risultati operativi. Dichiarazioni generiche su visibilità o sicurezza fornirebbero meno evidenze.
I clienti dovrebbero inoltre descrivere come governano i log di prompt e completamenti. Queste informazioni mostreranno se l'osservabilità centralizzata supera le verifiche di privacy, conformità e accesso interno.
Il secondo segnale è una valutazione indipendente di Fastly AI Firewall. I test dovrebbero misurare i tassi di rilevamento per injection diretta, injection indiretta, jailbreak, prompt codificati, attacchi multilingue e contenuti benigni sulla sicurezza.
Dovrebbero inoltre pubblicare tassi di falsi positivi, latenza, consumo aggiuntivo di token e comportamento con lo streaming. Senza queste misurazioni, gli acquirenti possono confrontare l'architettura, ma non le prestazioni difensive verificate.
I test devono tenere conto dell'evoluzione dei modelli e dei metodi di attacco. Un controllo che si comporta bene contro firme note può comunque avere difficoltà con attacchi adattivi o specifici dell'applicazione.
Il terzo segnale è il modo in cui risponderanno Cloudflare, Palo Alto Networks e i fornitori specialistici. Un instradamento, un'identità, una prevenzione della perdita di dati o un'autorizzazione degli agenti più integrati aumenterebbero la pressione sulla piattaforma combinata di Fastly.
Anche la roadmap di Fastly avrà importanza. La documentazione attuale identifica già limiti pratici, inclusa l'applicazione dei token con la formula del best effort e un'ispezione incompleta delle risposte in streaming.
Colmare queste lacune rafforzerebbe il caso per un unico control plane. Lasciarle invariate preserverebbe spazio per livelli di sicurezza applicativi o concorrenti.
I team aziendali non devono attendere che il mercato si stabilizzi prima di valutare il rilascio. Possono iniziare con un carico di lavoro circoscritto in modalità di registrazione e confrontare i rilevamenti con i controlli esistenti.
Un pilota dovrebbe includere prompt benigni rappresentativi, test avversari, risposte in streaming, guasti dei fornitori e scenari di limite di budget. I team dovrebbero anche verificare ciò che Fastly archivia e chi può accedere a ciascun record.
Le prove sugli agenti richiedono un test aggiuntivo. Un agente dovrebbe affrontare permessi espliciti sugli strumenti e contratti API mentre tenta flussi di lavoro sia validi sia non autorizzati.
Il risultato dovrebbe essere misurato a livello di azione aziendale, non solo a livello di richiesta di rete. Una richiesta ben formata può comunque produrre un'azione inaccettabile.
Fastly AI Firewall merita attenzione perché collega la sicurezza all'instradamento, alla spesa e all'applicazione delle API degli agenti. Questa combinazione corrisponde alla forma operativa dell'AI in produzione più da vicino di un filtro dei prompt isolato.
La questione aperta è se Fastly possa trasformare la sua posizione sulla rete in un'autorità affidabile sul comportamento dell'AI. L'ispezione edge offre visibilità e un'opportunità di applicazione, ma il contesto aziendale risiede ancora altrove.
Per sviluppatori e responsabili della sicurezza, la prossima mossa è concreta: testare i controlli AI di Fastly su carichi di lavoro reali, documentare ogni punto cieco e confrontare i risultati con le difese concorrenti sul percorso delle richieste. Il valore del prodotto emergerà dal comportamento misurato sotto guasto e attacco, non dalle dimensioni della rete sottostante.
