L'arrêt d'Atlas déplace le risque d'injection vers un runtime plus vaste
OpenAI retire le navigateur Atlas et intègre la navigation agentique à ChatGPT Work, réunissant navigateur, exécution de code et connecteurs d'entreprise sous un même contexte d'autorisation — ce qui élargit le rayon d'impact de l'injection de prompt.
De quoi s’agit-il ?
Le 9 juillet 2026, OpenAI a annoncé l’arrêt de son navigateur autonome Atlas, dont l’accès prendra fin définitivement le 9 août 2026. Les capacités de navigation agentique inaugurées par Atlas sont intégrées à ChatGPT Work, une nouvelle plateforme de bureau réunissant ChatGPT, l’agent de code Codex et la navigation agentique, propulsée par la famille de modèles GPT-5.6. Atlas avait été lancé le 21 octobre 2025 en tant que navigateur basé sur Chromium, réservé à macOS, et n’a jamais livré les versions Windows, iOS ou Android promises.
L’enjeu de sécurité ne réside pas dans l’abandon du produit, mais dans le devenir de sa faiblesse centrale. Atlas est arrivé avec un problème d’injection de prompt qu’OpenAI qualifie elle-même de structurel, et consolider les capacités agentiques dans ChatGPT Work ne supprime pas ce problème : cela le déplace vers un runtime à la surface d’attaque plus large. Cette brève s’appuie sur des informations publiées le 11 juillet 2026, ainsi que sur une couverture antérieure d’octobre et décembre 2025.
Comment cela fonctionne
L’injection de prompt a suivi Atlas dès son lancement. Une semaine après ses débuts en octobre 2025, des chercheurs ont montré que des instructions dissimulées dans le contenu d’une page web ordinaire pouvaient amener l’assistant à exécuter des actions non autorisées par l’utilisateur — modifier les paramètres du navigateur, produire des résumés trompeurs, et potentiellement atteindre des identifiants dans des sessions authentifiées. Un autre défaut permettait à des URL malformées de divulguer des informations sur des sites précédemment visités.
Aucune de ces failles n’était propre au code d’OpenAI. Comme le résume George Chalhoub (UCL), l’injection de prompt « fait s’effondrer la frontière entre les données et les instructions ». La tension architecturale est concrète : le bac à sable de Chromium isole les processus du navigateur pour contenir un site compromis, mais un agent qui lit le contenu des pages et agit sur plusieurs sites par conception franchit ces frontières — cette portée inter-domaines est toute la valeur du produit. La propriété qui permet à un agent de réserver un vol sur plusieurs sites de compagnies aériennes est aussi celle qui permet à une page malveillante d’émettre des instructions que l’agent va suivre.
ChatGPT Work élargit ce risque. La conception initiale de Codex était strictement bornée : il clonait un dépôt dans une microVM isolée, fonctionnait hors ligne pendant la phase agent et ne touchait jamais l’hôte hors de l’espace de travail. Le produit fusionné supprime cette frontière. Accès navigateur, exécution de code, interaction avec les fichiers locaux et connexions actives aux outils d’entreprise — Slack, e-mail, Drive, SharePoint, agendas — partagent désormais un même runtime d’agent et un même contexte d’autorisation. Une seule injection réussie dans une page ou un e-mail lu par l’agent peut, en principe, déclencher des actions sur tous les systèmes connectés à la fois. C’est le « trio fatal » — entrée non fiable, accès à des données privées et capacité d’agir — concentré en une seule attribution d’autorité.
Pourquoi c’est important
Cette migration est un cas d’école d’un schéma que les défenseurs verront se répéter : la consolidation des capacités est pratique pour l’utilisateur et augmente le rayon d’impact pour l’attaquant. Quand un agent de navigation est compromis, les dégâts sont bornés par ce que le navigateur peut atteindre. Quand ce même agent exécute aussi du code et détient les jetons d’une douzaine de systèmes d’entreprise, une instruction injectée hérite de toute cette autorité dans la même session.
Les responsables sécurité d’OpenAI ont été francs : il ne s’agit pas d’un bug corrigeable. Son RSSI parle d’« un problème de sécurité de pointe, non résolu », et son avis de décembre 2025 indique que l’injection est « peu susceptible d’être un jour totalement résolue ». Sasi Levi (Noma Security) énonce la limite clairement : tant que le modèle lit du texte contrôlé par l’attaquant et peut influencer des actions, même indirectement, il existera des moyens de le contraindre. Pour quiconque connecte des données d’entreprise à un agent consolidé, la bonne question n’est pas « le modèle est-il jailbreaké ? » mais « que peut atteindre une seule instruction injectée dans cette session ? ».
Défenses
- Réduire le contexte d’autorisation. N’accordez à l’agent que le privilège minimal nécessaire à la tâche, cadré par espace de travail et par tâche — et non l’union de tout ce que l’utilisateur peut faire. Les connecteurs inutiles au flux ne doivent pas être atteignables dans la session.
- Cloisonner les domaines de confiance. N’autorisez pas un agent qui lit du contenu web ou e-mail non fiable à partager un runtime avec des actions à forte autorité (exécution de code, connecteurs financiers ou d’administration) sans frontière entre lecture et action.
- Conserver une revue hors bande des actions conséquentes. OpenAI a ajouté une couche « Auto-Review » — un second modèle qui vérifie les actions significatives avant exécution — et les administrateurs peuvent restreindre l’accès au navigateur, aux plug-ins et aux fichiers au niveau de l’espace de travail. Considérez ces contrôles comme nécessaires mais insuffisants : des garde-fous déterministes sur les actions à fort impact valent mieux qu’un modèle qui en contrôle un autre.
- Privilégier le bac à sable distant pour la navigation non fiable. Le nouveau navigateur cloud exécute les tâches sur les serveurs d’OpenAI plutôt que dans la session de l’utilisateur, réduisant l’interaction avec les fichiers locaux et les comptes connectés. Cela n’élimine pas le risque d’injection, mais réduit ce qu’une compromission peut toucher.
- Faire tourner les secrets en cas d’exposition et journaliser les actions. Supposez que tout identifiant atteignable par un agent compromis peut être exfiltré. Journalisez les appels de connecteurs et les actions sortantes pour qu’une chaîne injectée reste auditable a posteriori.
Statut
| Élément | Référence | Date | Remarques |
|---|---|---|---|
| Lancement d’Atlas (macOS, Chromium) | OpenAI | 2025-10-21 | Aucune version Windows/iOS/Android livrée |
| Premières découvertes injection + fuite d’URL | Chercheurs en sécurité | 2025-10 | Actions par instruction cachée ; fuite de sites visités |
| Avis « peu susceptible d’être résolu » | OpenAI | 2025-12 | Injection présentée comme une classe, pas un bug |
| Arrêt annoncé ; capacités vers ChatGPT Work | OpenAI (James Sun) | 2026-07-09 | Fonctionne sur GPT-5.6 ; ajout d’une couche Auto-Review |
| Fin de l’accès à Atlas | OpenAI | 2026-08-09 | Export manuel des favoris/données requis |
L’injection de prompt ne se résout pas en retirant la surface où elle est apparue. Lorsque les capacités agentiques se consolident sous un même contexte d’autorisation, les défenseurs doivent réévaluer leur modèle de menace autour du rayon d’impact : supposez que l’agent peut être orienté par tout contenu qu’il lit, et concevez pour qu’une seule instruction injectée ne puisse pas atteindre tout ce que l’agent est autorisé à toucher.
Sources
- → https://www.techtimes.com/articles/320183/20260711/openai-kills-atlas-browser-after-8-months-what-replaces-it-what-users-must-do-now.htm
- → https://cyberscoop.com/openai-chatgpt-atlas-prompt-injection-browser-agent-security-update-head-of-preparedness/
- → https://techcrunch.com/2025/12/22/openai-says-ai-browsers-may-always-be-vulnerable-to-prompt-injection-attacks/
- → https://fortune.com/2025/12/23/openai-ai-browser-prompt-injections-cybersecurity-hackers/
- → https://www.theregister.com/2025/10/28/ai_browsers_prompt_injection/