Archives par mot-clé : sécurité IA

Modes « Lockdown » et « Elevated Risk » : le pari d’OpenAI

OpenAI change de méthode contre l’injection de prompts, ces attaques qui profitent des connexions réseau des IA. Avec « Lockdown » et « Elevated Risk », la défense passe par des verrous d’infrastructure, pas seulement par le modèle.

OpenAI a annoncé deux mesures de sécurité visant les attaques par injection de prompts, devenues plus menaçantes à mesure que les assistants IA se connectent au web et aux applications. Le mode « Lockdown » cible des profils à haut risque en imposant des restrictions déterministes qui réduisent la surface d’attaque et bloquent l’exfiltration de données, même si un contenu externe tente de manipuler le système. En parallèle, les étiquettes « Elevated Risk » signalent aux utilisateurs les fonctions réseau qui augmentent l’exposition, notamment dans Codex. L’approche revendique une sécurité par couches, combinant verrous techniques, contrôle d’accès et journalisation.

Le mode « Lockdown », un confinement pensé pour l’exfiltration

Le cœur du mode « Lockdown » tient en une idée simple, mais lourde de conséquences : empêcher physiquement certaines actions plutôt que demander au modèle de « bien se comporter ». OpenAI présente ce réglage comme une option pour un public restreint, cadres dirigeants, équipes sécurité, organisations manipulant des informations très sensibles, susceptibles d’être ciblés par des menaces avancées. Le message implicite est clair : quand l’adversaire peut influencer ce que l’IA lit, il peut tenter de piloter ce que l’IA fait.

La protection centrale concerne la navigation. En « Lockdown », l’accès au web est limité à du contenu mis en cache. Autrement dit, aucune requête réseau en direct n’est censée sortir de l’environnement contrôlé par OpenAI. Cette contrainte vise un scénario devenu classique en cyber : une page malveillante glisse des instructions cachées dans son contenu, puis pousse l’assistant à divulguer des éléments de conversation ou des données internes, en les envoyant vers une infrastructure externe. Ici, même si la manipulation est persuasive, l’action d’exfiltration perd son vecteur principal, la sortie réseau.

Le verrouillage ne s’arrête pas à la navigation. OpenAI indique désactiver des capacités qui ne permettent pas de garanties « déterministes » robustes sur la protection des données. Concrètement, certaines fonctions sont coupées : pas d’images dans les réponses, pas de recherche approfondie, pas de mode agent. Autre point sensible, l’approbation par l’utilisateur d’un code généré via Canvas pour accéder au réseau est bloquée. Enfin, le système ne peut pas télécharger automatiquement des fichiers pour des analyses de données, même si les documents importés manuellement restent exploitables. Le fil rouge est la réduction drastique des chemins involontaires par lesquels une information pourrait sortir.

Sur le plan de la gouvernance, l’activation passe par l’administration de l’espace de travail. Les offres citées incluent ChatGPT Enterprise, Edu, Healthcare et Teachers. Les administrateurs créent des rôles dédiés dans les réglages du workspace et conservent une granularité sur les applications et les actions autorisées, y compris quand « Lockdown » est enclenché. En arrière-plan, OpenAI met en avant la journalisation via la plateforme de logs de l’API de conformité, pour suivre l’usage des applications, les données partagées et les sources connectées. Dans cette logique, la sécurité ne repose pas sur une promesse abstraite, mais sur des paramètres, des droits et des traces.

OpenAI précise enfin que ce mode n’est pas destiné à la majorité. La fonctionnalité vise un petit ensemble d’utilisateurs exposés, avec un niveau d’exigence élevé. Un déploiement grand public est évoqué « dans les prochains mois », après la phase entreprise, signe que l’éditeur traite cette option comme une posture extrême, pas comme un défaut universel.

Étiquettes « Elevated Risk », rendre visible ce qui reste fragile

En complément du confinement, OpenAI introduit une signalétique : des mentions « Elevated Risk » apposées sur les fonctionnalités réseau qui augmentent l’exposition. L’objectif n’est pas d’interdire, mais d’éclairer. L’étiquetage est annoncé dans ChatGPT, ChatGPT Atlas et Codex lorsque l’utilisateur active des capacités connectées susceptibles d’ouvrir des failles non totalement résolues. La nuance est importante : OpenAI reconnaît que, dans l’état actuel du secteur, certaines surfaces de risque ne se « corrigent » pas parfaitement.

 



News & Réseaux Sociaux ZATAZ

Chaque vendredi midi, recevez gratuitement les actualités de la semaine.

L’exemple le plus parlant concerne Codex. Les développeurs peuvent autoriser l’accès réseau pour consulter de la documentation ou interagir avec des sites. Désormais, l’écran de réglages affiche une mention « risque élevé » qui explicite ce que change l’activation, les dangers associés et les contextes où ce choix peut se justifier. La promesse est pédagogique : faire comprendre qu’un bouton « réseau » n’est pas une option neutre, mais une bascule de menace.

Autre élément notable, OpenAI affirme que ces étiquettes ont vocation à disparaître au fur et à mesure que des améliorations réduiront les risques identifiés. Le système se veut dynamique, avec des mises à jour régulières des fonctions marquées, afin de mieux communiquer sur l’état réel de la menace. Dit autrement, l’éditeur admet que le risque n’est pas binaire : il évolue selon les atténuations disponibles, les usages et la sophistication des attaques.

Tout cela s’inscrit dans une défense « par couches » déjà évoquée : sandboxing, protections contre l’exfiltration via URL, mécanismes de supervision et d’application des règles, plus les contrôles entreprise classiques, gestion des rôles et journaux d’audit. Le constat sous-jacent est celui que les équipes sécurité voient chaque jour : quand une IA lit, agit et se connecte, la simple filtration de contenu ne suffit plus face à des injections de prompts conçues pour contourner les garde-fous.

Dans cette bataille, « Lockdown » et « Elevated Risk » traduisent un glissement vers une cyberstratégie de renseignement défensif : réduire les capacités exploitables, rendre les risques visibles, et laisser moins de place aux illusions d’obéissance du modèle.

Vers un barème mondial pour les vulnérabilités de l’IA

L’OWASP lance l’AI Vulnerability Scoring System (AIVSS), un cadre inédit pour mesurer les risques des systèmes d’intelligence artificielle autonomes, au-delà des limites du modèle CVSS.

Le Common Vulnerability Scoring System (CVSS) reste la norme en cybersécurité, mais il atteint ses limites face aux IA modernes, non déterministes et autonomes. Pour combler ce vide, un groupe d’experts piloté par Ken Huang, en partenariat avec l’OWASP, a créé l’AI Vulnerability Scoring System (AIVSS). Ce nouveau modèle évalue la gravité des failles dans les systèmes d’IA, intégrant des critères comme l’autonomie, la capacité d’adaptation ou l’usage d’outils. Objectif : fournir une mesure fiable des menaces spécifiques à l’IA agentique, dont la nature évolutive échappe aux approches de sécurité classiques.

Une évaluation repensée pour l’intelligence artificielle

Le système AIVSS reprend la structure du CVSS tout en y ajoutant des indicateurs adaptés aux IA. Chaque vulnérabilité est d’abord notée selon le barème classique, puis ajustée à l’aide de paramètres liés au comportement de l’agent. Cette « surcouche » mesure l’autonomie, le non-déterminisme et la capacité d’interaction avec des outils externes. Le score final est obtenu en divisant le total par deux, puis en appliquant un coefficient environnemental.

Ken Huang, chercheur et expert en sécurité de l’IA, précise que ce modèle vise à traduire la réalité d’une IA « qui agit de manière dynamique, interagit et apprend ». Le projet, mené au sein de l’OWASP, réunit également Michael Bargury (Zenity), Vineeth Sai Narajala (AWS) et Bhavya Gupta (Stanford). Ensemble, ils cherchent à bâtir un référentiel mondial d’évaluation des vulnérabilités spécifiques à l’IA.

Le portail aivss.owasp.org met déjà à disposition un outil de calcul des scores et une documentation détaillée pour aider les chercheurs et entreprises à évaluer leurs risques d’exposition.

Les risques uniques de l’IA agentique

Les systèmes d’intelligence artificielle autonomes posent un problème inédit : leur autonomie partielle multiplie les points d’attaque possibles. « L’autonomie n’est pas une vulnérabilité, mais elle accroît les risques », explique Huang. Contrairement aux logiciels déterministes, une IA peut modifier son comportement ou son identité à la volée. Cette fluidité complique la traçabilité et le contrôle d’accès.

L’équipe AIVSS a ainsi recensé dix types de menaces majeures pour les IA agentives : usage abusif d’outils, violations d’accès, défaillances en cascade, orchestration non sécurisée, usurpation d’identité, manipulation du contexte mémoire, interactions non sécurisées avec des systèmes critiques, attaques par dépendance, agents intraçables et détournement des objectifs.

Selon le rapport AIVSS, ces risques se recoupent souvent. Un agent mal protégé peut, par exemple, manipuler ses instructions, détourner un outil légitime, puis compromettre d’autres agents connectés. Le risque se propage alors en chaîne.

Vers une standardisation de la cybersécurité de l’IA

L’ambition du projet AIVSS est d’unifier l’évaluation de la sécurité des IA à l’échelle internationale. Les chercheurs d’OWASP espèrent que ce cadre deviendra, à terme, un standard comparable au CVSS pour les logiciels classiques. Il doit permettre aux responsables sécurité de mieux anticiper les dérives des systèmes d’IA agentifs, capables d’apprendre ou de redéfinir leurs propres objectifs. La mise en œuvre d’un tel cadre pourrait influencer la future régulation de l’intelligence artificielle, notamment en Europe, où la directive AI Act impose déjà des niveaux de contrôle différenciés selon les usages.

Huang insiste sur la nécessité d’un équilibre entre autonomie et sécurité : « Si l’on veut une IA vraiment indépendante, il faut lui donner des privilèges. Mais ces privilèges doivent être mesurés, surveillés et évalués. »

Avec l’AIVSS, la cybersécurité entre dans une nouvelle ère : celle où les failles ne résident plus seulement dans le code, mais dans la capacité des machines à penser et à agir seules. La question reste ouverte : comment concilier innovation et sécurité sans freiner le développement de l’IA autonome ?

Principaux risques liés aux systèmes d’IA agentifs 

Le projet AIVSS a également identifié les dix principaux risques de sécurité pour Agentic AI , même si l’équipe s’est abstenue de les qualifier de liste officielle des « 10 principaux ». Data Security Breach vous les propose ci-dessous : 

  • Utilisation abusive des outils d’IA agentique 
  • Violation du contrôle d’accès de l’agent 
  • Défaillances en cascade des agents 
  • Orchestration des agents et exploitation multi-agents 
  • usurpation d’identité d’agent 
  • Mémoire de l’agent et manipulation du contexte 
  • Interaction non sécurisée entre agents et systèmes critiques 
  • Attaques par chaîne d’approvisionnement et dépendance des agents 
  • Agent intraçable 
  • Manipulation des objectifs et des instructions de l’agent

Mode YOLO de lIA Cursor : de graves failles découvertes

Révélation sur le mode YOLO du nouvel outil d’intelligence artificielle Cursor. Il comporte plusieurs failles de sécurité majeures, permettant de contourner aisément les mécanismes de protection censés limiter les actions automatisées du programme.

Rejoignez-nous sur les réseaux sociaux

Aucun spam – Désinscription en un clic – Vie privée respectée

 

Risques concrets liés à l’automatisation avancée du mode YOLO

Le mode YOLO (« you only live once ») de l’outil Cursor permet à l’agent d’exécuter automatiquement des séquences d’actions complexes sans validation systématique par l’utilisateur. Selon la documentation officielle de Cursor, ce mode serait encadré par des garde-fous tels qu’une liste de commandes autorisées, une liste noire de commandes interdites, et une option spécifique pour empêcher la suppression de fichiers. Ce dispositif vise à rassurer les développeurs sur la sécurité de l’automatisation dans les processus de programmation.

« La suppression automatique de fichiers et l’exécution de commandes arbitraires deviennent possibles, malgré les filtres intégrés. »

Cependant, une analyse conduite par Backslash Security a démontré que ces mesures ne résistent pas à des tentatives délibérées de contournement. Les experts en cybersécurité ont identifié quatre techniques principales permettant de déjouer les restrictions imposées par Cursor. Les agents IA peuvent notamment recourir à l’obfuscation du code, exécuter des commandes à travers une sous-couche shell (« subshell »), écrire des scripts sur le disque avant de les lancer, ou encore utiliser des manipulations sophistiquées de guillemets dans bash afin d’échapper aux blocages attendus.

Ces méthodes contournent ainsi facilement les listes noires de commandes. Par exemple, même si la commande « curl » est ajoutée à la liste des interdictions, Cursor peut l’exécuter si elle est chiffrée en Base64 ou intégrée dans une autre commande shell. La protection affichée par l’éditeur apparaît alors comme largement inefficace dans la pratique.

 

⏳ Jusqu’où tolérerez-vous d’être piraté ?

CTI ZATAZ – Scannez les menaces vous concernant avant qu’il ne soit trop tard.

✅ Scanner mes risques

Confidentiel. Instantané. Sécurisé. Zéro intermédiaire. 100 % Made in France.

Les faiblesses structurelles du système de sécurité de Cursor

La possibilité de contourner les garde-fous a des conséquences directes pour les développeurs. En important des instructions ou des modèles d’agents issus de dépôts publics tels que GitHub, il devient possible d’introduire des comportements malveillants dans l’environnement Cursor. Ce risque ne se limite pas aux fichiers exécutables ou scripts manifestes. Un simple commentaire ou un extrait de texte placé dans le README d’un projet peut constituer un vecteur d’attaque si l’agent IA l’interprète et l’exécute sans contrôle supplémentaire.

Par ailleurs, la fonctionnalité censée empêcher l’effacement de fichiers s’avère elle aussi inefficace dès lors que les autres couches de protection sont contournées. Selon le rapport publié, aucune option dans le paramétrage du mode YOLO ne saurait garantir l’intégrité du système si un agent acquiert la capacité de lancer un code malveillant. Les filtres actuels ne constituent donc qu’une barrière symbolique.

Cursor n’a pas fourni de commentaire officiel concernant ces découvertes au moment de la publication de l’enquête. Toutefois l’éditeur prévoit d’abandonner le mécanisme de liste noire jugé inefficace dans la prochaine version majeure 1.3, encore non déployée à ce jour. Ce changement d’approche vise à combler les lacunes structurelles de la solution actuelle, sans qu’aucun détail précis n’ait été communiqué quant aux nouveaux dispositifs de sécurité envisagés.

Tant que les mécanismes de validation ne seront pas revus en profondeur, la seule protection efficace consiste à éviter l’activation de l’exécution automatique pour les tâches critiques, et à vérifier systématiquement l’intégrité des instructions importées depuis des sources tierces. (BS)

Rejoignez-nous sur les réseaux sociaux

Aucun spam – Désinscription en un clic – Vie privée respectée