WSO2 a annoncé la disponibilité générale de WSO2 Agent Manager le 15 septembre 2026. Cette plateforme de contrôle open source doit enregistrer, exécuter, gouverner, observer et évaluer des agents IA utilisant différents frameworks et environnements de déploiement. Le produit sort ainsi de la version bêta annoncée plus tôt en 2026 et propose des déploiements auto-hébergés ou exploités comme service.
La sortie est importante pour les entreprises parce qu'elle réunit plusieurs contrôles dans une même couche opérationnelle: inventaire central, identité propre à chaque agent, règles d'accès délégué, garde-fous pour modèles et outils, évaluation, observabilité et environnement d'exécution isolé. WSO2 présente aussi le produit comme indépendant du framework, notamment pour LangChain, CrewAI, AWS Strands et Microsoft Agent Framework.
Ce qui est disponible maintenant
L'annonce principale affirme qu'Agent Manager est disponible et entièrement open source. La page produit actuelle propose un essai et décrit des options auto-hébergées et logicielles en tant que service. Cela soutient l'affirmation de disponibilité, même si les performances, l'efficacité des contrôles et les résultats en entreprise restent des déclarations du fournisseur sans test indépendant.
La page décrit un inventaire central et une identité distincte pour chaque agent. Des politiques de délégation définissent ce qu'un agent peut consulter et pour le compte de qui il agit. Ce point est important lorsque des agents empruntent un compte humain ou un identifiant de service partagé, empêchant ensuite l'enquête de distinguer les acteurs automatisés.
WSO2 annonce aussi plus de 40 garde-fous intégrés aux niveaux de l'organisation, de l'agent, de MCP et du modèle. Les exemples comprennent le masquage des données personnelles, la vérification des URL, la validation du contenu et celle de la sémantique des requêtes. La plateforme inclut également surveillance, évaluation et environnement destiné à isoler l'exécution.
Pourquoi une plateforme de contrôle est différente
La gestion classique des applications suppose généralement des services stables, des appels prévisibles et des identités durables. Les agents peuvent choisir des outils, créer des plans en plusieurs étapes et changer de comportement avec le contexte. La gouvernance doit donc relier le but déclaré de l'agent à ses actions réelles.
Une plateforme utile doit répondre à six questions. Quels agents existent? Qui en est responsable? À quoi chacun peut-il accéder? Quelle tâche et quel utilisateur ont délégué l'autorité? Quelles actions l'agent a-t-il tentées? Qu'est-ce qui a changé dans le système externe?
Un inventaire sans preuve d'action laisse une lacune. Des garde-fous sans identité distincte peuvent bloquer un motif sans montrer quel agent est responsable. L'observabilité sans exécution peut expliquer un incident après l'effet, mais ne peut arrêter l'action. La valeur d'une plateforme intégrée dépend du partage des identifiants et du contexte de politique entre les couches.
Les limites à tester
La disponibilité générale ne prouve pas une couverture équivalente de tous les frameworks, outils et protocoles. Les équipes doivent vérifier le traitement des agents exécutés hors de l'environnement isolé, des serveurs MCP personnalisés, des tâches asynchrones, de la mémoire longue et des identifiants API directs.
Elles doivent aussi tester les pannes. Si le service de politique, le fournisseur d'identité ou le composant d'évaluation est indisponible, l'agent s'arrête-t-il, continue-t-il avec moins de capacités ou contourne-t-il le contrôle? La réponse sûre peut varier selon l'action, mais elle doit être explicite et vérifiable.
Le nombre de garde-fous ne constitue pas un résultat. Une politique qui détecte une donnée sensible ou une instruction dangereuse nécessite encore une réponse définie, la preuve de la décision et la confirmation que l'action bloquée ou autorisée a produit l'effet prévu. Les promesses de souveraineté, de contrôle et de préparation à la production doivent être validées dans l'architecture et le modèle de menace du client.
Une séquence d'adoption pratique
Commencez par importer ou enregistrer un petit groupe d'agents réels. Pour chacun, attribuez un propriétaire, un objectif métier, un modèle, des outils, des accès aux données et un lieu de déploiement. Comparez l'inventaire avec les dépôts, les services cloud et les éléments observés sur les terminaux pour trouver les agents manquants.
Émettez ensuite une identité distincte et remplacez les identifiants partagés lorsque cela est possible. Les règles de délégation doivent intégrer utilisateur, tâche, ressource et type d'action. Un agent de développement peut lire un dépôt tandis qu'une modification de branche protégée nécessite une décision de politique séparée.
Appliquez les garde-fous et les évaluations au chemin d'action le plus risqué. Testez le travail attendu et les défaillances, notamment l'injection de requêtes, l'accès excessif aux données, une dépendance indisponible et un résultat d'outil différent de l'attente de l'agent.
Enfin, reliez les journaux d'identité, requête, politique, appel d'outil et effet. Le guide Maetra d'inventaire des agents donne une base pour les agents et leurs capacités. Le guide des journaux d'audit IA aide à définir les preuves nécessaires après une action à conséquence.
Analyse Maetra
La sortie de WSO2 reflète un passage plus large de la gestion des modèles à celle d'acteurs opérationnels. Une entreprise peut utiliser plusieurs modèles et frameworks, mais la question de gouvernance reste constante: quelle identité était autorisée à réaliser quelle action pour quelle tâche?
Le meilleur schéma sépare inventaire, autorisation, inspection de sécurité et vérification du résultat tout en conservant une chaîne de preuve commune. Une plateforme de contrôle peut fournir le contexte partagé. Les équipes ont encore besoin de politiques fondées sur les conséquences métier et de tests indépendants démontrant leur tenue en cas de panne.
La disponibilité générale d'Agent Manager offre une option concrète aux organisations recherchant une couche auto-hébergée ou exploitée. Elle doit être évaluée comme une infrastructure, pas comme la preuve automatique que les agents qui la traversent sont sûrs, conformes ou alignés.