एजंटवर विश्वास ठेवणे थांबवा: मंजुरीला (Approvals) नेमक्या टूल कॉल्सशी (Tool Calls) जोडा
बहुतेक एजन्टिक सिस्टिम्स (agentic systems) फाईल लिहिणे किंवा पैसे हस्तांतरित करणे यांसारख्या धोकादायक कृतींना केवळ एका साध्या मंजुरीने (approval) सुरक्षित ठेवतात.
सहसा, ही मंजुरी सिस्टिम स्टेटमधील एक बुलियन फ्लॅग (boolean flag) असते.
उदाहरण: approved: true.
ही एक चूक आहे. बुलियन तीन प्रकारे अपयशी ठरते ज्याचा फायदा हल्लेखोर (attackers) घेऊ शकतात:
- फ्लिप (Flip): एखादा हल्लेखोर प्रॉम्प्ट इंजेक्शन (prompt injection) किंवा कोडमधील त्रुटींद्वारे स्टेट 'false' वरून 'true' मध्ये बदलू शकतो.
- रिप्ले (Replay): तुम्ही "read file" सारखी सुरक्षित कमांड मंजूर करता. सिस्टिम "true" पाहते आणि "delete database" सारखी दुसरी, धोकादायक कमांडला परवानगी देते.
- आर्ग्युमेंट ड्रिफ्ट (Argument Drift): तुम्ही "$10 पाठवा" मंजूर करता. अंमलबजावणीपूर्वी (execution) एखादा हल्लेखोर ती रक्कम $10,000 मध्ये बदलतो. फ्लॅग अजूनही "true"च दर्शवतो.
समस्या अशी आहे की तुम्ही मंजुरीला संपूर्ण सेशनचा (session) एक गुणधर्म म्हणून मॉडेल करत आहात. ती एका विशिष्ट कॉलसाठी पुरावा (evidence) असणे आवश्यक आहे.
हे कसे सुधारावे:
जेव्हा एखादी व्यक्ती कॉल मंजूर करते, तेव्हा एक सुरक्षित टॅग (secure tag) तयार करा. या टॅगमध्ये या चार गोष्टी लॉक होणे आवश्यक आहे:
- युनिक टूल कॉल आयडी (unique tool call ID).
- नेमक्या आर्ग्युमेंट्सचा (arguments) हॅश (hash).
- वापरकर्त्याची ओळख (user identity).
- एक्सपायरी वेळ (expiration time).
अंमलबजावणीच्या (execution) नेमक्या वेळी या टॅगची पडताळणी करा. फक्त सिस्टिमला माहित असलेली सिक्रेट की (secret key) वापरा.
अंमलबजावणीसाठी या नियमांचे पालन करा:
- कॅनोनायझेशन (Canonicalization) वापरा: मंजुरी देणारा आणि अंमलबजावणी करणारा या दोघांनीही नेमके तेच बाईट्स (bytes) हॅश केले पाहिजेत. नंबर आणि की (keys) मॅच होतील याची खात्री करण्यासाठी RFC 8785 वापरा.
- फेल क्लोज्ड (Fail Closed): जर टॅग गहाळ असेल, एक्सपायर झाला असेल किंवा चुकीचा असेल, तर एक विशिष्ट "not approved" एरर द्या. त्याला सामान्य टूल रिझल्ट (tool result) म्हणून मानू नका.
- बाय डिफॉल्ट नाकारणे (Deny by Default): केवळ स्पष्ट मंजुरी आवश्यक असलेल्या टूल्सनाच परवानगी द्या. बाकी सर्व नाकारा.
- रिप्ले हाताळा (Handle Replays): जर तुम्ही Temporal सारखी इंजिन्स वापरत असाल, तर तुमची सिक्रेट की डिटरमिनिस्टिक (deterministic) असल्याची खात्री करा. जर सिस्टिम रीस्टार्ट झाल्यानंतर की बदलली, तर सर्व विद्यमान मंजुरी (approvals) अयशस्वी होतील.
ऑथोरायझेशन (Authorization) हे स्टेटचा एखादा तरंगता भाग नसावा. ते एक बांधलेले पाकीट (bound envelope) असावे जे सिद्ध करते: "या विशिष्ट व्यक्तीने या विशिष्ट टूलसाठी, या विशिष्ट वेळेपर्यंत, या विशिष्ट आर्ग्युमेंट्सना मंजुरी दिली आहे."
बुलियन वापरणे थांबवा. ते सोपेपणाचे साधन नाहीत. ते एक बग (bug) आहेत.
पर्यायी लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi