Axonius ajoute des agents IA à sa plateforme SaaS de cybersécurité sans abandonner le modèle d’isolation client par client qui sous-tend son déploiement AWS existant, selon une nouvelle étude de cas du blog AWS Machine Learning.

L’entreprise a utilisé Amazon Bedrock AgentCore pour exécuter des agents dans des centaines d’environnements clients distincts. La conception répond à un problème central pour les éditeurs de logiciels qui ajoutent des fonctionnalités agentiques : un agent doit être utile à travers de nombreux locataires tout en restant limité aux données, API, contrôles d’identité et coûts d’exploitation du client qu’il sert.

AWS décrit l’architecture et ses bénéfices rapportés dans un billet rédigé par le fournisseur. La source ne fournit ni tests de performance indépendants ni commentaires de clients d’Axonius ; les affirmations concernant l’échelle du déploiement et les résultats opérationnels doivent donc être considérées comme rapportées par AWS.

Axonius conserve son modèle SaaS basé sur des silos

Axonius propose une plateforme de renseignement sur les actifs pour les équipes de sécurité et d’IT. Selon AWS, le service recoupe des informations provenant de plus de 1 400 systèmes et exploite des centaines d’environnements clients isolés. Chaque charge de travail client s’exécute dans un Amazon Virtual Private Cloud, ou Amazon VPC, dédié, contenant des composants tels que des répartiteurs de charge, des bases de données et une infrastructure de calcul générale.

Le premier agent IA décrit dans l’article analyse de grands environnements d’entreprise, identifie des écarts et des risques, et interprète des millions de points de données provenant de multiples intégrations. AWS indique que cette fonctionnalité vise à permettre à des analystes juniors de réaliser des analyses complexes sans que des analystes seniors aient à passer des heures en investigation manuelle.

Au lieu de déplacer cette charge de travail vers une architecture SaaS partagée, Axonius souhaitait que l’agent suive son modèle de locataire existant. Cette décision a façonné les exigences techniques : un agent gérant l’environnement d’un client ne doit pas accéder aux données d’un autre client, tout en s’intégrant aux schémas d’authentification, de déploiement et d’API déjà établis par le service.

Pour les concepteurs d’IA, le point essentiel est que la multi-location ici ne consiste pas seulement à attribuer un identifiant client à une requête. L’agent doit être déployé, autorisé, connecté, surveillé et facturé de manière à préserver les frontières déjà attendues d’un produit de sécurité.

Trois modèles de déploiement, avec des compromis différents

AWS présente les choix de conception autour de trois modèles courants pour les déploiements d’agents SaaS : silo, pool et bridge.

Dans une architecture en silo, chaque locataire reçoit des ressources dédiées. Appliqué à AgentCore Runtime, cela peut signifier déployer un agent dédié pour chaque client. Cela offre une frontière d’infrastructure claire, mais augmente le nombre de ressources à provisionner, mettre à jour, surveiller et retirer.

Le modèle pool utilise des ressources partagées. Un seul agent peut servir plusieurs locataires, chaque session recevant un identifiant de session distinct. AWS explique qu’AgentCore Runtime fournit une microVM dédiée à chaque session, tandis que des contrôles au niveau de l’application assurent la séparation entre locataires.

Cette approche simplifie le déploiement et l’intégration des clients, mais elle transfère davantage de responsabilité à l’application. L’agent doit interpréter correctement le contexte du locataire à chaque requête et empêcher tout accès inter-locataires. Le comportement spécifique à un locataire peut également nécessiter une logique conditionnelle supplémentaire dans un déploiement partagé.

Le modèle bridge combine les deux approches. Un runtime d’agent peut être partagé tandis que des contrôles plus stricts au niveau du locataire sont appliqués à la couche des outils. Dans l’architecture évoquée par AWS, AgentCore Gateway se situe entre l’agent et les outils sortants, permettant de vérifier les appels d’outils au regard des frontières de locataire avant exécution.

AWS présente ce modèle hybride comme un moyen de réduire les coûts d’infrastructure tout en conservant un point de contrôle plus solide pour l’accès aux systèmes clients. L’étude de cas ne divulgue pas tous les détails de mise en œuvre en production, il n’est donc pas possible, à partir des éléments disponibles, d’évaluer comment Axonius a réparti chaque composant entre ressources partagées et dédiées.

L’identité et l’accès aux outils font partie de la frontière d’isolation

Axonius disposait déjà d’un module d’authentification et d’autorisation fonctionnant sur une infrastructure Amazon EC2 spécifique à chaque locataire. Son besoin était d’ajouter des agents sans remplacer ce flux d’identité.

AWS décrit une conception dans laquelle les locataires s’authentifient via un fournisseur d’identité OAuth 2.0, tel qu’Amazon Cognito. Les jetons contiennent une revendication spécifique au locataire, par exemple un identifiant de locataire personnalisé. Le validateur JWT intégré dans AgentCore Runtime vérifie le jeton à l’aide du point de terminaison de découverte du fournisseur d’identité, tandis que l’agent lit la revendication pour acheminer les requêtes vers le bon environnement client.

Cette séparation est importante. La validation du jeton établit qu’une requête provient d’un fournisseur d’identité accepté, mais l’agent et ses outils doivent encore appliquer correctement la revendication du locataire. En pratique, la frontière de sécurité dépend à la fois du mécanisme d’autorisation de la plateforme et du code qui mappe l’identité vers les API, les magasins de données et les outils.

Le même principe s’applique à l’intégration de services. AWS indique que l’agent associé à un locataire doit disposer d’un accès sécurisé aux API de ce locataire. L’article présente AgentCore Gateway comme un point d’application possible pour les appels sortants d’outils, créant une couche où le contexte du locataire peut être vérifié avant qu’un outil n’interagisse avec la charge de travail client.

Preuves, contrôle des coûts et échelle opérationnelle

AWS identifie le suivi des coûts comme l’une des exigences principales d’Axonius, car l’invocation du modèle devrait représenter une grande partie des dépenses d’un agent. Une comptabilisation par locataire peut aider un fournisseur SaaS à décider comment tarifer une fonctionnalité IA, fixer des limites d’utilisation et identifier les clients ou les flux de travail à consommation inhabituellement élevée.

L’entreprise devait également ajouter la charge de travail de l’agent à son processus existant de livraison continue basé sur des silos. Cette exigence est facile à négliger : une architecture qui fonctionne en prototype peut devenir difficile à exploiter lorsque chaque environnement client possède son propre cycle de déploiement.

L’observabilité était une autre préoccupation mentionnée. AWS indique qu’Axonius avait besoin d’une surveillance, d’alertes et de traces à l’échelle du parc pour un grand nombre d’agents, avec suffisamment de détails pour enquêter sur les défaillances. Ces besoins rendent les opérations d’agents différentes de la surveillance applicative classique. Les équipes doivent comprendre non seulement si un service est disponible, mais aussi quels appels modèle, outils, sessions et autorisations de locataire ont contribué à un résultat.

Les éléments disponibles proviennent d’AWS et non d’un auditeur indépendant ou d’un entretien client. AWS rapporte qu’AgentCore a permis à Axonius de déployer des agents multi-locataires isolés sans construire de zéro une infrastructure personnalisée d’isolation de calcul, d’authentification ou d’observabilité. Il s’agit d’une affirmation du fournisseur sur le rôle de la plateforme, pas d’une comparaison vérifiée indépendamment du temps d’ingénierie, de la sécurité ou du coût total.

Ce que cela signifie pour les développeurs et les acheteurs d’entreprise

Pour les entreprises SaaS, le cas Axonius met en évidence une séquence pratique pour ajouter des agents : partir du modèle de locataire existant, identifier les frontières de données et d’outils, puis décider quels contrôles relèvent du runtime, de l’application ou d’une couche gateway.

Le choix affecte aussi l’économie du produit. Des ressources dédiées peuvent offrir une isolation et une personnalisation plus claires, mais des runtimes partagés peuvent simplifier l’intégration et les opérations. Une conception bridge peut réduire les doublons, mais elle exige une application rigoureuse des politiques à chaque frontière d’outil. Aucun des modèles n’élimine le besoin de tester les échecs d’autorisation, les revendications de locataire malformées, les permissions d’outils excessives et les fuites accidentelles de données.

Les acheteurs d’entreprise qui évaluent des fonctionnalités IA devraient demander aux fournisseurs comment l’identité du locataire suit une requête d’agent, si les appels d’outils sont autorisés indépendamment, comment l’utilisation du modèle est attribuée et comment les traces sont séparées pour la réponse aux incidents. Ces questions sont particulièrement importantes pour les logiciels de sécurité, où un agent peut traiter des informations sensibles d’inventaire, de configuration et de vulnérabilité.

L’implication plus large pour le marché est que les plateformes d’agents se concurrencent autant sur les primitives opérationnelles que sur l’accès aux modèles. L’isolation du runtime, l’intégration de l’identité, les gateways, l’automatisation du déploiement et l’observabilité peuvent déterminer si un agent passe d’une démonstration à un produit qu’un fournisseur SaaS peut prendre en charge sur des centaines d’environnements.

À surveiller ensuite

Les prochains signaux seront des détails de production concrets de la part d’Axonius ou d’AWS : savoir si l’entreprise utilise en production un runtime partagé, des runtimes dédiés ou une configuration bridge ; comment l’attribution des coûts au niveau du locataire est mise en œuvre ; et quels contrôles sont appliqués dans le code applicatif par rapport à AgentCore Gateway.

Les développeurs devraient également surveiller des preuves indépendantes concernant la surcharge de déploiement, la gestion des incidents et les tests d’isolation. Davantage de détails sur le choix des modèles, le débit, la latence et le coût d’exploitation du premier agent Axonius permettraient de mieux juger l’architecture au-delà de ses objectifs de conception déclarés.

Point de vue de Creati.ai

L’exemple d’Axonius concerne moins l’ajout d’un chatbot à un produit de sécurité que l’adaptation de l’exécution d’agents à un plan de contrôle SaaS existant. Le travail difficile consiste à relier l’identité, l’accès aux données, les outils, la facturation, les déploiements et le débogage au locataire qui possède la requête.

L’étude de cas AWS montre pourquoi l’infrastructure d’agents gérée est attractive pour les éditeurs de logiciels indépendants, mais elle ne prouve pas qu’une abstraction de plateforme élimine le risque de sécurité au niveau de l’application. La leçon la plus forte pour les développeurs est de traiter le routage des locataires et l’autorisation des outils comme des contrôles critiques du produit, puis de valider les affirmations du fournisseur avec des données de déploiement et d’échec avant de s’engager dans une architecture à grande échelle.