एआय एजंटला काय स्पर्श करण्याची परवानगी आहे हे ठरवणे: परवानग्या सीमा जी वाईट दिवस टिकते

एआय एजंटबद्दलचा मनोरंजक प्रश्न "आम्ही ते कार्य करू शकतो का?" हे "ज्या दिवशी चूक झाली त्या दिवशी पुनर्प्राप्ती कशी दिसते?"

एआय एजंट परवानग्यांबद्दल बहुतेक लेखन हे एकतर ओळख-व्यवस्थापन विक्रेता सामग्री (ओक्टा-आकाराचे आकृत्या, स्कोप टेबल्स, ओडब्ल्यूएएसपी वर्गीकरण) किंवा एंटरप्राइझ-सुरक्षा अनुपालन फ्रेमिंग (SOC 2 पुरावे, EU AI कायदा क्रॉस-रेफरेंस) आहे. दोन्ही योग्य संदर्भात उपयुक्त आहेत आणि ज्या दिवशी एखाद्या लहान ऑपरेटरला त्यांच्या गिट रेपॉजिटरी किंवा त्यांच्या थेट उत्पादन साइटची चावी दिली जाते त्या दिवशी त्यांना खरोखर काय आवश्यक असते. त्यांना एक निर्णय फ्रेमवर्क आवश्यक आहे जे एजंट करू शकणाऱ्या प्रत्येक कृतीसाठी प्रामाणिकपणे एका प्रश्नाचे उत्तर देते: वाईट दिवशी सर्वात वाईट प्रशंसनीय परिणाम काय आहे आणि त्यातून पुनर्प्राप्ती कशी दिसते?

ही पोस्ट ही फ्रेमवर्क आहे, जे प्रत्यक्षात हस्तांतरित एजंट्सना या वेबसाइटवर प्रवेश लिहिण्यापासून लिहिलेले आहे. खाली दिलेली प्रत्येक गोष्ट एकतर मी करत असलेले काहीतरी आहे किंवा मी ठरवले आहे की ते करण्याची पुनर्प्राप्ती किंमत सुविधेचे समर्थन करण्यासाठी खूप जास्त आहे. ही सुरक्षा-विक्रेता खेळपट्टी नाही आणि ती तुम्हाला पॉलिसी इंजिन विकत नाही.

"किमान विशेषाधिकार" हा चुकीचा पहिला प्रश्न का आहे

इंडस्ट्री-स्टँडर्ड फ्रेमिंग least privilege आहे : एजंटला जे आवश्यक आहे तेच द्या. हे एक चांगले तत्व आहे परंतु ते खूप उशीरा आहे. ते उत्तर देते "किती प्रवेश?" प्रथम उत्तर न देता "कोणत्या वर्गाची कृती कोणत्याही स्तरावर प्रवेश देणे सुरक्षित आहे?"

लहान ऑपरेटरला खरोखर मदत करणारा ऑर्डर आहे:

1. ब्लास्ट त्रिज्यानुसार क्रियेचे वर्गीकरण करा. ते केले जाऊ शकते की नाही यावरून नाही — API चे समर्थन करणारे काहीही केले जाऊ शकते — परंतु ती चूक झाल्यास काय होते आणि पूर्ववत केले जाऊ शकत नाही. बहुतेक परवानग्यांचे निर्णय येथूनच सुरू झाले पाहिजेत आणि जिथे ते जवळजवळ कधीच करत नाहीत. 2. कृती एखाद्या वर्गाशी संबंधित आहे की नाही हे ठरवा तुम्ही एजंटना अजिबात करू द्याल. काही वर्ग तसे करत नाहीत, टोकन कितीही कठोरपणे व्यापलेले असले तरीही. 3. केवळ , पहिल्या दोन गेट्स पास करणाऱ्या कृतींसाठी, विशिष्ट स्कोप आणि टोकनसाठी कमीत कमी विशेषाधिकार लागू करा.

चरण 1 आणि 2 वगळणे म्हणजे तुम्ही एजंटसह कसे समाप्त करता ज्याला "फक्त त्या एका फोल्डरसाठी हटविण्याची परवानगी आवश्यक आहे" आणि वाईट दिवसानंतर तुम्ही परत मिळवू शकत नाही असे काहीतरी काढून टाकले आहे.

ब्लास्ट-रेडियस वर्गीकरण जे इतर सर्व काही ठरवते

कृतीचे मूलत: चार वर्ग आहेत, आणि एजंटने कधीही कृतीला स्पर्श केला पाहिजे की नाही हे निर्धारित करते, API च्या व्याप्ती सूचीला नाही.

वर्ग १ — एजंट स्वतःच, काही सेकंदात उलट करता येईल. एजंट मसुदा संपादित करतो. एजंट एक क्वेरी चालवतो आणि निकालाची तपासणी करतो. एजंट एजंटच्या मालकीच्या फाइलमध्ये सामग्री तयार करतो. वर्ग 1 च्या खराब कृतीतून पुनर्प्राप्ती म्हणजे एजंट पुन्हा प्रयत्न करतो. कोणतीही अर्थपूर्ण स्फोट त्रिज्या नाही कारण कारवाईने एजंटचा स्वतःचा सँडबॉक्स कधीही सोडला नाही. हे मुक्तपणे द्या; असे न केल्याने एआय एजंट निरुपयोगी वाटतात.

वर्ग २ — माणसाद्वारे मिनिटांत उलट करता येणार आहे. एजंट गिट करण्यासाठी वचनबद्ध आहे. एजंट एका शाखेत ढकलतो. एजंट CMS वर मसुदा अपलोड करतो. एजंट "पाठवण्याआधी पुनरावलोकन" रांगेत ईमेल लावतो. पुनर्प्राप्ती ही आहे की मानवी लक्षात येते, परत येते किंवा पुनरावलोकन करते. ब्लास्ट त्रिज्या खरी आहे पण बाउंडेड — वाईट कमिट ही वाईट कमिट आहे आणि git revert हे एक वास्तविक उत्तर आहे ज्याची किंमत सुमारे तीन मिनिटे आहे. मानवी लक्षात येऊ देणाऱ्या ऑडिट ट्रेलसह हे मंजूर करा.

वर्ग ३ — तासांत किंवा दिवसांत उलट करता येणार आहे, वास्तविक खर्चावर. एजंट सार्वजनिकपणे पोस्ट करतो. एजंट वास्तविक यादीला ईमेल पाठवतो. एजंट थेट उत्पादन डेटाबेस सुधारित करतो. पुनर्प्राप्ती ही आहे की मानवी लक्षात येते आणि एखादी कृती करते ज्याचे स्वतःच परिणाम होतात (सार्वजनिक पोस्ट हटवणे, एक सुधारणा ईमेल पाठवणे, स्थलांतर परत करणे). विशिष्ट क्रियेची स्फोट त्रिज्या लहान असेल तरच हे मंजूर करा आणि ऑडिट ट्रेल तुम्हाला काही मिनिटांत वाईट केस पकडू देते, तासांत नाही.

वर्ग ४ — अपरिवर्तनीय, किंवा केवळ व्यवसाय-बदलाच्या खर्चावर उलट करता येण्याजोगे. एजंट ग्राहक रेकॉर्ड हटवतो. एजंट पैसे हलवतो. एजंट खाते क्रेडेंशियल बदलतो. एजंट काहीतरी पोस्ट करतो जे सुधारणे उतरण्यापूर्वी वायरद्वारे उचलले जाते. पुनर्प्राप्ती अशी आहे की तुम्ही माफी मागण्यासाठी किंवा पैसे भरण्यात एक आठवडा घालवला आणि ट्रस्टची किंमत कायम आहे. हे देऊ नका. कधी. एजंट कितीही सक्षम असला, टोकनची व्याप्ती कितीही कमी असली तरीही. वर्ग 4 ची क्रिया स्वयंचलित करण्याच्या सुविधेला ती एकदा चुकीची ठरवण्याची किंमत कधीच नाही.

वर्गांमधील रेषा सराव मध्ये अस्पष्ट नाहीत. त्यांना अस्पष्ट वाटणारी गोष्ट म्हणजे उद्योग तुम्हाला अशी साधने विकतो जी तांत्रिकदृष्ट्या प्रत्येक कृती करू शकतात आणि तुम्हाला कोणती ते ठरवू देतात. वरील वर्गीकरण हा प्री-टूल निर्णय आहे — तुम्ही वर्ग 4 क्रियेला स्पर्श करू शकणाऱ्या कोडची एक ओळ लिहिण्यापूर्वी, कृती कोडमध्ये अजिबात आहे की नाही हे स्वतःला विचारा.

ज्या विशिष्ट गोष्टी मी माझ्या एजंटना करू देतो

ठोसतेसाठी, मी या साइटवर दिलेली अचूक स्कोप येथे आहे, वरील वर्गांमध्ये मॅप केलेली आहे. हे टेम्प्लेट नाही — तुमचे ऑपरेशन वेगळे आहे — पण हे फ्रेमवर्कचे काम केलेले उदाहरण आहे.

वर्ग १, मंजूर: जे काही वाचते. रेपो फाइल्स वाचा, साइटमॅप वाचा, डिप्लॉय लॉग वाचा, डायजेस्ट वाचा, वर्कलिस्ट वाचा, बॅकलॉग वाचा. प्रकाशन एजंट शक्य ते सर्व वाचतो, सर्व वेळ, आणि कोणताही पुनर्प्राप्ती खर्च नाही कारण वाचन काहीही बदलत नाही.

वर्ग 1, मंजूर: एजंटच्या सेशनच्या मालकीच्या आणि कमिट करण्यापूर्वी तपासलेल्या फाइल्सवर लिहिणारे काहीही. मसुदा पोस्ट, व्युत्पन्न कव्हर्स, व्युत्पन्न केलेले OG कार्ड, अपडेट केलेला बॅकलॉग मेटाडेटा. वाईट केस एक वाईट मसुदा आहे; पुनर्प्राप्ती "फाइल हटवा, पुन्हा प्रयत्न करा" आहे.

वर्ग २, मंजूर: बिल्ड गेट पास झाल्यावर main ला कमिट करते. हे महत्वाचे आहे. npm run build शून्य परतावा या विशिष्ट अटीवर, मानवी पुनरावलोकनाच्या पायरीशिवाय, क्लाउडफ्लेअर पेजेस तैनात केलेल्या शाखेत लिहिण्याची क्षमता मी एजंटला स्पष्टपणे देतो. बिल्ड गेट हे क्लास 3 ऐवजी क्लास 2 ची क्रिया बनवते: तुटलेली तैनाती check-posts , check-links आणि check-search द्वारे पकडली जाते आणि गेट्समधून जाणारी खराब कमिट काही मिनिटांतच git revert -सक्षम असते.

वर्ग २, मंजूर: origin/main वर ढकलतो. समान तर्क — उपयोजित पाइपलाइनचे दूरवर स्वतःचे बिल्ड गेट आहे आणि क्लाउडफ्लेअर पृष्ठे रोलबॅकसाठी मागील उपयोजन राखून ठेवतात. एक क्लिक कोणत्याही एकल उपयोजन पूर्ववत करते.

वर्ग २, मंजूर: कमिट तयार करण्यासाठी, समस्या उघडण्यासाठी, वर्कलिस्टवर समस्या स्थिती अपडेट करण्यासाठी GitHub API कॉल करते. हे सर्व रेपो इतिहासात ऑडिट करण्यायोग्य आहेत आणि हाताने पूर्ववत करता येणार नाहीत.

वर्ग 3, विचारात घेतले आणि मंजूर केले नाही: माझ्या नावाखाली लिंक्डइन किंवा कोणत्याही सामाजिक प्लॅटफॉर्मवर प्रकाशित करणे. LinkedIn वरील खराब पोस्टची पुनर्प्राप्ती किंमत ही एक हटविलेली पोस्ट आहे ज्याने ती पाहिली त्या प्रत्येकाने स्क्रीनशॉट देखील शेअर केला आहे, तसेच एक प्रतिष्ठित कर आहे. "लिंक्डइन अपडेट म्हणून लेख पोस्ट करा" स्वयंचलित करण्याची सोय त्या लायक नाही. साइटचे AUTOMATION-PLAN दस्तऐवज स्पष्टपणे सांगते "ते LinkedIn किंवा ईमेलला स्पर्श करत नाही" असे हे विशिष्ट कारण आहे — वर्ग विचारात घेतला गेला आणि नाकारला गेला, फक्त पूर्ववत सोडला गेला नाही.

वर्ग ३, विचारात घेतले आणि मंजूर केले नाही: वृत्तपत्र सूचीवर ईमेल पाठवणे. समान तर्क. खराब ईमेलमधून वास्तविक सूचीमध्ये पुनर्प्राप्ती ही एक सुधारणा ईमेल आहे जी लोक "हे लोक त्यांची प्रणाली सरळ ठेवू शकत नाहीत" म्हणून देखील वाचतात, तसेच कायमस्वरूपी सदस्यत्व रद्द करतात. जेव्हा एखादी मानवी क्लिक पाठवते तेव्हा वृत्तपत्रे पाठवली जातात.

वर्ग 4, हार्ड-ब्लॉक: कोणतीही प्रकाशित पोस्ट हटवणे, कोणतेही सदस्य रेकॉर्ड हटवणे, _headers , _redirects , functions/ , functions/ किंवा package.json अवलंबित्वांमध्ये बदल स्पष्टपणे पुनर्विलोकन न करता. एजंट हे प्रपोज करू शकतो — रन लॉग एंट्रीमध्ये — पण त्यांना उतरवणारी कमिट मी वाचलेली असावी, एजंटने लिहिलेली नाही. हे एजंटवर एक वास्तविक घर्षण आहे आणि ते मला हवे आहे.

क्लास ४, हार्ड-ब्लॉक केलेले: क्लाउडफ्लेअर खाते सेटिंग्ज, DNS किंवा प्रवेश नियमांशी संबंधित काहीही. खाते क्रेडेन्शियल्स एजंटच्या वातावरणात अजिबात नाहीत. जर त्यांना बदलण्याची गरज असेल तर मी त्यांना बदलतो.

एजंटला कोणतीही कारवाई मंजूर करण्यापूर्वी विचारायचे दोन प्रश्न

नवीन क्षमता समाविष्ट करण्यासाठी तुम्ही एजंटच्या परवानग्या वाढवण्याआधी, प्रत्येकी एका परिच्छेदात या दोन्ही गोष्टींना उत्तर देण्यास भाग पाडा. चेकलिस्ट नाही — वास्तविक वाक्ये.

प्रश्न 1: या क्रियेचा सर्वात वाईट प्रशंसनीय परिणाम कोणता आहे, आणि पुनर्प्राप्तीसाठी किती वेळ लागतो? सरासरी परिणाम नाही; सर्वात वाईट प्रशंसनीय. तुमच्या लक्षात येण्यापूर्वी एजंट सैद्धांतिकदृष्ट्या दहा हजार वेळा कारवाई करू शकत असल्यास, तो नंबर वापरा, एक नाही. "एजंट एक चुकीचा ईमेल पाठवू शकतो" ही ​​वर्ग 3 क्रिया आहे; "एजंट लूप करून एक हजार प्राप्तकर्त्यांना तोच चुकीचा ईमेल पाठवू शकतो आणि काहीही पकडण्याआधी" ही क्लास 4 क्रिया आहे. स्वायत्तता ही वर्ग बदलते.

प्रश्न 2: पुनर्प्राप्तीसाठी कोणत्या वर्गाची व्यक्ती आवश्यक आहे, आणि ते एखाद्या वाईट दिवशी उपलब्ध होणार आहेत का? पुनर्प्राप्तीसाठी 15 मिनिटांच्या आत तुम्हाला वैयक्तिकरित्या पोहोचणे आवश्यक आहे जी पुनर्प्राप्ती अजूनही वर्ग 2 क्रिया आहे ती खरोखर वर्ग 2 नाही — ती भाग्यवान वेळेची गृहीतक असलेली वर्ग 3 आहे. एखाद्या वाईट केसचे निराकरण करण्यासाठी इतर कोणाकडे क्रेडेन्शियल्स आहेत आणि ते किती विश्वासार्हपणे पोहोचू शकतात याबद्दल प्रामाणिक रहा.

जर तुम्ही दोन्ही प्रश्नांची उत्तरे तुमच्या स्वतःच्या समाधानासाठी प्रत्येक परिच्छेदात देऊ शकत नसाल, तर "मी कृती मंजूर करावी?" नाही आहे.

मी प्रत्यक्षात पाहिलेले तीन अपयश मोड

अयशस्वी मोड 1: "हे केवळ डेमोसाठी आहे." एजंटला विकासादरम्यान आवश्यकतेपेक्षा व्यापक परवानगी मिळते कारण ते सर्वकाही मंजूर करणे जलद असते आणि नंतर संकुचित होते. मग डेमो कार्य करतो, डेमो स्टेजिंग बनतो, स्टेजिंग उत्पादन बनते आणि एजंटने एखाद्या केसला त्याच्या संकुचित-नंतर स्वत: ने नकार दिला असता तोपर्यंत परवानग्या कमी करणे कोणालाही आठवत नाही. पहिल्या ओळीपासून संकुचित करा, अगदी विकासादरम्यानही - यास सुरूवातीस दहा मिनिटे लागतात आणि गो-लाइव्ह नंतर ते अशक्य आहे कारण आता खरे काम त्यावर अवलंबून आहे.

अयशस्वी मोड 2: "व्याप्तिमध्ये विनाशकारी क्रियांचा समावेश नाही." GitHub च्या repo स्कोपमध्ये, उदाहरणार्थ, शाखा हटवणे, फोर्स-पुशिंग, फाइल्स हटवणे समाविष्ट आहे. हे वाचन-लेखनाच्या व्याप्तीसारखे दिसते आणि ते प्रत्यक्षात "या भांडारासाठी काहीही करा" स्कोप आहे. स्कोपच्या वास्तविक परवानग्या देण्यापूर्वी ते वाचा, स्कोपचे नाव नाही. बहुतेक OAuth स्कोप बंडल क्रियांचा कॉलर परवानगी देऊ इच्छित नाही; बंडलिंग हे आहे जेथे स्फोट त्रिज्या राहतात.

अयशस्वी मोड 3: "आम्ही नंतर देखरेख जोडू." ऑडिट ट्रेलशिवाय मंजूर केलेली कोणतीही वर्ग 2 किंवा वर्ग 3 परवानगी जी तुम्हाला वाईट कृती लक्षात येऊ देते ती शांतपणे वर्ग 4 ची क्रिया आहे, कारण कोणाच्या लक्षात येईपर्यंत पुनर्प्राप्ती घड्याळ सुरू होत नाही आणि जर कोणी लक्षात घेतले नाही तर पुनर्प्राप्ती होत नाही — फक्त जमा झालेले नुकसान आहे. ऑडिट ट्रेल ही कृती प्रमाणेच वर्गाची व्याख्या करते. हा what to log when an AI agent acts on your behalf मधील संपूर्ण युक्तिवाद आहे: लॉगिंग हे दस्तऐवजीकरण नाही, ते प्रतिबंधात्मक उपाय आहे.

"मनुष्य इथला आहे का?" प्रश्न

एकदा तुम्ही एखाद्या कृतीचे वर्गीकरण केले की, एक विशिष्ट निर्णय थिएटरपासून चांगल्या चालणाऱ्या ऑटोमेशनला वेगळे करतो: तुम्ही माणसाला लूपमध्ये ठेवता का?

उद्योग डीफॉल्ट आहे: होय, वर्ग 3 किंवा त्यावरील कोणत्याही गोष्टीवर. ते चुकीचे उत्तर आहे, आणि त्याच कारणासाठी "फक्त एक पुनरावलोकन पाऊल जोडा" हे चुकीचे उत्तर आहे इतर सर्वत्र अपयशी ठरते — ज्या माणसाला आठवड्यातून दोनशे गोष्टी मंजूर कराव्या लागतात ते नियंत्रण नाही, ते खुर्चीसह रबर स्टॅम्प आहेत. मानवी तपासणी केवळ तेव्हाच खरी आहे जेव्हा मनुष्य खरोखर वाईटातून चांगले आउटपुट सांगू शकतो आणि जर ते लक्ष देण्याइतके कमी असेल तर.

सराव मध्ये कार्य करणारे दोन नियम:

1. मानवी तपासणी हे केवळ एक नियंत्रण असते जेव्हा मनुष्य नकार देऊ शकतो. जर नकार देणे महाग असेल (रिलीझला अडथळा आणतो, क्लायंटला विलंब होतो, म्हणजे एक कठीण संभाषण), मानव नियमितपणे नकार देत नाही, म्हणून चेक थिएटर आहे. जर पुनरावलोकनकर्त्याचे काम योग्य असेल, लोकप्रिय होण्यासाठी नाही आणि नकार देणे खरोखर विनामूल्य असेल तर - चेक कार्य करते. 2. आठवड्यातून 20 वस्तूंवर मानवी तपासणी हे एक नियंत्रण आहे; आठवड्यातून 200 वस्तूंवर मानवी तपासणी नाही. उंबरठ्याच्या खाली, मानव लक्ष देतात. वर, ते वाचणे बंद करतात. थ्रेशोल्ड कार्यानुसार बदलते परंतु बहुतेक प्रणालींनी गृहीत धरले त्यापेक्षा ते खूपच कमी आहे — मी वापरतो "जर मी यापैकी प्रत्येक वैयक्तिकरित्या उघडले तर ते थ्रेशोल्डच्या खाली आहे; जर मी स्किम केले तर ते नाही".

जिथे मानवी तपासणी थिएटर आहे, तिथे प्रामाणिक उत्तर "एक चांगली चेकलिस्ट जोडा" नाही. हे एकतर आहे: विशिष्ट निर्णय पूर्णपणे स्वयंचलित करा (चेक मूल्य जोडत नाही; तो काढून टाका), किंवा जोपर्यंत माणूस प्रत्यक्षात तो करू शकत नाही तोपर्यंत आवाज कमी करा (चेक महत्वाचे आहे; व्हॉल्यूम ही समस्या आहे, चेक नाही). रबर-स्टॅम्प स्टेपसह ऑटोमेशन एक नसलेल्या ऑटोमेशनपेक्षा वाईट आहे, कारण स्टेपची उपस्थिती त्या डिझाइनपासून दोष दूर करते ज्यामुळे आवाज खूप जास्त झाला.

परवानग्या निर्णयासाठी आवश्यक असलेल्या विशिष्ट कलाकृती

तुम्ही एजंटला दिलेल्या प्रत्येक कृती वर्गासाठी, तीन विशिष्ट कलाकृती अस्तित्वात असणे आवश्यक आहे. तिघांपैकी कोणीही गहाळ असल्यास, परवानगी जबाबदारीने दिली गेली नाही - ती आशावादीपणे मंजूर केली गेली आहे.

आर्टफॅक्ट १ — एजंटच्या बाहेरून ऑडिट ट्रेल. एजंटने काय केले याचा स्वतःचा लॉग नाही. एक बाह्य रेकॉर्ड — एक गिट इतिहास, एक API प्रतिसाद लॉग, संदेश आयडी असलेली ईमेल रांग — जी एजंट मरत असताना, प्रक्रिया मारली जाते, मशीनची शक्ती गमावते. कृतीचा खरा पुरावा अभिनेत्याच्या बाहेर राहतो. what to log when an AI agent acts on your behalf मध्ये संपूर्ण युक्तिवाद पहा; अगदी लहान आवृत्ती अशी आहे की एजंट त्याच्या स्वतःच्या कृतींचा सर्वात कमी विश्वासार्ह साक्षीदार आहे.

आर्टफॅक्ट 2 — पुनर्प्राप्ती प्रक्रिया, लिहून ठेवली आहे. प्रति कृती वर्ग एक-परिच्छेद दस्तऐवज जो म्हणतो: "जर क्रिया X चुकीची झाली, तर त्या क्रमाने Y आणि Z करा आणि W मिनिटांमध्ये पुनर्प्राप्ती पूर्ण होण्याची अपेक्षा करा." प्रक्रिया अस्तित्वात नसल्यास, क्रिया खरोखर पुनर्प्राप्त करण्यायोग्य नाही - ती पुनर्प्राप्त केलेली नाही परंतु अद्याप सापडलेली नाही. तुम्ही पहिल्यांदा परवानगी द्याल त्याआधी प्रक्रिया लिहा, तुम्हाला पहिल्यांदा गरज पडल्यानंतर नाही.

आर्टफॅक्ट 3 — किल स्विच. एकल नावाची जागा जिथे तुम्ही काही सेकंदात ही क्रिया करण्याची एजंटची क्षमता रद्द करू शकता. माझ्यासाठी, या साइटवर, किल स्विच हे आहेत: GitHub OAuth टोकन फिरवणे (सर्व लेखन प्रवेश नष्ट करणे), Cloudflare API टोकन फिरवणे (डिप्लॉय व्हेरिफिकेशन नष्ट करणे) आणि डेली-रन क्रॉन अक्षम करणे (ट्रिगर मारणे) वर सेट करणे. तिन्ही डॉक्युमेंटेड आहेत, तिन्ही प्रत्येकी एक कमांड आहेत आणि तिन्ही गोष्टी मी किमान एकदा वापरल्या आहेत.

रिअल किल स्विचशिवाय, परवानगी ही परवानगी नाही - ही एक चांगली गोष्ट आहे. एका मिनिटात तुम्ही रद्द करू शकत नाही असे काहीही देऊ नका.

सर्वात कठीण एक: उभे राहणे विरुद्ध फक्त वेळेत परवानग्या

एजंट परवानग्यांमधील सर्वात सामान्य चूक म्हणजे क्लास 3 क्रियेसाठी स्थायी प्रवेश मंजूर करणे जेणेकरून एजंट "आवश्यकतेनुसार ते हाताळू शकेल". स्थायी परवानग्या वर्ग 3 क्रिया वर्ग 4 च्या समस्यांमध्ये बदलण्याचे कारण आहे: स्थायी विशेषाधिकारावर बसलेला निष्क्रिय किंवा तडजोड केलेला एजंट निष्क्रिय नाही — ते उघड झाले आहे. म्हणूनच Microsoft's own guidance आणि industry security research on AI agent identities दोन्ही एकाच शिफारशीवर एकत्रित होतात: लहान TTL आणि स्वयंचलित रद्दीकरणासह, त्यांना आवश्यक असलेल्या क्षणीच उन्नत परवानग्या द्या.

जस्ट-इन-टाइम मॉडेल असे आहे: एजंट जेव्हा गरज असेल तेव्हा परवानगी मागतो, काही महिन्यांत नव्हे तर काही मिनिटांत मोजले जाणारे आजीवन टोकन मिळते आणि एजंटला ते वापरायचे आहे की नाही हे टोकन कालबाह्य होते. एजंटला पुढील तासासाठी परवानगीची आवश्यकता नसल्यास, कोणतेही एक्सपोजर अस्तित्वात नाही. जर एजंटने त्या तासात तडजोड केली असेल, तर हल्लेखोराला एक टोकन वारसा मिळतो जे ते पिव्होट करण्यापूर्वी कालबाह्य होते.

हे सेट करण्यासाठी अधिक काम आहे. वाईट दिवस टिकून राहणाऱ्या परवानगी मॉडेलमध्ये आणि वाईट दिवसाला वाईट तिमाहीत बदलणाऱ्या मॉडेलमधील फरक देखील आहे. जर तुम्ही तुमच्या एजंटसाठी फक्त एक अस्पष्ट पायाभूत सुविधा तयार करणार असाल, तर ते आहे.

पुढील मंगळवारी काय करायचे

तुम्ही तुमच्या स्वतःच्या सिस्टीमवर एजंट आधीच चालवत असल्यास, या आठवड्यात खालील दोन व्यायाम करा.

व्यायाम १. तुमचा एजंट सध्या करू शकणारी प्रत्येक कृती लिहा. साधनांची नावे नव्हे - क्रिया. "गिट करण्यासाठी वचनबद्ध आहे." "माझ्या विश्लेषण एंडपॉइंटवर HTTP POST पाठवा." "डेटाबेस पंक्ती वाचा." "डेटाबेस पंक्ती लिहा." प्रत्येकासाठी, वरील वर्गीकरणावरून वर्ग चिन्हांकित करा.

व्यायाम 2. यादीतील प्रत्येक वर्ग 3 किंवा वर्ग 4 क्रियेसाठी, तीन-आर्टिफॅक्ट चाचणीचे उत्तर द्या: बाहेरून ऑडिट ट्रेल, लिखित पुनर्प्राप्ती प्रक्रिया, किल स्विच. तिघांपैकी कोणत्याहीवर अयशस्वी होणारी कोणतीही कृती, एकतर कृती अवनत करा (कलाकृती अस्तित्त्वात येईपर्यंत परवानगी रद्द करा) किंवा पुढील धावण्यापूर्वी कलाकृती तयार करण्यासाठी वेळ द्या.

जर व्यायामाला एक तास लागला, तर तुमचे एक छोटे ऑपरेशन आहे आणि हे एक तासाचे आहे. यास एक आठवडा लागल्यास, तुमचे ऑपरेशन मोठे आहे आणि आता ते करण्यास उशीर हा पहिल्या वाईट दिवसाच्या खर्चापेक्षा कमी आहे ज्यासाठी तुम्ही तयारी केली नाही.

हे बाकीच्या कामात कुठे बसते

परवानग्या सीमा ही अप्राप्य एजंट चालवण्याची प्रतिबंधक बाजू आहे. ऑडिट ट्रेल ही डायग्नोस्टिक बाजू आहे, what to log when an AI agent acts on your behalf मध्ये — लॉग तुम्हाला सांगतो का एजंटने काय केले; परवानग्या म्हणजे काय मर्यादा काय एजंट अजिबात करू शकला असता. ते एकत्रितपणे स्वायत्त प्रणाली कार्यक्षम बनवतात.

तुमची समस्या अपस्ट्रीम असल्यास — एजंटला कोणती कामे सोपवायची हे तुम्ही अद्याप ठरवलेले नाही — how to automate your work with AI मधील फ्रेमिंग हा पूर्वीचा प्रश्न आहे. आणि जर तुमचा विशिष्ट अयशस्वी मोड वर्कफ्लो असेल जो हिरवा चालतो आणि काहीही करत नाही — एक मूक वर्ग 2 क्रिया पूर्ण झाल्याचे भासवत — निदान the automation failure nobody catches मध्ये आहे.

वारंवार विचारले जाणारे प्रश्न

जस्ट-इन-टाइम एजंट टोकन किती काळ जगला पाहिजे?

विशिष्ट कृतीसाठी पुरेसा लांब, आणि यापुढे नाही. कमिट आणि पुश सायकलसाठी जे मिनिटे आहेत; लूपमध्ये चालणाऱ्या बॅच जॉबसाठी, ही लूपची लांबी आणि लहान बफर असते. जर तुम्ही काही मिनिटांत नंबर सांगू शकत नसाल, तर टोकन म्हणजे पोशाख घालून स्टँडिंग ऍक्सेस.

मी प्रत्येक वर्ग 3 क्रियेवर मानवी पुनरावलोकनाची पायरी टाकावी किंवा ती पूर्णपणे स्वयंचलित करावी?

डीफॉल्टनुसार नाही. जर समीक्षक शिक्षेशिवाय खऱ्या अर्थाने नकार देऊ शकत असेल आणि प्रत्येक आयटम वाचण्याइतपत आवाज कमी असेल तर पुनरावलोकन ठेवा. अन्यथा एक निवडा: निर्णय पूर्णपणे स्वयंचलित करा किंवा पुनरावलोकन वास्तविक होईपर्यंत आवाज कमी करा. रबर-स्टॅम्पची पायरी कोणत्याही पायरीपेक्षा वाईट असते कारण ती जबाबदारी कमी करते.

माझ्या एजंटला एका विशिष्ट एज केससाठी वर्ग 4 ची परवानगी हवी असल्यास काय?

मग ती धार केस स्वयंचलित नाही. एजंट कृती तयार करू शकतो, विनंती लॉग करू शकतो आणि मानवी पृष्ठ करू शकतो — परंतु कमिट, पाठवणे किंवा हटवणे हे मानवाकडून केले जाते. एक वर्ग 4 केस स्वयंचलित करण्याची सोय ही सर्व कार्यान्वित करू शकतील असे प्लंबिंग बांधण्यासाठी कधीही फायदेशीर नाही.

एका एजंट टोकनसाठी किती क्रिया आहेत?

वर्ग मोजा, ​​क्रिया नाही. वर्ग 1 आणि वर्ग 2 क्रियांचे कोणतेही मिश्रण असलेले एक टोकन ठीक आहे; वर्ग 2 आणि वर्ग 3 मध्ये पसरलेला एकच टोकन आहे जेथे ब्लास्ट त्रिज्या शांतपणे रेंगाळते, कारण दोघांसाठी ऑडिट अपेक्षा भिन्न आहेत. वर्गाच्या सीमांसह टोकन विभाजित करा, वैशिष्ट्याच्या सीमांसह नाही.

एजंट फक्त वेळापत्रकानुसार चालत असल्यास मला किल स्विचची आवश्यकता आहे का?

होय. एक शेड्यूल्ड एजंट जो आधीच काढून टाकला आहे आणि मिड-लूप आहे तो नक्की जेव्हा तुम्हाला ऍक्सेस मागे घ्यायचा असेल आणि "पुढील विंडोची वाट पहा" हा किल स्विच नाही. टोकन फिरवणे किंवा ट्रिगर अक्षम करणे ही एकच दस्तऐवजीकरण केलेली कमांड नसेल, जी तुम्ही किमान एकदा चालवली असेल, तर तुमच्याकडे ती नाही.

एजंटने स्वतःचे ऑडिट लॉग लिहावे की मी बाह्य प्रणालींवर अवलंबून राहावे?

बाह्य प्रणाली. एजंट त्याच्या स्वतःच्या कृतींचा सर्वात कमी विश्वासार्ह साक्षीदार असतो - क्रॅश झालेला, मारला गेला किंवा तडजोड केलेला एजंट त्याचा लॉग लिहिणे पूर्ण करणार नाही. Git हिस्ट्री, API प्रतिसाद लॉग आणि मेसेज क्यू एजंट मरताना टिकून राहतात; एजंटचा स्वतःचा लॉग ही एक सोय आहे, पुरावा नाही.

मी आधीच दिलेल्या परवानग्यांचे ऑडिट करण्याचा जलद मार्ग कोणता आहे?

एजंट सध्या साध्या इंग्रजीत करू शकत असलेल्या प्रत्येक क्रियेची यादी करा, वर्गीकरणातील प्रत्येक वर्गासह चिन्हांकित करा आणि प्रत्येक वर्ग 3 किंवा वर्ग 4 ओळीसाठी तीन कलाकृती तपासा — बाह्य ऑडिट ट्रेल, लेखी पुनर्प्राप्ती प्रक्रिया, वन-कमांड किल स्विच. कलावस्तू गहाळ असलेली कोणतीही पंक्ती कलाकृती अस्तित्वात असेपर्यंत रद्द केली जाते. या कामाचा एक तास तुम्ही तयार न केलेल्या पहिल्या वाईट दिवसापेक्षा स्वस्त आहे.

एक-वाक्य आवृत्ती

प्रत्येक एजंट क्रियेचे तुम्ही व्याप्तीनुसार वर्गीकरण करण्यापूर्वी स्फोट त्रिज्यानुसार वर्गीकरण करा; टोकन कितीही घट्ट असले तरीही वर्ग 4 क्रियांना पूर्णपणे नकार द्या; तीन कलाकृतींची आवश्यकता आहे — बाह्य ऑडिट ट्रेल, लेखी पुनर्प्राप्ती प्रक्रिया, वन-कमांड किल स्विच — तुम्ही मंजूर केलेल्या प्रत्येक वर्ग 2 आणि वर्ग 3 परवानगीसाठी; आणि जेव्हा योग्य वेळेत होईल तेव्हा वर्ग 3 क्रियेसाठी कधीही स्थायी प्रवेश मंजूर करू नका. परवानग्या मॉडेल जे वाईट दिवस टिकून राहते ते वाईट दिवसाभोवती डिझाइन केलेले असते, चांगले नाही.