Archives par mot-clé : contrôle d’accès

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.

La CNIL sanctionne Nexpubica pour le logiciel PCRM

Une fuite fonctionnelle a exposé des dossiers d’usagers à des tiers dans des portails d’action sociale. Trois ans plus tard, la CNIL inflige 1,7 million d’euros pour défauts de sécurité jugés élémentaires.

Le 22 décembre 2025, la CNIL a condamné NEXPUBLICA FRANCE à 1 700 000 euros d’amende pour insuffisance de mesures de sécurité autour de PCRM, un progiciel de gestion de la relation usagers utilisé dans l’action sociale, notamment par des MDPH. Fin novembre 2022, des clients ont signalé à la CNIL que des utilisateurs accédaient à des documents appartenant à des tiers. Les contrôles ont mis en évidence des faiblesses techniques et organisationnelles, des vulnérabilités connues via des audits, et des corrections tardives, après la violation. La sensibilité des données, dont certaines révèlent un handicap, a pesé lourd.

Le déclencheur : des usagers voient les documents d’autrui

Le dossier démarre par une alerte venue du terrain. Fin novembre 2022, des clients de NEXPUBLICA FRANCE notifient à la CNIL une violation de données personnelles après des signalements d’usagers : sur le portail, certains auraient consulté des documents concernant des tiers. Ce type d’incident est redouté en environnement social, car l’accès indu, même « par erreur », produit un dommage immédiat pour les personnes, et expose l’organisation à une perte de confiance durable.

La CNIL intervient alors par des contrôles auprès de l’éditeur. Le contexte est celui d’un logiciel métier, PCRM, destiné à gérer la relation avec les usagers de l’action sociale et utilisé, selon les éléments fournis, par des maisons départementales des personnes handicapées dans certains départements. Autrement dit, la chaîne de traitement ne se limite pas à un site web : elle relie des collectivités, des agents, des workflows administratifs, et des espaces de dépôt ou de consultation de pièces justificatives.

Dans une lecture cyber, l’incident ressemble à une brèche de cloisonnement. Quand un usager obtient des pièces qui ne lui appartiennent pas, l’hypothèse la plus simple n’est pas un « piratage spectaculaire » mais un défaut de contrôle d’accès, de gestion de session ou de logique applicative. C’est précisément ce que la CNIL sanctionne ici : une sécurité qui n’a pas été pensée au niveau du risque réel, alors que le produit traite des données particulièrement sensibles.

Pourquoi l’article 32 du RGPD pèse si lourd dans ce cas

La CNIL fonde la sanction sur l’obligation de sécurité prévue par l’article 32 du RGPD. Le principe est connu, mais il mérite d’être traduit en termes concrets : le responsable de traitement et le sous-traitant doivent mettre en place des mesures adaptées au risque, en tenant compte de l’état de l’art, du coût de mise en œuvre, et de la nature et des finalités du traitement. Ici, la nature du traitement est déterminante : le dossier concerne l’action sociale et inclut des informations pouvant révéler un handicap. La sensibilité intrinsèque augmente mécaniquement le niveau d’exigence attendu.

La formation restreinte, organe de la CNIL chargé des sanctions, retient une faiblesse « généralisée » du système d’information et une forme de négligence, avec des problèmes structurels laissés en place dans la durée. L’autorité relève aussi que la plupart des vulnérabilités constatées relevaient d’un manque de maîtrise de l’état de l’art et de principes de base en sécurité. C’est un point clé : ce reproche ne vise pas une sophistication technique manquante, mais l’absence de fondamentaux.

Le raisonnement suivi par la CNIL, tel qu’il est décrit, tient en trois étapes. Premièrement, des failles existent dans PCRM et exposent des données. Deuxièmement, ces failles étaient identifiées, notamment au travers de plusieurs audits. Troisièmement, malgré cette connaissance, les corrections n’ont été apportées qu’après les violations. Cette chronologie aggrave l’appréciation, car elle transforme une vulnérabilité en manquement persistant, donc en risque accepté par défaut.

Une sanction calibrée sur la sensibilité, l’ampleur et la posture d’éditeur

Le montant, 1 700 000 euros, est justifié par plusieurs critères mentionnés : capacités financières de la société, non-respect de principes élémentaires, nombre de personnes concernées, et sensibilité des données. L’addition de ces facteurs compose une logique de proportionnalité : plus les données sont intimes et le public vulnérable, plus l’exposition est grave ; plus les failles sont « basiques » et connues, plus l’inaction est difficile à défendre.

Le dossier comprend un élément de contexte qui pèse lourd politiquement : NEXPUBLICA FRANCE est spécialisée dans la conception de systèmes et logiciels informatiques. Pour la CNIL, cette spécialisation rend l’argument de l’ignorance moins crédible. Dans une approche de renseignement économique, cela renvoie aussi à l’enjeu de chaîne d’approvisionnement logicielle : quand un éditeur fournit des briques à des acteurs publics, la faiblesse d’un produit peut se répercuter sur des services essentiels et sur des populations sensibles, sans qu’il y ait besoin d’une attaque sophistiquée.

La formation restreinte n’a pas assorti la sanction d’une injonction de mise en conformité, car l’entreprise a déployé les correctifs nécessaires après les violations. Ce détail compte : il montre que l’autorité a choisi de sanctionner l’insuffisance initiale et la gestion tardive des risques, tout en constatant une remédiation effective. En clair, la conformité obtenue après coup n’efface pas le défaut de sécurité au moment où les données étaient exposées.