# AI एजेंट मंजूरी नियंत्रण: नियम बनाम स्पष्ट निर्णय

हर बार जब किसी AI एजेंट को API टोकन या SSH कुंजी की जरूरत हो, उसे छोटा-सा एंटरप्राइज ऑथराइजेशन प्रोग्राम देने की जरूरत नहीं है। ज्यादातर टीमों को ऐसे तीन निर्णय चाहिए जिन्हें दबाव की स्थिति में भी समझा जा सके: क्या सीक्रेट स्टोर उपलब्ध है, क्या यह एजेंट प्रोसेस इस रन में कार्रवाई कर सकता है, और क्या इस खास क्रेडेंशियल के लिए नई मानव मंजूरी चाहिए?

पॉलिसी इंजन इससे कहीं ज्यादा सवालों के जवाब दे सकते हैं। वे हर परमिशन बदलाव को एक छोटे सॉफ्टवेयर प्रोजेक्ट में भी बदल सकते हैं, जिसमें भरोसेमंद इनपुट, जांचे जाने वाले नियम, समझाए जाने वाले अपवाद और ऐसे फेलियर शामिल होते हैं जो किसी के सबसे गलत समय पर शर्त बदलने के बाद सामने आते हैं। जब आपकी एक्सेस समस्या में सचमुच बदलता हुआ स्वामित्व और अलग-अलग सीमाएं हों, तभी नियम इंजन अपनाएं। साधारण मंजूरी सीमा के आसपास सजावट के लिए इसे न लगाएं।

## नियम इंजन ऑथराइजेशन को सॉफ्टवेयर रखरखाव बना देता है

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

यह काम सही ठहराया जा सकता है। किसी कंपनी को अलग-अलग संसाधन मालिकों से एक्सेस शर्तें तय करवानी पड़ सकती हैं, क्षेत्र या वातावरण के आधार पर कार्रवाई सीमित करनी पड़ सकती है, या कानूनी और संविदात्मक जरूरतें लागू करनी पड़ सकती हैं। ऐसे मामलों में कुछ तय नियंत्रण असंबंधित मामलों को एक ही कठोर मंजूरी में धकेल सकते हैं। गलती यह मानना है कि घोषणात्मक सिंटैक्स इस जटिलता को छिपा देता है, इसलिए इसकी कोई कीमत नहीं है।

एक परिचित नियम देखें:

```text
allow if
  agent.project == "payments"
  and request.host ends_with ".internal.example"
  and request.method in ["GET", "POST"]
  and time.weekday in ["Mon", "Tue", "Wed", "Thu", "Fri"]
```

यह तब तक समझदारी भरा लगता है, जब तक किसी को संचालन से जुड़े सवालों के जवाब न देने पड़ें। `agent.project` कौन तय करता है? क्या एजेंट इसे प्रभावित कर सकता है? क्या `ends_with` में `not-internal.example` भी मान्य होगा? किसी ऐसे endpoint पर POST क्या अनुमति देता है जो बनाना, रिफंड करना, हटाना या ट्रांसफर शुरू करना, सब कर सकता हो? शनिवार को घटना होने पर क्या होगा? क्या बाद का deny पहले के allow को रद्द करता है?

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

Open Policy Agent का दस्तावेज सही रूप से पॉलिसी को कोड बताता है और उसकी जांच की सलाह देता है। यह लचीलेपन का मार्केटिंग नारा नहीं है। यह संचालन संबंधी जिम्मेदारी को स्वीकार करना है: अगर कोई पॉलिसी महत्वपूर्ण एक्सेस नियंत्रित करती है, तो टीम को उसके बदलावों को कोड बदलाव की तरह लेना होगा। समीक्षकों को fixtures चाहिए। CI को अपेक्षित निर्णय चाहिए। ऑन-कॉल इंजीनियर को यह जानने का तरीका चाहिए कि किस पॉलिसी संस्करण ने अनुरोध मंजूर किया।

कई टीमें इस जिम्मेदारी को छोड़ देती हैं। वे कॉन्फिगरेशन फाइल में कुछ नियम चिपका देती हैं और छह महीने बाद पता चलता है कि किसी को नहीं मालूम कि denial टाइपो, गायब इनपुट या जानबूझकर बनाई सीमा के कारण हुआ था। AI एजेंट इस विफलता को और साफ दिखाता है, क्योंकि वह कॉल के असामान्य क्रम बना सकता है और किसी इंसान से कहीं तेज उस शाखा को चला सकता है जिसे नजरअंदाज किया गया हो।

तय नियंत्रण मनमानी शर्तें व्यक्त करने से इनकार करके रखरखाव का दायरा घटाते हैं। यह सीमित लगता है क्योंकि यह सचमुच सीमित है। उपयोगी सवाल यह है कि यह सीमा किसी वास्तविक जरूरत को रोकती है या केवल उस भविष्य के नियम को, जिसे कोई शायद कभी लागू करना चाहे।

## जब कॉल के परिणाम हों, तो निर्णय की स्पष्टता जरूरी है

ऑपरेटर को एक वाक्य में बता पाना चाहिए कि कॉल क्यों मंजूर हुई। अगर जवाब के लिए नियमों का पूरा बंडल पढ़ना, प्राथमिकता सुलझाना और एजेंट से मिले attributes देखना पड़े, तो घटना के दौरान ऑपरेटर भरोसे से एक्सेस मंजूर या रद्द नहीं कर सकता।

स्पष्ट निर्णय एक शांत लेकिन आम गलती भी रोकते हैं: कोई नियम कार्रवाई को तकनीकी रूप से अनुमति दे सकता है, लेकिन उस व्यक्ति के लिए उसे समझने योग्य नहीं बनाता जो उसके परिणामों की जिम्मेदारी उठाएगा। किसी अनाम प्रोसेस ने किसी सामान्य क्षमता के लिए एक्सेस मांगा, ऐसा कहने वाला प्रॉम्प्ट ऑपरेटर को निर्णय लेने के लिए लगभग कुछ नहीं देता। यह मंजूरी नहीं, औपचारिकता है।

एक उपयोगी ऑथराइजेशन स्क्रीन ठोस सवालों के जवाब देती है:

- किस executable ने कार्रवाई का अनुरोध किया और उसे किसने साइन किया?
- क्या यह नया प्रोसेस है या इस सेशन के लिए पहले से मंजूर प्रोसेस?
- कार्रवाई में कौन-सा क्रेडेंशियल इस्तेमाल होगा?
- अनुरोध कहां जाएगा या SSH किस होस्ट से संपर्क करेगा?
- मंजूरी देने वाला व्यक्ति एक रन को मंजूर कर रहा है या एक संवेदनशील इस्तेमाल को?

पहले सवाल को आम तौर पर मिलने वाले सम्मान से ज्यादा महत्व मिलना चाहिए। एजेंट नाम केवल लेबल हैं। प्रोसेस पहचान प्रमाण है। कोई प्रोसेस खुद को `release-agent` कह सकता है, जबकि कोड-साइनिंग अथॉरिटी या executable path समीक्षक को ऐसा प्रमाण देते हैं जो नाम बदले जाने के बाद भी कायम रहता है। पहचान का प्रमाण यह साबित नहीं करता कि हर निर्देश सुरक्षित है, लेकिन सवाल को एक वास्तविक principal तक सीमित करता है।

NIST Special Publication 800-207 zero trust को विरासत में मिले नेटवर्क भरोसे के बजाय स्पष्ट सत्यापन और लगातार मूल्यांकन पर आधारित बताता है। स्थानीय एजेंट कार्रवाइयों के लिए व्यावहारिक सीख इससे सरल है: कार्रवाई के समय actor और अनुरोध का मूल्यांकन करें। किसी एजेंट को टोकन देकर यह उम्मीद न रखें कि आपके नियंत्रण से बाहर जाने के बाद भी सीमा अर्थपूर्ण रहेगी।

निर्णय की स्पष्टता सुरक्षा गुण भी है। जब लोग किसी मंजूरी का अनुमान लगा सकते हैं, तो वे अप्रत्याशित मंजूरी पहचान सकते हैं। जो coding agent सामान्यतः issue data पढ़ता है, अगर अचानक production write credential इस्तेमाल करने को कहे, तो कॉल मशीन से बाहर जाने से पहले यह अंतर साफ दिखना चाहिए।

## पहचान, अथॉरिटी और सीक्रेट का इस्तेमाल अलग सवाल हैं

टीमें अक्सर तीन अलग सवालों को एक पॉलिसी वक्तव्य में मिला देती हैं और फिर समझ नहीं पातीं कि कौन-सी धारणा विफल हुई। इन्हें अलग रखें।

पहचान पूछती है कि अनुरोध किसने किया। स्थानीय एजेंट के मामले में इसमें प्रोसेस, उसकी कोड-साइनिंग अथॉरिटी, parent process और उसका जीवनकाल शामिल हो सकता है। इंसान के लिए समझने योग्य एजेंट लेबल मददगार है, लेकिन उसे अकेले सुरक्षा निर्णय नहीं चलाना चाहिए।

अथॉरिटी पूछती है कि पहचाना गया प्रोसेस इस रन में कार्रवाई कर सकता है या नहीं। सेशन मंजूरी इसी सवाल के लिए है। यह दर्ज करती है कि किसी व्यक्ति ने नए प्रोसेस की जांच की और उसे एक तय action gateway इस्तेमाल करने की अनुमति दी, जब तक वह बंद न हो जाए या ऑपरेटर मंजूरी रद्द न कर दे।

सीक्रेट का इस्तेमाल पूछता है कि किसी खास API key या SSH key को इस कार्रवाई के लिए इस्तेमाल किया जा सकता है या नहीं। वॉल्ट गेट और प्रति-क्रेडेंशियल मंजूरी यहीं होनी चाहिए। लॉक किया गया वॉल्ट हर कार्रवाई को रोकना चाहिए, चाहे पहले सेशन निर्णय कुछ भी रहा हो। बहुत संवेदनशील क्रेडेंशियल के लिए हर बार मानव मंजूरी जरूरी हो सकती है, भले प्रोसेस के पास सेशन अथॉरिटी पहले से हो।

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

आखिरी विफलता सबसे महत्वपूर्ण है। अगर एजेंट के पास plaintext क्रेडेंशियल हैं, तो आपकी पॉलिसी ने केवल पहला इस्तेमाल जांचा। एजेंट यह मान subprocess को दे सकता है, लॉग में डाल सकता है, किसी दूसरी सेवा को भेज सकता है या मूल मंजूरी खत्म होने के बाद भी उसका इस्तेमाल कर सकता है। ऐसा गेटवे जो सीक्रेट को एजेंट से दूर रखता है, सीमा बदल देता है: एजेंट कार्रवाई का अनुरोध करता है और गेटवे खुद authenticated कार्रवाई करता है।

यह अंतर «secret masking» से कहीं स्पष्ट है। टोकन एजेंट तक पहुंचने के बाद आउटपुट को redact करने से वह उसकी memory, prompt history, shell environment या child process से हटता नहीं है। एजेंट तक टोकन पहुंचने से रोकना आकस्मिक दोबारा इस्तेमाल की पूरी श्रेणी को समाप्त करता है।

## सामान्य एजेंट मामले के लिए तीन स्पष्ट नियंत्रण पर्याप्त हैं

छोटा नियंत्रण सेट तब काम करता है जब हर नियंत्रण एक निर्णय की जिम्मेदारी ले और दूसरे निर्णयों को हल करने का दिखावा न करे। स्थानीय डेवलपर एजेंट के लिए तीन नियंत्रण पॉलिसी भाषा बनाए बिना वास्तविक जोखिम के बड़े हिस्से को संभाल सकते हैं।

पहला, absolute vault gate लगाएं। वॉल्ट लॉक होने पर हर कार्रवाई विफल हो। इससे ऑपरेटर को भौतिक और वैचारिक stop condition मिलती है। यह नियम मूल्यांकन, याद रखे गए सेशन या नेटवर्क जांच पर निर्भर नहीं होना चाहिए। Mac पर Secure Enclave और Touch ID से hardware-gated unlocking इस निर्णय को खास तौर पर स्पष्ट बना सकता है: ऑपरेटर ने वॉल्ट खोला है या नहीं।

दूसरा, पहली बार दिखने वाले एजेंट प्रोसेस को उसके जीवनकाल के लिए मंजूर करें। मंजूरी में प्रोसेस की ऐसी पहचान होनी चाहिए जो केवल friendly name बदलने से प्रभावित न हो और प्रोसेस बंद होते ही खत्म हो जाए। इससे हर सामान्य अनुरोध पर प्रॉम्प्ट नहीं दिखता, लेकिन मंजूरी डिफॉल्ट रूप से स्थायी भी नहीं बनती।

तीसरा, चुने हुए क्रेडेंशियल को हर इस्तेमाल पर मंजूरी के लिए चिह्नित करें। इसका इस्तेमाल कम और सोच-समझकर करें। ऐसा deployment credential जो production infrastructure बदल सकता है, व्यापक host access वाली SSH identity या पैसे भेज सकने वाला token हर कॉल पर तत्काल निर्णय मांग सकता है। इसके विपरीत read-only development token, जिसे एजेंट बार-बार इस्तेमाल करता है, आम तौर पर ऐसा नहीं मांगता।

इससे बनने वाली निर्णय सीढ़ी समझना आसान है:

```text
if vault is locked:
    deny action
else if this agent process has no current session approval:
    ask for session approval
else if the selected credential requires approval per use:
    ask for credential approval
else:
    execute the action
```

यह least privilege का विकल्प नहीं है। क्रेडेंशियल का दायरा फिर भी सीमित होना चाहिए और अनुरोध मार्ग में transport security तथा target validation होना चाहिए। यह सीढ़ी मानव नियंत्रण बिंदु को स्पष्ट बनाती है। यह administrator token को सुरक्षित क्रेडेंशियल में नहीं बदलती।

क्रम महत्वपूर्ण है। प्रति-कॉल प्रॉम्प्ट को लॉक किए गए वॉल्ट को कभी bypass नहीं करना चाहिए। याद रखा गया सेशन, बार-बार मंजूरी वाले क्रेडेंशियल के निर्णय को bypass नहीं कर सकता। सामान्य नियम इंजन में ये प्राथमिकताएं अक्सर अलग-अलग पॉलिसी में रहती हैं और ऑडिट करना कठिन हो जाता है। तय सीढ़ी में क्रम ही मॉडल है।

## स्वामित्व बदलता हो तो पॉलिसी इंजन अपनी कीमत साबित करता है

पॉलिसी इंजन तब उचित है जब ऑथराइजेशन निर्णय कई स्वतंत्र रूप से स्वामित्व वाले संसाधनों के अनुसार बदलना पड़े और इस बदलाव को क्रेडेंशियल के चुनाव या मंजूरी की कुछ श्रेणियों से व्यक्त न किया जा सके।

मान लीजिए कोई shared automation service कई business unit संभालती है। हर unit के अलग repository, cloud account और data store हैं। मालिकों को तय समूहों को अस्थायी एक्सेस देना, अलग retention शर्तें लगाना और केंद्रीय governance प्रक्रिया के तहत निर्णयों का ऑडिट करना है। यहां पॉलिसी लेयर सही डिजाइन हो सकती है, क्योंकि संगठन को delegated rule ownership और बड़े estate में एक जैसा enforcement चाहिए।

दूसरा अच्छा मामला server-side service है जो कई untrusted client से अनुरोध पाती है। कार्रवाई से पहले service को tenant, role, object ownership, request origin और transaction state जांचनी पड़ सकती है। तय स्थानीय सेशन मंजूरी इसका विकल्प नहीं है। सर्वर को हर अनुरोध पर निर्णय लेना होगा, भले पास में मंजूरी देने वाला कोई इंसान न हो।

इन मामलों को हर स्थानीय coding agent के सामने पॉलिसी इंजन लगाने का कारण न बनाएं। डेवलपर मशीन का सवाल आम तौर पर छोटा होता है: क्या यह signed agent process, operator की अनुमति के दौरान, इस stored credential को इस action gateway के जरिए इस्तेमाल कर सकता है? इंसान के पास पहले से स्थानीय संदर्भ है। समय सीमा, project tag और अनुमानित risk score जैसी शर्तें जोड़ने से नियंत्रण के बजाय झूठा भरोसा बढ़ सकता है।

एक और कठोर सीमा है। पॉलिसी जरूरत से ज्यादा व्यापक क्रेडेंशियल को ठीक नहीं कर सकती। कोई नियम एक host के अनुरोधों को अनुमति दे सकता है, लेकिन अगर एजेंट bearer token निकाल सकता है, तो token का issuer खुद उसका दायरा लागू करे। सीक्रेट को गेटवे में रखें और provider पर उसका दायरा सीमित करें। गेटवे ऑथराइजेशन को एक layer मानें, resource-side access control का विकल्प नहीं।

## मंजूरी की थकान बताती है कि दायरा गलत है

बार-बार दिखने वाले प्रॉम्प्ट लोगों को ज्यादा सावधान नहीं, बल्कि ज्यादा तेज बनाते हैं। अगर कोई व्यक्ति repository metadata लाते समय वही मंजूरी कार्ड बीस बार देखता है, तो वह सीख जाता है कि क्लिक करने से काम आगे बढ़ता है। इसके बाद ग्यारहवीं बार आया सचमुच अलग अनुरोध भी उसी reflex से मंजूर हो सकता है।

आम जवाब यह है कि increasingly specific शर्तों के आधार पर प्रॉम्प्ट दबाने वाले अधिक smart नियम बनाए जाएं। इससे अक्सर दिखाई देने वाली थकान की जगह अदृश्य जटिलता आ जाती है। कोई read calls के लिए अपवाद लिखता है और बाद में पता चलता है कि read समझे जाने वाले endpoint ने remote computation शुरू कर दी या ऐसा data दिखा दिया जिसे समीक्षा चाहिए थी। मंजूरियों की संख्या घटती है, लेकिन निर्णय की जांच कठिन हो जाती है।

मंजूरी का दायरा उस मानव निर्णय के अनुसार तय करें जिसकी जरूरत है। सेशन मंजूरी कहती है, «मैं इस प्रोसेस को पहचानता हूं और इस रन के लिए दिए गए सामान्य क्रेडेंशियल के साथ इसे काम करने देता हूं।» प्रति-कॉल मंजूरी कहती है, «इस क्रेडेंशियल के इस्तेमाल का असर इतना है कि मैं इसे अलग से जांचूंगा।» कोई भी प्रॉम्प्ट सिर्फ इसलिए नहीं होना चाहिए कि implementation confirmation dialog दिखाना चाहती है।

अच्छा क्रेडेंशियल डिजाइन इसे आसान बनाता है। एक शक्तिशाली token रखकर हर कॉल को पॉलिसी से फ़िल्टर करने की उम्मीद न करें। क्रेडेंशियल को उनके असर के आधार पर अलग करें। सामान्य डेवलपमेंट काम के लिए एजेंट को सीमित token दें। production बदलने वाला token अलग रखें और उसके इस्तेमाल पर स्पष्ट निर्णय मांगें। इससे क्रेडेंशियल की संख्या बढ़ सकती है, लेकिन ऑथराइजेशन सीमा से नाजुक request parsing हट जाती है।

एक अस्वीकार योग्य सलाह का सीधा जवाब जरूरी है: «हर एजेंट कार्रवाई के लिए मंजूरी मांगें» सुरक्षित लगता है, क्योंकि इससे मानव क्लिक का पूरा रिकॉर्ड बनता है। बार-बार होने वाली कम-असर वाली कॉल के लिए यह आम तौर पर गलत है। लोग समान अनुरोधों की बाढ़ की अच्छी तरह जांच नहीं कर सकते। जहां समीक्षक अलग निर्णय ले सकता हो, वहीं मंजूरी मांगें और बाकी को लॉग करें, ताकि टीम वास्तविक व्यवहार की जांच कर सके।

## एक harmless नियम नुकसानदेह अनुरोध को मंजूर कर सकता है

एक आम विफलता तब शुरू होती है जब टीम किसी एजेंट को staging service अपडेट करने की अनुमति देना चाहती है। वे ऐसा नियम बनाते हैं जो `api.example.internal` को POST अनुरोध की अनुमति देता है, जब एजेंट `staging` project होने का दावा करे। गेटवे सीधे token डाल नहीं सकता, इसलिए एजेंट को उसके environment में token मिल जाता है।

Debugging के दौरान एजेंट copied command का पालन करता है, जो उसी hostname पर management endpoint इस्तेमाल करती है। endpoint POST स्वीकार करता है और ऐसा operation उपलब्ध कराता है जो configuration को production में promote कर सकता है। पॉलिसी को allowed method, allowed host और allowed project label दिखते हैं। वह allow लौटाती है।

टीम इसे policy bug कह सकती है, लेकिन विफलताएं कई हैं:

1. Method intent बताने के लिए बहुत व्यापक था।
2. एजेंट द्वारा नियंत्रित project attribute ने ownership साबित नहीं किया।
3. Host में अलग-अलग असर वाले endpoint मौजूद थे।
4. Token enforcement point के बाहर था और अनुरोध के बाद फिर इस्तेमाल हो सकता था।
5. ऑपरेटर ने ऐसा निर्णय नहीं देखा जो staging update और production promotion में अंतर करता।

Route pattern जोड़ने से यह खास छेद बंद हो सकता है। फिर कोई versioned path, alternate hostname, batch endpoint या behavior बदलने वाला query parameter जोड़ देगा। पॉलिसी बढ़ती जाती है क्योंकि मूल क्रेडेंशियल बहुत कुछ कर सकता है।

बेहतर डिजाइन staging और production क्रेडेंशियल अलग करता है। सामान्य सेशन gateway के जरिए staging credential इस्तेमाल कर सकता है। production credential के लिए हर इस्तेमाल पर मंजूरी चाहिए और मंजूरी में target तथा action साफ होने चाहिए। गेटवे credential डालकर परिणाम लौटाता है, जबकि एजेंट को उसका value कभी नहीं मिलता।

यह डिजाइन फिर भी API provider पर निर्भर है कि दोनों क्रेडेंशियल का दायरा सही रखे। यह मंजूर एजेंट को खराब staging बदलाव करने से नहीं रोकता। लेकिन यह सुनिश्चित करता है कि ढीले नियम और reusable token के जरिए staging workflow चुपचाप production authority न पा सके।

## एजेंट के आपके लिए जांच करने से पहले denial path जांचें

ऑथराइजेशन परीक्षणों को केवल सामान्य अनुरोध के सफल होने का प्रमाण नहीं देना चाहिए। उन्हें यह भी साबित करना चाहिए कि अपेक्षित परिस्थितियों में सिस्टम कार्रवाई रोकता है। ये परीक्षण इतने छोटे होने चाहिए कि क्रेडेंशियल या agent integration बदलने से पहले चलाए जा सकें।

तय निर्णय सीढ़ी के लिए अपेक्षित परिणामों की तालिका लिखें और उसे implementation के साथ रखें:

| Vault state | Session approval | Credential setting | Expected result |
| --- | --- | --- | --- |
| locked | present | ordinary | deny |
| unlocked | absent | ordinary | request session approval |
| unlocked | present | ordinary | execute |
| unlocked | present | per-call | request credential approval |
| unlocked | revoked | ordinary | deny or request a new session approval |

यह तालिका एक गंभीर प्रकार की regression पकड़ती है: कोई engineer सुविधा के लिए ऐसा मार्ग जोड़ देता है जो vault state से पहले session authority जांचता है, या remembered process को प्रति-कॉल credential decision छोड़ने देता है। तालिका policy language सीखे बिना intended order की समीक्षा संभव बनाती है।

पॉलिसी इंजन के लिए केवल allow होने वाले उदाहरणों की जांच न करें। Missing attributes, malformed URLs, alternate hostnames, policy version changes, rule conflicts, clock changes और explicit denies भी जांचें। Open Policy Agent का testing model rule tests को support करता है, लेकिन कठिन काम आपका है: ऐसे inputs तय करना जिन्हें attacker, buggy agent या future integration प्रभावित कर सकते हैं।

एजेंट के active रहते revocation भी जांचें। सेशन शुरू करें, मंजूर करें, सामान्य कार्रवाई करें, access revoke करें और वही अनुरोध दोहराएं। दूसरी कोशिश को action gateway पर denial मिलना चाहिए। अगर revocation केवल dashboard record बदलती है, लेकिन प्रोसेस के पास usable credential रहता है, तो प्रभावी authority revoke नहीं हुई है।

HTTP के लिए लौटे परिणाम में इतना संदर्भ जांचें कि authorization header उजागर किए बिना failure का कारण समझा जा सके। SSH के लिए सुनिश्चित करें कि helper चुनी हुई identity से connect करता है, लेकिन private key material calling agent को नहीं देता। ये बातें साधारण लगती हैं, जब तक कोई घटना टीम को यह पता लगाने पर मजबूर न कर दे कि प्रोसेस के पास वास्तव में क्या था।

## ऑडिट लॉग को प्रॉम्प्ट से अलग सवाल का जवाब देना चाहिए

मंजूरी नियंत्रण उसी क्षण कार्रवाई रोकते या अनुमति देते हैं। ऑडिट लॉग बाद में बताता है कि क्या हुआ, किसने मंजूर किया और किसी ने रिकॉर्ड बदला या नहीं। इन दोनों कामों को अस्पष्ट «accountability» सुविधा में न मिलाएं।

उपयोगी event record में session identity, लिया गया निर्णय, secret value के बजाय credential reference, action type, target, outcome और ordering information होनी चाहिए। Session revocation भी दर्ज करें। उस कड़ी के बिना जांचकर्ता अनुरोध तो देख सकते हैं, लेकिन यह नहीं जान सकते कि वह operator द्वारा मंजूरी वापस लेने से पहले हुआ या बाद में।

Tamper evidence के बारे में शब्द सावधानी से चुनें। Hash chain बाद में हुए modification या deletion का पता लगाने में मदद कर सकती है, जब verifier के पास अपेक्षित chain data हो। वह यह साबित नहीं कर सकती कि compromised system ने शुरुआत में हर event रिकॉर्ड किया था। वह यह भी तय नहीं कर सकती कि मंजूरी समझदारी भरी थी या नहीं। लॉग recorded history का प्रमाण देता है, time machine नहीं।

स्थानीय गेटवे के लिए write-blind encrypted audit log एक उपयोगी विभाजन देता है: कार्रवाई करने वाला component events रिकॉर्ड करता है, जबकि सामान्य readers history को फिर से लिखने के बजाय projected journals पढ़ते हैं। Offline verification खास तौर पर उपयोगी है, क्योंकि chain structure जांचने के लिए उपलब्ध service या decryption key की जरूरत नहीं पड़ती।

Sallyport agent runs को Sessions journal में और individual actions को Activity journal में रिकॉर्ड करता है। दोनों encrypted hash-chained audit log से project किए जाते हैं। उसका `sp audit verify` command ciphertext पर offline chain जांचता है, जो उस लॉग के लिए सही दिशा है जिसकी जरूरत मशीन के संदिग्ध हो जाने के बाद भी पड़ सकती है।

ऑडिट समीक्षा को व्यावहारिक रखें। जब कोई एजेंट आपको चौंकाए, पहले उस प्रोसेस की पहचान करें जिसे session approval मिली थी, actions को समय के क्रम में देखें, active session revoke करें और प्रभावित provider logs जांचें। स्थानीय journal बताता है कि gateway से क्या गुजरा; destination service बताती है कि remote system ने क्या स्वीकार किया।

## ऐसा छोटा निर्णय मॉडल चुनें जिसे आप चला सकें

लचीलेपन की अमूर्त इच्छा से नहीं, वास्तविक authority path से शुरुआत करें। एजेंट को किन क्रेडेंशियल की जरूरत है, किन क्रेडेंशियल के परिणाम इतने गंभीर हैं कि नई मंजूरी चाहिए और active process को व्यक्ति कैसे revoke कर सकता है, यह लिखें। अगर इससे तीन स्थिर निर्णय निकलते हैं, तो उन्हें स्पष्ट रखें।

जब संगठन को ऐसे rule ownership और variation की जरूरत हो जिन्हें credential split, session approval और per-call approval से व्यक्त नहीं किया जा सकता, तब पॉलिसी इंजन अपनाएं। इसके बाद आने वाली जिम्मेदारी स्वीकार करें: पॉलिसी के version रखें, adversarial inputs जांचें, precedence लिखें, owners तय करें और exceptions की समीक्षा कोड जितनी सावधानी से करें।

खराब डिजाइन «rules» या «prompts» नहीं है। खराब डिजाइन वह authorization boundary है जिसे एजेंट के कार्रवाई की प्रतीक्षा करते समय कोई समझा नहीं सकता। अगर आपकी टीम यह नहीं बता सकती कि अनुरोध क्यों मंजूर है, तो उसे smart बनाने से पहले decision model छोटा करें।