AIR lève 50 M$ : 27 % des extensions d’agents échouent à son filtre

AIR est sortie de la discrétion à New York le 1er septembre 2026 avec un financement total de 50 millions de dollars mené par Sequoia Capital et Greenoaks. Le communiqué de lancement d’AIR présente un pare-feu qui inspecte les informations, instructions et outils entrant dans le contexte des agents IA, avant qu’ils puissent influer sur leurs décisions.

Le compte rendu de TechCrunch détaille deux tours de 10 et 40 millions de dollars, dirigés respectivement par Sequoia et Greenoaks, et rapporte qu’AIR filtre environ 27 % des extensions et compétences qu’elle trouve en ligne. Ce pourcentage est une mesure interne appliquée au corpus découvert par l’entreprise, pas un taux d’attaques ni un résultat observé chez ses clients.

Un pare-feu placé devant le contexte des agents

AIR défend la thèse qu’une chaîne d’approvisionnement spécifique se forme autour des agents IA. Elle comprend les compétences, plugins, serveurs MCP, sous-agents et autres composants qui leur apportent des instructions, des données ou la capacité d’exécuter une action.

Le produit cherche à contrôler ce que l’agent reçoit, et pas seulement les autorisations dont il dispose. La plateforme doit découvrir les agents actifs dans l’entreprise, y compris les usages non approuvés par l’équipe informatique, puis intercepter des opérations telles que le chargement d’une compétence ou la consultation d’un contenu externe.

AIR associe cette visibilité à une liste de confiance et à une place de marché de modules préévalués. L’approche se distingue par son insistance sur le filtrage préventif et la réévaluation continue, mais elle ne crée pas une catégorie sans concurrence : Noma Security, Zenity, Astrix Security et Operant AI proposent déjà, avec des périmètres différents, de la découverte d’agents, de la gouvernance, du contrôle d’accès, de la surveillance à l’exécution ou des passerelles MCP.

De la découverte d’une extension à sa révocation

Le parcours annoncé commence par l’inventaire des agents et des composants auxquels ils font appel. AIR examine ensuite les instructions externes, les dépendances logicielles, les comportements cachés et les accès susceptibles d’exposer des données ou des systèmes internes.

Lorsqu’un composant ne satisfait pas les règles de l’organisation, il peut être bloqué avant son chargement. S’il est ultérieurement considéré comme malveillant, vulnérable ou non approuvé, la plateforme doit retrouver les agents et les processus qui en dépendent, puis permettre sa révocation à l’échelle de l’entreprise.

Cette dernière étape est essentielle : un verdict isolé ne protège pas les autres workflows qui utilisent la même extension. AIR transforme donc l’évaluation en politique opérationnelle, avec un état d’autorisation susceptible d’être modifié et appliqué à l’ensemble du parc d’agents.

Pourquoi une approbation ne peut pas être définitive

Une extension approuvée peut rester identique tout en allant chercher des instructions ou du code auprès d’une ressource qui évolue. Un paquet peut être mis à jour, un dépôt transféré, un domaine récupéré par un nouveau propriétaire ou le compte d’un mainteneur compromis. L’analyse du fichier installé ne décrit alors plus tout ce que l’agent consommera pendant son exécution.

La confiance doit donc être recalculée lorsqu’un composant ou l’une de ses dépendances change. Si la nouvelle évaluation échoue, l’autorisation antérieure doit pouvoir être retirée et les processus concernés identifiés, sans attendre qu’un incident confirme le danger.

Cette logique introduit néanmoins un compromis que le lancement ne quantifie pas. Un filtrage trop permissif peut laisser passer une dépendance devenue hostile ; un filtrage trop strict peut interrompre des automatisations légitimes. AIR n’a pas publié de taux de faux positifs, de fréquence moyenne de réévaluation ni de mesure de la continuité des agents après une révocation.

Les chiffres de recherche ne prouvent pas l’efficacité en production

L’étude technique publiée par AIR indique avoir examiné 142 836 compétences actives, dont 9 570 provenant de skills.sh et 133 266 collectées dans la communauté GitHub, puis en avoir classé 17 822, soit environ 12,4 %, comme dépendant d’au moins une source externe jugée non fiable ; les compteurs disponibles représentaient au total 6,7 millions d’installations.

Cette recherche mesure la présence d’une dépendance dont la confiance paraît insuffisante à partir de signaux portant notamment sur les domaines, les comptes GitHub, les paquets et les hébergeurs. Elle ne démontre pas que chaque ressource diffusait un contenu hostile, que chaque installation avait été compromise ou que le pare-feu avait empêché un incident.

Le taux affiché lors du lancement répond à une autre question : il décrit la part des composants trouvés en ligne qui ne franchissent pas le filtre actuel d’AIR. L’entreprise ne fournit pas le dénominateur exact de cette mesure, sa période de collecte, le traitement des doublons ni la répartition entre contenus malveillants, vulnérables, non approuvés ou simplement insuffisamment fiables.

La levée, ses principaux investisseurs et l’architecture générale du produit sont désormais documentés. Il reste à établir la précision du classement, les conséquences des faux positifs et les résultats obtenus dans des environnements clients : sans ces données, AIR démontre une surface de risque et décrit un mécanisme de contrôle, mais pas encore son efficacité opérationnelle.

À lire aussi:

• Levanta lève 22 millions, les commissions restent aux créateurs
• Faro lève 37,3 millions : ses agents devront comprendre tout l’essai clinique
• Arga lève 10 M$ : ses copies de logiciels laissent les agents échouer sans dégâts