AIR lève 50 M$ : son pare-feu veut filtrer les extensions des agents IA
AIR Security est sortie de l’ombre le 1er septembre 2026 avec un pare-feu destiné à contrôler ce qui entre dans le contexte des agents d’intelligence artificielle, comme l’établit l’annonce officielle datée du 1er septembre. L’entreprise a réuni 50 millions de dollars dans des tours menés par Sequoia Capital et Greenoaks, un financement également documenté par SecurityWeek dans son compte rendu du 3 septembre.
Le produit veut examiner les skills, plugins, serveurs MCP et autres composants auxquels les agents se connectent, avant leur installation puis pendant leur utilisation. Ces fonctions sont présentées et commercialisées par AIR ; les pages accessibles ne fournissent toutefois pas de validation indépendante permettant de mesurer leur efficacité en production.
Les 50 millions proviennent de deux tours d’amorçage
Le financement ne correspond pas à une opération unique. Les informations recueillies par TechCrunch détaillent un premier tour de 10 millions de dollars mené par Sequoia, suivi quelques semaines plus tard d’un second de 40 millions mené par Greenoaks ; Swish, Netz et plusieurs investisseurs individuels ont aussi participé.
AIR a été cofondée par Yair Saban, directeur général, et Niv Hoffman, directeur technique. Les capitaux doivent notamment soutenir le recrutement de chercheurs et le développement commercial aux États-Unis et en Europe. La taille de la levée renseigne sur les moyens accordés à l’entreprise, mais elle ne constitue ni un test du produit ni une mesure de réduction du risque.
Le pare-feu cible le contexte plutôt que le seul modèle
Le périmètre revendiqué dépasse le modèle d’IA lui-même. La présentation de la plateforme AIR place son contrôle entre les agents et les sources externes : skills contenant des instructions réutilisables, plugins regroupant plusieurs composants, serveurs MCP donnant accès à des outils ou à des données, sous-agents, sites web et données internes.
Cette position doit permettre d’intercepter un composant avant qu’il n’influence la décision ou l’action d’un agent. Les catégories de risques affichées comprennent les instructions externes, les comportements cachés, l’injection de prompt, les permissions excessives, les actions non autorisées, l’exfiltration de données et la compromission de la chaîne logicielle. Il s’agit de menaces que le produit est conçu pour rechercher, et non de résultats de détection vérifiés par un tiers.
La réévaluation continue répond à un problème distinct du contrôle initial. Une extension acceptée peut évoluer après une mise à jour, charger une dépendance différente ou être touchée par la compromission du compte qui la maintient. La valeur du dispositif dépend donc autant de sa capacité à observer les changements que de son analyse au moment de l’installation.
Cette approche laisse aussi une question d’architecture : le pare-feu ne peut contrôler que les composants, appels et sources qu’il voit effectivement. Un agent, une intégration ou un canal de données situé hors de son périmètre d’observation peut réduire la couverture réelle, même si les mécanismes fonctionnent comme prévu sur les flux intégrés.
Control, Filter, Defend et Marketplace couvrent quatre étapes
La plateforme est répartie en quatre briques aux rôles différents. AIR Control doit inventorier les agents autorisés ou non et leur appliquer des règles de configuration, d’identité et de permissions. AIR Filter est chargé d’évaluer les skills, plugins, serveurs MCP et sous-agents avant leur installation.
AIR Defend correspond à la protection pendant l’exécution : détection des actions, réponse et application des contrôles en temps réel. AIR Marketplace doit, pour sa part, servir de catalogue commun pour des extensions externes préévaluées et des composants internes certifiés. L’ensemble associe ainsi découverte du parc, filtrage préalable, contrôle à l’exécution et gestion de l’offre disponible.
Ces couches ne produisent pas la même garantie. Un inventaire peut révéler un agent inconnu sans prouver que ses actions sont sûres ; un filtre peut bloquer un paquet suspect sans anticiper toutes ses évolutions ; un catalogue limite les choix aux composants approuvés sans éliminer une compromission ultérieure. La protection à l’exécution dépend, elle, des actions observables et de la possibilité technique de les interrompre.
L’efficacité reste à démontrer par des mesures reproductibles
Les informations publiques disponibles ne donnent pas de benchmark indépendant et reproductible pour AIR. Pour juger la détection, il faudrait disposer d’un corpus documenté d’extensions bénignes et malveillantes, connaître les familles d’attaques représentées et publier séparément les faux négatifs et les faux positifs. La catégorie « bloqué » devrait aussi distinguer un composant malveillant, vulnérable, excessivement permissif ou simplement non approuvé par une politique interne.
La couverture opérationnelle exige d’autres mesures : part des agents et des appels réellement inspectés, délai entre la modification d’un composant et la révocation de sa confiance, latence ajoutée aux tâches et comportement en cas d’indisponibilité du contrôle. Des résultats ventilés par agent, environnement d’hébergement et type d’intégration seraient nécessaires pour éviter qu’une moyenne masque un canal peu ou pas couvert.
Des audits tiers et des essais de contournement permettraient enfin de vérifier si le filtrage résiste à des instructions dissimulées, à des mises à jour malveillantes et à des chemins d’accès indirects aux outils. À ce stade, le financement, le périmètre général et les quatre couches de la plateforme sont documentés. La réduction mesurable du risque chez les clients, elle, reste inconnue tant qu’un protocole public et des résultats indépendamment reproductibles ne sont pas disponibles.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.