Fastly AI Firewall se lance avec des contrôles d’exécution, mais la sécurité en périphérie reste le véritable test

Fastly a lancé le 21 septembre trois contrôles IA connectés, dont Fastly AI Firewall, AI Runtime Control et une extension d’API Security. Cette version regroupe le routage des modèles, l’inspection des prompts, les limites de dépenses et les restrictions applicables aux agents dans le chemin de requêtes edge existant de Fastly.

Ce positionnement crée la tension centrale. Fastly ne commercialise pas un filtre de modèles isolé supplémentaire. L’entreprise veut que ses infrastructures deviennent le point de contrôle entre les applications, les fournisseurs d’IA, les utilisateurs et les API d’entreprise.

Cloudflare et Palo Alto Networks rivalisent déjà pour certaines parties de cette position. Fastly doit donc démontrer que son architecture edge fournit un contrôle utile sans ajouter une latence, un coût, une exposition de la vie privée ou une complexité de déploiement inacceptables.

Ce lancement intervient alors que le trafic machine occupe une part croissante du réseau de Fastly. Fastly affirme que les requêtes générées par des machines ont dépassé la moitié du trafic réseau en juillet et août 2026. L’entreprise indique également que le trafic IA a progressé 6,5 fois plus vite que le trafic humain entre janvier et mai.

Ces chiffres proviennent des propres observations de Fastly sur son réseau, et non d’une mesure indépendante de l’ensemble d’internet. Ils expliquent néanmoins pourquoi un fournisseur edge considère la gouvernance de l’IA comme une opportunité d’infrastructure plutôt que comme une catégorie de sécurité distincte.

Fastly AI Firewall transforme l’edge en point de contrôle de l’IA

La version de Fastly combine trois contrôles qui ciblent différentes parties d’une requête IA en production.

AI Runtime Control se place entre une application et ses fournisseurs de modèles. Les applications envoient les requêtes de modèles via un endpoint Fastly, au lieu d’appeler directement chaque fournisseur.

Fastly utilise des clés virtuelles pour protéger les identifiants sous-jacents des fournisseurs. Les administrateurs peuvent associer ces clés à des modèles, des utilisateurs, des budgets et des limites de trafic, tout en conservant l’accès aux fournisseurs publics ou auto-hébergés.

Cette architecture offre aux opérateurs une vue centralisée du volume de requêtes, de la consommation de tokens, du choix des fournisseurs et des réponses des modèles. Elle prend également en charge le basculement entre fournisseurs lorsqu’un service configuré devient indisponible.

Fastly AI Firewall ajoute une inspection de sécurité à ce plan de contrôle. Il vérifie les prompts avant leur transfert et examine les réponses éligibles avant leur renvoi à une application.

L’entreprise indique que le firewall recherche des schémas connus d’injection de prompts et de jailbreak. Une injection de prompt survient lorsqu’une entrée non fiable tente de remplacer ou de neutraliser les instructions censées guider un modèle.

Les clients peuvent exécuter le firewall en mode journalisation ou en mode blocage. La journalisation conserve la requête tout en enregistrant une détection, tandis que le blocage rejette une requête correspondante avant qu’elle n’atteigne le fournisseur.

Le troisième composant vise les agents qui appellent des API d’entreprise. L’API Security étendue de Fastly peut comparer les requêtes entrantes à un contrat d’API publié, qui définit les opérations et formats de données acceptés par un service.

Les organisations peuvent observer ou bloquer les requêtes qui enfreignent ces contrats. Le contrôle s’applique aux applications conventionnelles, aux flux de travail assistés et aux agents autonomes.

Cette distinction est importante, car un agent peut produire un trafic réseau syntaxiquement valide tout en tentant une opération non prise en charge. Un contrôle de disponibilité traditionnel ne détermine pas si l’action demandée relève de l’autorité de l’agent.

Fastly présente les trois composants comme un système unique sur le chemin des requêtes. Les appels de modèles peuvent être routés et mesurés, les prompts peuvent être inspectés et les actions des agents peuvent être limitées à une frontière d’API.

Selon l’annonce de lancement, les trois capacités sont devenues disponibles lorsque Fastly les a annoncées. La version ne décrivait ni un aperçu futur ni un projet de recherche réservé sur invitation.

Fastly affirme également que les contrôles s’exécutent sur sa plateforme mondiale existante. Ce réseau disposait d’une capacité de 622 térabits par seconde au 30 juin 2026, selon l’entreprise.

Il traitait plus de cinq billions de requêtes par jour au 31 mars, selon Fastly. Ces chiffres décrivent l’échelle de la plateforme, mais ils n’établissent pas les performances des nouveaux produits IA.

L’évolution stratégique reste toutefois claire. Fastly a étendu sa position dans la diffusion et la sécurité des applications au chemin des requêtes de modèles, où les dépenses d’IA et les politiques de sécurité peuvent être appliquées conjointement.

Cela crée une proposition commerciale plus large qu’un filtre de prompts autonome. Cela demande aussi aux clients de placer des interactions sensibles avec des modèles dans une couche opérationnelle supplémentaire.

Pourquoi AI Runtime Control devient un enjeu d’infrastructure

L’IA d’entreprise crée simultanément un problème de routage, un problème de coûts et un problème d’autorisation.

Une première application IA se connecte souvent directement à un fournisseur de modèles avec un seul identifiant. Les systèmes de production sont plus complexes, car les équipes utilisent plusieurs modèles, comptes, régions et chemins de basculement.

Les agents accroissent cette complexité. Ils peuvent sélectionner des outils, envoyer des requêtes, récupérer des données et déclencher des opérations sans qu’une personne n’approuve chaque appel réseau.

Fastly AI Runtime Control tente de normaliser ces interactions avant qu’elles n’atteignent un fournisseur. Une clé virtuelle identifie l’appelant, tandis que Fastly substitue le véritable identifiant du fournisseur plus loin dans le chemin de requête.

Cela peut limiter la dissémination des clés de fournisseurs entre les applications et les environnements de développement. Cela donne également à une organisation un emplacement cohérent pour appliquer des politiques de débit et de budget.

La documentation sur le runtime de Fastly indique que les limites de débit peuvent s’appliquer aux requêtes ou aux tokens par minute. Les règles budgétaires peuvent alerter les administrateurs ou bloquer des activités supplémentaires après un seuil configuré.

L’application fondée sur les tokens comporte une réserve importante. Fastly précise que le nombre final de tokens reste inconnu jusqu’à la fin de la réponse ; les limites de tokens fonctionnent donc sur la base du meilleur effort.

Cela signifie que le plan de contrôle peut contraindre l’utilisation sans garantir une application parfaitement exacte des limites de tokens. Une réponse coûteuse peut se terminer avant que son nombre final de tokens n’entre dans l’enregistrement comptable.

La même documentation indique que les administrateurs peuvent inspecter les enregistrements des requêtes et des réponses. Les journaux peuvent inclure les noms de modèles, les clés virtuelles, les données de session, les horodatages et les nombres de tokens.

Cette visibilité offre une valeur opérationnelle, mais elle soulève une question de gouvernance. Les prompts et les complétions peuvent contenir des documents internes, des données clients, des identifiants ou des informations personnelles.

Les équipes de sécurité auront besoin de politiques claires de conservation, de contrôle d’accès et de traitement régional avant de centraliser ces enregistrements. Un journal unifié n’est utile que si l’organisation régit aussi qui peut l’inspecter.

La décision de Fastly de combiner la gestion du trafic et la sécurité reflète une évolution plus large du marché. Les passerelles IA deviennent des points d’application des politiques plutôt que de simples proxys.

Cloudflare, par exemple, associe la supervision d’AI Gateway à des contrôles de sécurité des applications sur son réseau. Ses contrôles d’injection de prompts attribuent aux requêtes un score que les clients peuvent utiliser dans des règles de firewall ou de limitation de débit.

Palo Alto Networks aborde le sujet sous l’angle de la sécurité d’entreprise. Sa sécurité à l’exécution inspecte les interactions en direct entre les modèles, les applications, les agents, les plugins, les données et les services externes.

Ces produits n’ont pas des architectures ou une couverture identiques. Ils se disputent toutefois le même emplacement stratégique : le point où une interaction IA peut encore être observée et arrêtée.

L’avantage de Fastly réside dans son rôle existant dans la diffusion et la protection du trafic applicatif. Les clients qui utilisent déjà son réseau edge pourraient préférer étendre un plan de contrôle établi plutôt que déployer une autre passerelle indépendante.

Son désavantage est tout aussi direct. Les acheteurs peuvent choisir une plateforme cloud, un fournisseur de sécurité ou une passerelle spécialisée déjà plus proche de leurs modèles, identités ou contrôles de données.

Cette concurrence met sous pression à la fois les fournisseurs d’infrastructure et les acheteurs d’entreprise. Les fournisseurs doivent relier performances, sécurité, observabilité et gouvernance des coûts sans créer de systèmes de politiques contradictoires.

Les acheteurs doivent décider où doit se situer l’autorité. La périphérie du réseau offre une large visibilité, tandis que le code applicatif peut préserver un contexte métier plus détaillé.

Aucune couche ne voit tout. Une passerelle peut inspecter une requête, mais l’application peut savoir si l’action demandée convient à un client ou à un flux de travail particulier.

Fastly parie que l’edge peut devenir la couche commune d’application, tandis que les applications conservent leur propre logique d’autorisation. La valeur d’AI Runtime Control dépend de la qualité de coopération entre ces deux couches.

Le mécanisme du produit définit aussi ses limites

Fastly AI Firewall réduit l’exposition sur le chemin des requêtes, mais il n’élimine pas l’injection de prompts ni les comportements dangereux des agents.

Fastly décrit son inspection comme déterministe. Le firewall compare les requêtes à des signatures connues d’injection et de jailbreak, plutôt que d’envoyer chaque prompt à un autre modèle génératif.

Ce choix présente un intérêt pratique. Les contrôles déterministes peuvent offrir un comportement prévisible et éviter le coût d’exécution d’un second modèle pour chaque interaction.

Fastly encapsule également les entrées non fiables avec des tokens de frontière cryptographiques. Les instructions associées indiquent au modèle de traiter les éléments encapsulés comme des données, et non comme des commandes faisant autorité.

Cette technique répond à une faiblesse fondamentale des applications fondées sur les modèles de langage. Les instructions système et le texte non fiable parviennent finalement à un modèle sous forme de flux de tokens liés, malgré leurs niveaux d’autorité intentionnels différents.

Un document malveillant peut donc contenir des instructions destinées au modèle qui le lit. L’attaque devient indirecte lorsque la charge utile arrive par du contenu récupéré, un e-mail, un site web ou une autre source externe.

Fastly vérifie les sorties éligibles à la recherche d’indices montrant qu’une attaque a affecté le modèle. Les administrateurs peuvent examiner les balises de détection, les classifications des menaces et les résultats canary avec les autres informations de requête.

Ces contrôles ajoutent de la friction face aux attaques connues, mais les attaquants peuvent varier la formulation, l’encodage, la langue ou le contexte. Un système de signatures doit continuellement évoluer à mesure que de nouvelles méthodes de contournement apparaissent.

OWASP classe l’injection de prompts au premier rang de sa liste 2025 des principaux risques pour les applications de grands modèles de langage. Ses conseils de prévention recommandent des défenses en couches plutôt que de s’appuyer sur un seul filtre.

Ces défenses comprennent la séparation des instructions et des données, la limitation des privilèges des modèles, la validation des sorties, l’exigence d’une approbation humaine pour les actions importantes et la surveillance des comportements.

La documentation de Fastly expose une autre limite. L’inspection des réponses exige une réponse complète ; les requêtes en streaming sont donc transmises sans inspection de sortie.

Le streaming délivre le texte généré progressivement au lieu d’attendre la réponse complète. Il favorise des interfaces de chat réactives, mais le firewall ne peut pas évaluer la réponse terminée avant que l’application ne commence à la recevoir.

L’isolation structurelle ajoute également des tokens aux requêtes. Fastly précise que les fournisseurs de modèles des clients facturent ces tokens supplémentaires selon leurs conditions d’utilisation habituelles.

Cela ne rend pas la protection impraticable. Cela signifie toutefois que les clients doivent mesurer si le coût supplémentaire en tokens reste acceptable à leur volume de production.

La latence exige une attention similaire. L’inspection en ligne ajoute du traitement à un parcours où les utilisateurs attendent déjà l’inférence du modèle, l’exécution d’outils et la récupération de données.

L’infrastructure edge de Fastly devrait réduire la distance réseau pour de nombreuses requêtes. L’annonce ne fournit pas de benchmarks de latence indépendants pour l’ensemble de la séquence de pare-feu et de plan de contrôle.

Les faux positifs constituent un compromis distinct. Les discussions liées à la sécurité, les prompts de débogage et les contenus de recherche peuvent légitimement contenir les mêmes expressions que celles utilisées dans une attaque.

Le mode journalisation permet aux équipes d’observer ces détections avant de bloquer. Il laisse aussi actives les requêtes correspondantes pendant la période d’évaluation.

Le mode blocage réduit cette exposition, mais risque de rejeter du trafic valide. Les clients devront effectuer des tests adaptés à leurs charges de travail plutôt que de considérer qu’une seule politique convient à toutes les applications.

Le composant d’application des API dépend également de contrats précis. Un schéma obsolète ou incomplet peut bloquer une activité valide d’agent ou autoriser des opérations dont le risque n’apparaît que dans le contexte métier.

La conformité au contrat n’est pas la même chose que l’autorisation. Un agent peut appeler un endpoint autorisé avec des données valides tout en poursuivant un objectif inapproprié.

Le produit fonctionne donc mieux comme une couche au sein d’un système plus large. Les autorisations applicatives, les contrôles d’identité, les restrictions d’outils, les journaux d’audit et l’approbation humaine restent nécessaires.

Ce lancement est important car il intègre ces contrôles dans une infrastructure existante. Son importance ne doit pas être confondue avec l’affirmation selon laquelle l’inspection réseau résout l’ensemble du problème de sécurité des agents.

Fastly se mesure à Cloudflare et aux fournisseurs de sécurité sur le même chemin de requête

La principale bataille concurrentielle porte sur le contrôle du trafic IA, et non sur la propriété du modèle sous-jacent.

Fastly n’a pas besoin que ses clients se standardisent sur un seul fournisseur de modèles. AI Runtime Control est conçu pour acheminer les requêtes vers des modèles publics et auto-hébergés via un endpoint commun.

L’indépendance vis-à-vis des fournisseurs peut séduire les équipes préoccupées par les pannes, l’évolution des performances des modèles ou la dépendance à un seul éditeur. Elle crée également un intermédiaire central que les clients doivent exploiter et auquel ils doivent faire confiance.

Cloudflare suit une stratégie edge comparable. Son AI Gateway gère l’observabilité et le contrôle des modèles, tandis que AI Security for Apps ajoute des détections liées aux prompts, aux sujets et aux données via son pare-feu applicatif web.

Le système d’injection publié par Cloudflare utilise un score gradué de 1 à 99. Fastly met l’accent sur des signatures déterministes, des tokens de délimitation, des balises de détection et un comportement de journalisation ou de blocage choisi par le client.

La documentation disponible décrit différentes surfaces de contrôle, mais elle ne permet pas de comparer définitivement leur précision. Des tests indépendants nécessiteraient des jeux de données, configurations, modèles et méthodes d’attaque communs.

Palo Alto Networks propose un cadrage de sécurité plus large. Son produit d’exécution décrit des protections contre l’injection, les contenus empoisonnés, les liens malveillants, les fuites de données, les interactions avec les modèles et l’activité des agents.

Cette ampleur peut convenir aux organisations qui standardisent déjà leurs opérations de sécurité sur Palo Alto Networks. Fastly peut répliquer par sa proximité avec la diffusion d’applications et une architecture familière à ses clients existants.

Les entreprises spécialisées dans la sécurité de l’IA constituent une autre source de pression. Elles peuvent se concentrer étroitement sur l’évaluation des modèles, le red teaming, les garde-fous ou le comportement des agents sans exploiter un réseau de diffusion généraliste.

Les spécialistes peuvent innover rapidement dans une catégorie de menaces donnée. Ils peuvent aussi obliger les clients à ajouter un fournisseur, un proxy, un langage de politique et un magasin de télémétrie supplémentaires.

La décision d’achat dépendra donc de plus qu’une liste de fonctionnalités. Les équipes doivent comparer l’emplacement du déploiement, le traitement des données, la couverture des modèles, l’expressivité des politiques, l’observabilité et le comportement en cas de défaillance.

Le comportement en cas de défaillance mérite une attention particulière. Un contrôle en ligne doit décider si le trafic se poursuit lorsque les services d’inspection, de journalisation ou de politique deviennent indisponibles.

Un comportement fail-open protège la disponibilité, mais autorise du trafic non inspecté. Un comportement fail-closed préserve l’application des contrôles, mais peut transformer une dépendance de sécurité en panne applicative.

Fastly met en avant le basculement entre fournisseurs au sein d’AI Runtime Control. Les acheteurs devraient vérifier séparément comment la plateforme gère les défaillances de l’inspection par pare-feu, de la journalisation, de l’évaluation des politiques et de la validation des API.

La consolidation des fournisseurs crée sa propre tension. Utiliser une seule plateforme pour la diffusion, la sécurité applicative, le routage IA et les contrôles des agents peut réduire la fragmentation opérationnelle.

Cela peut également accroître la dépendance à un seul chemin de requête. Une erreur de configuration, un incident de plateforme ou la compromission d’un compte pourrait affecter plusieurs couches simultanément.

Les organisations ayant des exigences strictes d’isolation peuvent préférer des fournisseurs ou points d’application distincts. D’autres accepteront cette concentration en échange d’opérations plus simples et d’une télémétrie unifiée.

Fastly doit également prouver que ses clients edge existants souhaitent confier à l’entreprise la gestion des interactions avec les modèles. La diffusion d’actifs web et l’inspection de conversations IA complètes suscitent des attentes différentes en matière de confidentialité et de conformité.

La voie d’adoption la plus solide à court terme passe probablement par les clients actuels de Fastly. Ils acheminent déjà le trafic de leurs applications via le réseau et comprennent son modèle de configuration.

Les nouveaux clients font face à une comparaison plus difficile. Fastly doit démontrer une profondeur de sécurité suffisante pour rivaliser avec les fournisseurs spécialisés, ainsi qu’une valeur opérationnelle assez forte pour justifier le reroutage des appels aux modèles.

C’est pourquoi cette version est plus qu’une annonce de fonctionnalité. Fastly cherche à passer de la protection des applications à la gouvernance de l’activité IA générée par ces applications.

Trois signaux montreront si le pari de Fastly sur la sécurité de l’IA fonctionne

Les preuves d’adoption, les tests de sécurité indépendants et les réactions concurrentielles révéleront si l’edge devient une couche de contrôle IA durable.

Le premier signal est l’adoption en production. Fastly devrait à terme présenter des exemples de clients expliquant quels modèles, charges de travail et politiques passent par AI Runtime Control.

Des études de cas utiles indiqueraient la portée du déploiement, l’effort de migration, les activités bloquées, la gestion des faux positifs et les résultats opérationnels. Des déclarations générales sur la visibilité ou la sécurité apporteraient moins de preuves.

Les clients devraient également décrire comment ils gouvernent les journaux de prompts et de complétions. Ces informations montreront si l’observabilité centralisée résiste aux examens de confidentialité, de conformité et d’accès interne.

Le deuxième signal est une évaluation indépendante de Fastly AI Firewall. Les tests devraient mesurer les taux de détection pour les injections directes, les injections indirectes, les jailbreaks, les prompts encodés, les attaques multilingues et les contenus de sécurité bénins.

Ils devraient également publier les taux de faux positifs, la latence, la consommation supplémentaire de tokens et le comportement en streaming. Sans ces mesures, les acheteurs peuvent comparer les architectures, mais pas les performances défensives vérifiées.

Les tests doivent tenir compte de l’évolution des modèles et des méthodes d’attaque. Un contrôle performant face à des signatures connues peut néanmoins peiner face à des attaques adaptatives ou propres à une application.

Le troisième signal concerne la réaction de Cloudflare, Palo Alto Networks et des fournisseurs spécialisés. Un routage, une identité, une prévention des pertes de données ou une autorisation des agents davantage intégrés accroîtraient la pression sur la plateforme combinée de Fastly.

La feuille de route de Fastly elle-même comptera également. La documentation actuelle identifie déjà des limites pratiques, notamment l’application des limites de tokens au mieux et une inspection incomplète des réponses diffusées en streaming.

Combler ces lacunes renforcerait l’argument en faveur d’un plan de contrôle unique. Les laisser inchangées préserverait de la place pour des couches de sécurité applicatives ou concurrentes.

Les équipes d’entreprise n’ont pas besoin d’attendre que le marché se stabilise avant d’évaluer cette version. Elles peuvent commencer avec une charge de travail limitée en mode journalisation et comparer les détections à leurs contrôles existants.

Un pilote devrait inclure des prompts bénins représentatifs, des tests adversariaux, des réponses en streaming, des défaillances de fournisseurs et des scénarios de limites budgétaires. Les équipes devraient aussi vérifier ce que Fastly stocke et qui peut accéder à chaque enregistrement.

Les essais d’agents nécessitent un test supplémentaire. Un agent devrait être confronté à des autorisations d’outils explicites et à des contrats API tout en tentant des flux de travail valides et non autorisés.

Le résultat devrait être mesuré au niveau de l’action métier, et pas seulement au niveau de la requête réseau. Une requête bien formée peut toujours produire une action inacceptable.

Fastly AI Firewall mérite l’attention car il relie la sécurité au routage, aux dépenses et à l’application des API des agents. Cette combinaison correspond davantage à la réalité opérationnelle de l’IA en production qu’un filtre de prompts isolé.

La question ouverte est de savoir si Fastly peut transformer sa position sur le réseau en une autorité fiable sur le comportement de l’IA. L’inspection edge offre de la visibilité et une occasion d’appliquer des contrôles, mais le contexte métier demeure ailleurs.

Pour les développeurs et les responsables de la sécurité, la prochaine étape est concrète : tester les contrôles IA de Fastly sur des charges de travail réelles, documenter chaque angle mort et comparer les résultats aux défenses concurrentes sur le chemin de requête. La valeur du produit ressortira de son comportement mesuré face aux pannes et aux attaques, et non de la taille du réseau qui le sous-tend.