Créer une démo IA est devenu un jeu d’enfant. Mais déployer en production dans les entreprises reste bloqué par des problèmes de performance, des coûts et des failles de sécurité que les équipes signalent depuis longtemps.

Aujourd’hui, nous prenons l’une de ces vulnérabilités à bras-le-corps.

Une nouvelle catégorie d’attaque sur l’identité

Des chercheurs en sécurité de l’Université chinoise de Hong Kong ont récemment identifié de nouvelles variantes de COAT (Cross-app OAuth Account Takeover)une attaque de phishing ciblant l’IA agentique et les plateformes d’intégration. Ils ont présenté leurs travaux à Black Hat 2025, montrant comment les architectures OAuth basées sur des connexions peuvent être exploitées pour accéder sans autorisation à des systèmes d’entreprise.

Le mécanisme est simple, mais redoutable :

  1. Un acteur malveillant (Mallory) déclenche un flux d’autorisation pour une intégration GitHub, par exemple
  2. Au lieu de finaliser ce flux, Mallory envoie le lien d’autorisation à une victime (Bob)
  3. Si Bob clique sur le lien et autorise l’accès (ou si GitHub autorise automatiquement parce que Bob a déjà connecté une intégration similaire), l’autorisation aboutit
  4. Comme la session initiale appartient à Mallory, Mallory obtient l’intégration GitHub avec les accès de Bob, soit une prise de contrôle du compte.

Ce n’est pas une vulnérabilité passive. Elle nécessite du phishing actif. La victime doit cliquer sur un lien malveillant et, dans la plupart des cas, consentir explicitement à l’autorisation. Mais toute équipe de sécurité sait que le phishing et le spearphishing sont des vecteurs d’attaque efficaces… et quand vous êtes un agentique runtime comme Arcade.dev, le facteur humain est un risque qui mérite d’être traité.

Pourquoi c’est important pour l’IA agentique

Les entreprises construisent de plus en plus d’agents qui doivent se connecter à leurs systèmes métier, en s’appuyant sur des technologies comme Arcade pour sécuriser ces connexions. C’est ainsi qu’émerge ce que les chercheurs appellent le « connection-based OAuth » ou « OAuth-as-a-Service » : des systèmes centralisés de gestion de tokens qui créent des « connexions OAuth » abstraites comme handles pour les tokens gérés.

Si elles ne sont pas construites avec soin, ces plateformes de connexions OAuth peuvent être victimes de nombreuses attaques documentées contre OAuth. Dans le scénario le plus grave, l’attaquant n’a même pas besoin d’un compte dans votre organisation. Il crée un compte sur une application utilisant une infrastructure OAuth partagée, déclenche un flux d’authentification, et peut hameçonner des utilisateurs d’organisations complètement différentes. Les relations de confiance existent déjà, beaucoup d’utilisateurs ont déjà consenti à des accès larges, et les utilisateurs inattentifs cliquent souvent sur des liens sans trop les examiner.

La réponse d’Arcade : refonte du flux d’autorisation

Grâce à la position d’Arcade au sein des comptes enterprise et à l’expérience en sécurité de l’équipe, Luo et al. nous ont contactés en privé en avril 2025 pour nous présenter leurs travaux. Notre réponse a été sans équivoque : il fallait corriger cela, et bien le corriger. Nos clients comptent parmi les plus grandes entreprises déployant des agents en production, ce n’était pas négociable. En explorant différentes solutions, nous avons aussi tenu à respecter deux principes directeurs :

  • Garder Arcade simple à utiliser
  • Rester sécurisé par défaut autant que possible

Au final, cela nous a conduits à repenser le flux d’autorisation d’Arcade en introduisant une vérification obligatoire de l’utilisateur. Les applications et agents construits sur Arcade disposent désormais de deux options, adaptées à différentes étapes du cycle de vie de votre projet :

  • Vérification utilisateur Arcade : lors de l’autorisation, les utilisateurs sont invités à se connecter à leur compte Arcade (s’ils ne le sont pas déjà). Idéal pour démarrer, les projets internes et les preuves de concept : simple, sécurisé par défaut, sans développement supplémentaire.
  • Vérification utilisateur personnalisée : pour les déploiements en production, Arcade peut déléguer à une route de votre application qui effectue les vérifications de session, sans que vos utilisateurs finaux n’aient à interagir directement avec Arcade. Ils restent entièrement dans le contexte d’authentification et l’UX de votre application.

Tous les détails de ces approches sont disponibles ici : docs.arcade.dev/en/home/auth/secure-auth-production.

Les deux approches atteignent le même objectif : lier le flux d’autorisation à une session utilisateur vérifiée, de façon transparente pour l’utilisateur final. Quand Bob reçoit le lien de phishing de Mallory, son navigateur est sollicité pour vérifier son identité avant que le flux puisse aboutir. Le système détecte que la session appartient à Bob mais que l’autorisation a été initiée par Mallory, et rejette correctement le flux pour protéger Bob.

Scénarios protégés

Cette approche élimine les deux variantes d’attaque, inter-tenant et inter-compte :

Attaques inter-tenantUn acteur malveillant possédant un compte Arcade piège une victime utilisant une application complètement différente basée sur Arcade. Auparavant possible dans certains cas où les relations de confiance et les applications OAuth étaient partagées. Désormais bloqué dans tous les cas, car la vérification utilisateur s’assure que l’utilisateur finalisant le flux correspond à celui qui l’a initié, et les URI OAuth doivent être uniques

Avant

Après

Attaques inter-compte : Un acteur malveillant ayant un compte dans votre application piège un autre utilisateur de cette même application. Auparavant possible car l’identité de l’utilisateur n’était pas vérifiée lors de l’autorisation. Désormais bloqué grâce au même mécanisme de vérification.

Avant

Après

Autres approches évaluées

Lors de notre première analyse de cette vulnérabilité avec l’équipe de recherche, nous avons exploré plusieurs stratégies d’atténuation avant de retenir la vérification utilisateur. Chacune avait ses attraits, mais aucune ne traitait la cause racine : l’absence de lien réel entre l’utilisateur initiant l’autorisation et celui la finalisant. Voici les pistes explorées qui n’ont pas passé la sélection :

  • PKCE (Proof Key for Code Exchange) a été notre premier réflexe. C’est un élément important de la sécurité OAuth pour les clients non fiables (publics), et les praticiens OAuth y recourent naturellement. Mais PKCE n’aide pas ici : l’attaquant contrôle la requête initiale, et PKCE garantit seulement l’intégrité de la requête elle-même. Quand la victime finalise le flux, elle répond simplement au défi de l’attaquant.
  • La signature cryptographique de la requête initialeétait tentante, mais se heurte au même problème. C’est l’attaquant qui initie le flux. C’est lui qui génère et signe la requête. Cela ne ferait que valider les donnéesde l’attaquant, sans empêcher l’attaque.
  • Validation de l’identité renvoyée par les IDPs/AS tiersCertains fournisseurs d’identité et serveurs d’autorisation OAuth retournent des informations sur l’utilisateur qui autorise, mais pas tous. Et ceux qui le font utilisent des formats variés : Github vous identifie par un @username, Gmail par une adresse e-mail.
  • Timeouts agressifssemblaient aussi tentants : rendre la fenêtre d’autorisation si courte qu’elle serait difficile à exploiter. Mais ça ne la rendrait pas impossible. Par exemple, un spearphishing via Discord, SMS, IRC Slack ou d’autres messageries pourrait contourner cela avec une attaque bien synchronisée. Un attaquant habile et motivé peut amener une victime à cliquer très vite sur un lien si elle est déjà devant son clavier. De plus, une fenêtre suffisamment courte pour vraiment prévenir cette attaque rendrait votre application/agent inutilisable (un compromis impossible).
  • Sécurité par l’obscurité, comme masquer les flux dans des iFrames ou des popups. Cela pourrait rendre l’exploitation plus difficile, sans pour autant stopper un attaquant expérimenté capable de contourner facilement l’obfuscation côté client.
  • Imposer des applications OAuth et des URI de redirection dédiées pour chaque projetrésout une partie du problème, et est déjà supporté par de nombreuses plateformes dont Arcade. Cela atténue le scénario inter-tenant, mais n’élimine pas le vecteur d’attaque inter-compte où l’attaquant et la victime utilisent la même application.

Le problème fondamental de toutes ces fausses-atténuations : l’identité de l’utilisateur n’est jamais réellement confirmée. La seule vraie solution est donc celle que nous avons mise en œuvre : lier le flux d’autorisation à une session utilisateur vérifiée. Tout le reste n’est que théâtre de sécurité.

L’appel d’Arcade à l’industrie

COAT illustre exactement le type de défi sécuritaire qui préoccupe les équipes de sécurité alors que les entreprises s’empressent de déployer des agents. Pendant que le cycle de hype se concentre sur ce que les agents peuvent faire, les équipes de sécurité en production posent une autre question : « Peut-on vraiment déployer ça en toute sécurité ? » La réponse doitêtre oui, mais seulement si l’industrie prend ces vulnérabilités au sérieux.

L’Arcade Runtime est utilisé par certaines des plus grandes entreprises déployant de vrais agents en production. La sécurité n’est donc pas une réflexion après coup, elle est au fondement de notre architecture. C’est pourquoi nous avons choisi de traiter ce problème proactivement et déployé les correctifs il y a plusieurs mois. Nous n’attendons pas qu’une faille soit exploitée dans la nature. Nous ne traitons pas cela comme une préoccupation théorique. Nous l’avons corrigé, avant que cela ne devienne un problème pour nos clients.

Toutes les plateformes d’intégration n’ont pas encore mitigé COAT, mais nous espérons qu’elles suivront. Quand les entreprises déploient des agents IA en production à grande échelle, elles ne peuvent pas se permettre de travailler avec des technologies qui traitent la sécurité comme une réflexion après coup. Elles doivent pouvoir faire confiance à leurs partenaires technologiques pour prendre les décisions architecturales difficiles quand c’est nécessaire, même si cela implique un investissement d’ingénierie significatif.

Arcade fait partie des pionniers de ces déploiements agentiques pensés avec la sécurité en premier, en collaboration avec les meilleurs chercheurs en sécurité du monde. Nous sommes déterminés à rester à l’avant-garde, parce que nous croyons que l’avenir de l’IA agentique en dépend. Les entreprises qui déploient réellement des agents à grande échelle, celles quipassent des démos aux systèmes de productionqui gèrent des données sensibles et des workflows critiques, ont besoin de partenaires qui accordent autant d’importance à leur posture de sécurité qu’à l’expérience développeur. C’est l’exigence que nous nous imposons, et nous n’en dérogeons pas. Parce que la promesse de l’IA agentique ne se résume pas à ce que les agents peuvent faire : c’est aussi la capacité des entreprises à leur faire confiance pour le faire en toute sécurité.