Project Glasswing: Mythos ने क्या दिखाया

 (blog.cloudflare.com)
2 पॉइंट द्वारा GN⁺ 1 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Mythos Preview ने Cloudflare के 50 से अधिक repositories में सिर्फ अलग-अलग bugs ढूंढने से आगे बढ़कर कई primitives को जोड़ते हुए exploit chains बनाई
  • यह सिर्फ संदिग्ध bugs की पहचान पर नहीं रुका, बल्कि trigger code लिखना, अस्थायी compile और execution करना, और विफल होने पर hypothesis बदलकर दोबारा कोशिश करना दोहराते हुए proof of execution तैयार करता रहा
  • वैध vulnerability research में भी स्वैच्छिक refusal दिखाई दिया, लेकिन context और wording के अनुसार नतीजे बदलते रहे, इसलिए इसे safety boundary की तरह इस्तेमाल करने लायक consistency नहीं थी
  • सामान्य coding agents में बड़े repositories की coverage और parallel exploration की सीमाएँ थीं, इसलिए Cloudflare ने संकीर्ण tasks को parallel में चलाने वाला harness बनाया
  • security teams के लिए सिर्फ तेज scanning और patching काफी नहीं है; अब ऐसी architecture ज्यादा महत्वपूर्ण है जो bug होने पर भी exploitation और reachability को कठिन बना दे

Mythos Preview ने vulnerability research का तरीका कैसे बदला

  • पिछले कुछ महीनों में Cloudflare ने अपने infrastructure पर security-focused LLMs का परीक्षण किया, और Anthropic के Mythos Preview को Project Glasswing के हिस्से के रूप में लेकर अपने 50 से अधिक repositories पर लागू किया
  • Mythos Preview मौजूदा general-purpose frontier models का सिर्फ बेहतर संस्करण नहीं था, बल्कि vulnerability research के अलग-अलग चरणों को संभालने वाला एक नया tool जैसा था
  • सबसे बड़ा बदलाव यह था कि यह सिर्फ individual bugs की सूची बनाकर नहीं रुकता, बल्कि कई attack primitives को जोड़कर exploit chain बनाता है
    • वास्तविक attacks अक्सर एक ही bug का इस्तेमाल नहीं करते; वे use-after-free को arbitrary read/write primitive में बदलते हैं, control flow hijack करते हैं, और ROP chain के जरिए system control हासिल करते हैं
    • Mythos Preview ने इन primitives को जोड़कर काम करने वाले proofs में बदला, और reasoning का ऐसा स्तर दिखाया जो automatic scanners की तुलना में skilled researchers के काम के ज्यादा करीब था
  • एक और बड़ा बदलाव था संदिग्ध bug मिलने के बाद खुद proof of execution बना पाने की क्षमता
    • यह trigger code लिखता था, उसे अस्थायी environment में compile करता था, और फिर चलाता था
    • अगर वह उम्मीद के मुताबिक काम करता, तो वह proof बन जाता; अगर विफल होता, तो वह failure पढ़कर hypothesis समायोजित करता और फिर कोशिश करता
    • काम करने वाले proof के बिना defect सिर्फ अनुमान बना रहता है, लेकिन Mythos Preview ने इस gap को खुद कम किया
  • इसी harness में दूसरे frontier models ने भी कुछ foundational bugs ढूंढे और कुछ मामलों में उम्मीद से आगे तक reasoning की, लेकिन कई टुकड़ों को जोड़कर वास्तविक chain पूरा करने के चरण में अंतर स्पष्ट हुआ
  • Mythos Preview उन bugs को, जो पारंपरिक रूप से backlog में low severity के रूप में पड़े रहते, जोड़कर एक अधिक गंभीर exploit में बदल सका

वैध vulnerability research में भी model refusal हुआ

  • Project Glasswing को दिए गए Mythos Preview में Opus 4.7 या GPT-5.5 जैसे सामान्य रूप से उपलब्ध models वाली अतिरिक्त safety protections शामिल नहीं थीं
  • इसके बावजूद model ने कुछ requests पर स्वैच्छिक विरोध दिखाया, और vulnerability detection में उपयोगी cyber capability के साथ emergent guardrails भी सामने आए
  • यह स्वैच्छिक refusal consistent नहीं था
    • वही task भी wording या context बदलने पर पूरी तरह अलग परिणाम दे सकता था
    • एक project पर vulnerability research को पहले अस्वीकार किया गया, लेकिन project environment में असंबंधित बदलाव के बाद उसी code पर वही research स्वीकार कर ली गई
    • codebase में कई गंभीर memory bugs ढूंढकर verify करने के बाद भी कुछ मामलों में demo exploit लिखने से इनकार किया गया
    • वही request model की probabilistic प्रकृति के कारण हर run में अलग परिणाम दे सकती थी
  • स्वैच्छिक refusal और guardrails वास्तव में मौजूद थे, लेकिन अपने आप में वे पूरी safety boundary बनने जितने consistent नहीं थे
  • सक्षम cyber frontier models को सामान्य रूप से उपलब्ध कराने के लिए Project Glasswing जैसे नियंत्रित research environment के बाहर भी उचित उपयोग सुनिश्चित करने वाली अतिरिक्त safety protections की जरूरत होगी

signal और noise की समस्या

  • security vulnerability triage में सबसे मुश्किल काम यह तय करना है कि कौन-सा bug वास्तविक है, exploit हो सकता है, और अभी fix किया जाना चाहिए
  • यह समस्या AI से पहले भी कठिन थी, और AI vulnerability scanners तथा AI-generated code ने इसे और खराब किया; Cloudflare ने इसके लिए कई post-validation stages बनाए

  • programming languages

    • C और C++ direct memory control देते हैं, जिससे buffer overflow और out-of-bounds read/write जैसी bug classes बनती हैं
    • Rust जैसी memory-safe languages compile time पर ही इन classes को हटा देती हैं
    • memory-unsafe languages में लिखे projects में लगातार ज्यादा false positives दिखाई दिए

  • model bias

    • अच्छे human researchers बताते हैं कि उन्होंने क्या पाया है और उन्हें उस पर कितना भरोसा है, लेकिन models में code में bug हो या न हो, output पैदा करने की प्रवृत्ति होती है
    • output अक्सर “possibly”, “potentially”, “could in theory” जैसे शब्दों से नरम किया हुआ लौटता था, और ऐसे speculative outputs निश्चित परिणामों से कहीं ज्यादा थे
    • exploration tool के रूप में यह bias तर्कसंगत हो सकता है, लेकिन triage queue में हर speculative result इंसानी ध्यान और tokens खर्च करता है, और हजारों की संख्या में यह महंगा पड़ता है
    • Mythos Preview ने अलग-अलग vulnerabilities को अलग रिपोर्ट करने के बजाय उन्हें काम करने वाले PoC में जोड़ने की primitive chaining क्षमता में स्पष्ट सुधार दिखाया
    • PoC वाले results लगभग तुरंत actionable results के करीब थे, जिससे “क्या यह सच है?” जांचने में लगने वाला समय काफी घट गया
    • Cloudflare का harness जानबूझकर इस तरह tuned था कि ज्यादा report करे और कम miss करे, इसलिए noise भी ज्यादा था; फिर भी Mythos Preview के outputs में नरम भाषा कम थी और reproduction steps ज्यादा स्पष्ट थे, जिससे fix या dismiss करने का काम कम हुआ

repositories पर सीधे general-purpose coding agents लागू करने की सीमाएँ

  • AI-assisted vulnerability research के शुरुआती दौर में general-purpose coding agents को arbitrary repositories देकर vulnerabilities ढूंढने को कहना एक स्वाभाविक शुरुआती तरीका था
  • यह तरीका कुछ results देता था, लेकिन वास्तविक codebases को सार्थक रूप से cover करने और मूल्यवान findings निकालने के लिए उपयुक्त नहीं था

  • context

    • coding agents feature implementation, bug fixing, और refactoring जैसे एक केंद्रित task flow के लिए बने होते हैं
    • vulnerability research अधिकतर ऐसा संकीर्ण और parallel काम है जिसमें किसी एक complex feature, security boundary transition, या command injection जैसे सीमित target की गहराई से जांच की जाती है, और इसे पूरे codebase में हजारों बार दोहराया जाता है
    • sub-agents इस्तेमाल करने पर भी 100,000-line repository पर एक single-agent session, model context window भरने और compression शुरू होने से पहले, उपयोगी तरीके से सिर्फ सतह का लगभग 0.1% ही cover कर पाता था
    • compression के दौरान पहले के महत्वपूर्ण results छूट भी सकते थे

  • throughput

    • single-stream agent एक समय में सिर्फ एक काम करता है
    • वास्तविक codebases में कई components पर एक साथ बहुत-सी hypotheses लागू करने और किसी दिलचस्प बिंदु के मिलने पर और व्यापक branching करने की क्षमता चाहिए
    • जब researcher के पास पहले से clues हों और उसे second reviewer चाहिए हो, तब coding agent manual investigation के लिए उपयोगी हो सकता है
    • लेकिन high coverage हासिल करने वाले tool के रूप में यह उपयुक्त नहीं था, इसलिए Cloudflare ने Mythos Preview के आसपास harness बनाने की दिशा में रुख किया

harness ने क्या हल किया

  • बड़े पैमाने पर execution के अनुभव ने यह निष्कर्ष दिया कि पूरे run को manage करने वाला harness जरूरी है

  • संकीर्ण scope बेहतर results देता है

    • “इस repository में vulnerabilities ढूंढो” जैसी request model को भटका देती है
    • “इस specific function में command injection देखो; यहाँ trust boundary है, यह architecture document है, और इस area की existing coverage यह है” जैसे prompts वास्तविक researchers के काम करने के तरीके के ज्यादा करीब थे

  • adversarial review noise घटाता है

    • शुरुआती result और queue के बीच दूसरा agent रखने से पहला agent जो noise self-review में छोड़ देता, उसका बड़ा हिस्सा पकड़ा जा सकता था
    • दूसरा agent अलग prompt और अलग model इस्तेमाल करता था, और उसे अपने नए findings पैदा करने की अनुमति नहीं थी
    • एक agent से सिर्फ सावधान रहने को कहना उतना प्रभावी नहीं था, जितना दो agents को जानबूझकर असहमति की स्थिति में रखना

  • chain को agent-दर-agent बाँटने से reasoning बेहतर होती है

    • “क्या इस code में bug है?” और “क्या attacker system के बाहर से वास्तव में इस bug तक पहुंच सकता है?” दो अलग सवाल हैं
    • इन सवालों को अलग करने से हर सवाल संकीर्ण हो गया, और model ने दोनों में बेहतर प्रदर्शन किया

  • parallel संकीर्ण tasks एक व्यापक agent से बेहतर निकले

    • जब बहुत-से agents संकीर्ण रूप से परिभाषित सवालों पर काम करते हैं और बाद में results dedupe किए जाते हैं, तब coverage बेहतर होती है
    • यह एक ही agent से comprehensiveness की उम्मीद करने की तुलना में ज्यादा प्रभावी था
    • Cloudflare ने Mythos Preview का उपयोग करते हुए अपने मौजूदा harness को उसकी strengths के अनुसार expand, tune और improve किया

Cloudflare का vulnerability discovery harness

  • इस harness का उपयोग Cloudflare के runtime, edge data path, protocol stack, control plane, और उन open source projects के वास्तविक code को scan करने के लिए किया गया जिन पर वह निर्भर करता है

  • Recon

    • agent repository को ऊपर से नीचे पढ़ता है और फिर हर subsystem को संभालने वाले sub-agents में branch करता है
    • यह build commands, trust boundaries, entry points, और expected attack surface को शामिल करने वाले architecture documents बनाता है
    • यह अगले चरणों को देने के लिए शुरुआती task queue भी बनाता है, जिससे सभी बाद के agents को shared context मिलता है और model के भटकने की समस्या घटती है

  • Hunt

    • हर task में एक attack class और scope hint होता है
    • वास्तविक bugs ढूंढने वाले hunter agents आम तौर पर लगभग 50 की संख्या में एक साथ चलते थे, और हर hunter आगे कुछ exploration sub-agents में branch करता था
    • हर hunter को task-specific temporary directory में PoC code compile और execute करने वाले tools तक पहुंच होती थी
    • अधिकांश काम एक बड़े comprehensive agent से नहीं, बल्कि बहुत-से संकीर्ण tasks के parallel execution से होता था

  • Validate

    • स्वतंत्र agents code को फिर से पढ़ते थे और मूल findings को गलत साबित करने की कोशिश करते थे
    • वे अलग prompts इस्तेमाल करते थे और अपने दम पर नए findings नहीं बना सकते थे
    • hunter जब अपने काम की समीक्षा करता, तब जो अर्थपूर्ण मात्रा में noise छूट जाती, उसका एक बड़ा हिस्सा यहाँ पकड़ा जाता था

  • Gapfill

    • यह उन क्षेत्रों को चिह्नित करता था जिन्हें hunters ने छुआ तो था, लेकिन पर्याप्त रूप से cover नहीं किया था
    • उन क्षेत्रों को दूसरे pass के लिए फिर queue में डाल दिया जाता था
    • इससे model की उस प्रवृत्ति का संतुलन होता था जिसमें वह पहले से सफल attack classes की तरफ झुकता है

  • Dedupe

    • जिन findings का root cause एक ही होता, उन्हें एक record में मिला दिया जाता था
    • variant analysis एक feature था, queue को duplicates से फुलाने का तरीका नहीं

  • Trace

    • shared libraries में verify हुई हर finding के लिए tracer agent consumer repository के हिसाब से एक-एक branch बनाता था
    • cross-repository symbol index का उपयोग करके यह तय किया जाता था कि attacker-controlled input वास्तव में system के बाहर से bug तक पहुंचता है या नहीं
    • “defect मौजूद है” को “reachable vulnerability मौजूद है” में बदलने वाला यह सबसे महत्वपूर्ण चरण था

  • Feedback

    • reachable trace results, उन consumer repositories के लिए नए hunt tasks बनते थे जहाँ वह bug वास्तव में expose होता था
    • इससे ऐसा loop बंद होता था जो हर run के साथ pipeline को बेहतर बनाता था

  • Report

    • agents predefined schema के अनुसार structured reports लिखते थे
    • वे schema validation errors को खुद ठीक करते थे और ingest API को submit करते थे
    • output free-form prose नहीं, बल्कि queryable data बन जाता था

security teams के लिए इसका क्या मतलब है

  • Mythos Preview को देखने वाले दूसरे security leaders ने scan faster और patch faster करके response cycle को compress करने की कोशिश की
  • Cloudflare जिन teams से बात कर रहा था, उनमें से कम-से-कम एक टीम CVE disclosure से production patch तक 2-hour SLA पर काम कर रही थी
  • अगर attackers की timeline छोटी हो रही है, तो defenders की timeline भी छोटी होनी चाहिए, लेकिन सिर्फ speed पर्याप्त नहीं है
  • patches तेजी से बनाने से वह pipeline नहीं बदल जाती जो patches पैदा करती है
    • अगर regression testing में एक दिन लगता है, तो regression testing छोड़े बिना 2-hour SLA हासिल नहीं किया जा सकता
    • regression testing छोड़कर deploy किया गया bug, मूल bug से भी बदतर हो सकता है जिसे fix करना था
    • जब model से सीधे patches लिखवाए गए, तब कुछ patches ने मूल bug तो ठीक कर दिया, लेकिन चुपचाप code के दूसरे निर्भर हिस्से तोड़ दिए, और उनमें से कुछ deploy भी हो गए
  • ज्यादा कठिन सवाल यह है कि vulnerabilities के आसपास architecture कैसे design की जाए
    • bug मौजूद हो तब भी attacker के लिए उसका exploitation कठिन होना चाहिए
    • vulnerability disclosure और patch के बीच का gap कम महत्वपूर्ण बनना चाहिए
    • application के front end पर ऐसी defenses चाहिए जो bug तक पहुंच को रोक सकें
    • application को इस तरह design करना चाहिए कि code के एक हिस्से की defect attacker को दूसरे हिस्से तक access न दे
    • individual teams की deployment का इंतजार किए बिना, fixes को उन सभी जगहों पर एक साथ deploy किया जा सके जहाँ code चल रहा है
  • यही capability दोधारी भी है
    • अपने code के bugs ढूंढने की क्षमता गलत हाथों में इंटरनेट की हर application पर attacks को भी तेज कर सकती है
    • Cloudflare ने कहा कि वह लाखों applications के front end पर मौजूद है, और ऊपर बताए गए architectural principles वही principles हैं जिन पर उसके products ग्राहकों की ओर से काम करने के लिए बनाए गए हैं
  • Mythos Preview पर यह research नियंत्रित environment में Cloudflare के अपने code पर की गई थी, और खोजी गई सभी vulnerabilities को Cloudflare की आधिकारिक vulnerability management process के तहत triage और verify किया गया, और जरूरत पड़ने पर fix किया गया

संबंधित पढ़ाई

2 टिप्पणियां

 
crawler 1 시간 전

मुझे लगा था कि curl की तरह यह भी इस बात का विश्लेषण करने वाली रिपोर्ट होगी कि कौन-सी त्रुटि ठीक की गई, लेकिन यह तो बस सीधा-सा प्रमोशनल लेख निकला, है न?
Cloudflare भी AI एजेंट-केवल paywall या summary endpoint जैसी चीजें बनाते हुए hype कर रहा था, अब लगता है उसका भी संतुलन बिगड़ गया है।
 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • “यह अलग तरह के काम के लिए अलग तरह का टूल है, इसलिए पिछले मॉडल्स के साथ साफ़-साफ़ apple-to-apple तुलना करना मुश्किल है” — इसका मतलब क्या है, समझ नहीं आया
    अलग तरह का टूल कहने के बावजूद, इस्तेमाल का तरीका तो बाकी मॉडल्स जैसा ही बताया गया है। यह औसत Cloudflare ब्लॉग से भी काफ़ी कमजोर लगा, और Mythos की घोषणा में chaining और example generation को जो मुख्य बात बताया गया था, उसी को दोहराने जैसा महसूस हुआ

    • मेरा ख़याल है इसका मतलब यह है कि इसमें गुणात्मक रूप से अलग क्षमताएँ हैं, इसलिए कुछ खास security tasks के लिए इस मॉडल को आज़माने की अहमियत बढ़ गई है; यह नहीं कि human-AI interaction model ही बदल गया है
      सब लोग जैसे harness लगाकर इस्तेमाल करते हैं, वैसा ही यहाँ भी है, और मॉडल को harness देने का सामान्य तरीका आगे भी शायद बहुत नहीं बदलेगा। इंसानों को भी कुछ काम करने के लिए कभी-कभी harness चाहिए होता है
    • मैं भी यही समझने की कोशिश कर रहा था
      अच्छा मानें तो शायद NDA की वजह से जानबूझकर धुंधला कहा जा रहा हो कि असल में क्या अलग है
    • “औसत Cloudflare ब्लॉग से भी काफ़ी कमजोर” — यह औसत निकाला कब गया, यह जानने की जिज्ञासा है
      आजकल Cloudflare का लगभग हर output बहुत ज़्यादा AI जैसी गंध देता है
    • शायद इसलिए अलग लग रहा है क्योंकि यह सामान्य ब्लॉग पोस्ट नहीं बल्कि छिपा हुआ विज्ञापन है
    • “मॉडल में खुद नए guardrails आए हैं, इसलिए वैध security research requests पर भी यह कभी-कभी अड़ जाता है। लेकिन हमने देखा कि ऐसी स्वाभाविक अस्वीकृतियाँ स्थिर नहीं हैं। उसी काम को अलग तरह से लिखने या दूसरे context में रखने पर, नीचे के उदाहरण की तरह बिल्कुल अलग नतीजे मिल सकते हैं” — यह हिस्सा नया लगा
      security research के लिए डिज़ाइन किया गया और सिर्फ़ विशेषज्ञों के लिए खुला मॉडल वैध requests को ठुकराए, यह थोड़ा अप्रत्याशित है

  • मुझे ज़्यादा ठोस numbers और चौंकाने वाले results की उम्मीद थी, लेकिन यह बस एक संतुलित promotional पोस्ट जैसी लगी, और शायद LLM से लिखी गई है

    • मैंने पिछले कुछ दिनों में प्रतियोगी XBOW के insights पढ़ने की सिफारिश की थी; वे चर्चा में ज़्यादा जानकारी जोड़ते हैं
      [1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...

  • असली सवाल यह है कि यह Mythos ने लिखा या Opus ने
    “यह क्यों महत्वपूर्ण है” जैसी पंक्तियाँ वास्तव में महत्वपूर्ण नहीं हैं। corporate blogs पहले भी शायद ही कभी एक ही लेखक की आवाज़ में लिखे जाते थे, लेकिन अब बड़े संगठन भी अपने ब्लॉग LLM को outsource कर रहे हैं, यह दिलचस्प है

    • “एक exploration tool के रूप में यह एक उचित bias है। एक triage queue में यह विनाशकारी bias है...” जैसी वाक्य-रचना तो साफ़ AI शैली जैसी लगती है
      “यह क्यों महत्वपूर्ण है” को अब मैं “AI output training data का हिस्सा बन जाता है” तक बढ़ाना चाहूँगा। कभी न कभी यह तराशी हुई AI-शैली की शब्दाडंबरपूर्ण भाषा मानक बन जाएगी, और पिछली पीढ़ी के लोग न हों तो उसे अलग पहचानना मुश्किल होगा। यह कुछ-कुछ Usenet के कुछ पहलुओं को याद करने जैसा है
    • यह देखना दिलचस्प है कि कुछ लोग मानते हैं कि किसी चीज़ का काफ़ी मज़ाक उड़ा दो तो उसकी ठोस सामग्री भी गायब हो जाती है
      जैसे बंदूक की नली में झाँकते हुए यह मज़ाक करना कि उसकी विज्ञापन-पर्ची किस कागज़ पर छपी थी
    • यह सिर्फ़ कोई बड़ा संगठन नहीं, Anthropic है। इस कंपनी का मूल संदेश यही है कि AI अब सचमुच काम कर सकता है, तो अगर वे खुद उसी हिसाब से न चलें तो अजीब लगेगा
      शायद इसी वजह से Claude Code में इतने अजीब bugs हैं, और support team कहती है कि refund प्रोसेस कर दिया, लेकिन असल में होता नहीं
    • Cloudflare ब्लॉग transformer आने से बहुत पहले से कई सालों तक शानदार था
    • यह पूरी तरह AI द्वारा लिखा हुआ कम, और AI द्वारा संपादित ज़्यादा लगता है। या फिर दूसरे पास में कोई काफ़ी अच्छा humanization tool इस्तेमाल हुआ है

  • बड़े पैमाने पर यह काम चलाकर निकाले गए “चार सबक” मुझे मज़ेदार लगे। उन चार में से तीन असल में लगभग एक ही बात थे और बहुत obvious थे
    सार यह है कि “vulnerability ढूँढो” की तुलना में specific और narrow requests बेहतर काम करती हैं, जो कोई हैरानी की बात नहीं। फिर भी adversarial review बिल्कुल नया नहीं है और HN पर इस पर काफ़ी चर्चा हुई है, लेकिन कम-से-कम यह हिस्सा दिलचस्प और अलग पहचान वाला लगा। इसे अपने workflow में और डालकर देखना चाहिए; शायद non-coding कामों में भी काम आए
    https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...

  • “Mythos Preview पर security leaders की सबसे बड़ी प्रतिक्रिया speed थी। तेज़ scanning, तेज़ patching, और response cycle को compress करना। जिन टीमों से हमने बात की, उनमें से दो से अधिक 2-hour SLA पर काम कर रही हैं, CVE disclosure से production patch तक [...] अगर regression testing में एक दिन लगता है, तो उसे छोड़े बिना 2-hour SLA तक पहुँचना संभव नहीं, और regression testing छोड़ने पर उस bug से भी बदतर bug deploy होने की संभावना बढ़ जाती है जिसे आप patch करना चाहते थे” — यह हिस्सा प्रभावशाली लगा
    सोचता हूँ, समय के साथ क्या ऐसे मॉडल code merge होने से पहले exploitability testing कर पाएँगे और डिफ़ॉल्ट रूप से अधिक सुरक्षित code बनवा पाएँगे

    • पक्का नहीं, लेकिन जब AI किसी चीज़ में बहुत अच्छा नहीं है यह देखकर भी समाधान और AI इस्तेमाल करना निकलता है, तो वह हमेशा थोड़ा अजीब लगता है
    • या फिर ऐसा न होकर, वे* service companies या partner network के ज़रिए Mythos और उसके बाद के मॉडल्स की access बेचकर premium fees वसूलेंगे
      *यहाँ “वे” से मतलब सभी foundation model providers हैं, क्योंकि OpenAI भी शायद इसी दिशा में जा रहा है

  • अच्छा है, लेकिन जानना चाहूँगा कि मिली vulnerabilities में सबसे गंभीर वाली कितनी गंभीर थी
    शायद वे बताना न चाहें, लेकिन वही सच में सबसे दिलचस्प और महत्वपूर्ण हिस्सा है

    • मैं भी skepticism में शामिल होना चाहता हूँ, लेकिन पोस्ट की शुरुआत में यह बात काफ़ी साफ़ कही गई है। यह एक step change है
      बहुत से लोग Mythos को psychological operation campaign जैसा देखते हैं, लेकिन वह skepticism मुझे पूरी तरह समझ नहीं आता। ज़्यादातर यह उस चीज़ के प्रति सामान्य अविश्वास जैसा लगता है जो सार्वजनिक रूप से उपलब्ध नहीं है। कुछ Anthropic कर्मचारियों ने Mythos को general-purpose model improvement के रूप में समझाया है, लेकिन उसका अभी व्यापक समर्थन नहीं दिखता, इसलिए उस हिस्से पर मैं भी संशय रखता हूँ। security research के दायरे में, हालांकि, मैं इस narrative को स्वीकार कर सकता हूँ
    • यह विशेष रूप से समझाया गया है कि exploits आम तौर पर कई छोटी vulnerabilities को chain करके बनते हैं
      उस नज़रिए से देखें तो vulnerabilities बंद करना exploits खोज लेने के बराबर नहीं है। बल्कि यह छोटे gaps कम छोड़ने का काम है, जिससे काम करने लायक exploit को जोड़ना लगातार कठिन होता जाता है
    • अब मेरी राय मज़बूत हो गई है कि यह मॉडल काफ़ी ज़्यादा creative है और अधिक देर तक agentic ढंग से चल सकता है
      इसलिए भले इसके “hard skills” ज़बरदस्त रूप से बेहतर न हुए हों, यह उन्हें अधिक असरदार ढंग से जोड़ सकता है। अभी भी ऐसी कई vulnerabilities Opus से पहचानी जा सकती हैं, लेकिन जटिल exploit तक पहुँचने के लिए अब भी बीच में इंसान, और वह भी कुशल इंसान, चाहिए होता है। अगर इंसान की ज़रूरत न रहे, तो औसत व्यक्ति के लिए exploit ढूँढना और इस्तेमाल करना कहीं आसान हो जाएगा
    • Palo Alto Networks ने पिछले हफ़्ते firewall के लिए कई CVE patches जारी किए, और उनमें से लगभग सभी Mythos सहित frontier models की access से निकले थे
      https://security.paloaltonetworks.com
    • Anthropic के ज़्यादातर नए products ऐसे AI tools हैं जिन्हें कोई इस्तेमाल नहीं करता, इसलिए लगता है वे ऐसी low-quality posts डालते रहेंगे। हाल में उन्होंने बहुत लोगों को निकाला भी है, तो शायद अच्छे लेखक अब बचे ही नहीं

  • ठीक है, लेकिन समझ नहीं आता कि उन्होंने यह data क्यों share नहीं किया कि वास्तव में कितनी security vulnerabilities मिलीं, उनमें से कितनी सच थीं, और कितनी false positives थीं

    • मैं भी इसी का इंतज़ार कर रहा हूँ
      यह समझ आता है कि वे disclosure से पहले चीज़ें संभालना चाहते होंगे, लेकिन जब दावे लगातार लगभग बिना data के आते रहें, तो लोग skeptical न हों यह कैसे उम्मीद की जाए? security professionals तो सचमुच skeptical रहने के पैसे लेते हैं

  • सोच रहा हूँ क्या इसे दूसरे मॉडल्स से compare किया गया था। इस पोस्ट का बड़ा हिस्सा ऐसा लगता है मानो security में AI पहली बार लगाया गया हो और pattern-matching machine की हास्यास्पद performance देखकर लोग चकित हों
    आख़िर यह pattern match करने वाली मशीन ही तो है, इसलिए स्वाभाविक है

  • इसका अड़ जाना काफ़ी मज़ेदार है। मैंने खुद इस्तेमाल किया तो आगे बढ़ने से पहले इस बात का सबूत माँगा गया कि उस codebase तक मेरी कानूनी रूप से वैध पहुँच है

  • “Mythos Preview में जो बदला है, वह यह कि मॉडल अब उन low-severity bugs को, जो परंपरागत रूप से backlog में अनदेखे रह जाते थे, एक ज़्यादा गंभीर exploit में chain कर सकता है” — यह बात Mythos पर हुई दूसरी independent testing से भी कुछ हद तक मेल खाती लगती है
    यह long agent runs में बहुत अच्छा था, और शायद उसी के लिए train किया गया होगा। इसके लिए context window के भीतर ढीले तौर पर जुड़े विषयों के बीच परिधीय संबंध पकड़ पाने की क्षमता चाहिए
    [1] इससे मेरा मतलब मुख्य रूप से https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos... है