AWS a confirmé mardi avoir patché un contournement d'autorisation (CWE-862) dans Amazon Quick — le service BI et IA-agentique — qui laissait les utilisateurs avec permissions refusées par admin atteindre les chat agents IA quand même. Jason Kao de Fog Security a signalé le bug via HackerOne (rapport #3577145) le 4 mars ; AWS a livré le fix aux régions initiales le 11 mars et complété le rollout le 12 mars. La divulgation publique vient aujourd'hui après la fenêtre standard de divulgation coordonnée. Le bug n'expose pas de données cross-tenant, mais pour les admins essayant de gouverner l'usage « shadow AI » à l'intérieur de leur propre compte AWS, il a cassé le seul contrôle qu'ils avaient.
La mécanique de contournement est embarrassamment simple. Un admin met des permissions personnalisées pour refuser les capacités Chat Agent pour un utilisateur. L'UI de Quick cache dûment le panneau chat. Mais une requête HTTP directe vers le backend Chat Agent (« Parle-moi des mangues ») va droit à l'agent parce que la vérification d'autorisation côté serveur qui aurait dû valider le refus des permissions personnalisées n'a jamais été écrite. CWE-862 (« Autorisation Manquante ») est la classe de bug d'autorisation la plus commune précisément parce qu'elle est invisible jusqu'à ce que quelqu'un prenne la peine de sonder au-delà de l'UI. Post-patch la même requête retourne HTTP 401 avec `AGENT_ACCESS_DENIED`. Scope : limité au compte AWS d'origine, avec l'agent chat système par défaut qui s'auto-provisionne au lancement de Quick restant atteignable aux utilisateurs refusés. Fog Security n'a observé aucun accès cross-tenant aux données, aucune escalade de privilège hors du compte affecté.
L'angle intéressant n'est pas ce bug en particulier — c'est le pattern. Les hyperscalers livrent des produits IA agentiques à vitesse de conférence (Amazon Quick à re:Invent, OpenAI Daybreak la semaine dernière, mode Gemini Live de Google), et la surface de contrôle d'accès pour chaque nouveau produit est plus grande que la capacité de revue des équipes IAM. L'enforcement UI-only est exactement le raccourci que prennent ceux qui livrent sous pression, et les admins assument « j'ai refusé à cet utilisateur la permission, donc il ne peut pas » sans penser à tester avec un appel direct au backend. Le problème de gouvernance « shadow AI » — l'IT entreprise ne peut pas réellement empêcher les employés d'utiliser les fonctionnalités IA pour lesquelles la compagnie paye aussi — devient une vraie question de procurement. AWS a patché en 8 jours, ce qui est le bon pattern. Mais le fait que le bug ait été livré en premier lieu est le problème récurrent, et ça continuera d'arriver à mesure que plus de services agentiques atterrissent.
Déjà patché dans toutes les régions au 12 mars — aucune action nécessaire pour les clients Quick au-delà de vérifier que le service montre le comportement mis à jour. La note plus large pour les constructeurs : si vous livrez un produit IA agentique, les vérifications d'autorisation doivent tourner sur chaque endpoint backend qui touche l'agent, pas seulement sur la surface UI qui liste les actions. La question de gouvernance shadow-AI va être un point de pression réglementaire à l'intérieur des grandes orgs sur la prochaine année — les admins veulent des règles de refus exigibles, les fournisseurs IA veulent que leurs fonctionnalités soient aussi faciles à atteindre que possible, et ces deux demandes ne sont pas compatibles sans IAM côté serveur disciplinée. Le manquement d'AWS Quick est le cas facile (single-tenant, patché vite). Les cas plus durs sont les intégrations cross-produit où le « je suis autorisé » d'un service est trusté par un autre sans re-vérification.