Gouvernez chaque agent, pas seulement chaque requête.
Un agent transforme une instruction en dizaines d'appels de modèles, d'outils et d'autres agents. Wäg se place devant tous : il sait quel agent agit, pour quelle personne, ce qu'il peut toucher, ce qu'il peut dépenser et qui a approuvé l'étape risquée — et il peut le prouver ensuite. Construisez vos agents où vous voulez. Ils atteignent tout en passant par ici.
Un agent n'est pas une requête plus grande.
Une requête de chat est une décision que vous autorisez ou refusez. Un agent est une boucle : il lit un document, appelle un outil, lit le résultat, en appelle un autre, et continue jusqu'à se juger terminé. Les échecs coûteux ne sont pas les mauvaises réponses. Ce sont la boucle qui ne s'arrête pas, l'outil qui a changé en silence, les données parties par un appel que personne n'a inspecté, et le secret qui vit pour toujours dans une variable d'environnement.
MCP et A2A identifient l'agent et le compte qu'il utilise. Ni l'un ni l'autre ne porte ce qu'un auditeur demande en premier : quel humain a autorisé cette étape précise. Wäg inscrit l'identité de l'approbateur sur l'appel lui-même, dans une entrée chaînée par hachage que vous pouvez vérifier hors ligne.
Treize contrôles, dans l'ordre où vous les rencontrez
Apache-2.0 sauf mention contraire. Tout s'applique aux agents que vous construisez n'importe où — LangGraph, Bedrock AgentCore, Vertex, Foundry, Claude Code ou votre propre boucle — puisqu'ils atteignent tous modèles, outils et autres agents à travers la passerelle.
Les agents sont des principaux
Un agent est une identité à part entière, avec un propriétaire humain nommé, un runtime déclaré, un niveau de risque et une finalité. Chaque requête porte l'agent et la personne pour qui il agit, jusque dans le journal des requêtes et le registre de preuves.
Des exécutions, et des limites qui les arrêtent
Une exécution est une tâche d'agent. Plafonnez ses requêtes, appels d'outils, tokens, coût et durée. Au-delà du plafond, la requête suivante de l'exécution est refusée et l'appelant apprend quelle limite il a atteinte — avant l'arrivée de la facture, plutôt qu'après.
Politique d'outils : le pare-feu des agents
Des règles ordonnées décident de chaque appel d'outil : autoriser, refuser, faire classer par un modèle, ou retenir pour un humain. Les conditions lisent les arguments et l'appelant, si bien que "les remboursements au-dessus de 1 000 exigent une approbation" tient en une règle. Le mode à blanc compte ce qu'une règle aurait fait, et "Tester un appel" montre quelle règle décide — dans la console ou en CI.
Des approbations signées d'un nom
Un appel retenu attend une personne, pas un indicateur. Les approbateurs sont des utilisateurs ou des équipes, l'auto-approbation est refusée par défaut et chaque demande expire. Ils décident dans la console ou via une invite dans leur propre client MCP, et un e-mail peut les prévenir qu'une demande attend ; décider dans Slack ou Microsoft Teams relève d'Enterprise. La décision et son auteur sont inscrits au registre.
Contrôle des flux de données
Les outils portent des étiquettes : renvoie des données privées, renvoie du contenu contrôlé par des tiers, peut faire sortir des données. Dès qu'une exécution a touché les deux premières, la troisième est refusée ou retenue — le trio mortel, fermé par construction. Le contrôle porte aussi sur la donnée elle-même, par empreintes chiffrées de ce qu'un outil sensible a renvoyé, jamais sur le texte.
Épinglage des outils
Chaque outil MCP est épinglé à la définition approuvée par un administrateur : nom, description, schémas et annotations, de sorte qu'un outil qui cesse d'être en lecture seule compte comme modifié. Quand un serveur en change un, il passe en quarantaine jusqu'à ce qu'un humain examine la différence et l'accepte. Les substitutions cessent d'être silencieuses.
Aucune clé permanente
Les agents obtiennent des identifiants valables quelques minutes, prouvant qui ils sont avec une paire de clés enregistrée plutôt qu'un secret partagé, liés à une seule exécution si vous le souhaitez. DPoP rend inutile un jeton copié ; le TLS mutuel et les identités SPIFFE fonctionnent aussi, et les clés durables peuvent être purement interdites.
Sortie gérée
Les agents atteignent des API tierces via une destination enregistrée, et la passerelle ajoute l'identifiant — l'agent ne détient donc jamais la clé, et ses propres en-têtes d'authentification sont retirés au passage. Chaque destination fixe les méthodes et les chemins autorisés, et chaque appel traverse la politique d'outils, les approbations, les budgets, les garde-fous, la résidence et le registre comme n'importe quel autre.
Chaque connexion sortante
Pointez le HTTPS_PROXY d'un agent vers la passerelle et tout son trafic web passe par la control plane, pas seulement ses appels de modèles et d'outils. Des règles d'hôte décident quels sites il peut atteindre, et chaque connexion est traitée comme un appel d'outil — politique, approbations et étiquettes de flux de données s'appliquent donc, et elle compte dans l'exécution. Le nom TLS doit correspondre à l'hôte demandé, l'encrypted client hello est refusé, et les tunnels ouverts se ferment en quelques secondes quand un droit est retiré ou l'agent arrêté. Ouvrir le TLS pour certains hôtes, afin que règles de requête et garde-fous s'appliquent à l'intérieur, relève d'Enterprise.
D'autres agents, derrière vos clés
Enregistrez un agent distant par sa carte d'agent A2A, et vos équipes et vos agents l'appellent sous /v1/a2a avec leurs identifiants habituels. L'agent distant ne voit jamais que l'identifiant de la passerelle, et chaque message passe par contrôles d'accès, budgets, garde-fous, limites d'exécution, politique d'outils et preuves, comme un appel de modèle.
Inventaire et arrêt d'urgence
Trouvez les agents que personne n'a déclarés — Wäg les reconnaît à la façon dont leur trafic se comporte — ainsi que les serveurs MCP que vos développeurs font tourner sur leurs propres machines, d'après les noms d'outils que portent leurs requêtes. Donnez à chacun une date de revue et une expiration appliquée. Quand quelque chose tourne mal, arrêtez une exécution, un agent ou tous les agents d'une organisation, sur chaque réplica et chaque région à la fois.
Des agents venus d'autres plateformes Enterprise
Importez dans l'inventaire les agents que Microsoft Foundry, AWS Agent Registry, Microsoft Entra Agent ID et Gemini Enterprise connaissent déjà, et gardez-les synchronisés. Chacun reçoit un responsable, un niveau de risque, des limites d'exécution et des politiques d'outils ; ses instructions et ses identifiants ne sont jamais lus.
Paiements par agent Enterprise
Donnez à un agent un mandat de dépense plutôt qu'une carte : son propre budget par devise, une approbation au-delà d'un seuil, et la trace de chaque paiement. Des rails pour x402, les mandats AP2 et le paiement ACP ou UCP, la passerelle détenant l'identifiant ou vérifiant un agent qui détient le sien.
Des preuves, pas une capture d'écran de tableau de bord
Une gouvernance qu'on ne peut pas prouver est une intention. Chaque décision ci-dessus atterrit au même endroit : un registre chaîné par hachage et signé, que vous pouvez exporter et vérifier hors ligne avec la clé publique de la passerelle.
- Chaque appel de fournisseur, chaque issue et chaque changement de configuration, chaînés — une lacune ou une retouche se voit.
- Chaque approbation : qui a demandé, pour quoi, qui a décidé, et quand elle aurait expiré.
- Des spans OpenTelemetry pour les exécutions d'agents, ingérés depuis votre propre framework, de sorte que la vue de la passerelle et celle de l'agent forment un seul arbre de traces.
- Avec Enterprise, des paquets de preuves d'agents : des paquets signés regroupant les exécutions, approbations, arrêts et le registre d'une organisation, rattachés au règlement sur l'IA et à DORA.
Cela tourne là où vous tournez
Un binaire Rust dans votre propre infrastructure. Pas de phone-home, air-gap possible, et Apache-2.0 pour tout ce qui précède, sauf les cartes marquées Enterprise, les approbations Slack et Teams, les jetons de fournisseur d'identité et de workload, la politique d'outils sur les réponses pass-through, l'inspection TLS et les règles d'outils pour les appareils. Les agents atteignent les modèles via un point d'accès compatible OpenAI, les outils via la passerelle MCP et les autres agents via la passerelle A2A — sous les mêmes politiques, budgets et preuves.
MCP et gouvernance des outils · Toute la plateforme · Comparaison avec LiteLLM
Mettez un plan de contrôle devant vos agents
Exploitez-le dans votre propre infrastructure
Tout ce qu'il faut pour exploiter une control plane en production est sous Apache-2.0 et le restera — routage, haute disponibilité, cache, bascule, budgets, politique, MCP, tâches et observabilité. Auto-hébergé, sans compte, sans appel vers l'extérieur.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Ce n'est pas un pull qui fonctionne : les images ne sont pas encore publiques. Les partenaires de conception reçoivent les informations du registre en privé.
Déployer en 5 minutesFaçonnez-le en tant que partenaire de conception
Wäg n'est pas encore disponible publiquement. Nous travaillons avec un petit groupe d'équipes qui exploitent de l'IA multi-fournisseurs en production et prennent au sérieux la gouvernance et la souveraineté, afin de durcir la control plane sur des charges réelles.
- Toutes les capacités Enterprise incluses, sans coût de licence
- Migration accompagnée — nous la faisons avec vous, y compris depuis LiteLLM
- Un lien direct avec les ingénieurs et une influence réelle sur la suite