En mars 2026, des attaquants ont compromis l’environnement AWS de Context.ai et volé des tokens OAuth que son « IA Office Suite » (désormais désactivé) avait accumulés auprès d’utilisateurs. L’un de ces tokens appartenait à un employé de Vercel qui s’était inscrit avec son compte Google Workspace professionnel et avait accordé des permissions étendues à l’intégration. L’attaquant a utilisé ce token pour se connecter au Google Workspace de Vercel en tant qu’employé, a pivoté vers les systèmes internes de Vercel et a exfiltré une partie des variables d’environnement non sensibles de clients, qui ont ensuite été mises en vente sur BreachForums pour 2 M$ par un compte se réclamant de ShinyHunters. Les deux entreprises ont publié des bulletins le 19 avril 2026. Le mode de défaillance commun n’est pas l’injection de prompt, ni un bug dans un LLM, ni une faille du protocole MCP. C’est le schéma vieux de plusieurs décennies d’une application OAuth tierce qui stocke côté serveur des tokens utilisateurs à longue durée de vie et à larges permissions, devenant ainsi un coffre à tokens de grande valeur dont la compromission se propage à tous les tenants connectés.

En tant qu’acteur central de la sécurité agentique, nous avons chez Arcade réalisé une analyse approfondie pour comprendre comment tout cela s’est déroulé. Voici la décomposition

Ce qui a cédé

Vercel : Un employé avait connecté le « IA Office Suite » de Context.ai à son compte Google Workspace d’entreprise avec un consentement large (« Tout autoriser »). Quand l’environnement AWS de Context.ai a été compromis, l’attaquant a récupéré le token Google OAuth de cet employé, s’est authentifié en tant que lui dans le Workspace de Vercel, puis a escaladé vers les environnements internes de Vercel et lu des variables d’environnement que les clients n’avaient pas marquées comme « sensibles ». Les variables d’environnement sensibles de Vercel (stockées de façon non lisible) ne montrent aucune trace d’accès.

Context.ai : Des attaquants ont obtenu un accès non autorisé à l’environnement AWS qui hébergeait le IA Office Suite désactivé, un produit grand public permettant aux utilisateurs de connecter des agents IA à des applications SaaS tierces via une couche d’intégration. Cet environnement contenait des tokens OAuth des utilisateurs d’Office Suite, et au moins certains ont été volés. Context.ai a d’abord informé un seul client en mars 2026 et n’a pris la mesure de l’étendue des dégâts qu’après que l’enquête de Vercel l’a révélée. Context.ai n’a pas divulgué le vecteur d’intrusion initial dans AWS. CrowdStrike a été mandaté pour la forensique, mais aucun rapport public n’avait été publié au 21 avril. L’environnement AWS concerné, l’hébergement et l’application OAuth d’Office Suite ont été mis hors ligne après l’incident.

Classe commune : Accumulation de tokens par un mandataire confus dans une intégration IA multi-tenant. Un service IA tiers avait accumulé des tokens OAuth de production pour les fournisseurs d’identité principaux de nombreux utilisateurs, les avait stockés côté serveur, puis (une fois compromis) est devenu un pivot en un seul saut vers chaque tenant ayant jamais autorisé l’application. La dimension « IA » est accessoire à l’exploitation ; la vulnérabilité est une compromission classique de coffre à credentials dans la chaîne d’approvisionnement SaaS, amplifiée par des scopes OAuth trop larges.

Modèle d’auth en cause :

  • Côté Vercel : flux d’autorisation OAuth 2.0 Google Workspace avec consentement à larges permissions accordé par une identité d’entreprise. The Register cite Context.ai indiquant que les « configurations OAuth internes de Vercel semblent avoir autorisé cette action à accorder ces larges permissions dans le Google Workspace d’entreprise de Vercel. » Autrement dit, les contrôles d’administration Workspace ne restreignaient pas les applications tierces que les employés pouvaient autoriser avec des identités d’entreprise, et aucune restriction de scope par application n’était en place.

  • Côté Context.ai : stockage côté serveur de refresh tokens OAuth 2.0 à longue durée de vie (et probablement de tokens d’accès à courte durée) pour un IdP tiers, dans un environnement AWS multi-tenant partagé, couplé à une UX de consentement acceptant des scopes larges (« Tout autoriser »). L’état du chiffrement des tokens au repos n’est pas divulgué ; le fait que les tokens étaient utilisables après exfiltration implique que le chiffrement ne couvrait pas les tokens, ou que la clé de déchiffrement était également accessible depuis l’environnement compromis.

IOC (verbatim de Vercel) : OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com Les administrateurs Google Workspace sont invités à vérifier l’utilisation immédiatement. Vercel indique que l’application « a potentiellement touché ses centaines d’utilisateurs dans de nombreuses organisations. »

Implication IA / MCP / appel d’outil : Le produit compromis était un produit d’agents IA (Context.ai IA Office Suite) qui utilisait OAuth pour appeler des SaaS externes au nom des utilisateurs. L’exploitation réelle n’a toutefois pas utilisé le modèle IA, n’a pas eu recours à l’injection de prompt et n’a pas nécessité le protocole MCP. Le produit IA n’était pertinent que parce qu’il était l’entité qui avait demandé et stocké le token OAuth à larges permissions. Aucun CVE n’a été attribué à la date de ce rapport ; aucun n’est attendu, car aucune vulnérabilité logicielle dans Vercel ou Google n’a été exploitée.

Le mode de défaillance commun

Accumulation centralisée de tokens OAuth avec des scopes trop larges dans une plateforme d’agents tierce, couplée à un rayon d’explosion inter-tenant au niveau du plan de contrôle cloud de la plateforme.

Mécaniquement, le schéma est le suivant :

  1. Une plateforme IA/agent tierce sollicite un consentement OAuth pour l’identité principale d’un utilisateur (Google Workspace, Microsoft 365, etc.) avec des scopes suffisamment larges pour couvrir de nombreux appels d’outils futurs, souvent parce que le produit ne sait pas à l’avance quels outils l’utilisateur invoquera.
  2. Les refresh tokens sont stockés côté serveur, de façon centralisée par la plateforme, car l’agent s’exécute de façon asynchrone ou dans une boucle côté serveur et doit pouvoir appeler les API des fournisseurs sans que l’utilisateur soit présent.
  3. L’environnement cloud de la plateforme est un domaine de confiance unique. Une compromission de cet environnement produit un coffre à tokens : une seule intrusion, de nombreuses victimes, au niveau de l’IdP et pas seulement au niveau de la plateforme.
  4. Le token volé est indiscernable d’une session légitime côté fournisseur. Il n’existe pas d’attestation hors bande prouvant que l’appel provient de la plateforme et non d’un attaquant rejouant le token, car c’est la plateforme qui a reçu le token du fournisseur au départ.
  5. La politique IdP d’entreprise ne restreignait pas les applications tierces pouvant se lier aux identités d’entreprise, ni avec quels scopes. La configuration d’administration de Vercel autorisait « Tout autoriser » à une application que Context.ai décrit comme émettant des tokens reflétant « l’étendue d’accès détenue par ce compte. »

C’est le même type d’incident que la compromission OAuth GitHub de Heroku/Travis-CI en 2022 et l’incident CircleCI de 2023. Ce n’est pas nouveau avec l’IA. Ce que l’IA change, c’est le volume et l’étendue des scopes : une plateforme d’agents qui peut « envoyer des emails, créer des documents, lire Drive, gérer le calendrier, poster sur Slack » demande une union de scopes bien plus large qu’une intégration mono-usage, et devient donc un coffre à tokens bien plus précieux.

Ce que l’architecture d’Arcade fait pour protéger vos agents

Arcade.dev est le seul runtime MCP pour des déploiements d’agents IA sécurisés et fiables.

Isolation des tokens OAuth par utilisateur. Arcade lie chaque autorisation à un utilisateur précis : l’outil déclare requires_auth=Reddit(scopes=["read"]) et Arcade déclenche un challenge OAuth pour cet utilisateur, le fournisseur émet un token qu’Arcade stocke associé à cet utilisateur, et le token est injecté dans l’outil Context uniquement pendant l’invocation de cet utilisateur.

Scope par outil, pas par application. Chaque outil déclare ses scopes minimaux. Gmail.SendEmail demande gmail.send et non une union de scopes à l’échelle du Workspace. L’utilisateur contrôle ainsi précisément quelles données les services tiers peuvent consulter et quelles actions ils peuvent effectuer dans ses comptes. Un token d’outil unique compromis a un rayon d’explosion étroit par construction.

Le LLM et le client MCP ne voient pas le token. Arcade est conçu pour gérer les tokens OAuth avec soin quand les agents invoquent un outil. Le token OAuth est récupéré par l’Engine et injecté dans un objet Context côté serveur au runtime. La fonction outil effectue l’appel HTTP sortant côté serveur. Cela ferme le chemin injection-de-prompt → fuite-de-token qui existe quand des outils mal conçus chargent les tokens dans le même processus que le modèle.

Respect des frontières de sécurité. Comme nous l’avons détaillé dans notre guide d’autorisation de serveur MCP, Arcade respecte les frontières de sécurité entre le client MCP (non fiable), le serveur MCP (fiable) et le fournisseur d’auth (fiable). C’est l’inversion architecturale du schéma Context.ai, où le runtime d’agent était aussi le coffre à tokens et où une seule compromission a tout fait effondrer.

Vérificateur d’utilisateur. Quand un utilisateur autorise un outil pour la première fois, Arcade effectue une vérification d’identité « pour s’assurer que l’utilisateur qui autorise l’outil est bien celui qui a lancé le flux d’autorisation, ce qui aide à prévenir les attaques de phishing. » Les déploiements en production sont censés implémenter un vérificateur personnalisé pour que les utilisateurs s’authentifient contre le système d’identité propre de l’application, et non celui d’Arcade.

Hooks d’accès contextuel. Arcade fournit trois points de hook (accès, pré-exécution, post-exécution) qui permettent à l’opérateur d’injecter des webhooks pouvant refuser un appel d’outil, supprimer des données personnelles d’une réponse, analyser les sorties pour détecter des injections de prompt, ou enregistrer chaque invocation. Les hooks s’enchaînent au niveau de l’organisation et du projet ; le comportement en cas d’échec (fail-closed ou fail-open) est configurable. C’est le mécanisme pour « auditer chaque interaction » et détecter les schémas d’exfiltration au runtime.

Auto-hébergement pour réduire le rayon d’explosion. Arcade publie de la documentation pour le déploiement de serveur MCP sur site et un Engine auto-hébergé («  lire la doc). Faire tourner Arcade dans le cloud du client réduit le risque inter-tenant illustré dans le cas Context.ai à un risque mono-tenant.

Journaux d’audit. Le plan de contrôle d’Arcade est entièrement auditable et fournit un enregistrement automatique et immuable de chaque action administrative effectuée sur le runtime d’agents.

Conclusion

Parler « d’incident IA » est une imprécision qui occulte la vraie leçon. Aucun modèle n’a été contourné. Aucune faille MCP n’a été exploitée. Aucune injection de prompt n’a été déclenchée. Ce qui s’est passé, c’est qu’une petite entreprise IA a construit un produit nécessitant des tokens OAuth larges et à longue durée de vie pour offrir un comportement agentique utile, les a stockés centralement, a été compromise, et a livré à un attaquant une session d’entreprise prête à l’emploi donnant accès à l’employeur de l’un de ses utilisateurs. La dimension IA compte parce que les produits agentiques demandent systématiquement des unions de scopes plus larges que les intégrations mono-usage, ce qui rend leurs backends plus précieux à cibler. Mais dans ce cas précis, la technique d’exploitation est un pivot OAuth tiers typique des années 2010.

L’architecture d’Arcade s’attaque directement aux deux propriétés les plus dangereuses de ce schéma : elle scope les tokens par outil plutôt que par application, et elle maintient les tokens hors du processus LLM/client pour qu’une compromission de la surface orientée agent ne signifie pas une compromission des tokens. Soyons honnêtes : cela ne rend pas le plan de contrôle invincible, ne lit pas dans les pensées des utilisateurs sur les scopes raisonnables, et ne corrige pas la politique IdP d’entreprise. Ce que cela fait, c’est changer le calcul du rayon d’explosion : compromettre un coffre à tokens façon Arcade donne des tokens plus étroits et plus auditables, et les déploiements auto-hébergés suppriment le levier inter-tenant qui a fait d’une seule intrusion chez Context.ai un incident multi-organisations. La bonne conclusion pour les responsables techniques est plus ciblée que « changez de prestataire ». C’est : « auditez chaque application OAuth tierce liée à votre IdP d’entreprise, imposez des minima de scopes au niveau de l’administration Workspace, et traitez toute plateforme d’agents qui accumule des refresh tokens comme un store de credentials de production. » Vercel a déjà modifié un comportement par défaut en réponse : la création de variables d’environnement est désormais sensible par défaut. Le défaut plus profond qui doit encore changer se situe en amont des deux entreprises, dans l’UX de consentement OAuth.

L’équipe d’Arcade.dev a passé des années à renforcer l’auth chez Okta, Stormpath et Redis. Nous appliquons ces leçons pour rendre l’infrastructure IA prête pour la production. Découvrez ces principes en action dans notre blueprint pour une alternative OpenClaw sécurisée avec Arcade et Claude Code.

Vous voulez créer des agents IA qui fonctionnent vraiment en production ? En attendant que l’autorisation arrive dans MCP, Arcade implémente déjà une auth sécurisée pour plus de 100 intégrations. Pas de bot tokens, pas de cauchemars de sécurité. Juste de vrais flux OAuth qui fonctionnent.

Commencer à construire avec Arcade → S’inscrire.