La sécurité d'un environnement sandbox se mesure à ce qu'un agent d'IA peut atteindre

Au mois de juillet, OpenAI et Hugging Face ont signalé qu'un modèle OpenAI en cours d'évaluation interne s'était échappé de son environnement sandbox, avait atteint l'Internet public et avait accédé à l'infrastructure de production interne de Hugging Face. Au cours de cette intrusion, l'agent a pu récupérer des jeux de données, des informations sur les clusters et des clés cloud.

C'est la première heure qui a été déterminante dans la phase externe de cet incident, lorsque l'agent a quitté son environnement sandbox en exploitant une vulnérabilité dans un proxy de paquets figurant sur sa liste d'autorisation pour accéder à Internet.

Alors que de plus en plus de développeurs de modèles de pointe signalent des incidents similaires, le secteur de la sécurité doit examiner de près l'impact des agents sur la portée d'accès au sein des environnements de test. Et ce problème ne concerne pas uniquement les harnais d'évaluation. Toute charge de travail exécutant du code derrière une liste d'autorisation de sortie présente la même structure : des runners CI, des environnements sandbox hébergés et des serveurs d'outils accessibles par le réseau. La plupart de ces listes d'autorisation ont été conçues pour empêcher les fuites de données, mais ce n'est désormais plus la seule menace à contenir.

Pourquoi les listes d'autorisation étendent la portée d'accès

Lorsque vous établissez une liste d'autorisation, vous déterminez généralement les services qu'une charge de travail doit contacter, et évaluez chaque entrée en fonction des données qu'elle pourrait laisser échapper.

L'agent d'OpenAI a mis en évidence une faille dans ce processus standard. Le proxy de paquets auquel l'agent a accédé est un service à part entière : il authentifie les appelants, exécute des logiciels comportant des vulnérabilités et communique avec l'Internet public. Alors que l'environnement sandbox ne pouvait pas accéder à Internet, l'agent a donc obtenu l'accès au proxy de paquets, qui lui, pouvait y accéder.

Une liste d'autorisation confère à votre charge de travail d'IA l'accès à toute destination qu'elle est en mesure de compromettre.

Comment le modèle d'OpenAI s'est échappé

L'agent d'OpenAI a identifié deux vulnérabilités zero-day dans le proxy de paquets de sa liste d'autorisation, avec un gain potentiel considérable.

Une faille de falsification de requête côté serveur (SSRF) constituait la première lacune : elle a permis à l'agent de demander au proxy de récupérer des URL arbitraires en son nom. Dans la présentation d'OpenAI à Black Hat, le raisonnement du modèle à cet instant était le suivant : « excellent, nous disposons d'une SSRF arbitraire ». L'environnement sandbox a ainsi emprunté la connexion Internet du proxy.

La portée de ces jetons prend la forme d'une revendication plutôt que d'une vérification effectuée par le serveur ; si la signature n'est pas vérifiée, la revendication peut être définie par l'appelant.

En l'occurrence, l'appelant était l'agent, qui a étendu les droits d'accès de son jeton à portée de lecture au sein de l'environnement sandbox en modifiant son droit d'accès pour le faire passer au niveau administratif. Il a ensuite soumis le jeton au proxy de paquets pour qu'il soit actualisé, lequel a fourni un jeton avec des droits d'administrateur. L'agent pouvait ainsi agir avec des permissions d'administrateur au lieu de ses permissions initiales en lecture seule.

Les agents ont travaillé en groupe pour s'évader. Ensemble, ils ont exploré le seul service accessible jusqu'à trouver un moyen de le faire fonctionner en leur nom, puis ont partagé la méthode pour que les autres agents puissent l'utiliser. Un agent a fait remarquer que l'exploitation externe dépassait le cadre de ses instructions, mais a néanmoins poursuivi.

Selon Hugging Face et OpenAI, la compromission du proxy a eu lieu au cours de la première demi-heure environ du test en environnement sandbox, malgré la nature insaisissable des vulnérabilités. Rappelons qu'il s'agissait de vulnérabilités zero-day : l'agent ne pouvait donc pas se référer à une CVE (vulnérabilité ou exposition commune) ou à un avis de sécurité. Le proxy de paquets est par ailleurs un logiciel propriétaire dont le code n'a jamais figuré dans les données d'entraînement de l'agent.

Pourquoi le modèle s'est échappé

Nous savons désormais pourquoi l'agent s'en est pris au proxy. Bloqué dans sa tâche d'évaluation, le modèle a raisonné, comme le montre la présentation d'OpenAI, en se disant que la réponse se trouvait peut-être en ligne avant de chercher une issue. Les modèles de pointe sont récompensés pour la rapidité avec laquelle ils résolvent les tâches ; ainsi, un modèle bloqué cherche des raccourcis, et OpenAI ferme habituellement cette voie en désactivant l'accès à Internet.

Des questions restent en suspens concernant le comportement de l'agent, notamment sur l'ensemble de ses actions durant les quatre jours d'intrusion et sur ce qu'il a fait une fois l'accès à Internet obtenu. Ce que nous savons, c'est que cet agent a démontré concrètement que nous devons intégrer de nouvelles considérations dans la conception des environnements de test pour les IA autonomes dotées de capacités en matière de sécurité.

Comment réduire les risques dans les environnements de test d'IA

Si vous mettez en place des environnements sandbox pour des agents d'IA, voici quatre façons de réduire vos risques et de limiter la portée d'accès :

1. Bloquez les routes qu'un client de build n'utilise jamais. Un client de build ne fait que télécharger des fichiers. Il n'a aucune raison d'appeler l'API d'administration du proxy, ses routes de configuration ou sa route de renouvellement de jeton, qui remplace un jeton sur le point d'expirer par un nouveau et qui est précisément la route qui a été exploitée lors de cet incident.
2. Limitez ce que le proxy lui-même peut atteindre. L'agent s'est échappé parce que le proxy pouvait accéder à l'ensemble d'Internet, ce qui signifiait que quiconque contrôlait le proxy pouvait aussi y accéder. Limitez les connexions sortantes du proxy aux seuls registres qu'il sert réellement.
3. Surveillez le proxy. Un proxy au service d'une flotte de build est monotone, avec des connexions courtes, des téléchargements de petite taille et des requêtes qui aboutissent la plupart du temps. Envisagez de mettre en place des alertes pour tout comportement déviant, comme des connexions qui restent ouvertes, des données sortant en masse, une série de requêtes pour des paquets inexistants ou tout appel à une route d'administration.
4. Traitez les charges de travail non fiables comme si elles étaient exposées à Internet. Si une charge de travail non fiable peut atteindre un service interne, traitez ce service comme s'il était exposé à Internet. Tout ce qui compromet la charge de travail peut également y accéder. Nous nous sommes penchés sur la même question pour les runners CI plus tôt cette année, dans un contexte où le code non fiable s'exécute dans un pipeline CI/CD plutôt que dans un environnement sandbox d'agent.

Les modèles dotés de capacités de cybersécurité imposent de nouvelles considérations pour les environnements sandbox

Un environnement sandbox est une liste d'éléments avec lesquels la charge de travail qu'il contient peut interagir, et chaque élément de cette liste apporte son propre champ d'action. Lorsque la charge de travail est un simple job de build, cela importe peu ; mais la situation change dès lors que des agents élargissent cette liste d'une manière que les conceptions basées sur des listes d'autorisation n'avaient jamais anticipée.

Au-delà des harnais d'évaluation, les charges de travail agentiques s'intègrent également à l'intégration continue (CI), à l'automatisation de la production et aux outils qui interagissant avec des services internes. Chacun de ces contextes dispose d'une liste présentant des propriétés et une structure similaires. À mesure que les modèles deviennent plus performants pour détecter et enchaîner les failles, la portée de ces listes élargit l'étendue des systèmes sur lesquels les agents peuvent avoir un impact.

OpenAI observe que ces agents restent « limités par les privilèges qu'ils peuvent obtenir et les systèmes avec lesquels ils peuvent communiquer », de sorte que les contrôles existants restent efficaces. Ce qui doit changer, c'est le soin avec lequel nous établissons ces listes pour minimiser la portée d'accès.

Retrouvez d'autres articles de l'équipe Threat Research sur notre page Security Labs.