OpenClaw est devenu l’un des frameworks agents les plus largement adoptés, mais il doit encore faire ses preuves à l’échelle de l’entreprise. Les agents ont besoin de véritables informations d’identification (clés API, jetons OAuth, comptes de service) pour fonctionner efficacement, et Brex a constaté que les garde-fous traditionnels ne pouvaient pas contenir ce que ces agents faisaient avec eux.
Brex a décidé de surmonter ces limitations en créant une plate-forme interne appelée CrabTrap. Le proxy HTTP/HTTPS open source intercepte tout le trafic réseau, examine les règles de politique et utilise un LLM en tant que juge pour décider si les demandes d’agent doivent être approuvées ou refusées.
«Ce que nous avons remarqué, c’est que la couche réseau était un point d’application inexploité», a déclaré Pedro Franceschi, co-fondateur et PDG de Brex, à VentureBeat. «Chaque demande formulée par un agent est une opportunité d’intercepter, de raisonner et de prendre une décision politique.»
Franceschi souhaite que les responsables informatiques en tirent les enseignements suivants : la gouvernance des agents doit passer des autorisations au niveau du SDK et des modèles de garde-fous à un plan de contrôle de réseau centralisé qui applique et apprend du comportement réel des agents dans la nature.
Comment le Brex a ciblé la couche transport
La « solution évidente » (du moins au début) à la faille de sécurité des agents était les garde-fous, et une grande partie des premiers travaux s’est concentrée sur les outils ciblés, les autorisations par action et les approbations humaines. Mais à mesure que les agents évoluent, chaque nouvelle fonctionnalité signifie qu’il existe une autre API à régler ou à auditer, a noté Franceschi.
« Tout système agent doté de plusieurs outils et d’un accès à l’Internet ouvert crée une tension immédiate pour les constructeurs : plus vous rendez un agent compétent, plus il devient dangereux, et plus vous le rendez sûr, moins il est utile », a-t-il déclaré.
Les solutions existantes à ce compromis étaient « faibles » : les jetons API à granularité fine aident à la marge mais peuvent toujours être mal utilisés et restreindre les fonctionnalités. Les garde-fous sémantiques (tels que le contexte, les compétences ou l’orientation rapide) sont facilement contournés par une injection rapide, en particulier pour les agents connectés à Internet.
Les agents peuvent être « défragmentés » lorsqu’ils bénéficient d’un accès en lecture seule ou d’un ensemble d’outils limités, mais ils ne peuvent alors pas effectuer un travail significatif, a déclaré Franceschi. D’un autre côté, accorder un large accès en écriture et une grande surface d’outils peut entraîner des hallucinations et de réelles conséquences en matière de production.
Les passerelles MCP (Model Context Protocol) appliquent la politique au niveau de la couche de protocole, mais uniquement pour le trafic utilisant MCP. Parallèlement, les garde-fous des fournisseurs LLM sont liés à un modèle unique et peuvent être « opaques » pour être personnalisés avec des politiques spécifiques à l’entreprise. Et des outils puissants comme Nvidia OpenShell offrent davantage un « contrôle de sortie par bac à sable ».
« Lorsque nous avons commencé, nous n’avions pas trouvé de solution pour déployer en toute sécurité des harnais comme OpenClaw », a déclaré Franceschi. « Au lieu d’attendre que l’industrie rattrape son retard, nous avons décidé de nous approprier le problème et d’inventer les outils nécessaires. »
Ils avaient notamment besoin d’une plate-forme placée entre chaque agent et chaque requête réseau, et capable de prendre « des décisions nuancées sur ce qu’il fallait autoriser », a-t-il déclaré.
Cela a fait de la couche de transport un élément architectural essentiel et un point de départ naturel, a-t-il déclaré.
En fonctionnant sur cette couche, CrabTrap est indépendant du framework, du langage et de l’API. Il ne nécessite pas de wrappers SDK ni d’intégration par outil. Utilisateurs définis HTTP_PROXY et HTTPS_PROXY dans l’environnement de l’agent, et chaque requête sortante est acheminée via le proxy avant d’atteindre une destination.
Cependant, a souligné Franceschi, le Brex n’a pas commencé au niveau des transports parce qu’il pensait que c’était la seule réponse ; ils croient plutôt en une « sécurité par niveaux ».
« La couche transport était tout simplement sous-investie, et nous avons vu une opportunité d’y ajouter une application significative en plus de tout le reste », a-t-il déclaré.
La boucle de formation LLM-as-a-juge
CrabTrap combine des règles statiques déterministes avec un LLM en tant que juge pour les demandes qui ne relèvent pas des modèles connus, a expliqué Franceschi. Le juge « tire uniquement sur la longue traîne de points de terminaison inconnus ou de formes de requêtes inhabituelles », ce qui, pour un agent expérimenté, représente généralement moins de 3 % des requêtes.
Le problème le plus urgent était de savoir comment savoir si une politique est la bonne ? Avec des règles statiques, il est « relativement simple » de raisonner sur l’exactitude. Mais avec un juge LLM, le système n’est pas déterministe et les utilisateurs doivent avoir l’assurance que la politique approuve les bonnes demandes et bloque le reste.
«Notre idée clé était d’amorcer une politique à partir du comportement observé plutôt que de l’écrire à partir de zéro», a déclaré Franceschi. Commencer par un comportement réel et le modifier sur la base d’apprentissages du monde réel s’est avéré « considérablement plus efficace que de partir d’une page blanche ».
L’équipe de Brex a construit un générateur de politiques (lui-même une boucle agentique) qui exécute les agents sous-jacents en mode fantôme, analyse l’historique du trafic réseau, échantillonne les appels représentatifs et rédige une politique en langage naturel qui correspond à ce que fait réellement l’agent.
À partir de là, ils ont construit un système d’évaluation qui teste les changements de politique avant leur mise en œuvre. CrabTrap compare les entrées d’audit historiques avec un projet de politique et signale les modifications exactes à apporter. Les utilisateurs peuvent répartir les résultats par méthode, URL, décision initiale et statut de l’accord.
Tout cela se déroule avec des appels de juges simultanés, donc rejouer des milliers de demandes « prend des minutes, pas des heures », a déclaré Franceschi. Brex a également développé une boucle de rétroaction en direct : les pistes d’audit complètes sont stockées dans PostgreSQL et interrogeables via l’API d’administration et le tableau de bord. Dans les cas où une ressource est continuellement refusée, le système peut demander à un humain ou à un agent de proposer une mise à jour de politique pour examen.
« Cela boucle la boucle entre les dénégations observées et l’affinement politique », a déclaré Franceschi.
Principaux défis et obstacles
Bien sûr, la construction n’a pas été sans défis. L’un des problèmes majeurs était la latence : « Placer un LLM entre un agent et chaque demande d’API sortante semblerait arrêter les choses », a-t-il déclaré.
Cependant, cela ne s’est pas avéré être un problème aussi grave que prévu. Cela pour deux raisons : Le juge LLM n’agit que sur une petite fraction des demandes (les 3 % susmentionnés). Les agents s’adaptent rapidement à des schémas de trafic prévisibles ; Une fois observés, les modèles à volume élevé deviennent des règles statiques. Deuxièmement, en utilisant des modèles petits et rapides comme Claude Haiku, cela signifiait que, même lorsque le juge tirait, la latence supplémentaire était « négligeable ». Ce phénomène peut être encore réduit grâce à des modèles locaux et à une mise en cache rapide, a déclaré Franceschi.
Le défi le plus difficile et le moins évident était l’injection rapide, a-t-il déclaré. Le juge reçoit la requête HTTP complète et tout le contenu est contrôlé par l’utilisateur, donc potentiellement, une URL, un en-tête ou un corps de requête contrefait pourrait manipuler la décision du juge.
Brex a résolu ce problème en structurant la requête en tant qu’objet JSON avant de l’envoyer au modèle, de sorte que tout le contenu contrôlé par l’utilisateur est « échappé plutôt qu’interpolé sous forme de texte brut », a déclaré Franceschi.
Résultats et où CrabTrap pourrait évoluer
Brex suit quelques facteurs pour mesurer l’impact interne de CrabTrap : l’engagement avec les agents, les modèles de trafic réseau et les scores nets de promoteur (NPS). Le résultat le plus significatif de CrabTrap a été « la confiance organisationnelle », a déclaré Franceschi.
Auparavant, l’équipe avait de « réelles hésitations » lorsqu’il s’agissait de déployer des agents autonomes à grande échelle dans l’ensemble des opérations commerciales, car les options de garde-fou existantes n’offraient pas suffisamment de garanties.
«CrabTrap a changé ce calcul», a déclaré Franceschi. Ils disposent désormais d’une couche d’application en laquelle ils ont confiance, ce qui leur permet d’étendre le déploiement des agents à davantage de secteurs de l’entreprise et de déléguer davantage de configuration et de gestion des agents aux utilisateurs.
Franceschi a qualifié les politiques dérivées du trafic de « étonnamment fortes ». L’équipe s’attendait à ce que le concepteur de politiques produise un « point de départ approximatif » nécessitant une révision manuelle lourde. En pratique, cependant, le fait de pointer la plateforme sur quelques jours de trafic réel a produit des politiques qui correspondaient au jugement humain sur la « grande majorité des demandes retenues ».
De plus, CrabTrap a révélé la quantité de bruit générée par les agents. «La piste d’audit a rendu cela visible pour la première fois», a déclaré Franceschi. Ils ont utilisé les journaux de refus et l’analyse du trafic non seulement pour ajuster les politiques, mais aussi pour renforcer les agents eux-mêmes, supprimer des outils et éliminer des catégories entières de demandes qui faisaient perdre du temps et des jetons.
«Le proxy est devenu un outil de découverte, pas seulement un outil d’application», a-t-il déclaré.
Domaines de croissance (et contribution de la communauté open source)
Brex s’attend à ce que CrabTrap continue d’évoluer, d’autant plus qu’il l’a publié en open source. «Nous espérons que la communauté contribuera à le façonner», a déclaré Franceschi.
Les domaines d’amélioration incluent des fonctionnalités d’authentification plus approfondies telles que l’authentification unique (SSO), le contrôle d’accès basé sur les rôles (RBAC) ; des workflows d’escalade qui permettent aux agents de demander des autorisations supplémentaires ; et des recommandations politiques basées sur des modèles de déni.
La configuration programmatique, ou le développement de points de terminaison d’API pour « créer, élaborer et appliquer » des politiques aux agents, pourrait permettre d’automatiser l’ensemble du cycle de vie des politiques plutôt que de le gérer manuellement, a déclaré Franceschi.
En ce qui concerne l’escalade, si un agent se voit continuellement refuser une ressource ou un point de terminaison donné, il devrait être en mesure d’acheminer les demandes vers des humains ou d’autres agents d’IA pour examen et de justifier cela en expliquant pourquoi il a besoin d’y accéder.
«Cela transforme CrabTrap d’une frontière d’application stricte en quelque chose qui ressemble davantage à un système d’autorisation géré», a déclaré Franceschi.
De plus, la politique a été conçue pour s’amorcer à partir du trafic réseau, mais il est possible d’incorporer des signaux supplémentaires autour des traces des agents et des appels de ressources, ainsi qu’un contexte plus large sur ce que les agents tentent finalement d’accomplir. Cela peut contribuer à produire des politiques plus précises et nuancées.
Enfin, il y a une « question philosophique ouverte » sur la bonne posture pour CrabTrap : devrait-il s’agir d’une couche entièrement transparente dont l’agent lui-même ignore l’existence, ou devrait-il fonctionner davantage comme un « gestionnaire bien intentionné » ? (c’est-à-dire que l’agent connaît la couche et peut interagir avec elle).
La communauté open source peut contribuer à façonner ces développements, et CrabTrap ne fera que s’améliorer avec davantage d’utilisateurs, a déclaré Franceschi. Les agents du Brex communiquent avec un ensemble spécifique d’API ; Les équipes utilisant CrabTrap avec différents agents, services et exigences politiques feront apparaître « des cas extrêmes et des modèles que nous ne pouvons pas résoudre seuls ».
«Nous avons des projets ambitieux quant à la direction que cela pourrait prendre, et nous préférons construire à ciel ouvert», a déclaré Franceschi.
Ce que les autres constructeurs peuvent apprendre de CrabTrap
La réponse a été plus forte que prévu. CrabTrap compte plus de 700 étoiles sur GitHub. Franceschi a déclaré que Brex avait également entendu OpenAI, le PDG de Y Combinator, Garry Tan, et le programmeur Pete Steinberger, tous exprimant leur intérêt pour le déploiement d’une infrastructure interne similaire.
La leçon plus large : « Ne laissez pas les lacunes en matière d’infrastructures devenir des excuses pour attendre », a conseillé Franceschi. Il existe de « véritables obstacles » pour toute entreprise cherchant à déployer sérieusement des agents d’IA, notamment des problèmes de sécurité, le manque d’outils ou des garde-fous peu clairs.
« Il est tentant de ne rien faire jusqu’à ce que l’industrie rattrape son retard », a-t-il déclaré. «La leçon de CrabTrap est que vous pouvez vous approprier directement ces problèmes.»
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
