कमजोर नियंत्रणों के बिना ब्लॉक की गई AI एजेंट कॉल की जांच

ब्लॉक की गई AI एजेंट कॉल ऐसी रुकावट नहीं हैं जिन्हें हर हाल में हटाना चाहिए। वे आपके नियंत्रण तंत्र का वह हिस्सा हैं जो बताता है कि एजेंट के निर्देश, टूल interface, access setup या व्यवहार का वास्तविक स्थिति से मेल कहां टूट गया। अगर आप हर अस्वीकृति को अधिक permission की मांग मानेंगे, तो आखिरकार एजेंट को उसी क्षण सबसे व्यापक अधिकार दे देंगे जब उसके अगले कदम पर भरोसा करने का कारण सबसे कम होगा।

मैंने टीमों को deadline के दबाव में उपयोगी अस्वीकृति को स्थायी exception में बदलते देखा है। पहला approval मामूली लगता है। दूसरा सामान्य। जल्द ही एजेंट ऐसे credential से production तक पहुंच जाता है जिसे उसे कभी देखना ही नहीं चाहिए था, ऐसे टूल के जरिए जिसे कोई साफ-साफ समझा नहीं सकता। यह efficiency gain नहीं है। यह वह जांच है जिसे आपने करने से इनकार कर दिया।

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

अस्वीकृति का रिकॉर्ड प्रमाण है, error message नहीं

ब्लॉक किया गया अनुरोध एजेंट की कोशिश और आपके दिए जाने वाले अधिकार के बीच असहमति दर्ज करता है। इस असहमति को समझने तक सुरक्षित रखें। इससे missing credential, unapproved process, बहुत अस्पष्ट tool, गलत environment या ऐसी मांग सामने आ सकती है जो कभी की ही नहीं जानी चाहिए थी।

«Blocked» शब्द दो अलग घटनाओं को मिला देता है। कोई कार्रवाई gateway में authorization न होने से रुक सकती है, या बाहरी सेवा तक पहुंचने के बाद वहां अस्वीकृत हो सकती है। पहली घटना बताती है कि आपके नियंत्रण ने अनुरोध रोका। दूसरी बताती है कि आपने अनुरोध बाहर जाने दिया और गंतव्य ने उसे ठुकराया। पहली घटना की जांच करें, इससे पहले कि वह दूसरी बन जाए।

उपयोगी रिकॉर्ड ऐसे सवालों का जवाब देता है जिनका जवाब console transcript आमतौर पर नहीं देता:

• किस agent process ने अनुरोध किया और उसकी पहचान कैसे हुई?
• उसने कौन-सा exact HTTP operation या SSH command मांगा?
• उसने कौन-सा destination और credential reference चुना?
• किस gate या approval condition ने उसे रोका?
• कौन-से task instruction या repository context ने उस अनुरोध को जन्म दिया?

«Agent को deployment access चाहिए था» को इनमें से किसी सवाल का जवाब न मानें। Deployment access एक category है। जांच के लिए operation, target और expected outcome चाहिए। «Staging API से current release status पढ़ना» ऐसी बात है जिसे जांचा जा सकता है। «Deploy access» अगली दिखाई देने वाली हर चीज को मंजूर करने का निमंत्रण है।

NIST Special Publication 800-92, Guide to Computer Security Log Management, यह महत्वपूर्ण बात कहता है कि logs incident response और operational troubleshooting में मदद करते हैं। जिस हिस्से को टीमें छोड़ देती हैं वह है preservation: log में इतना context होना चाहिए कि सामान्य गलती और असामान्य अनुरोध में फर्क किया जा सके। केवल approval popup रिकॉर्ड नहीं है। कॉपी की गई terminal line भी रिकॉर्ड नहीं है। कोई setting बदलने से पहले पूरे run और individual call को सुरक्षित रखें।

अस्वीकृतियों का एक और लाभ है: वे मानव operator को यह स्पष्ट करने पर मजबूर करती हैं कि कौन-सा अधिकार देना था। यही कथन अगले agent run की जांच बन जाता है। अगर कोई «admin», «production» या «repository access» जैसे व्यापक शब्दों के बिना इसे नहीं बता सकता, तो task autonomous execution के लिए तैयार नहीं है।

Access बदलने से पहले मांगी गई कार्रवाई का नाम लें

ब्लॉक की गई कॉल की जांच तब तक नहीं हो सकती जब तक आप उसे ऐसे वाक्य में न बदल दें जिसे कोई दूसरा engineer दोहरा सके। वाक्य में actor, action, destination, authentication reference और expected result होने चाहिए। इनमें से कोई हिस्सा गायब हो तो इसे साधारण permission request न मानें।

HTTP के लिए method, path, hostname और यह दर्ज करें कि कॉल state पढ़ती है या बदलती है। GET /releases/current और POST /releases एक ही service और credential इस्तेमाल कर सकते हैं, फिर भी जोखिम बहुत अलग है। Status endpoint पढ़ सकने वाला bearer token deployment शुरू करने में भी सक्षम हो सकता है। Friendly credential label देखकर सुरक्षित scope का अनुमान न लगाएं।

SSH के लिए host alias, मांगी गई command, tool उपलब्ध कराता हो तो working directory और expected artifact दर्ज करें। «Build host पर tests चलाएं» अभी भी बहुत अस्पष्ट है। «Checked-out repository में git status --short चलाएं» reviewer को task से तुलना करने के लिए ठोस आधार देता है। Shell redirect, command substitution, package installation, deletion या network transfer वाली commands पर ज्यादा ध्यान दें, क्योंकि दिखाई देने वाला verb असली प्रभाव छिपा सकता है।

Run उपलब्ध रहते हुए यह छोटी जांच-नोट लिखें:

Run identity:
Task instruction:
Requested operation:
Target host or API path:
Credential reference:
Control that denied it:
Expected result:
Why this request belongs to the task:
Smallest safe repair:

यह नोट उस आम handoff failure को रोकता है जिसमें एक व्यक्ति prompt देखता है, दूसरा approval card और तीसरा destination का error response। हर व्यक्ति के पास सही लगने वाला एक टुकड़ा होता है, इसलिए कोई faith पर approval दे देता है।

Sallyport की session authorization प्रक्रिया की code-signing authority से शुरू होती है। नए run को मंजूर करने से पहले यही विवरण देखना चाहिए। Process identity यह साबित नहीं करती कि अनुरोध समझदारी भरा है, लेकिन इससे हर local process को एक जैसा मानने की गलती नहीं होती। अपेक्षित signed application से शुरू हुआ terminal और उसी कार्रवाई की मांग करने वाला अज्ञात executable अलग मामले हैं।

Free-text task description को प्रमाण न मानें। एजेंट उसे गलत समझ सकता है, inherited instructions आपस में टकरा सकते हैं और malicious repository ऐसी instructions डाल सकती है जो सामान्य project guidance जैसी दिखें। Requested action की तुलना अपने नियंत्रण वाले task source, जैसे reviewed ticket या स्पष्ट operator instruction, से करें। Repository text input है, authority नहीं।

अस्वीकृति का स्रोत जांच का तरीका बदल देता है

अलग-अलग controls अलग कारणों से रोकते हैं और हर कारण का सुधार अलग होता है। हर अस्वीकृति को एक ही «permission denied» bucket में डालने से निर्णय कहां हुआ, यह छिप जाता है और गलत सुधार होते हैं।

Locked vault की अस्वीकृति का अर्थ है कि कार्रवाई आगे नहीं बढ़नी चाहिए। Credential को environment variable या prompt में डालकर, अथवा alternate code path बनाकर इसका जवाब न दें। ऐसा करने से वही सुरक्षा bypass होगी जिसने समस्या पकड़ी थी। पहले पुष्टि करें कि Mac पर मौजूद व्यक्ति इस task के लिए access unlock करना चाहता है। फिर उसी व्यक्ति द्वारा run context की समीक्षा के बाद आगे बढ़ें।

New-session denial का अर्थ है कि agent process को अपने वर्तमान run के लिए authority नहीं मिली। Process identity और task boundary देखें। दोनों आपके शुरू किए काम से मेल खाते हों तो per-session approval उचित है, क्योंकि इसका lifetime सीमित होता है: run खत्म, authority खत्म। Process identity अनजान हो तो harmless दिखने वाली call के कारण approval न दें। अपरिचित process भरोसा बनाने के लिए harmless first call का उपयोग कर सकता है।

Per-call approval का अर्थ है कि credential owner ने हर उपयोग को human decision के लिए चिह्नित किया है। Agent कई समान requests कर रहा हो तो यह condition न हटाएं। पूछें कि task गलत तरीके से बनाया गया है या नहीं। Batch operation को अलग, सोच-समझकर बनाए workflow की जरूरत हो सकती है, न कि click-through approvals की ऐसी श्रृंखला की जिसमें reviewer पढ़ना बंद कर दे।

Absent या mismatched credential अलग स्थिति है। Agent task से जुड़ी named operation मांग सकता है, लेकिन vault में उस destination के लिए credential न हो या बाहरी service scope पर्याप्त न हो। पहले destination का इरादा सुनिश्चित करें। फिर narrow credential mapping जोड़ें या ठीक करें। Secret agent को देकर समस्या diagnose न कराएं। Gateway authentication कर सकता है और agent को केवल result दिख सकता है।

External authorization failure पर अलग प्रतिक्रिया चाहिए। Call gateway से सही तरीके से बाहर गई हो सकती है, लेकिन service 401, 403 या domain-specific error से उसे अस्वीकार कर सकती है। Request shape और returned result सुरक्षित रखें। Service account का scope तभी ठीक करें जब पुष्टि हो जाए कि operation task का हिस्सा था। इससे पहले service role बदलना साधारण setup issue को व्यापक स्थायी access में बदल देता है।

व्यावहारिक परिणाम साफ है: gateway denial आपकी बनाई सीमा की रक्षा करती है, जबकि external rejection बताती है कि आपकी सीमा ने प्रयास को पहले ही अनुमति दे दी थी। Incident notes में दोनों को «blocked» न लिखें। अलग labels इस्तेमाल करें। बाद में आपको जानना होगा कि request स्थानीय स्तर पर रुकी थी या downstream जाकर विफल हुई।

Intent को agent की explanation से नहीं, task से समझें

Agent यह बता सकता है कि उसने अनुरोध क्यों किया, लेकिन उसकी explanation उसके reasoning का प्रमाण है, access का औचित्य नहीं। कार्रवाई task का हिस्सा है या नहीं, यह task owner तय करता है। यह बात तब भूल जाती है जब agent कहता है कि environment देखने के लिए उसे broad command चाहिए और operator blocking से थक चुका होता है।

पहले desired outcome देखें। अगर task failing test ठीक करने का है, तो build status पढ़ने वाली API call उचित हो सकती है। Deployment credential rotate करने वाली call तब तक उचित नहीं जब तक task में credentials की बात साफ न हो। Documentation update करने के task में shared host पर package install करने वाला SSH request «build को इसकी जरूरत है» से साबित नहीं होता।

फिर उस outcome तक पहुंचने का सबसे छोटा रास्ता देखें। Agent अक्सर broad action चुनता है क्योंकि उसे बताना आसान होता है। Arbitrary shell text वाला tool discovery commands, environment inspection और composite scripts को बढ़ावा देता है, जबकि named operation पर्याप्त होती। Arbitrary API URL वाला tool task से बाहर endpoints खोजने का रास्ता खोलता है।

एक आसान test है: क्या agent के चलने से पहले आप narrow expected-action statement लिख सकते हैं? अगर आप «current issue labels पढ़ें» कह सकते हैं लेकिन «labels बदलें» नहीं, तो write call ambiguous नहीं है। वह scope से बाहर है। उसे deny करें और उस instruction path की जांच करें जिसने request पैदा किया।

यहां एक लोकप्रिय लेकिन खराब सलाह सामने आती है: agent को broad read access दें क्योंकि read-only सुरक्षित है। Read access customer data, internal topology, deployment details, access patterns और service में गलती से रखे secrets उजागर कर सकता है। Write से कम destructive हो सकता है, फिर भी authority है। Read operations को उसी service, resource class और environment तक सीमित करें जिसकी job को जरूरत है।

Prompt instructions भी कमजोर प्रमाण हैं, क्योंकि repository content agent को प्रभावित कर सकता है। Dependency installation script में agent को local credential directory देखने को कहा जा सकता है। Setup document किसी अनजान host पर curl command मांग सकता है। Agent उस text का faithfully पालन कर सकता है और फिर भी ऐसी कार्रवाई कर सकता है जिसे आपने authorize नहीं किया। Untrusted repository instructions को review योग्य data मानें, खासकर जब वे नया external action करवाएं।

Mismatch को सरल भाषा में लिखें। «Task ने release status पढ़ने को कहा, agent ने release बनाने को कहा।» «Task में staging था, request production पर गई।» «Tool description ने known host बताया, request ने नया hostname दिया।» ऐसे वाक्य engineer को कारण ठीक करने में मदद करते हैं। «Security ने deny किया» मदद नहीं करता।

बार-बार होने वाली अस्वीकृतियां अक्सर tool contract की कमी दिखाती हैं

Tool interface तब समस्या बनता है जब वह open-ended parameters के रूप में security decisions model को दे देता है। Agent host, branch, path, credential या shell command का अनुमान लगाता है। हर denial access problem जैसा लगता है, जबकि असली समस्या यह हो सकती है कि tool ने allowed action को कभी स्पष्ट ही नहीं किया।

मान लें agent से पूछा गया कि release पूरा हुआ या नहीं। Loose HTTP tool कोई भी method, URL, arbitrary headers और credential selector स्वीकार कर सकता है। Agent repository text में मिले endpoint को चुनता है और deny हो जाता है। कोई destination approve कर देता है, फिर follow-up में agent दूसरा endpoint चुनता है। Operator को हर call अलग से उचित लगती है और approvals के जरिए एक अनreviewed API client बन जाता है।

बेहतर tool वही operation देता है जो वास्तव में समर्थित है: named environment के लिए release status पढ़ना। Tool owner base destination और HTTP method तय करता है। Agent केवल release identifier जैसा छोटा parameter देता है। Gateway credential को सिर्फ intended call में जोड़ता है। अब denial का अर्थ साफ है: environment, identifier, process या credential mapping contract से मेल नहीं खाती।

यही नियम SSH पर लागू होता है। Coding agent को general remote shell न दें, यदि काम में दो maintenance actions ही चाहिए। उन actions को known arguments वाली scripts के रूप में expose करें या narrow command form validate करने वाला wrapper इस्तेमाल करें। Restrictive interface डिजाइन करते समय असुविधाजनक लग सकता है। पहली बार जब agent गलत host पर compound command चलाना चाहेगा, वही interface समझदारी भरा लगेगा।

Denial cluster में इन patterns को खोजें:

• Agent बार-बार destination names या API paths गढ़ता है।
• Task बदले बिना read और write calls के बीच बदलता रहता है।
• एक ही task को कई असंबंधित credentials चाहिए।
• Reviewer को लंबी command के shell effects का अनुमान लगाना पड़ता है।
• Tool description outcome बताती है, लेकिन consequential parameters खुले छोड़ देती है।

हर instance पर नया exception न जोड़ें। Tool contract बदलें। Narrow tools agent की reliability भी बढ़ाते हैं, क्योंकि वे वे निर्णय हटा देते हैं जिन्हें language models ठीक से नहीं संभालते। Agent को supported operations में से चुनना चाहिए, strings से अपनी security boundary नहीं बनानी चाहिए।

Sallyport secrets को encrypted vault में रखता है और credentials agent को दिए बिना HTTP या SSH actions चलाता है। यह separation तभी उपयोगी है जब action interface इतना specific हो कि human उसका निर्णय कर सके। Credential isolation secret leakage रोकता है, लेकिन overbroad action request को स्वीकार्य नहीं बनाता।

एक failed run को शुरू से अंत तक देखें

Denial investigation में sequence सुरक्षित रखें, क्योंकि पहला unusual call बाद के सभी requests को समझा सकता है। केवल अंतिम blocked action देखने से झूठी कहानी बनती है, जैसे agent अचानक suspicious हो गया हो।

एक वास्तविक उदाहरण लें। Agent को successful staging build के बाद service की release notes update करने का task मिलता है। वह repository files पढ़ता है। फिर staging build status लेने के लिए HTTP call मांगता है। यह task से मेल खाती है और expected run authorization के बाद सफल हो जाती है। इसके बाद वह generated artifact देखने के लिए build host पर SSH access मांगता है। यह उचित हो सकता है, लेकिन नया channel है और task से दोबारा तुलना चाहिए।

Host बताता है कि expected artifact मौजूद नहीं है। Agent repository script पढ़ता है जिसमें लिखा है कि operator remote command चलाकर artifacts फिर से बना सकता है। अब वह output directory साफ करने, dependencies install करने और build चलाने वाली command मांगता है। Per-call denial मिलती है।

सिर्फ इसलिए command approve न करें कि पहली HTTP request legitimate थी। Original task में rebuild, shared host बदलने या dependencies install करने की बात नहीं थी। Tool path status checking से remote modification में बदल गया। सही जांच पूछती है:

1. क्या किसी human ने artifact rebuild करने की अनुमति दी थी, या agent ने repository text से यह निष्कर्ष निकाला?
2. क्या build host autonomous changes के लिए है, या agent को missing artifact report करना चाहिए?
3. क्या compound remote shell command की जगह dedicated build operation हो सकती है?
4. क्या output directory इसी task की है, या उसे साफ करने से किसी दूसरे run पर असर पड़ेगा?
5. क्या staging build सफल न होने पर task को अलग workflow चाहिए?

सुधार यह हो सकता है कि absent artifact report करके रुक जाएं। Reviewed build action और isolated workspace जोड़ा जा सकता है। Pipeline को ठीक करना भी जरूरी हो सकता है, जिसने artifact बनाना था। General SSH authority देना सबसे खराब सुधार है, क्योंकि इससे तीनों संभावनाएं एक broad permission के नीचे छिप जाती हैं।

यही क्रम बताता है कि approval fatigue design failure क्यों है। Human पहले normal call और फिर technical requests देखकर momentum में approval देने लगता है। Control technically काम करता रहता है, लेकिन review quality गिरती जाती है। Meaningful boundaries पर निर्णय रखें: नया process, high-consequence credential या scope change। हर कुछ seconds में किसी व्यक्ति से नया shell program समझने की अपेक्षा न करें।

Audit trail की integrity जांचने के बाद ही उस पर भरोसा करें

Logs तभी उपयोगी हैं जब पता हो कि घटना के बाद उन्हें बदला नहीं गया। Plain append-only claim काफी नहीं है, खासकर जब agent चलाने वाली machine compromise हो या किसी operator के पास record को «साफ» करने का कारण हो।

Hash-chained audit log हर entry को पिछली entry से जोड़ता है। पुराने ciphertext को बदलने पर आगे का chain relationship बदल जाता है और verification में tampering का पता चलता है। इससे मूल event सही नहीं हो जाता और recording से पहले हुए नुकसान को भी नहीं रोका जा सकता। इसका सही उपयोग करें: retained sequence चुपचाप बदली नहीं गई, इस पर भरोसा।

लंबी review शुरू करने से पहले और incident के लिए records export करने पर verification चलाएं। Sallyport अपने encrypted audit chain को इस command से offline verify कर सकता है:

sp audit verify

Verification check के लिए vault key की जरूरत नहीं होती। इसका result investigation note में रखें, साथ में verification का समय और review किए गए records का set भी लिखें। Verification fail हो तो प्रभावित sequence को पूरी कहानी न मानें। मूल files सुरक्षित रखें, machine की पहुंच सीमित करें और destination service logs, repository history तथा task system जैसे independent evidence से तुलना करें।

Independent logs की क्षमता को बढ़ा-चढ़ाकर न बताएं। Destination service बता सकती है कि request आई, लेकिन यह जरूरी नहीं कि कौन-से local agent process ने उसे शुरू किया। Source control commit दिखा सकता है, पर यह नहीं कि agent ने वह बदलाव क्यों चुना। Correlation तभी काम करती है जब अलग sources में identifiers और time order सुरक्षित हों, न कि बाद में screenshots जमा करने से।

Notes में दो सवाल अलग रखें। पहला: «क्या इस agent run ने यह action मांगा?» दूसरा: «क्या मांगी गई action उचित थी?» Audit integrity पहले सवाल में मदद करती है। Task scope और human judgment दूसरे का निर्णय करते हैं। Teams दोनों को इसलिए मिला देती हैं क्योंकि intact log authoritative लगता है। Intact log यह साबित कर सकता है कि bad request हुई। वह request को अच्छा नहीं बना सकता।

संकीर्ण कारण ठीक करें और सुधार साबित करें

सही सुधार intended task को जारी रखता है और यह भी बचाए रखता है कि original request क्यों रोकी गई थी। जो सुधार केवल popup हटाता है, उस पर संदेह करें।

Missing access में intended service से जुड़ा credential reference जोड़ें और पुष्टि करें कि external scope केवल आवश्यक operation की अनुमति देता है। वही narrow request फिर चलाएं। सुधार जांचने के लिए broad action «सिर्फ पक्का करने के लिए» न आजमाएं। Test को साबित करना चाहिए कि specific failed case अब चलता है और असंबंधित requests अब भी fail होती हैं।

Unexpected process में known agent entry point फिर चलाएं और उसकी identity की तुलना denied process से करें। Upgrade या wrapper के कारण expected process बदला हो तो बदलाव दर्ज करें और देखें कि identity अलग क्यों है। अगर कोई समझा नहीं सकता, तो permanent approval से बात न दबाएं। Agent tools child processes चला सकते हैं, लेकिन हर child को parent का authority नहीं मिलता।

Tool defect में अगले autonomous run से पहले interface बदलें। जहां संभव हो arbitrary destinations को fixed destination से बदलें। Arbitrary command text की जगह named operation दें। Sensitive parameter को agent के नियंत्रण से बाहर करें। फिर boundary के दोनों ओर test करें:

• Intended process और task के साथ supported request सफल हो।
• अलग destination, command या write operation अस्वीकृत हो।
• Activity record में घटना reviewer के लिए साफ दिखे।
• Session record से behavior बदलने पर run revoke किया जा सके।

Suspicious request में scope पर चर्चा करते हुए run जारी न रखें। Authority revoke करें, session और call records सुरक्षित रखें और request से पहले के instruction sources देखें। Untrusted content पढ़ने के बाद सामान्य task unsafe हो सकता है। Process को शुरुआत में approval मिली थी, इसका अर्थ यह नहीं कि बाद की हर action के लिए blank check मिल गया।

Sallyport projects run और call journals को एक write-blind, encrypted, hash-chained audit log में रखता है और Sessions journal से तुरंत run revocation देता है। जब request sequence समझ में आना बंद हो जाए, revocation का उपयोग करें। यह containment action है, run शुरू करने वाले developer पर फैसला नहीं।

Investigation के अंत में एक वाक्य लिखें जो अगले operator का मार्गदर्शन कर सके: «Agent के पास approved read operation के लिए staging status credential नहीं था, इसलिए हमने वह जोड़ा», या «Repository text का पालन करते हुए agent ने unapproved remote rebuild की कोशिश की, इसलिए हमने run रोक दिया और reviewed build action देंगे।» यदि ऐसा वाक्य नहीं लिख सकते, तो कारण अभी नहीं मिला है।

Denials को bypass करने से समझना आसान बनाएं

लोग controls bypass तब करते हैं जब investigation task के महत्व से ज्यादा महंगी लगती है। उत्तर कमजोर controls नहीं हैं। उत्तर ऐसे records और tool interfaces हैं जो legitimate रास्ता स्पष्ट और unusual रास्ता दिखाई देने योग्य बनाएं।

Task instructions की सीमा तय करें। Environment, intended external action और stopping condition लिखें। «Failed staging deploy की जांच करें और कारण बताएं» report के लिए जगह छोड़ता है। «Production को staging जैसा बना दें» बिना review के writes, credentials और system changes को आमंत्रित करता है।

Reviewer को एक निर्णय ठीक से लेने के लिए पर्याप्त context दें। Session approval में दिखना चाहिए कि process किसने शुरू किया और वह किस run से जुड़ा है। Sensitive action approval में operation और destination ऐसे शब्दों में दिखें जिन्हें human समझ सके। यदि reviewer को credential name decode करना, opaque URL trace करना और shell pipeline को मन ही मन चलाना पड़े, तो आपने security work को जल्दबाजी वाले click में बदल दिया है।

Recurring denials को volume से नहीं, cause से मापें। Unsupported endpoint चुनने के कारण रोकी गई दस requests tool problem बताती हैं। हर run में नया process दिखने के कारण रोकी गई दस requests identity या invocation problem बताती हैं। Task लगातार फैलने के कारण रोकी गई दस requests planning problem बताती हैं। केवल count बहुत कम जानकारी देता है।

Autonomous agents को ordinary scripts जैसा बनाने की कोशिश न करें। Scripts को authority इसलिए मिलती है क्योंकि human ने उनका exact behavior लिखा और review किया होता है। Agent run के दौरान behavior चुनता है और नया repository content, tool output तथा errors शामिल कर सकता है। इसलिए action gateway में human decision path और moment के बाद भी बचा रहने वाला record जरूरी है।

अगली denied call का परिणाम बेहतर task या बेहतर tool होना चाहिए, broader exception नहीं। टीम इस नियम को अपनाएगी तो denials सही कारण से कम होंगी: agent को स्पष्ट और सीमित authority मिलेगी और बाकी blocks ऐसे behavior की पहचान करेंगे जिसे रोकना उचित है।