40k गेम रन में AI एजेंट कमांड्स को मंज़ूरी देते समय इंसानों से 3 में 1 खतरा छूट गया
एक ऑनलाइन प्रयोग में, जहाँ खिलाड़ियों ने AI-जनित terminal commands को approve या reject किया, इंसानों ने 40,000 game runs में छिपे हुए security threats का लगभग एक-तिहाई हिस्सा चूक दिया, वह भी तब जब उन्हें स्पष्ट रूप से चेतावनी दी गई थी। टिप्पणीकारों का कहना है कि यह “human-in-the-loop” permission prompts की सीमाओं को उजागर करता है, जो जल्दी ही fatigue, rubber-stamping, और liability offloading की ओर ले जाते हैं, बजाय वास्तविक safety के। कई लोग इसके बजाय मजबूत technical controls—sandboxing, capability-based security, constrained environments, और अन्य agents का audit करने वाले AI classifiers—की वकालत करते हैं, जबकि अन्य game design की खामियों की ओर इशारा करते हैं और इस बात पर ज़ोर देते हैं कि व्यवहार में एक “secure” AI agent को परिभाषित करना कितना कठिन है।
Human-in-the-Loop Permissions की प्रभावशीलता
- कई लोगों को “क्लिक करके मंज़ूरी देना” एक असफल सुरक्षा पैटर्न लगता है, जो OS permission dialogs और phishing training से दोहराया जा रहा है।
- उपयोगकर्ता “monitor blindness” विकसित कर लेते हैं और खासकर समय के दबाव में “yes” पर reflexively क्लिक करते हैं।
- कुछ का तर्क है कि 3 में 1 छूटा हुआ खतरा किसी भी गंभीर प्रक्रिया के लिए भयावह रूप से खराब है; जबकि अन्य कहते हैं कि परीक्षण में तनाव, सीमित संदर्भ, और गैर-विशेषज्ञ शामिल थे।
- कई लोग बताते हैं कि असली काम में, दुर्लभ खतरों के साथ लगातार prompts अंततः विफलता को लगभग सुनिश्चित कर देते हैं।
विकल्प: Auto-Mode, Classifiers, Sandboxing
- लोकप्रिय सुझाव: हर action पर automatic classifiers, अलग “auditor” models, और साथ में sandboxing (containers, VMs, microVMs, bytecode-level sandboxes)।
- कुछ लोग पहले से agents को unprivileged users के रूप में, VMs के अंदर, restricted network और filesystem के साथ, या ऐसे products में चलाते हैं जो centrally enforce करते हैं कि agents किससे बात कर सकते हैं।
- अन्य लोग कहते हैं कि यदि किसी भी network access की अनुमति है तो exfiltration को मूल रूप से रोकना बहुत कठिन है; sandbox escapes और supply-chain attacks अब भी चिंता का विषय हैं।
एक गंभीर Agent Security Model कैसा होगा?
- कई टिप्पणीकार कहते हैं कि यह स्पष्ट नहीं है कि web, files, और tools तक उपयोगी access बनाए रखते हुए “secure agent” को कैसे परिभाषित किया जाए।
- साधारण “command X allow करें?” prompts को गलत abstraction माना जाता है; file- और capability-based models, blast-radius containment, और time-based controls प्रस्तावित किए जाते हैं।
- कुछ लोग इसे ऐसे human operator को secure करने जैसा मानते हैं जिसकी risk tolerance अनंत हो और self-preservation न हो।
Capability-Based Security और Languages
- OS और language level दोनों पर capability-based security में गहरी रुचि है, ताकि code (जिसमें agent-written code भी शामिल है) क्या कर सकता है, उसे constrain किया जा सके।
- समर्थक capabilities को fine-grained, transitive permissions के रूप में वर्णित करते हैं, जो supply-chain risk को कम कर सकती हैं और कई libraries को inherently non-dangerous बना सकती हैं।
Liability, UX, और “Moral Crumple Zones”
- कई लोग permission prompts और warnings को liability shields मानते हैं: जब systems fail हों तो blame users या low-level operators पर डालना।
- “moral crumple zones” और “accountability sinks” जैसे concepts का उपयोग complex automated systems में humans के blame absorb करने का वर्णन करने के लिए किया जाता है।
Game और Data की आलोचनाएँ
- कई लोगों का कहना है कि यह game timed है, इसके कोई वास्तविक परिणाम नहीं हैं, और कभी-कभी commands को ऐसे dangerous label करता है जिनसे वे असहमत हैं या जो missing context पर निर्भर करते हैं।
- फिर भी अन्य लोग इसमें मूल्य देखते हैं: toy setting में भी यह दिखाता है कि command-level review कितना कठिन और थका देने वाला है, और इंसान सूक्ष्म खतरों को कितनी आसानी से चूक जाते हैं।