Contexte de sécurité des agents IA
Les agents d'intelligence artificielle sont de plus en plus intégrés à des flux de travail automatisés. Leur capacité à appeler des API externes implique la manipulation d'informations d'authentification, souvent injectées directement dans le contexte d'exécution. Cette pratique expose les jetons d'accès, les clés API ou les mots de passe à des risques de fuite, notamment lorsqu'un agent est compromis ou lorsqu'un développeur partage accidentellement son code.
Le modèle traditionnel consiste à stocker les secrets dans des variables d'environnement ou des fichiers de configuration. Dans un environnement d'agent, ces mécanismes ne garantissent pas la séparation entre le code de l'agent et les données d'authentification, créant une surface d'attaque élargie. La nécessité d'une isolation stricte des identifiants devient donc un enjeu de cybersécurité majeur pour les organisations qui déploient des agents IA en production.
Architecture proposée par WorkOS : Pipes et Relay
WorkOS introduit deux composants complémentaires. Pipes se présente comme un widget « drop‑in » qui prend en charge le flux complet d’OAuth : il initie la connexion, gère le rafraîchissement des jetons et stocke les identifiants de façon chiffrée. Le stockage se fait côté serveur, ce qui empêche toute exposition du secret dans le code de l'agent.
Le second composant, Relay, est disponible en accès anticipé. Relay agit comme un proxy dédié aux appels API de l'agent. Lorsqu'un agent envoie une requête, Relay intercepte le trafic, y attache les identifiants stockés côté serveur et ne transmet la requête qu'aux hôtes autorisés par le fournisseur. Cette restriction d’hôte limite les vecteurs d’exfiltration : même si un agent tente d’appeler un endpoint non approuvé, la requête est bloquée avant d’atteindre le réseau externe.
Les deux services fonctionnent de manière indépendante mais peuvent être chaînés : le widget Pipes fournit les secrets à Relay, qui les injecte dynamiquement dans chaque appel. Cette chaîne élimine la nécessité de coder les jetons dans le script de l'agent, tout en conservant la capacité de renouveler les tokens sans interruption de service.
Analyse des impacts et limites
Sur le plan de la sécurité, l’isolation serveur réduit la surface d’attaque liée aux fuites de secrets. Le chiffrement côté serveur, combiné à la gestion automatisée du rafraîchissement, diminue le temps d’exposition des jetons. De plus, la restriction d’hôte appliquée par Relay crée une barrière supplémentaire contre les mouvements latéraux, car chaque appel doit correspondre à une destination préalablement approuvée.
Cependant, la solution ne supprime pas la nécessité de contrôler les autorisations au niveau de l’agent. Le texte indique que « Permissions and other outbound paths still need their own controls », ce qui signifie que les politiques d’accès aux ressources internes restent à implémenter séparément. En outre, la dépendance à un service tiers (WorkOS) introduit un point de défaillance : une indisponibilité de Relay ou de Pipes pourrait interrompre l’ensemble des flux d’agent, affectant la continuité opérationnelle.
Enfin, le modèle repose sur la confiance dans le chiffrement et la gestion des clés de WorkOS. Les organisations doivent vérifier les certifications de conformité (par exemple SOC 2, ISO 27001) et auditer les mécanismes de rotation des clés pour éviter des scénarios où un accès serveur compromettait l’ensemble des agents.
