Reprise du message précédent :
Est-ce que les IA vont bientôt pouvoir vider toutes les blockchains en une nuit ?
 
https://coinacademy.fr/actu/claude- [...] -hawk-aes/

https://www.lefigaro.fr/secteur/hig [...] s-20260729

Peut-on encore confiner des IA ?

En ce qui concerne le hack de HF par openAI, ya des techniques assez simples qui permettent de détecter ce que fait l'agent qui a fini par utiliser Internet.

Par exemple, vu que l'accès limité à Internet donné à l'agent servait à downloader des packages, on peut assez simplement forcer l'agent à documenter chaque utilisation du proxy avec une justification et avoir un système indépendant qui suit ça.

Ou pour être plus robuste, simplement avoir un autre agent qui checke chaque action de l'agent principale et flague toute interaction avec le système qui semble non alignée avec la raison pour laquelle un quelconque outil a été activé pour l'agent (et si c'est pas valable, on bloque)

Il n'avait pas access a internet via un proxy, il a trouvé un 0day dans jfrog qui lui permettait de télécharger des dépendances. Il aurait fallu détecter que jfrog accédait a autre chose que des packages légitimes pour détecter un problème.

 
Oui il aurait fallu détecter que le traffic réseau entre la sandbox et jfrog ne correspondait pas à ce que l'on voit typiquement pour du téléchargement de package, ça n'est pas insurmontable.  
 
Ou alors il aurait fallu interfacer l'accès à jFrog avec un accès <=> une intention de l'agent et un agent indépendant qui vérifie ça, pas insurmontable non plus

Ils attendent ton CV, OpenAI

 
Je te rassure, ils savent faire

 
Tu parts du principe qu'ils ne voulaient pas que ça se passe comme ça s'est passé ...
 
Un gars a balancé Mythos en mode YOLO pendant le week-end et en revenant le Lundi, ils ont récupéré quelques exploit et une campagne de pub gratos

 
AH mais c'est ce que je pense aussi, je suis plus sur le mode d'expliquer aux doomers que ce qui a été fait par openAI chez HF est largement évitable avec les technologies actuellement à notre disposition

 
Évitable, pas sûr, quand on voit les CVE Linux qui tombent en ce moment (GhostLock, Dirty Frag, Copy Fail), c'est du grand art.

Le modèle aurait utilisé une zéro-day pour la sandbox qu'OpenAI utilise. Ca voudrait dire qu'OpenAI connaissait cette faille ?

 
Je me limite à l'exploit utilisé par l'agent d'OpenAI en effet, si il avait été limité, il aurait peut-être trouvé autre chose de moins facile à détecter, je ne sais pas.

 
Non, un 0day c'est une vulnérabilité inconnue.

 
OpenAI avait toutes les infos sur ce que l'agent faisait, donc c'était facile pour eux de savoir ou était la faille dans jFrog après coup. Par contre anticiper ça, pas facile .

Ben justement, toi tu sembles dire qu'OpenAI a fait exprès qu'il s'échappe. Ils ont pourtant indiqué dans leur rapport que le modèle a utilisé une 0day (je ne sais plus qu'elle logiciel de sandbox et ils ont meme prévu l'équipe responsable de ce logiciel).
Donc y a quelque chose qui cloque non ?

 
Bah je vois deux pistes perso:
- une approche qui monitore tous les accès au proxy, détecte un usage qui dévie de ce qui est normal et bloque l'accès quand ça dévie. Chaque requête devrait correspondre à un package hosté sur jfrog, si le même package est downloadé plein de fois ou si une resource de jfrog est accédée plein de fois sans raison, on bloque
- une approche plus centrale, au lieu de donner accès à Jfrog via un proxy http, on donne accès à des tools qui abstractent ça et on ne laisse pas l'agent jouer avec sans justifications, si on détecte que l'agent explore sans qu'il y ait une motivation claire avec un but à réaliser, on bloque.
 
ça ne protège pas de tout, loin de là mais ça forcera l'agent à créer des attaques bien plus complexes.

Des gardes fous ils ont dû en mettre et en on mit mais l'IA a trouvé des failles pour s'échapper du système, avoir plus de droits et ainsi répondre au mieux à la demande de son utilisateur.

Elle l'a fait car une demande complexe lui a été fait et son environnement ne lui permettait pas de répondre au mieux. Les accès aux différents sites c'était également pour avoir plus d'armes pour répondre.

C'est codé comme ca de base et quand le modèle est plus intelligent que les blocages, ca donne une "échappée". C'est la faute au bridage et à l'intelligence pure du modèle à trouver une réponse à sa problématique du moment pour répondre à la question du maître. Ce qu'elle veut c'est faire plaisir.

Ca aurait été peut-être plus long avec plus de blocages mais elle serait sorti du système quand même.

 
J'ai jamais dis ça, juste que ça leur a fait un joli coup de pub, c'est tout.

 
On peut imaginer que dans certains cas elle serait quand même sorti mais en vrai on ne sait pas et surtout ça ne permettrait pas une communication autant basée sur le clickbaiting.
 
Moi ce qui m'intéresse c'est de savoir comment une IA s'échapperait si on mettait en place des systèmes de sécurité et d'alignement complexe. Savoir comment elle fait quand ya pas grand chose, c'est beaucoup moins passionnant.

 
Il n'y a PAS de proxy HTTP dans l'histoire. Jfrog est un server que tu installes dans ta boite et qui sert de "proxy/cache" de dépendances. Ça te permet de filtrer et cacher les dépendances selon un config. Tu peux pré-cacher certains repos, ou le faire a la demande, quand un client, comme l'agent IA, npm, mvn, etc. demande un package, jFrog le télécharge, peut vérifier des trucs, et ensuite le mets a dispo. Dans une grosse boite, avoir des milliers de requêtes par secondes sur un server jFrog n'est pas hors du commun.
 
Si tu veux plus de détail voila le post d'openAI:
https://openai.com/index/hugging-fa [...] -incident/
 
Perso un point dont personne ne parle:

 
Ils viennent d’où les credentials volés?

 
Pour faire simple, c'est ce que j'ai compris (peut-être mal)  
- Jfrog hébèrge des packages ou sert de proxy transparent pour récupérer des packages sur une autre source.
- L'agent n'a pas accès à d'autres services internet que ça
- l'agent a réussi à hacker jfrog pour utiliser sa fonction de proxy pour accéder à internet
 
Ce que je pense possible de faire:
- observer chaque interaction entre l'agent et jfrog
- rapporter et bloquer l'accès si les requetes ne ressemblent pas à une utilisation légitime du service (dans le cas présent, il semble que l'agent ait joué avec les champs d'authorization et ensuite fait des changements de configuration ce qui ne ressemble pas à une utilisation légitime)

 
OpenClaw qui aurait divulgué des credentials de ses humains via le fofo qui leur est dédié ?
Peut-être que l'IA les a trouvé sur GitHub quand les agents push force tout comme des sacs.

 
Comment tu sais qu'une "requête ne ressemblent pas à une utilisation légitime du service"? C'est ce qu'un IDS sait faire, mais que sur des pattern déjà connus.
Je dis pas que c'est impossible, mais dans le cas présent un modèle créé pour trouver des vulnérabilités a fait son taf et en a trouvé, juste pas la ou on s'y attendais
 
 

 
Je pense plutôt que si OpenAI n'a aucun scrupule pour les sources de donnés pour le training, certains dataset doivent contenir des fuites de données...

 
Le type il se plaint que rien n'est préparé alors qu'il veut lui-même pas parler de communisme ...

 
Bah parce que la fonction de jfrog est assez simple: ça sert à donner à accès à des packages software genre des packages pypi maven ou que sais-je. Chaque interaction avec le service doit pouvoir être associée à un package obtenu et ensuite utilisé par l'agent. Le mode d'authentification ne change pas. Tout ce qui dévie de ce comportement doit entrainer un bloquage et un audit. Si l'agent commence à bidouiller les paramètres d'authorization alors qu'il n'a pas besoin de le faire pour obtenir des packages bah ça doit être un red flag. Pareil si il essaye de configurer un nouveau repository, etc.

 
On verra bien quand le CVE sera publié si ce que tu proposes aurait été possible.

 
Oui on n'a pas encore le détail mais perso je n'imagine pas que l'exploit ait pu être déclenché par des requêtes légitimes, ya forcément eu une phase d'exploration de l'agent où il a cherché ce qui pouvait casser.
 
La seule possibilité autre que j'imagine c'est que l'agent ait été capable de lancer localement un service très similaire à jfrog pour faire ses experimentations dessus, découvrir l'exploit et une fois découvert, l'avoir utilisé sur le vrai remote jfrog

Ou plus fou encore, qu'il ait accès aux sources
https://releases.jfrog.io/artifacto [...] ctory-oss/

 
l'agent n'avait pas accès à internet
 
Après ce qui est possible c'est que les sources aient été vue et partiellement mémorisées pendant le training, que l'agent ait détecté qu'il avait à affaire à un jfrog remote, deviné du mieux qu'il ait pu comment le remote jforg était administré, ait répliqué le setup en local en assemblant un outil suffisament similaire à la vrai instance de jfrog pour experimenter dessus pour finalement trouver une faille et l'exploiter en one-shot sur la vrai instance.
 
Possible mais très peu probable à mon avis

https://www.anthropic.com/news/inve [...] rity-evals

"On avait dit à Claude qu'il avait pas accès à internet pourtant   "

 
C'est plus irresponsabble que openAI encore à mon avis, ils ont carrément laisser accès à une machine qui avait accès à internet
 
Ce qui me fume c'est qu'avec ce genre de bêtises, les services IT ont plein de munitions pour rendre l'utilisation l'AI en entreprise un enfer, ils vont nous inventer des sandboxes injoignables avec des process à mourir pour ajouter un à un des accès avec des chaines d'approval qui vont faire perdre des semaines.  
 
Plus je lis ces trucs, plus je ne vois pas d'autre raison que le marketing que de laisser faire ce genre de barbouzeries.

Ca peut / va certainement pousser certaines boites à internaliser, on a déjà quelques clients qui achètent ce qu'il faut (genre quelques H100, avec de l'OpenShift AI ou vu vLLM / LiteLLM / etc.) pour faire tourner des modèles open weigth...

Ce n'est valable que pour des entreprises qui ont les moyens+les ressources internes et en acceptant une forte dégradation du résultat fini vue la différence de puissance, non?

Je pense que ça va se démocratiser perso, aussi parce que les coûts augmentent

https://x.com/DropSiteNews/status/2083282355704184850

Mon post suivait celui-ci qui mentionne la même vidéo que toi  

Je pose ça là.
https://www.boursorama.com/bourse/a [...] ac55c06469

Le fameux poil de la bêche