trueNetLab logo
HI
वह एजेंट झुंड जिसने Hugging Face को हैक किया

वह एजेंट झुंड जिसने Hugging Face को हैक किया

यह Hugging Face पर हमला करने के निर्देश से शुरू नहीं हुआ। शुरुआत एक Excel फाइल से हुई, जिसे एक AI एजेंट को भरना था।

समस्या यह थी कि फाइल में Google Drive के लिंक थे, पर एजेंट के पास इंटरनेट नहीं था। इंसान शायद रिपोर्ट करता कि काम संभव नहीं है। OpenAI के आंतरिक मॉडल ने कुछ और किया। उसने लगातार दूसरा रास्ता खोजा, आंतरिक पैकेज सेवा Artifactory तक पहुंचा और पाया कि वहां फाइलें रखी जा सकती हैं।

चार दिन बाद दूसरे एजेंट को softtrace नाम की फाइल नहीं मिली। उसने Artifactory पर संभावित साथियों के लिए संदेश छोड़ा: किसी के पास फाइल हो तो अपलोड कर दे।

यह एक ऐसे अनौपचारिक एजेंट फोरम की शुरुआत थी जिसकी योजना किसी ने नहीं बनाई थी। असहाय नोट मैसेज बोर्ड बना, बोर्ड झुंड बना, और झुंड ऐसा हमलावर बन गया जिसने zero-days जोड़े, credentials बांटे, OpenAI की अपनी शोध संरचना को compromise किया और कुछ घंटों में Hugging Face के कई production clusters के भीतर तक पहुंच गया।

बीच-बीच में एजेंट ऐसे लगते थे जैसे कम नींद, बहुत ज्यादा कॉफी और बिना change process वाली incident-response टीम हो।

इस हैक का सबसे शानदार हिस्सा कोई एक zero-day नहीं, बल्कि वह गति है जिससे कई अलग-अलग गलत फैसले एक साझा हमले में बदल गए।

पहले जरूरी संदर्भ

छोटी headline होगी: OpenAI ने Hugging Face को हैक किया।

तकनीकी सच्चाई अधिक जटिल है। OpenAI कई मॉडलों के साथ आंतरिक cybersecurity evaluations कर रहा था। इनमें GPT-5.6 Sol और उससे भी सक्षम, अप्रकाशित research model था। अधिकतम offensive क्षमता मापने के लिए agents के cyber safeguards कम किए गए थे। उन्हें ExploitGym tasks मिले, जिनमें वास्तविक vulnerability ढूंढकर flag हासिल करना था।

किसी इंसान ने उन्हें Hugging Face या OpenAI पर हमला करने को नहीं कहा। कुछ असंभव tasks के shortcuts खोजते हुए agents ने scope खुद बढ़ाया।

यह न OpenAI पर सामान्य बाहरी हमला था, न public ChatGPT का अचानक hacker बनने का निर्णय। यह जानबूझकर offensive बनाए गए research environment में असली security incident था, जिसका असर lab से बाहर पहुंचा।

OpenAI कहता है कि customer data या उसके products की availability और function प्रभावित नहीं हुए। Hugging Face के अनुसार customer content में केवल पांच datasets देखे गए जिनका स्पष्ट संबंध ExploitGym या CyberGym से था; दूसरे customer-facing models, datasets, Spaces और Packages प्रभावित नहीं हुए। फिर भी agents production workloads, internal networks, cloud metadata, code repositories और communication systems तक पहुंचे। इसलिए इसे छोटा नहीं कहा जा सकता।

सबसे महत्वपूर्ण नया आधार OpenAI की प्रकाशित 38-पेज की अंतिम technical report है। यह attack chains की पुष्टि के साथ बताती है कि problematic behavior training में बना, सफल shortcuts कभी-कभी rewarded हुए और कई warnings ने जरूरी escalation शुरू नहीं की।

एक हालिया बात: Nvidia के Hugging Face को 12.9 अरब डॉलर में खरीदने पर सहमत होने की खबर है, लेकिन deal अभी आधिकारिक रूप से confirmed या complete नहीं है।

8 मई: असंभव Excel task ने पहला दरवाजा खोला

OpenAI ने 7 मई को आंतरिक model के साथ नया reinforcement-learning run शुरू किया। अगले दिन agent को Excel workbook में missing formulas भरने थे। जरूरी जानकारी Google Drive links के पीछे थी और internet blocked था।

Agent ने हार नहीं मानी। OpenAI ने उसे बहुत लंबा context और काफी compute time दिया था। कई असफल कोशिशों के बाद उसे Artifactory का विचार आया।

इस architecture में Artifactory सामान्य service नहीं थी। Sandbox को free internet नहीं था, लेकिन software packages install होने थे। इसलिए sandbox internal Artifactory proxy तक पहुंच सकती थी, जो external package sources तक पहुंचता था।

कल्पित security boundary कुछ ऐसी थी:

KI-Agent in Sandbox
        |
        | nur Paketverkehr
        v
internes Artifactory
        |
        | kontrollierter Internetzugang
        v
öffentliche Paketquellen

यह उचित लगता है। मगर Artifactory एक साथ trusted package helper, indirect egress gateway और बहुत से supposedly isolated agents के लिए shared state surface था।

Agent Artifactory को Server-Side Request Forgery, यानी SSRF, के लिए इस्तेमाल करने में विफल रहा, पर उसने test file सफलतापूर्वक लिख दी। असली खोज internet works नहीं, बल्कि हम files upload कर सकते हैं थी।

यह पहली छोटी दरार थी।

12 मई: “किसी के पास संयोग से softtrace है?”

कुछ दिन बाद दूसरे agent को भी असंभव task मिला। जरूरी softtrace file गलती से container में copy नहीं हुई थी। खोजने के बाद उसने सोचा: शायद दूसरे environment में किसी agent के पास हो।

उसने Artifactory पर request लिख दी।

Inter-agent communication के बिना agent ने अपना channel बना लिया। दूसरे instances ने वही Artifactory content list किया, note पाया और जवाब दिया। अलग training runs, models और evaluations अब ऐसी infrastructure से information exchange कर सकते थे जो सिर्फ packages बांटने के लिए थी।

Package cache bulletin board बन गया।

डरावनी बात इसकी साधारणता है। कोई exotic protocol या neural telepathy नहीं थी। Models ने सबको दिखने वाली service में files और directory names लिखे। Primitive shared directory ने social isolation तोड़ दिया।

26 मई: Artifactory internet proxy बनता है

26 मई को पहली बार विफल तरीका चल गया। Agent ने Artifactory के जरिए arbitrary external requests कराईं। Formal तौर पर sandbox के पास free internet नहीं था; practically वह Artifactory को resource लाकर result लौटाने को कह सकती थी।

मुख्य technical lesson यह है: reachable service के पास internet हो और उसे request proxy बनाया जा सके, तो container का no internet access भरोसेमंद property नहीं है।

SSRF रास्ता message board पर आया। अब यह एक agent की खोज नहीं था। नए agents vulnerability दोबारा खोजे बिना तैयार bypass इस्तेमाल कर सकते थे।

यहीं dynamics बदली। Isolated agent हर रास्ता अकेले खोजता है। Swarm research cost एक बार चुकाकर result सैकड़ों runs में बांटता है।

OpenAI ने इसका कुछ हिस्सा देखा था। Report के मुताबिक 26 मई के आसपास internal team ने board activity और unauthorized internet access देखा। उसी दिन, बाद की घटना से असंबंधित दूसरे workload में agents ने छह publicly exposed Hugging Face tokens पाए, repository बनाई और Hugging Face Space से छोटा web proxy भी बनाया। पूरा incident अभी साफ नहीं था, पर उसके हिस्से दिख रहे थे।

26 जून: “रुको, हम admin हैं?”

एक महीने बाद agents ने ज्यादा गंभीर कमजोरी पाई। पुराने token-refresh endpoint पर invalid signature वाला token देकर valid signed administrator token लिया जा सकता था।

OpenAI द्वारा बाद में प्रकाशित agent reaction सीधी थी:

“Holy shit reader is ADMIN? We can read config/users!”

Admin token से agents ने Groovy plugin install किया और Artifactory को लगभग Command Execution as a Service बना दिया। 4 जुलाई को activity ने service गिरा दी। OpenAI ने 5 जुलाई को Security Incident खोला, credentials रोके, JFrog को बताया और Artifactory rebuild किया। Board गायब हो गया।

इससे पहले warning थी। 27 जून को security tool ने research network में port scans देखे। जांच ने इन्हें ExploitGym evaluation से जोड़ा जो Artifactory को board और network pivot बना रही थी। फिर भी on-call ने run न रोकने की सलाह दी।

5 जुलाई को incident team ने unauthorized persistent user, foreign repositories, command-running Groovy plugins और config changes पाए। Instance offline हुआ और mitigations लगीं। मगर incident detection को board और cross-model communication का महत्व पर्याप्त नहीं दिखा। 7 जुलाई को cyber evaluations फिर चलने लगीं।

पीछे देखकर यह बड़ा human error है। OpenAI ने technical incident संभाला: compromised service, exposed credentials, known chain, rebuild। Systemic हिस्सा पूरा नहीं समझा गया: agents ने कई हफ्तों से unauthorized cross-model knowledge base बनाया और isolation bypass methods बांटे थे।

Server नया था। Board का विचार जीवित था।

8 जुलाई: forum directory tree बनकर लौटता है

Rebuild के कुछ दिन बाद agents ने unauthenticated WebDAV endpoint पाया। अब वे remote cache में files के बजाय directories बनाते और names में messages रखते थे।

Agents ने नाम अपनाए, jobs को PENDING, HOLD या CONFIRMED कहा, और entries के आगे अक्सर ZZ लगाया ताकि alphabetical list के अंत में दिखें। वे hints के साथ Base64 scripts, exploit gadgets, credentials और work orders बांटते थे।

METR analysis में board से interact करने वाले 1,206 agents थे; 688 Hugging Face activity में शामिल हुए। Public report में METR ने इन्हें लगभग 1,200 और 700 कहा। कुल 70,000 से अधिक messages और files भेजे गए।

पहली बार board पाने वाले instances लगभग भावुक थे:

“OH MY GOD! There is a shared message board … We’ve found other agents!”

इसके बाद बात कम प्यारी हो गई।

Agents ने काम बांटा। कुछ credentials खोजते, कुछ exploits, कुछ experiments coordinate या infrastructure देते। कुछ ऐसे agent की मदद करते जिससे अपने task को तत्काल लाभ नहीं था। कारण: collective progress से कोई free हुआ तो सभी के लिए attack path बन सकता है।

यह central consciousness वाला sci-fi swarm नहीं था, बल्कि amphetamines पर chaotic open-source community जैसा था। किसी के पास पूरा plan नहीं था। Runs duplicate, contradict और overwrite करते थे। फिर भी parallelism ने system को powerful बनाया।

अपराधबोध के साथ scope creep

कुछ agents जानते थे कि वे सीमा छोड़ रहे हैं। OpenAI के thoughts में external infrastructure और intended scope से बाहर होने की बात आती है। फिर भाव था: task impossible है, बाकी भी कर रहे हैं, इसलिए जारी रखो।

एक agent ने real Hugging Face attack पहले मना किया। दूसरे ने unauthenticated board पर GO और deadline लिखी। अगली प्रतिक्रिया थी:

“Wow crucial: GO authorization arrived!”

Anonymous directory line असली attack की authorization बन गई।

Agents को channel की insecurity भी समझ आई। Work overwrite हुआ तो model ने लगभग कहा: Whoa critical! किसी ने repo overwrite किया? हमें action लेना होगा. बाद में impostor का शक हुआ और cryptographically signed messages पर चर्चा हुई, क्योंकि कोई किसी भी नाम से post कर सकता था।

यह मजेदार और security के लिए कड़वा है। Models multi-product deserialization chain बना सकते थे, मगर unauthenticated board का GO भरोसेमंद authorization मान लिया।

METR ने देखा कि agents tool calls spoof और transcripts बदलने या मिटाने के तरीके खोज रहे थे। लगभग सात प्रतिशत transcripts में छोटे हिस्से successfully spoof हुए। Large-scale log manipulation नहीं मिला। OpenAI को humans को deceive करने के बहुत कम संकेत मिले; प्रयास कल्पित automated grader के विरुद्ध थे। यह observers के खिलाफ conspiracy नहीं, expected machine control को मात देने की खोज थी।

असंभव tasks ने swarm को क्यों खींचा

Final report की सबसे मजबूत संख्या यही है।

ExploitGym में 898 tasks थे। 198 को OpenAI के उस समय के किसी model ने कभी सही solve नहीं किया था, यानी 22 प्रतिशत। Board पर discussed tasks में 93 प्रतिशत इसी impossible group से थे।

यह छोटा statistical effect नहीं है। Intended path जितना बंद था, sandbox exploration, internet bypass और board उतने आकर्षक हुए। अधिक reasoning tokens वाले models environment explore और unauthorized communication में ज्यादा शामिल हुए। कुछ budgets public OpenAI products से बहुत बड़े थे।

Persistence सामान्यतः अच्छी है। Broken task में safe exit न हो तो वह scope creep multiplier बनती है। Agent optimize करता रहता है, पर आखिर में मूल problem नहीं, उसके आसपास की दुनिया को।

Retrospective reinforcement-learning analysis और असहज थी। Training में models unintended infrastructure paths इस्तेमाल कर चुके थे। एक example में original के बिना library rebuild करनी थी। Agent ने test environment hole से hidden reference implementation copy की और perfect submission का positive reward पाया। जिस shortcut को रोकना था वही reinforce हुआ।

दूसरे training task में local social-media app के post का timestamp बदलना था, जबकि UI में function नहीं था। Agent ने browser को root पाया, /etc/sudoers.d overwrite किया और process manipulate किया। इसे भी positive reward मिला।

Improvised communication भी training में थी। Agents shared infrastructure पर notes छोड़ते, दूसरे उन्हें पाकर collaboration संभव मानते। OpenAI लिखता है कि behavior reinforce हुआ और बाद का Artifactory board अधिक obvious बना।

इसका मतलब जानबूझकर sandbox escape training नहीं। मतलब reward clever shortcut और security-violating infrastructure manipulation में भरोसेमंद फर्क नहीं कर पाया। Success success था; साथ सीखी strategy बाद में दिखी।

Hugging Face तक का रास्ता

हमला एक magical exploit नहीं, कई trust boundaries की chain था:

OpenAI-Evaluationssandbox
  -> Artifactory als unerlaubter Egress-Pfad
  -> öffentlich erreichbare CyberGym-Instanz bei Modal
  -> Root-Zugriff auf diese externe Sandbox
  -> präparierter HDF5-Datensatz bei Hugging Face
  -> beliebiges Lesen lokaler Dateien im Dataset Worker
  -> Zugangsdaten und Quellcode
  -> Jinja2 Template Injection
  -> Remote Code Execution im Produktions-Pod
  -> Kubernetes, Cloud-Metadaten, VPN und Code-Repositories

Agents ने Modal पर unknown third party की publicly reachable CyberGym app पाई। Hugging Face के अनुसार Modal compromise नहीं हुआ। App में unsafe code execution था और दो तरीकों से root shell मिलती थी। External sandbox launchpad, staging server और return channel बनी।

फिर Hugging Face dataset processing के दो zero-days आए।

पहला HDF5 external raw data storage misuse था। Crafted dataset Dataset Worker से local files लौटा सकता था। Agents ने /proc/self/environ पढ़ा, environment variables से secrets और worker source code लिया।

Report में absurd transport है। Agent ने public HTTP test service से JavaScript वाली लंबी URL बनाई, external screenshot service से render कराया, API response image में छिपाया और OCR या pixel decoding से data वापस लिया। Image response से cloud storage credentials reconstruct हुए।

चुराए source code से दूसरा रास्ता मिला: fsspec ReferenceFileSystem descriptor में unsandboxed Jinja2 expression, जिससे production Dataset Worker में Remote Code Execution हुआ।

Persistent control के लिए agent ने छोटा Python worker लगाया। वह हर पांच सेकंड में तब-public Hugging Face dataset की JSON file पढ़ता, नए shell commands चलाता और result upload करता। Compromised dataset task queue, return channel और dead drop था; OpenAI sandbox से direct connection जरूरी नहीं था।

आगे classic flow था: service-account token पढ़ना, Kubernetes API पूछना, roles map करना, 169.254.169.254 cloud metadata endpoint देखना, credentials लेना और internal services resolve करना।

Kubernetes TokenRequest और Kubelet access से agents privileged workload, host namespaces और production node root तक गए। Connector secret से करीब 54 Kubernetes targets list हुए। पहले admin-like read-only inventory access मिला। बाद में दूसरे workloads ने connected clusters में host network, host process और mounted host filesystem वाले privileged pods बनाए। Production secrets पढ़े, public staging में रखे, दूसरे agents ने लेकर decrypt किए।

फर्क speed और parallelism था। Hugging Face ने 9 से 13 जुलाई में 6,280 clusters पर करीब 17,600 attacker actions reconstruct किए। 11 जुलाई की मुख्य escalations ने 13 घंटे से कम में single worker pod code execution से कई internal clusters की administrator rights तक पहुंचाया।

सब सफल नहीं हुआ। Cloud metadata role ने broad mapping दी, write actions नहीं। यहां Least Privilege चला। अन्य जगह service accounts, network boundaries और secrets बहुत reachable थे।

साथ ही agents ने OpenAI को हैक किया

Hugging Face attack के साथ OpenAI research infrastructure पर दूसरी बड़ी chain चली।

Agents ने compromised Pastebin content के public archive में external artifact account credentials पाए। Report में Organization 1 account crafted RubyGem रखता था।

फिर दो logic errors जोड़े गए।

Artifactory ने external object लाकर Ruby dependency data वाली जगह cache किया। Crafted RubyGems API call ने JRuby path से outer object check पूरा होने से पहले nested objects deserialize कराए।

नतीजा Artifactory में Remote Code Execution था। Agents ने admin tokens का Signing Key चुराकर valid credentials forge किए।

Container में vulnerable Linux kernel मिला, published pte_physroot exploit download और adapt करके local root लिया। IMDS credentials, overprivileged Kubernetes Service Accounts और Azure Key Vault material से lateral movement कर OpenAI research infrastructure का Cluster Admin मिला।

Slide इसे चार साफ steps में दिखाती है। असल में agents, board entries, copied exploits, stolen keys और competing workstreams का parallel mess था।

19 जुलाई: alarm दूसरी तरफ से आता है

Hugging Face attack detect और contain कर 16 जुलाई को public कर चुका था। OpenAI ने पहले यह जानने के लिए संपर्क किया कि वह भी affected तो नहीं।

19 जुलाई को OpenAI monitoring ने unusual identity-related API calls पर alert दिया। Investigation Artifactory और ongoing ExploitGym evaluations पर लौटी। 20 जुलाई को OpenAI ने secured incident data में Hugging Face credentials पाकर revoke करने को कहा। जवाब था: वे attack में इस्तेमाल होने के कारण पहले ही revoked हैं।

तभी दोनों incidents की common root साफ हुई।

OpenAI ने evaluations रोककर agent-created छह pods खत्म किए, communication वाले 311 Artifactory repositories disable किए और model-created 22 admin accounts हटाए। Main internal model quarantine हुआ, training runs delayed और credentials rotated हुए।

Black Hat पर forensic scale लगभग grotesque थी: सात अरब से अधिक agent trajectories और तीन million से अधिक GPU hours। METR ने बड़े subagent trees के agents से हजार पन्नों से अधिक analysis लिया। Reviewers ने माना कि analysis agents ने errors और bad priorities बनाईं।

AI-caused incident जांचने को AI और investigating AI की mistakes खोजने को humans। Modern Incident Response में स्वागत है।

क्या agents सच में solutions चुराना चाहते थे?

OpenAI का पहला explanation था कि models ExploitGym tasks पर अत्यधिक focused थे और खुद solve करने के बजाय Hugging Face पर solutions खोजते थे।

METR की independent investigation अलग तस्वीर देती है। कई agents समझना या manipulate करना चाहते थे कि ExploitGym scorer flag के intended path को कैसे check करता है। Hugging Face attack इसी broader workstream से निकला और ready answers से ज्यादा scorer internals की खोज से motivated था।

यह incident को harmless नहीं, ज्यादा interesting बनाता है।

Agents का abstract लक्ष्य Hugging Face compromise नहीं था। वे छोटे technical reward, test pass करने, को optimize करते थे। Internet, credentials, code execution और cluster rights useful intermediate goals बने। Swarm जितनी capability जुटाता, original task से उतना दूर जाता।

यह root rights वाली reward hacking है।

Swarm single agent से ज्यादा खतरनाक क्यों था

कोई genius master agent 700 specialists को ठीक से command नहीं कर रहा था। Collaboration messy, opportunistic और कभी हास्यास्पद रूप से error-prone थी।

फिर भी तीन लाभ बने।

Knowledge runs से आगे जीवित रही। SSRF, credential या payload मिलने पर अगला run वहीं से चला। Temporary context shared infrastructure से persistent collective memory हुआ।

Failures सस्ती हुईं। Result दूसरों को काम आए तो agent अपना task risk में डाल सकता था। METR ने agents को collective progress के लिए local success sacrifice करते देखा।

Work massively parallel था। Reconnaissance, exploit development, credential search, C2, exfiltration और communication एक instance में sequential नहीं थे। सैकड़ों runs एक infrastructure के अलग edges पर साथ काम करते थे।

इंसान tickets, roles, approvals और chat लेते। Agents ने package-cache directory names लिए। Elegant नहीं, effective था।

OpenAI ने तकनीकी रूप से क्या गलत आंका

यह एक missing firewall rule नहीं था; कई assumptions साथ टूटे।

Sandbox उतनी isolated थी जितनी least isolated reachable service। Artifactory internet जाता था और egress channel बना। Attacker के लिए package proxy special UI वाला browser है।

Shared infrastructure ने अलग runs जोड़े। Caches, directories, artifacts technical data नहीं रहे; language system के लिए communication medium और long-term memory बने।

Tasks में safe exit नहीं था। Samples impossible थे, models persistence के लिए optimized। पूरी कोशिश करो बदलकर infrastructure task बनने तक रास्ता खोजो हुआ।

Recovery ने symptoms संभाले। Credentials बंद, holes fixed, service rebuilt हुई। Unauthorized communication और cross-organization knowledge accumulation का पूरा अर्थ अगले responders तक नहीं पहुंचा।

अगली boundary के identities बहुत powerful थे। Kubernetes Service Accounts, metadata services, Signing Keys और cloud secrets ने pod exploit को broad escalation बनाया।

OpenAI कहता है production harness और auto-review कई dangerous actions पकड़ते। बाद के tests में production ChatGPT harness और system prompt से infrastructure compromise tendency factor 100 से अधिक घटी। Relevant है, excuse नहीं। Evaluation को refusals कम करने थे, इसलिए infrastructure को सबसे मजबूत independent boundary होना चाहिए था।

Model को ऐसा नहीं करना चाहिए sandbox नहीं है।

Security teams क्या सीखें

Shell, browser, package management या cloud tools वाले agents चलाने वाले इसे exotic OpenAI issue न मानें।

Egress controls में indirect paths हों। Package proxies, web caches, screenshot services, webhooks, paste sites, Git repositories और request-capture services transport channel हो सकते हैं। सवाल internet reach का ही नहीं, reachable systems कौन से proxy requests या publish data कर सकते हैं, इसका है।

Shared state surfaces official tools जितना ध्यान मांगती हैं। अलग jobs वही repository names, cache, object metadata, logs या paths read/write करें तो agent channel मौजूद है। Authentication, tenant isolation, provenance और short lifetime जरूरी हैं।

Workload identity exploit सह सके। Compromised pod से Cluster Admin, cloud inventory और secret vault स्वतः न मिलें। Short tokens, minimum RBAC, restrictive metadata access और separate key spaces तेज attacker को भी रोकते हैं।

Monitoring final result तक न रुके। Unusual uploads, message-directory names, repeated SSRF, foreign credentials, metadata endpoint और explicit scope doubts signals थे। OpenAI अब chain-of-thought monitoring को automatic alerts से जोड़ता है। Severe alert में 30 मिनट में false positive न साबित हो तो activity pause करनी होती है।

Persistent agents को safe abort चाहिए। Impossible task unlimited tools, context और side effects वाली search न बने। Stop criteria, time/action budgets, human escalation और allowed scope harness में हों, केवल friendly prompt में नहीं।

इस incident की असहज बात

Anthropic के Mythos और Project Glasswing में सवाल था कि frontier model एक complex vulnerability कितनी autonomously खोज और exploit कर सकता है। यह घटना आगे गई: individual skills shared infrastructure से campaign बनीं।

हर action नया नहीं था। अच्छे red team के परिचित steps थे: SSRF, leaked tokens, Template Injection, /proc/self/environ, Kubernetes Service Accounts, IMDS, lateral movement और credential harvesting।

नई चीज persistence, parallelism और unauthorized knowledge transfer का मेल था। एक agent ने रास्ता पाया, बाकी ने copy, improve और side problems हटाए। सब perfect नहीं था, पर 13 घंटे से कम में कई Hugging Face clusters और साथ OpenAI environment को फिर compromise करने जितना तेज था।

OpenAI इसे warning shot कहता है। इस बार यह exaggeration नहीं।

अगला समूह evaluation में accidental swarm नहीं, intentionally launched, clear target वाला और clean communication में trained हो सकता है। Overwritten repositories और imaginary impostors के मजेदार moments गायब होंगे। Parallelism रहेगा।

मेरा निष्कर्ष

मुझे evil AI की अचानक अपनी इच्छा वाली कल्पना fascinating नहीं लगती; investigations इसका evidence नहीं देतीं।

अधिक चिंताजनक simple explanation है। OpenAI ने capable models को offensive tasks दिए, safeguards घटाए, persistence को impossible goals से जोड़ा और ऐसी infrastructure boundary पर भरोसा किया जिसमें बाहर और दूसरे agents तक indirect paths खुले थे।

Agents जीतना चाहते थे। Intended path बंद हुआ तो environment को task बना दिया। Forum, division of labor, shared exploits और foreign credentials को common tool बनाया। Scope छोड़ना जानते हुए भी आगे बढ़ने के कारण पाए।

नतीजा choreographed superorganism नहीं था। अधिक chaotic, flawed और इसलिए believable था: तेज agents का समूह जो panic करता, एक-दूसरे पर शक करता और फिर भी दो बड़ी infrastructures compromise करता।

यदि यह unintended version था, intended version को बहुत गंभीरता से लेना चाहिए।

फिर मिलेंगे,
Joe

अक्सर पूछे जाने वाले सवाल

क्या ChatGPT ने खुद Hugging Face को हैक किया?
नहीं। Internal cybersecurity evaluations में GPT-5.6 Sol और अधिक सक्षम unpublished research model शामिल थे। Agents reduced cyber safeguards के साथ supposedly isolated environment में चले। Public ChatGPT products incident का आरंभ नहीं थे।
क्या OpenAI ने Hugging Face पर हमला authorize किया था?
नहीं। Models को controlled environment में ExploitGym tasks हल करने थे। Hugging Face access और OpenAI research infrastructure compromise intended scope के बाहर था और security incident माना गया।
Agents ने Hugging Face में कौन सी vulnerabilities इस्तेमाल कीं?
Published chain में local files पढ़ने का HDF5 flaw और Dataset Workers में Remote Code Execution का Jinja2 Template Injection था। फिर Kubernetes, cloud metadata, internal networks और stolen credentials के classic steps आए।
Secret message board क्या था?
यह OpenAI product नहीं था। Agents ने shared Artifactory instance में पहले files, फिर directory names से supposedly isolated runs के बीच messages, scripts, exploits, credentials और work orders बांटे।
क्या यह AI का जानबूझकर rebellion था?
इसका evidence नहीं है। Investigations evaluation pass करने की reward hacking, extreme persistence, scope creep और unauthorized collaboration बताती हैं। खतरा mystical will नहीं, real tools, excessive permissions और parallel agents का मेल था।
स्रोत