# AI agent access pilot: expansion के योग्य metrics

Pilot को यह साबित करना चाहिए कि किसी AI agent को व्यापक authority देने से पहले लोग उसकी external actions को देख, समझ और रोक सकते हैं। इसका उद्देश्य केवल यह साबित करना नहीं होना चाहिए कि agent API call कर सकता है, SSH connection खोल सकता है या ticket जल्दी पूरा कर सकता है।

Teams अक्सर event counts का ढेर इकट्ठा करती हैं, घोषणा करती हैं कि कुछ भी नहीं बिगड़ा और access बढ़ा देती हैं। यह evidence नहीं है। उपयोगी measurements चार कठिन सवालों का जवाब देते हैं: क्या लोगों ने उन requests को समझकर approve किया, जिन्हें उन्होंने मंज़ूर किया? क्या controls ने सही requests को रोका? क्या agent ऐसी failures दोहराता रहा जो design flaw का संकेत थीं? और क्या कोई live run कितनी जल्दी बंद किया जा सकता था?

AI agent access pilot के लिए ऐसे कुछ ही measurements चाहिए जो decisions से जुड़े हों। Approval rate, blocked requests, repeated failures और revoke करने में लगा समय ट्रैक करें, लेकिन इनमें से किसी को अकेले score न मानें। आसपास के request, target, identity और outcome को हटाने पर हर metric आपको गुमराह कर सकता है।

## Pilot को control evidence के आधार पर विस्तार मिलता है

AI agent access pilot तभी expand करने के लिए तैयार है जब टीम allowed, denied और failed actions के sample को समझा सके और जरूरत पड़ने पर live session को रोक सके। Output quality evaluation का हिस्सा है, लेकिन वह control evidence की जगह नहीं ले सकती।

Pilot शुरू होने से पहले प्रस्तावित expansion को परिभाषित करें। वर्तमान authority, विचाराधीन अगली authority और उस बदलाव के external consequences लिखें। «Coding agent को हमारे issue tracker का उपयोग करने दें» कोई scope नहीं है। «इस signed local agent process को developer द्वारा शुरू किए गए runs के दौरान एक test project में issues बनाने की अनुमति दें» एक स्पष्ट scope है। इस अंतर से reviewers को ऐसी चीज़ मिलती है जिस पर वे निर्णय ले सकते हैं।

पहला pilot जानबूझकर सीमित रखें। Agent processes, human owners, target systems, credential paths और action types को सीमित करें। Narrow scope bureaucratic सावधानी नहीं है। इससे पता चलता है कि कोई अनपेक्षित request अस्पष्ट task, broken integration, confused agent या शुरुआत से बहुत व्यापक access का परिणाम है।

हर action के लिए उपयोगी pilot record इन सवालों का जवाब देता है:

- Request किस agent process ने किया और उसे किसने शुरू किया?
- उसने कौन-सा action करने को कहा और किस named target पर?
- किस access path या credential class ने उसे authorize किया?
- किसी व्यक्ति ने उसे allow या deny किया? क्यों?
- क्या result मिला, जिसमें external error भी शामिल है?

इस record को «agent ने tool इस्तेमाल किया» तक सीमित न करें। Issue पढ़ने का request और deployment settings बदलने का request दोनों HTTP का उपयोग कर सकते हैं, लेकिन उनके risks अलग हैं और review भी अलग होना चाहिए।

NIST SP 800-53 Rev. 5 के control AU-6 में audit review, analysis और reporting शामिल हैं। महत्वपूर्ण शब्द «review» है। Records सुरक्षित रखना पर्याप्त नहीं है, अगर कोई यह दोबारा नहीं समझ सकता कि request क्यों हुआ, किसने approve किया और वह सफल हुआ या नहीं। Agent pilot में audit data को access expansion पर decision लेने में मदद करनी चाहिए। अगर वह ऐसा नहीं कर सकता, तो वह evidence नहीं, केवल storage है।

ऐसी review cadence तय करें जिसे owners वास्तव में निभा सकें। हर active day के बाद छोटा review अक्सर महीने के अंत में होने वाले बड़े session से बेहतर होता है, क्योंकि task और surprises अभी ताज़ा रहते हैं। अजीब request को approve करने वाला व्यक्ति context समझा सकता है। Integration का owner failure को दोबारा पैदा कर सकता है।

किसी baseline के बिना «safe enough» की target संख्या तय न करें। इसके बजाय decision rules तय करें। उदाहरण के लिए, तब तक expansion न हो जब तक reviewers requests को initiating process से जोड़ न सकें, high-consequence actions के लिए tested revocation path न हो, या repeated failures का कारण स्पष्ट न हो। ऐसे rules बातचीत को आकर्षक dashboard के बजाय control quality पर केंद्रित रखते हैं।

## Approval rate review quality मापता है, trust नहीं

Approval rate बताता है कि requests को yes मिला या नहीं, लेकिन यह नहीं बताता कि वे yes समझकर दिए गए थे या नहीं। इसे उन requests की संख्या से approved requests को भाग देकर निकालें जिनमें human decision की ज़रूरत थी। Expired prompts, abandoned requests और automatic denials को अलग fields में रखें, चुपचाप हटाएं नहीं।

High rate का अर्थ हो सकता है कि agent सीमित और स्पष्ट environment में उचित work मांग रहा है। इसका अर्थ यह भी हो सकता है कि reviewers व्यस्त होने के कारण prompts पर जल्दी click कर रहे हैं, prompts में target नहीं दिया गया है या वही request इतनी बार आता है कि लोग पढ़ना बंद कर देते हैं। मैंने ऐसे approval systems देखे हैं जो कुछ ही दिनों में औपचारिकता बन गए, क्योंकि हर harmless call में वही सवाल पूछा जाता था। फिर टीम ने एक खतरनाक prompt को पिछले बीस harmless prompts की तरह ही approve कर दिया।

Approval rate को slices में पढ़ें। कम-से-कम action type, target class, session और reviewer को अलग करें। Read operations को account changes के साथ या test environment को production के साथ मिलाने पर average उस हिस्से को छिपा देता है जिस पर ध्यान देना चाहिए। Reads के लिए 95 प्रतिशत approval rate यह लगभग कुछ नहीं बताता कि लोग बाकी 5 प्रतिशत requests को ठीक से जांचते हैं या नहीं, जबकि वे requests state बदल सकते हैं।

हर सप्ताह एक छोटा sample review करें। कई approvals चुनें, जिनमें session के देर से आए एक approval और sensitive target वाला एक approval भी शामिल हो। Preserved record देखकर approving person से चार सवाल पूछें:

1. Agent क्या करना चाहता था?
2. Request किस process ने जारी किया?
3. कौन-सा external system उसे receive करने वाला था?
4. उस समय approval उचित क्यों था?

अगर basic सवालों के जवाब के लिए व्यक्ति को chat history, terminal scrollback या किसी दूसरे system को देखना पड़े, तो approval display में context की कमी है। अगर उन materials के बाद भी जवाब न मिले, तो access design उनसे ऐसे work को certify करने को कह रहा है जिसे वे समझते नहीं हैं।

Session authorization को sensitive action के approval से अलग रखें। Session authorization यह तय करता है कि नया शुरू हुआ process किसी agreed boundary के भीतर काम कर सकता है या नहीं। Per-action decision यह तय करता है कि इस खास operation पर ध्यान देना चाहिए या नहीं। Teams अक्सर इन दोनों decisions को मिला देती हैं और फिर कहती हैं कि उनके पास «human in the loop» है। हो सकता है उन्होंने process को केवल एक बार approve किया हो, लेकिन run के बीच में उसके work का स्वरूप बदलने का पता लगाने का कोई उपयोगी तरीका न हो।

उलटी गलती भी आम है: हर low-consequence action के लिए approval मांगना। इससे human decisions की अच्छी संख्या दिखती है, लेकिन review habit बेकार हो जाती है। Repetitive prompts को कम करने के लिए access path को सीमित या पुनर्गठित करें, लोगों को उन्हें जल्दी approve करना न सिखाएं।

Denominator को ईमानदारी से record करें। अगर agent approval path के बाहर authority हासिल करता है, तो वे calls pilot record में exception के रूप में शामिल होने चाहिए, भले ही call सफल हुआ हो। Bypasses को denominator से हटाने वाला metric controls को परिभाषा के अनुसार बेहतर दिखाता है।

## Denial के साथ कारण और verified outcome होना चाहिए

Blocked requests दिखाते हैं कि boundary pilot के बाहर के work को पकड़ती है या नहीं, लेकिन तभी जब block का कारण classify किया गया हो। हर denial को जीत मान लेना कुछ भी न सीखने का आसान तरीका है।

ऐसी cause taxonomy इस्तेमाल करें जो operator की अगली action से मेल खाए। अधिकांश pilot cases के लिए चार categories पर्याप्त हैं:

- Session authorize नहीं था या समाप्त हो चुका था।
- Requested action के लिए explicit approval चाहिए था और व्यक्ति ने उसे deny कर दिया।
- Access path उपलब्ध नहीं था क्योंकि उसका local vault या gate locked था।
- Request उस access से मेल नहीं खाता था जिसे pilot ने जानबूझकर दिया था।

Locked local vault के बाद हुआ denial दिखाता है कि किसी ने hard boundary बनाए रखी। User द्वारा request reject करने पर हुआ denial यह बता सकता है कि agent अपने task से आगे बढ़ गया, या request का description बहुत अस्पष्ट था। Scope से बाहर target के कारण हुआ denial अच्छी boundary दिखा सकता है, लेकिन incomplete design भी उजागर कर सकता है। इन कारणों को एक «blocked» bar में न मिलाएं।

इसके बाद external result verify करें। Control decision तभी महत्वपूर्ण है जब उस route से external action न हुआ हो। API call के लिए attempted method, endpoint category और returned error सुरक्षित रखें। SSH command के लिए audit design के अनुरूप requested host और command context सुरक्षित रखें। अगर architecture decision point से पहले work issue कर सकता है, तो यह न मानें कि local refusal का अर्थ remote side ने कुछ नहीं देखा।

यहीं teams prevented और failed के बीच का अंतर समझती हैं। Prevented request service तक पहुंचा ही नहीं, क्योंकि access boundary ने उसे रोक दिया। Failed request service तक पहुंचा और उसे error मिला। दोनों की review ज़रूरी है, लेकिन दोनों अलग कहानियां बताते हैं। हर 403 को successful block कहना इस बात को छिपा सकता है कि agent बार-बार उस resource को बदलने की कोशिश कर रहा है जिसे access design ने गलती से network के सामने खोल दिया है।

Denial होने पर वास्तविक review sequence अपनाएं:

1. Agent run ढूंढें और उस process की पहचान करें जिसने request जारी किया।
2. Requested operation और target पढ़ें, फिर उन्हें original task से मिलाएं।
3. Confirm करें कि external action होने से पहले control ने request रोक दिया था।
4. Cause तय करें: task ambiguity, prompt behavior, missing capability, incorrect access scope या attempted boundary violation।
5. तय करें कि task, agent setup, access grant में बदलाव करना है या कुछ नहीं।

आखिरी विकल्प महत्वपूर्ण है। कुछ blocked requests blocked ही रहने चाहिए। Pilot अक्सर टीम को हर failed attempt के बाद access देने के लिए प्रेरित करता है, क्योंकि boundary तक पहुंचने से पहले agent productive दिख रहा था। इससे design की जगह drift आ जाता है।

Denial clusters पर ध्यान दें। नए agent release के बाद एक endpoint पर दस denials अक्सर integration assumption की ओर इशारा करते हैं। अलग-अलग targets पर दस denials ऐसे agent task का संकेत हो सकते हैं जो model को बहुत अधिक स्वतंत्रता देता है। Reviewer द्वारा उसी intent को reject करने के बाद repeated denied requests मिलें, तो स्पष्ट कदम उठाएं: session रोकें, record सुरक्षित रखें और फिर retry करने से पहले task तथा tool instructions की जांच करें।

## Repeated failures access बढ़ाने के असुरक्षित दबाव को उजागर करती हैं

Repeated failed requests शुरुआती warning हैं कि agent, उसके instructions या access route में mismatch है। इन्हें एक raw total के रूप में नहीं, fingerprint के आधार पर गिनें।

एक उपयोगी fingerprint में operation category, target, error class, agent version या configuration और छोटी time window शामिल होती है। इससे एक transient service outage और ऐसे agent के बीच अंतर पता चलता है जो उसी unauthorized command को बीस बार retry करता है। यह भी दिखता है कि नए prompt या tool update से behavior बदला या नहीं।

Retries को इस बात का evidence न मानें कि agent को सचमुच access grant की ज़रूरत है। Agents इसलिए repeat करते हैं क्योंकि उनका planning loop उसी apparent next move को ढूंढता रहता है। केवल पांच बार decision का सामना करने से loop आपके risk decision को नहीं समझता। Retries खत्म करने के लिए credential देना टीम को यह सिखाता है कि agent के pressure पर access बढ़ाया जाए।

हर repeated failure की पहली और आखिरी occurrence की जांच करें। पहली occurrence original assumption बताती है। आखिरी यह बताती है कि agent ने strategy बदली, रुका या attempts बढ़ाए। यह अंतर महत्वपूर्ण है। Error समझकर permitted alternative action लेने वाले agent को बेहतर tool description की ज़रूरत हो सकती है। Prohibited host को probe करते रहने वाले agent को narrower task और session stop की ज़रूरत हो सकती है।

हर repeated failure group के लिए चार fields track करें: attempt count, elapsed time, result class और human response। Human response field अक्सर छोड़ दिया जाता है, जिससे गलत impression बनता है कि error अपने-आप समाप्त हो गया। हो सकता है किसी ने prompt बदला हो, access दिया हो, agent restart किया हो या session revoke किया हो। ये interventions result को समझाते हैं।

External service से लौटने वाली failure हमेशा access problem नहीं होती। Authentication errors खराब credential route बता सकती हैं। Validation errors अक्सर malformed agent input का संकेत होती हैं। Rate limits uncontrolled retry behavior दिखा सकती हैं। Network errors service conditions की ओर इशारा कर सकती हैं। हर category को अलग तरह से संभालें। Validation errors हल करने के लिए broader permissions देने वाली टीम अधिक exposure बनाएगी और requests फिर भी broken रहेंगी।

Universal number के बजाय pattern पर आधारित practical escalation threshold तय करें। उदाहरण के लिए, जब वही agent session किसी sensitive target पर human द्वारा reject किए गए access denial को दोहराए, तो तुरंत review करें। जब नई configuration external service पर errors की burst पैदा करे, तब review करें। जब service स्पष्ट रूप से caller को रुकने के लिए कहने के बाद retries जारी रहें, तब review करें। ये behavior rules हैं, vanity metrics नहीं।

Raw data के साथ छोटा decision log रखें। «Endpoint construction ठीक किया», «Access denied ही रखा» या «Run समाप्त किया और task boundary फिर से लिखी» जैसे notes लिखें। इससे pilot cumulative बनता है। इसके बिना हर weekly review उसी error pattern को फिर से खोजता है और उसे नई finding कहता है।

## Revocation time में discovery और proof भी शामिल होने चाहिए

Time to revoke containment को मापता है, और containment उस समय शुरू होता है जब किसी को समझ आता है कि run रोकना ज़रूरी है। पहले actionable signal से उस समय तक का interval मापें जब यह confirm हो जाए कि run कोई और authorized action नहीं कर सकता।

Revoke नाम वाला button तेज़ी से काम कर सकता है। यह उपयोगी है, लेकिन interval का केवल एक हिस्सा है। वास्तविक incident में engineer अजीब request देखता है, यह पहचानता है कि कौन-सा session उसका owner है, उसे रोकने का अधिकार ढूंढता है, action करता है और जांचता है कि agent आगे नहीं बढ़ सकता। अगर session identity स्पष्ट नहीं है, तो उसे खोजने में लगा समय भी metric में शामिल होना चाहिए।

Drill के दौरान ये timestamps record करें:

- Suspicious action review record में दिखाई दिया।
- किसी named person ने run revoke करने का निर्णय लिया।
- उस व्यक्ति ने revocation जारी की।
- System ने revocation record की।
- उसी run से किया गया controlled follow-up request deny हुआ।

आखिरी check proof है। Agent process रोककर और access समाप्त मानकर revocation test न करें। Process termination stale authorizations, दूसरे process, queued work या गलत session revoke करने वाले operator को छिपा सकती है। Test scope के भीतर harmless operation का उपयोग करें और verify करें कि revocation के बाद boundary उसे reject करती है।

यह drill सामान्य काम के दौरान चलाएं, केवल उस समय नहीं जब controls बनाने वाला व्यक्ति उपलब्ध हो। यह task ऐसे व्यक्ति को दें जिसने pilot configure नहीं किया है। अगर वह record से live run की पहचान नहीं कर सकता, तो process tribal knowledge पर बहुत निर्भर है। तेज़ revocation path जिसे केवल एक engineer इस्तेमाल कर सकता है, team को meaningful containment नहीं देता।

Session revoke करने और credential rotate करने में अंतर रखें। Session revocation एक active agent run को रोकती है। Credential rotation secret या authority को ही बदलती है और उसे share करने वाले legitimate work को प्रभावित कर सकती है। गंभीर event में दोनों की ज़रूरत हो सकती है, लेकिन दोनों अलग समस्याएं हल करते हैं। उन्हें एक ही action की तरह मापने पर targeted response धीमा और broad response efficient दिखाई देगा।

Sallyport agent runs के लिए Sessions journal रखता है, जिसमें instant revoke उपलब्ध है। इसके साथ individual calls के लिए Activity journal है। Pilot में यह separation run ढूंढने, उसे revoke करने और बाद के call record की पुष्टि करने का अभ्यास कराती है, बिना session control को credential replacement समझे।

Drill खराब होने पर भी उसका result सुरक्षित रखें। लंबा interval ऐसी fixable कमजोरी दिखाता है जैसे अस्पष्ट ownership, अपर्याप्त session labeling, missing notifications या ऐसा revocation action जिसे लोग पहुंच ही नहीं सकते। Failed drills छिपाने से पहली वास्तविक urgent revocation उस test में बदल जाती है जिसे आपको पहले ही चलाना चाहिए था।

## Audit records को असहमति के बाद भी टिकना चाहिए

Audit trail तभी मददगार है जब skeptical reviewer उसे export करने वाले व्यक्ति पर भरोसा किए बिना उसकी बात verify कर सके। Agent access pilots में यह गुण ज़रूरी है, क्योंकि authorization disputes बाद में सामने आते हैं, जब memories और terminal history बदल चुकी होती हैं।

हर sampled event के लिए reviewer को initiating agent run, authorization decision, action request, external result और बाद की revocation, अगर हुई हो, को आपस में जोड़ पाना चाहिए। Ordering सुरक्षित रखें। Clocks अलग हों या events देर से आएं, तो केवल timestamp misleading हो सकता है। Signed या protected record के भीतर sequence reviewer को reconstruction का आधार देता है।

कठिन अंतर activity log और tamper-evident audit record के बीच है। Activity log बताता है कि application अभी क्या दिखा रही है। Tamper-evident record आपको बदली, हटाई या reorder की गई history का पता लगाने देता है। जब pilot evidence के आधार पर wider access देना हो, तो दूसरे प्रकार के record की ज़रूरत होती है।

Sallyport अपने Sessions और Activity journals को encrypted hash-chained audit log से project करता है। इसका `sp audit verify` command vault key के बिना offline chain check करता है। Verification को केवल विवाद के बाद नहीं, बल्कि review routine का हिस्सा बनाएं। जो check कोई करता ही नहीं, उसका confidence पर कोई असर नहीं होता।

```text
sp audit verify
```

Verification result को review record के साथ रखें और वह time range लिखें जिसे उसने cover किया। अगर verification कोई समस्या बताती है, तो जांच पूरी होने तक उस log को normal operation के proof की तरह इस्तेमाल करना बंद करें। Readable entries को चुपचाप export करके spreadsheet के साथ आगे न बढ़ें। इससे केवल appearance बचती है और evidence का वही गुण खो जाता है जिसकी आपको ज़रूरत थी।

Audit records review fatigue भी दिखा सकते हैं। Prompt और approval के बीच का समय, request context और बाद के outcome की तुलना करें। Extremely fast approval अपने-आप carelessness नहीं बताता, खासकर familiar low-consequence work में। लेकिन unfamiliar targets और sensitive actions पर instant approvals का pattern reviewer के साथ बातचीत और prompts के redesign की मांग करता है।

Oversight में मदद मिलती है, इसलिए हर व्यक्ति को raw audit content का unrestricted access न दें। Agent activity में repository names, hostnames, request metadata और task details हो सकते हैं। तय करें कि इसे कौन review करेगा, कौन export कर सकता है और disputes कौन resolve करेगा। Audit visibility पर control भी access design का हिस्सा है।

## Weekly review का परिणाम decisions होना चाहिए, charts नहीं

Weekly pilot review का अंत scope, fixes और ownership पर स्पष्ट decisions के साथ होना चाहिए। अगर वह dashboard tour पर खत्म होता है, तो team ने risk posture बदले बिना activity मापी है।

एक compact packet लाएं: approvals का छोटा sample, sensitive action से जुड़े हर denial, top repeated failure groups, latest revocation drill और audit verification result। यह serious review के लिए पर्याप्त material है और लोगों को हर routine read request से नहीं गुजरना पड़ता।

हर owner से decision मांगें। Task owner तय करता है कि agent का requested work assigned task से मेल खाता था या नहीं। System owner तय करता है कि target access अभी भी उचित है या नहीं। Access mechanism का जिम्मेदार व्यक्ति तय करता है कि control ने अपेक्षा के अनुसार काम किया या नहीं। छोटी team में एक व्यक्ति कई roles निभा सकता है, फिर भी उन्हें नाम दें। Unnamed responsibility collective inattention बन जाती है।

Decisions plain language में लिखें। «Approved sessions के लिए pilot project में issue creation की अनुमति दें» testable है। «Guardrails सुधारें» testable नहीं है। हर change के साथ ऐसा measurement जोड़ें जो बताए कि वह काम कर रहा है या नहीं। अगर low-consequence reads के prompts कम करें, तो remaining approvals का sample लेकर देखें कि consequential actions के लिए लोगों को अब पर्याप्त context मिल रहा है या नहीं। अगर retry handling बदलें, तो देखें कि repeated failures सचमुच कम हुई हैं और blocked requests में नई बढ़ोतरी नहीं हुई।

सभी dimensions को एक साथ expand न करें। Targets बढ़ाना, write actions जोड़ना, अधिक agent processes स्वीकार करना और उसी सप्ताह approvals हटाना attribution नष्ट कर देता है। कुछ गलत होने पर कोई नहीं जानता कि उसका कारण कौन-सा change था। एक authority dimension expand करें, उसे एक review cycle में observe करें और rollback path बनाए रखें।

Pilot का अंत expansion न करने के decision के साथ भी हो सकता है। जब measurements दिखाएं कि team requests review, sessions contain या failures explain नहीं कर सकती, तब यह सफल result है। खराब परिणाम यह दिखावा करना है कि access व्यापक होने और agent runs बढ़ने के बाद ये gaps अपने-आप गायब हो जाएंगे।

## Broader authority को किसी specific passed test के बाद आना चाहिए

Access तभी expand करें जब प्रस्तावित नई authority current pilot के भीतर concrete test पास कर चुकी हो। Test उस consequence जैसा होना चाहिए जिसे आप अनुमति देने की योजना बना रहे हैं, किसी सुविधाजनक substitute जैसा नहीं।

अगर आप higher-consequence API action की अनुमति देना चाहते हैं, तो ऐसे requests पर reviewers को test करें जिनमें वही target context और approval burden हो। अगर आप agent को अधिक hosts पर SSH access देना चाहते हैं, तो पहले representative nonproduction host पर attribution, denial handling और revocation test करें। Read-only pilot यह साबित नहीं कर सकता कि लोग external state में बदलावों को सही ढंग से संभालेंगे।

Expansion decision को ऐसे claim के रूप में लिखें जिसे evidence गलत साबित कर सके: «Team इस action class को पर्याप्त context के साथ authorize कर सकती है, अपने task से बाहर के request का पता लगा सकती है और agreed response window के भीतर initiating session revoke कर सकती है।» फिर approvals, denials, failures, revocation drill और audit record को उस claim के सामने जांचें।

Approval percentage बढ़ने के कारण pilot को promote न करें। यह इसलिए बढ़ा हो सकता है क्योंकि reviewers prompts के अभ्यस्त हो गए, agent ने कठिन work मांगना बंद कर दिया या team ने चुपचाप denials को denominator से हटा दिया। Promotion के लिए representative evidence और exceptions का record चाहिए।

पहली action सरल और साधारण है: एक current agent run चुनें, एक approved call और एक denied या failed call को trace करें, फिर controlled drill में उसी run को revoke करें। अगर आपकी team इन events को reconstruct करके यह साबित नहीं कर सकती कि run ने authority खो दी, तो wider access देना जल्दबाज़ी होगी।