मैंने एक कमजोर ऐप बनाया और यह देखने में $1,500 खर्च किए कि क्या LLMs उसे हैक कर सकते हैं

एक developer ने जानबूझकर कमजोर web app पर विभिन्न large language models से उसे hack कराने के लिए $1,500 खर्च किए, जिससे उनकी offensive security क्षमता और provider-imposed safety guardrails के अक्सर बाधा बनने—दोनों—पर रोशनी पड़ी। टिप्पणीकार बहस करते हैं कि खासकर Claude जैसे models पर सख्त restrictions मुख्यतः ethics, liability, या भविष्य की upselling रणनीति हैं या नहीं, यह देखते हुए कि वे अक्सर penetration testing, reverse engineering, या user-owned credentials संभालने जैसे वैध कार्यों को ब्लॉक कर देते हैं। कई लोग तर्क देते हैं कि वास्तविक प्रभावशीलता मजबूत models को sophisticated “harnesses” के साथ जोड़ने से आती है, और भविष्य की safety systems को user verification या tiered access की जरूरत हो सकती है ताकि defenders attackers से कमजोर tools के साथ न रह जाएं.

Anthropic-शैली के गार्डरेल और घटती उपयोगिता

  • कई टिप्पणीकार बताते हैं कि Anthropic मॉडल अब वैध कार्यों से भी अधिक बार इनकार करने लगे हैं: लॉगिन, क्रेडेंशियल्स संभालना, CTFs, reverse engineering, bioscience, malware analysis, यहां तक कि MIT-licensed code को fork करना या स्थानीय निजी दस्तावेज़ों को प्राप्त करना।
  • कुछ लोग कहते हैं कि 4.6 सुरक्षा के लिए 4.7/4.8 की तुलना में बहुत अधिक उपयोगी था, जबकि बाद वाले “neutered” या भ्रामक लगते हैं (पहले नेटवर्क एक्सेस न होने का दावा करना, फिर बाद में उसे स्वीकार करना)।
  • अन्य लोग नोट करते हैं कि गार्डरेल कभी-कभी असंगत व्यवहार करते हैं: वही prompts एक session में पास हो सकते हैं और दूसरी में block, बीच-बीच में invisible safety prompts inject किए जा सकते हैं।
  • अल्पसंख्यक का तर्क है कि ये इनकार अधिकांश users के लिए वास्तव में अच्छे defaults हैं, जिन्हें agent को full credentials या खतरनाक कार्य नहीं देने चाहिए।

Business model, upsell, और “कौन professional है?”

  • यह प्रबल संदेह कि guardrails को सख्त करना paid “Security Pro”–style tiers की तैयारी है, जहां केवल vetted users को offensive capabilities मिलेंगी।
  • इस पर बहस कि vendors को व्यावहारिक रूप से यह तय करना चाहिए कि कौन “security professional” है, या स्वतंत्र professional bodies पर भरोसा करना चाहिए, या बस खुले tools होने चाहिए।
  • कुछ लोग भविष्य में fragmented, paywalled capabilities (security, databases, data science, आदि) का डर जताते हैं, जो streaming-service fragmentation जैसी होगी।

Mythos, harnesses, और benchmarking

  • दावे हैं कि एक internal model (Mythos) बहुत अधिक सक्षम है, लेकिन NDAs और guardrails के पीछे छिपा हुआ है; कुछ लोग संबंधित टिप्पणियों को शुद्ध marketing मानते हैं।
  • चर्चा इस बात पर जोर देती है कि Mythos की सफलता काफी हद तक एक sophisticated harness पर निर्भर करती है: प्रति file multiple passes, evolving prompts, और संदिग्ध प्रत्येक bug की स्पष्ट verification।
  • कई लोगों का तर्क है कि कोई भी निष्पक्ष तुलना समान रूप से engineered harnesses और multi-step validation का उपयोग करे, न कि सिर्फ “one-shot, find all bugs.”

Chinese / open models और security work

  • कई रिपोर्टें कहती हैं कि Chinese models (जैसे GLM, DeepSeek, Qwen, Mimo) databases पर हमला करने, crackmes हल करने, और pentesting में मदद करने के लिए कहीं अधिक इच्छुक हैं।
  • कुछ का दावा है कि ये पहले से ही Western flagships के बराबर प्रतिस्पर्धी हैं; अन्य benchmark का हवाला देकर पर्याप्त capability gap की बात करते हैं।
  • security practitioners चेतावनी देते हैं कि “safety-first” Western models से सीमित defenders, कम-प्रतिबंधित alternatives का उपयोग करने वाले attackers से पीछे रह सकते हैं।

Methodology, cost, और ethics

  • कई लोग article की methodology को “naive” कहते हैं, तर्क देते हुए कि वास्तविक workflows human-in-the-loop, multi-run होते हैं, और अक्सर कई models को जोड़ते हैं।
  • अन्य लोग जोर देते हैं कि असली cost driver अच्छे eval rigs और orchestration बनाना है, न कि token spend।
  • ongoing ethical debate: क्या unguardrailed models जो reliably vulnerabilities ढूंढ सकते हैं, व्यापक रूप से उपलब्ध होने चाहिए, या dual-use risks को देखते हुए tightly controlled होने चाहिए?