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 के रूप में टाइप किए जाते हैं:

इवेंट चुनें

इवेंट उपलब्धता और ब्लॉकिंग व्यवहार एजेंट हार्नेस पर निर्भर करते हैं। मिश्रित फ़्लीट में एक इवेंट पर निर्भर होने से पहले एजेंट हार्नेस देखें।
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-सेकंड की समय सीमा होती है।
  • क्लाउड ऑब्जर्व मोड नीति चलाता है लेकिन इसे लागू किए बिना एक गैर-allow निर्णय दर्ज करता है।
नीति मॉड्यूल को नियतात्मक और तेज रखें। शीर्ष-स्तरीय नेटवर्क कॉल या सर्वर स्टार्टअप से बचें। fn के अंदर काम को बाध्य करें, निर्भरता विफलताओं को पकड़ें और जानबूझकर चुनें कि क्या वह विफलता ऑपरेशन को अनुमति देनी चाहिए या नहीं।

API निर्यात

TypeScript PolicyContext, PolicyResult, CustomHook, PolicyDecision और PolicyFunction निर्यात करता है।

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

एक संस्करण प्रकाशित करें, इसे observe मोड में तैनात करें, निर्णयों को सत्यापित करें और प्रवर्तन के लिए आगे बढ़ें।