Skip to main content
कस्टम नीतियां आपके ट्रेस या ऑडिट से एक विफलता पैटर्न को एक निर्णय में बदल देती हैं जो एजेंट काम करते समय चलता है। एक नीति एक कार्रवाई की अनुमति दे सकती है, एजेंट को मार्गदर्शन दे सकती है, या कार्रवाई को अस्वीकार कर सकती है इससे पहले कि यह एक और घटना का कारण बने। एक कस्टम नीति का उपयोग करें जब व्यवहार आपके टूल्स, पाथ्स, कमांड्स, एनवायरनमेंट्स या ऑपरेटिंग नियमों पर निर्भर करता है। पहले बिल्ट-इन नीति कैटलॉग देखें ताकि आप किसी मौजूदा नियंत्रण को फिर से न बनाएं।

कस्टम नीति बनाएं

  1. Admin → policy editor पर जाएं, New policy चुनें, और विफलता का वर्णन करें जिसे आप रोकना चाहते हैं।
  2. नीति स्रोत जोड़ें, फिर संपादक में अपेक्षित मिलान और सुरक्षित गैर-मिलान परीक्षण करें। हर सत्यापन त्रुटि को हल करें।
  3. ड्राफ्ट को सहेजें और एक अपरिवर्तनीय संस्करण बनाने के लिए Publish version चुनें।
  4. Admin → enforcement पर जाएं, संस्करण को observe मोड में एक परीक्षण मशीन पर तैनात करें, और इसे लागू करने से पहले Observe → policy के तहत इसके निर्णयों को सत्यापित करें। कस्टम नीति को बनाने और प्रकाशित करने के लिए उपयोग किया जाने वाला नीति संपादक।

एक संकीर्ण नियम से शुरू करें

यह नीति विनाशकारी Kubernetes कमांड्स को केवल तब ब्लॉक करती है जब कमांड उत्पादन को लक्षित करता है। उस सटीक विफलता मोड के बाहर सब कुछ allow() देता है।
अच्छी नीतियां इतनी संकीर्ण होती हैं कि एक वाक्य में समझाई जा सकें। अवलोकन योग्य कार्रवाई से मेल खाएं—न कि इस इरादे से जो आप उम्मीद करते हैं कि एजेंट ने किया हो—और जैसे ही नियम लागू न हो तुरंत allow() देता है।

एक निर्णय चुनें

एजेंट के लिए कारण लिखें जिसे ठीक करना होगा। समझाएं कि क्या पहचाना गया था और इसे इसके बजाय क्या करना चाहिए।
सुरक्षा सीमा के लिए instruct() का उपयोग न करें। गाइडेंस डिलीवरी एजेंट हार्नेस के अनुसार भिन्न होती है। deny() का उपयोग करें जब कार्रवाई को रोका जाना चाहिए।

नीति ऑब्जेक्ट

fn के अंदर टूल्स को फिल्टर करें। match.toolNames सार्वजनिक कस्टम-नीति प्रकार का हिस्सा नहीं है।

नीति संदर्भ

हर नीति को एक PolicyContext प्राप्त होता है। हर वैकल्पिक मान को वास्तव में वैकल्पिक मानें। एजेंट संस्करण और इवेंट प्रकार सभी समान फील्ड प्रदान नहीं करते हैं।

सामान्य टूल इनपुट

Failproof AI समर्थित हार्नेस में सामान्य टूल्स को सामान्यीकृत करता है ताकि एक नीति आमतौर पर एक इनपुट आकार का उपयोग कर सके। रक्षात्मक जबरदस्ती का उपयोग करें क्योंकि टूल इनपुट मान unknown के रूप में टाइप किए गए हैं:

इवेंट चुनें

इवेंट उपलब्धता और ब्लॉकिंग व्यवहार एजेंट हार्नेस पर निर्भर करते हैं। एक मिश्रित बेड़े में किसी इवेंट पर निर्भर करने से पहले Agent harnesses देखें।
SessionStart, SessionEnd, UserPromptSubmit, PreToolUse, PermissionRequest, PermissionDenied, PostToolUse, PostToolUseFailure, Notification, SubagentStart, SubagentStop, TaskCreated, TaskCompleted, Stop, StopFailure, TeammateIdle, InstructionsLoaded, ConfigChange, CwdChanged, FileChanged, WorktreeCreate, WorktreeRemove, PreCompact, PostCompact, Elicitation, ElicitationResult, UserPromptExpansion, PostToolBatch, और Setup

सामान्य नीति पैटर्न बनाएं

संरक्षित पाथ्स में लेखन ब्लॉक करें

गैर-ब्लॉकिंग गाइडेंस दें

सेशन समापन को गेट करें

एक अस्वीकृत Stop इवेंट एजेंट को दोबारा कोशिश करने के लिए बना सकता है। केवल एक ऐसी शर्त पर गेट करें जिसे एजेंट वर्तमान वातावरण में संतुष्ट कर सके, और हर सबप्रोसेस या नेटवर्क कॉल को सीमित करें।

नीति फाइलें लोड करें

परंपरा फाइलें

परंपरा फाइलें स्वचालित रूप से लोड होती हैं:
  • प्रोजेक्ट और उपयोगकर्ता नीति निर्देशिकाएं दोनों लोड होती हैं।
  • फाइलें प्रत्येक निर्देशिका के भीतर वर्णानुक्रमिक रूप से लोड होती हैं।
  • एक फाइल policies.js, policies.mjs, या policies.ts में समाप्त होनी चाहिए।
  • एक फाइल में एकाधिक customPolicies.add() कॉल समर्थित हैं।
  • स्थानीय मॉड्यूल्स से सापेक्ष आयात समर्थित हैं।
  • प्रोजेक्ट नीतियां प्रतिबद्ध की जा सकती हैं ताकि समान नियम रिपोजिटरी का अनुसरण करें।

स्पष्ट फाइलें

स्पष्ट पाथ्स का उपयोग करें जब सत्यापन या कॉन्फ़िगरेशन को प्रवेश फाइल को सीधे नाम देना चाहिए:
स्पष्ट फाइलें पहले लोड होती हैं, इसके बाद प्रोजेक्ट परंपरा फाइलें और फिर उपयोगकर्ता परंपरा फाइलें। दोनों पाथ्स के माध्यम से खोजी गई फाइल एक बार लोड होती है।

सत्यापित और परीक्षण करें

सत्यापन मॉड्यूल को प्रोडक्शन लोडर के माध्यम से निष्पादित करता है और पुष्टि करता है कि यह कम से कम एक नीति को पंजीकृत करता है।
सत्यापन लापता फाइलें, सिंटैक्स त्रुटियां, अनसुलझे आयात, शीर्ष-स्तरीय अपवाद और मॉड्यूल-लोड टाइमआउट को पकड़ता है। यह साबित नहीं करता है कि आपका मेल तर्क सही है। कम से कम ये मामले परीक्षण करें:
  • एक कार्रवाई जो मेल खानी चाहिए और इच्छित नीति कारण दे।
  • एक पास-पास लेकिन सुरक्षित कार्रवाई जो allow() देनी चाहिए।
  • लापता या विकृत टूल फील्ड्स।
  • वैकल्पिक कमांड सिंटैक्स, पाथ्स, उद्धरण, मामला और व्हाइटस्पेस।
  • एक अनुपलब्ध सबप्रोसेस या नेटवर्क निर्भरता।
परिणाम को Observe → policy के तहत आपकी कस्टम नीति के लिए जिम्मेदार ठहराएं। एक ब्लॉक किया गया परीक्षण पर्याप्त नहीं है यदि एक अलग बिल्ट-इन नीति ने निर्णय लिया।

रनटाइम व्यवहार

  • बिल्ट-इन नीतियां कस्टम नीतियों से पहले मूल्यांकन करती हैं।
  • पहला deny आगे की नीति मूल्यांकन को बंद करता है।
  • कई instruct परिणामों को जोड़ा जा सकता है जब कोई नीति इवेंट को अस्वीकार नहीं करती है।
  • एक नीति फंक्शन के पास 10-सेकंड का निष्पादन समय सीमा है।
  • एक फेंकी गई अपवाद या टाइमआउट को लॉग किया जाता है और allow() के रूप में माना जाता है।
  • एक परंपरा फाइल जो लोड करने में विफल हो जाती है को छोड़ दिया जाता है; अन्य कस्टम फाइलें और बिल्ट-इन नीतियां जारी रहती हैं।
  • शीर्ष-स्तरीय मॉड्यूल लोडिंग के पास भी 10-सेकंड की समय सीमा है।
  • क्लाउड अवलोकन मोड नीति चलाता है लेकिन एक गैर-अनुमति निर्णय को इसे लागू किए बिना रिकॉर्ड करता है।
नीति मॉड्यूल्स को नियतात्मक और तेज रखें। शीर्ष-स्तरीय नेटवर्क कॉल या सर्वर स्टार्टअप से बचें। fn के अंदर काम को सीमित करें, निर्भरता विफलताओं को पकड़ें, और जानबूझकर चुनें कि क्या वह विफलता ऑपरेशन को अनुमति दे या अस्वीकार करे।

API निर्यात

टाइपस्क्रिप्ट PolicyContext, PolicyResult, CustomHook, PolicyDecision, और PolicyFunction को निर्यात करता है।

कस्टम नीतियां तैनात करें

एक संस्करण प्रकाशित करें, इसे अवलोकन मोड में तैनात करें, निर्णयों को सत्यापित करें, और प्रवर्तन में जाएं।