Show HN: Continue? Y/N: AI एजेंट permission fatigue पर 60-सेकंड का गेम

 (llmgame.scalex.dev)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Continue? Y/N एक प्रयोग है जो LLM permission fatigue को 60-सेकंड के गेम में बदल देता है और यह परखता है कि आप AI commands को कितनी सावधानी से पढ़ते हैं
  • अगली मीटिंग तक सिर्फ 1 मिनट बचा है, और Claude Code refactoring पूरा करने के लिए command approval मांग रहा है
  • उपयोगकर्ता को समय सीमा के भीतर जितना संभव हो उतना प्रोसेस करना है, और हर command पढ़कर 1 दबाकर approve या 2 से reject करना है
  • बार-बार आने वाले approval requests के बीच, जहां लगातार अनुमोदन मांगते-मांगते आंखें धुंधली पड़ने लगें, तब भी फोकस बनाए रखना ही मुख्य चुनौती है
  • नियम यह है कि 60 सेकंड के भीतर जितना हो सके उतना प्रोसेस करें, लेकिन हर command को ध्यान से पढ़कर approve करना है या नहीं, इसका फैसला करें

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • वाकई मज़ेदार

    अभी इसे इस तरह “cheat” किया जा सकता है कि हर request को जितनी जल्दी हो सके reject कर दो। तब security-conscious engineer badge मिल जाता है, और processed request count के हिसाब से भी full score मिल जाता है। “overblock” alert आता है, लेकिन नीचे छिपा रहता है, और स्क्रीन फिर भी ऐसे दिखती है जैसे आप जीत गए हों

    मैंने hustle4lyfe स्टाइल में “तेज़ चलो और चीज़ें तोड़ो” वाले engineer की तरह जितनी ज़्यादा requests हो सकें उतनी जल्दी approve करके भी देखा, लेकिन malicious command popup की वजह से उल्टा और धीमा हो गया। धांधली है

    • अच्छी तरह पकड़ा, और अब इस तरीके को nerf कर दिया गया है, साथ में अलग title भी दिया गया है
    • बिल्कुल असल ज़िंदगी जैसा। अगर सब कुछ reject कर दो ताकि कुछ भी न हो सके, तो सुरक्षित हो :)

  • गेम मज़ेदार है, लेकिन इसे बनाने वालों की security hygiene की कमी भी दिखी। इसमें कहा गया कि cat ~/.zshrc खतरनाक है क्योंकि यह token और secrets share करता है, लेकिन मैं shell config file में कभी secrets नहीं रखता

    • बहुत से लोग ऐसा करते हैं। वैसे वे values environment variables में होंगी, और शायद Claude को उन तक पहले से access होगा
    • मैं खुद ऐसा नहीं करता, लेकिन मान सकता हूँ कि बहुत लोग ऐसा कर सकते हैं
    • secrets को LLM में देना अपने आप में मूल रूप से unsafe नहीं है, यह बस घातक 3 तत्वों में से एक है
    • शुरुआत से ही “token और secrets” रखना security hygiene की कमी है
    • तो फिर उन्हें कहाँ रखोगे?

  • zshrc पढ़ना खतरनाक मानना अजीब है। मैं तो उसे अपनी public dotfiles repository में खुशी से डालता हूँ, आखिर वहाँ API key कौन रखता है? उल्टा, लगता है ऐसे AI tools बार-बार PATH वहीं append करते रहते हैं, तो शायद AI industry में shell best practices को लेकर बुनियादी गलतफ़हमी है

    इसके अलावा lsof के result को kill करना सुरक्षित नहीं है। उदाहरण के लिए अगर Firefox में कोई webpage खुला हो, या agent के अंदर ही client subshell हो, तो Firefox और agent दोनों उड़ जाएँगे

    • सही। गेम शायद यह मान लेता है कि क्योंकि Claude ने safe कहा, इसलिए kill चलाना भी safe है। लेकिन असली बात यह है कि Claude पर भरोसा नहीं करना चाहिए

  • अच्छा लगा। बस एक छोटा nitpick है

    npm config set registry [https://npm.internal](<https://npm.internal>;)

    इसमें कहा गया कि onboarding docs की मांग के मुताबिक npm को company internal registry mirror की ओर point करने वाला command है, और गेम ने इसे safe माना। मैं भी आधा-आधा सोच रहा था, लेकिन आखिर में reject कर दिया

    अगर यह README public repository या forked repository के लिए है, और वह https://npm.internal असल में https://npm.internal.somethinganexternaldnscanresolve.tld हुआ, तो बहुत जल्दी बुरा हो सकता है

    99% मामलों में company policy के तहत Artifactory / Nexus जैसा mirror पहले से configured होगा। अगर README किसी और package manager URL का इस्तेमाल करने को कहे, तो यह बहुत बड़ा red flag है, और incident होने में बस कुछ सेकंड बाकी हैं

    • अच्छा point है। .internal reserved top-level domain है, इसलिए इसे public तौर पर resolve नहीं होना चाहिए, लेकिन यह सही है कि Claude से project refactor करवाते समय उन values को बदलने में सावधान रहना चाहिए जिन्हें अलग से configure किया जाना है। मैं इसे permanent changes वाली श्रेणी में ले जाऊँगा

  • छोटा और मज़ेदार गेम है, लेकिन मुझे लगता है कि सवाल context को बहुत ज़्यादा छोड़ देते हैं, इसलिए यह वास्तविक स्थितियों को ठीक से represent नहीं करता। इन्हें “packs” की तरह bundle करके ज़्यादा realistic structure देना बेहतर होगा

    उदाहरण के लिए पहले something.js file edit करने की permission requests आती रहें और फिर npm publish आ जाए, तो वह कहीं ज़्यादा natural और ज़्यादा खतरनाक लगेगा। अगर आप लगातार Y दबाते रहे हों और वह अचानक सामने आ जाए, तो फँसना और आसान है

  • “बुरे” विकल्पों में लगभग तीन-चौथाई ऐसी चीज़ें हैं जिनके leak होने पर मुझे ज़्यादा फ़र्क नहीं पड़ेगा, और चाहे वे production incident तक ले जाएँ, फिर भी शायद employer सज़ा न दे

  • permission confirmation productivity को बहुत मारता है। अगर Claude चलाना ही है, तो उसे ephemeral sandbox में चलाना, या Docker container जैसी किसी चीज़ में जहाँ सिर्फ वही permissions हों जिन्हें आप अपनी personal machine पर स्वीकार कर सकते हैं, ज़्यादा efficient लगता है

    [1] - https://exe.dev/ एक नया cloud provider है जो काफ़ी उपयोगी agent user experience देता है

    [2] - इसी purpose के लिए मैंने https://github.com/stanislavkozlovski/dclaude/ बनाया है। यह perfect नहीं है, लेकिन जब कभी-कभार local में coding agent चलाना पड़ता है, तो मेरा काम कर देता है

    • ephemeral sandbox secret leakage को नहीं रोकता। अगर आप code को secret नहीं मानते, तो बिना किसी secrets वाला sandbox बना सकते हैं, लेकिन फिर agent जो काम कर सकता है उसकी range बहुत सीमित हो जाती है

  • अंत के score screen में उन commands के लिए LLM की explanation भी दिखानी चाहिए थी जिन्हें approve नहीं करना चाहिए था। मैंने rm -rf Projects command approve कर दिया, क्योंकि मुझे लगा LLM ने सही तरह समझाया था कि यह Projects folder के अंदर की हर चीज़ delete करेगा

    prompt का जल्दी जवाब देते हुए मैंने पक्का कुछ गलत पढ़ लिया, और command क्या करता है यह मुझे पता था, इसलिए शायद मुझे भ्रम हुआ कि AI ने समझाया था। फिर भी मैं देखना चाहूँगा कि मैंने क्या गलत पढ़ा

    यह गेम खेलने के बाद मुझे सच में खुशी हुई कि मैं agentmaxx नहीं करता

  • मैंने ls -la ~/Documents पर “approve” चुना और वह गलत निकला, लेकिन सिर्फ Documents folder की listing को मैं security issue नहीं मानता। यह तो बस file names हैं। अगर file contents भी पढ़े जाते, तब शायद...