OpenAI exigera une approbation pour les passerelles d’IA à partir du 20 novembre

Un assistant d’IA au travail peut sembler connecté directement à GPT, mais une autre entreprise peut traiter les requêtes en coulisses. Les employés voient les réponses, mais rarement le service qui fournit l’accès au modèle.

À partir du 20 novembre, OpenAI exigera des routeurs et passerelles de modèles d’IA qui donnent à des tiers un accès direct à ses modèles qu’ils obtiennent une approbation préalable. Cette évolution instaure une nouvelle supervision des services qui connectent les entreprises aux technologies d’IA par l’intermédiaire d’un tiers.

Pour les entreprises qui utilisent ces intermédiaires, cette évolution soulève deux questions : leur fournisseur est-il autorisé à proposer les modèles d’OpenAI, et gère-t-il de manière suffisamment sûre les données et identifiants de l’entreprise ?

OpenAI veut des garde-fous cohérents chez les fournisseurs de modèles

Dans son annonce du 21 octobre, OpenAI a expliqué comment les protections de sécurité devraient s’appliquer lorsque les clients accèdent à ses modèles directement ou par l’intermédiaire de partenaires d’hébergement et de revendeurs. Les services participants sont censés maintenir des normes comparables afin que les utilisateurs ne puissent pas simplement changer de fournisseur pour contourner les restrictions.

L’approche comprend plusieurs mesures à différentes étapes de l’accès aux modèles :

• Avant le déploiement. Les modèles font l’objet d’évaluations des risques et de tests visant à détecter les tentatives de contournement des garde-fous. Des programmes d’accès de confiance définissent également les conditions d’éligibilité à certaines fonctionnalités avancées.
• Pendant l’utilisation. Le suivi permet d’identifier les utilisations potentiellement abusives ; les partenaires sont censés enquêter sur les activités suspectes et agir en cas d’infraction.
• Après l’application des mesures. Les restrictions peuvent être réexaminées lorsque les clients remédient aux problèmes sous-jacents. Les SafetyIDs, actuellement en développement, pourraient également aider à distinguer les utilisateurs finaux lors des enquêtes sans révéler leur identité au développeur du modèle.

La confidentialité constitue un autre enjeu. OpenAI a cité Private Safety Processing comme moyen de détecter d’éventuelles utilisations abusives dans le cadre d’interactions connexes sans exposer leur contenu sous-jacent au personnel d’OpenAI. Une mise à jour du 22 septembre indiquait que l’accès était déployé progressivement pour les clients de l’API.

Les règles d’approbation distinguent les passerelles des applications d’IA ordinaires

Les règles d’utilisation révisées s’appliquent aux plateformes qui donnent à des tiers un accès direct aux modèles d’OpenAI. Les passerelles d’IA peuvent relayer les requêtes via une connexion commune, ce qui permet aux entreprises de travailler avec différents systèmes d’IA sans gérer séparément chaque intégration de modèle. Les services qui proposent cet accès intermédiaire doivent obtenir une approbation préalable.

Les applications qui intègrent GPT à leurs propres produits sont traitées différemment. Un assistant de support client ou un outil de génération de documents, par exemple, n’a pas besoin d’une approbation du seul fait qu’il utilise cette technologie. Les autorisations contractuelles existantes restent applicables, et les politiques précédentes restent en vigueur jusqu’au 20 novembre.

L’annonce ne fournit pas de liste des passerelles approuvées et n’explique pas comment les intermédiaires existants doivent demander un examen avant le 20 novembre.

Ce qu’eWeek a découvert : les attaques contre les passerelles révèlent des risques que l’approbation pourrait ne pas prévenir

Pour examiner dans quelle mesure la supervision prévue par OpenAI pourrait aider lorsqu’un intermédiaire d’IA est compromis, eWeek a étudié un exemple récent dans le monde réel impliquant LiteLLM, en examinant sa divulgation de sécurité de mars, les améliorations de sécurité ultérieures, ainsi que le rapport d’incident du 21 octobre. L’enquête a mis au jour une faille de sécurité récurrente impliquant le logiciel auquel les clients font confiance pour les connecter aux modèles d’IA.

Les logiciels malveillants distribués lors de l’incident d’octobre pouvaient dérober des identifiants et permettre l’exécution de code à distance. Plus inquiétant encore, le tag de code source GitHub légitime de LiteLLM ne contenait aucun fichier malveillant, car les attaquants avaient créé les versions infectées depuis un dépôt distinct qu’ils contrôlaient. Il a été demandé aux clients concernés de considérer comme compromis les secrets accessibles, bien que la version privée destinée aux entreprises du projet n’ait pas été affectée.

Le projet d’OpenAI pourrait être utile si des identifiants de fournisseur volés étaient ensuite utilisés pour effectuer des requêtes suspectes auprès des modèles. La coordination avec des intermédiaires approuvés pourrait faciliter les enquêtes et l’application des mesures chez les services participants, tandis que les SafetyIDs pourraient aider à distinguer les utilisateurs légitimes lorsque ces identifiants accompagnent les requêtes. Toutefois, aucune de ces mesures ne vérifierait à elle seule l’intégrité des logiciels de passerelle téléchargés. La distinction est également importante dans les divulgations d’OpenAI sur des comportements d’IA ayant franchi les limites prévues : les informations qui aident à enquêter sur un problème ne l’empêchent pas en elles-mêmes.

Les incidents de LiteLLM n’ont aucun lien établi avec la décision d’instaurer une approbation, mais ils montrent pourquoi l’autorisation seule ne peut garantir la sécurité d’une passerelle. 

Avant le 20 novembre, les entreprises devraient demander à leurs fournisseurs de passerelles si l’obligation d’approbation s’applique à leur service, de quelle autorisation ils disposent et si l’examen pourrait affecter le maintien de leur accès aux modèles d’OpenAI. L’annonce laisse ces questions propres à chaque fournisseur sans réponse.

Les équipes de sécurité devraient également déterminer quels identifiants leurs passerelles peuvent atteindre, qui peut autoriser les mises à jour logicielles et comment elles révoqueraient les accès et rétabliraient un déploiement de confiance après une compromission. Les conclusions des évaluations de la sécurité du cloud et des identités renforcent l’importance d’examiner les autorisations excessives et les identifiants exposés, parallèlement à l’intrusion initiale.

Pour les équipes chargées des achats, la conséquence pratique est un examen élargi des fournisseurs : choisir un modèle d’IA signifie aussi évaluer l’intermédiaire qui le fournit. L’autorisation du fournisseur, les contrôles des mises à jour logicielles et la réponse aux incidents doivent chacun être étayés par des éléments probants.

À lire aussi : Nvidia apporte la supervision dopée à l’IA aux clusters de GPU, Minerva étant conçue pour détecter les problèmes d’infrastructure avant qu’ils n’interrompent les charges de travail.