AI agent refresh tokens को कैसे नियंत्रित करें

AI agent के पास कभी भी refresh token नहीं होना चाहिए। यह नियम तब तक कठोर लगता है, जब तक आप यह नहीं देखते कि token करता क्या है: मूल human approval लोगों की नज़र से ओझल हो जाने के बाद भी कोई process access लेता रह सकता है। Access token जल्दी expire हो सकता है, लेकिन refresh token उस संबंध को बनाए रखता है।

सही तरीका यह नहीं है कि agent को bearer credential सुरक्षित रखने में बेहतर बनाया जाए। Credential को ऐसी action layer में रखें, जिसका नियंत्रण human-owned process के पास हो। Agent किसी खास external action का अनुरोध करे, layer तय करे कि उस run को वह कार्रवाई करने की अनुमति है या नहीं, ज़रूरत पड़ने पर ही refresh करे और परिणाम लौटाए। इससे approval, revocation और हर इस्तेमाल की जाँच के लिए स्पष्ट जगह मिलती है।

केवल password vault इस समस्या को हल नहीं करता। Vault storage की सुरक्षा करता है। Agent action layer इस्तेमाल को नियंत्रित करती है। Teams अक्सर इन दोनों कामों को मिला देती हैं और बाद में पाती हैं कि encrypted store में रखा token अब भी उस हर process के लिए उपलब्ध है जो store से सही सवाल पूछ सकता है।

AI agent refresh tokens trust boundary बदल देते हैं

AI agent refresh tokens खतरनाक हैं, क्योंकि वे authority को उस agent process से आगे बढ़ा देते हैं जिसे पहले उनकी ज़रूरत थी। अगर coding agent environment variable, configuration file, browser profile या secret manager response से refresh token पढ़ सकता है, तो वह अपने लिए उपलब्ध किसी भी HTTP client के ज़रिए उसका इस्तेमाल कर सकता है। Token अब सीमित task से जुड़ा नहीं रहता। वह उस process पर नियंत्रण पाने वाली किसी भी चीज़ का हो जाता है।

OAuth 2.0, RFC 6749, refresh tokens को ऐसे credentials बताता है जिनसे मौजूदा token expire या invalid होने पर access tokens लिए जाते हैं। Specification इन्हें optional रखती है, लेकिन इसका मतलब यह नहीं कि वे harmless हैं। Providers इन्हें इसलिए जारी करते हैं क्योंकि हर access token renewal पर interactive authorization करना थकाऊ होगा। यही सुविधा बताती है कि unattended agent के पास refresh token क्यों नहीं होना चाहिए।

इन तीन भूमिकाओं को अलग रखें:

• Account owner वह व्यक्ति या service identity है जिसके account ने access दिया।
• Action requester वह agent process है जो अभी API call करने का अनुरोध कर रहा है।
• Credential custodian वह component है जो refresh token रखता है और token endpoint से बात करता है।

छोटे setup में एक व्यक्ति या program एक से अधिक भूमिकाएँ निभा सकता है, लेकिन भूमिकाएँ फिर भी मौजूद रहनी चाहिए। अगर वही agent तीनों भूमिकाएँ निभाता है, तो वह नया account जोड़ सकता है, scope बढ़ा सकता है, अनिश्चित समय तक refresh कर सकता है और कार्रवाई को सामान्य requests के बीच छिपा सकता है। यह authorization design नहीं है। यह chatbot से जुड़ा bearer token है।

मैंने teams को यह कहते सुना है कि «agent को केवल read access चाहिए», और फिर वे broad repository, email या cloud access वाला refresh token स्थानीय .env file में रख देते हैं। Access token की अवधि कम हो सकती है, लेकिन refresh token गलती को स्थायी बना देता है। Prompt injection को model से password चुराने के लिए मनाने की ज़रूरत नहीं होती। वह model को context में plausible दिखने वाली request के लिए अब भी valid grant इस्तेमाल करने के लिए उकसा सकता है।

Boundary credentials के agent process में पहुँचने से पहले होनी चाहिए। Agent को न token value मिले, न ऐसा नकली placeholder मिले जिसे वह कहीं और exchange कर सके। उसे operation interface मिले: यह issue fetch करो, यह draft बनाओ, इस deployment का status पढ़ो, इस approved host से SSH session खोलो। उस operation के पीछे protocol details action layer संभाले।

Grant का मालिक human होना चाहिए, केवल prompt को approve करने वाला नहीं

Refresh को approve करने वाले व्यक्ति का नाम OAuth connection बनने से पहले तय होना चाहिए। «कोई भी developer allow पर click कर सकता है» तब तक ठीक लगता है, जब तक account owner कंपनी छोड़ न दे, shared mailbox किसी और के पास न चला जाए या agent किसी और की identity से service reconnect न कर दे।

Personal SaaS account के लिए account owner initial authorization पूरी करे और revocation या expiry के बाद reconnection को approve करे। Shared operational account के लिए accountable owner और उसे revoke कर सकने वाला backup तय करें। Machine identity के लिए service owner उसके client registration और scopes को authorize करे। केवल इसलिए व्यक्ति और machine identity को एक जैसा न मानें कि दोनों एक ही API call कर सकते हैं।

अक्सर एक browser click में समा जाने वाले इन चार फैसलों को अलग रखें:

1. मूल grant कौन बना सकता है।
2. परिणामस्वरूप मिले refresh token को कौन-सी action layer रख सकती है।
3. कौन-से agent sessions उस grant के तहत actions माँग सकते हैं।
4. Grant revoke करने या नया connection approve करने का अधिकार किसके पास है।

मूल OAuth consent screen केवल पहले फैसले का उत्तर देती है, और कभी-कभी वह भी अधूरा। वह provider को बताती है कि account holder ने बताए गए scopes वाले client को authorize किया है। वह आपके local system को यह नहीं बताती कि untrusted repository, नया agent subprocess या रातभर चलने वाला job उस grant का इस्तेमाल कर सकता है या नहीं।

एक उपयोगी ownership record में provider account email से अधिक जानकारी होनी चाहिए। Opaque grant ID, provider name, account reference, scope set, owner, backup revoker, connection date और उन actions का record रखें जिन्हें इसके लिए अनुरोध किया जा सकता है। Refresh token को इस record में copy न करें। Record token की व्याख्या करे, दूसरा secret store न बने।

Shared access सबसे कठिन स्थिति है। Team अक्सर सुविधा के लिए एक administrator account जोड़ती है और फिर हर developer के agent को उसी identity के तहत काम करने देती है। इससे accountability खत्म हो जाती है। अगर API service accounts, app installations, delegated identities या सीमित project tokens देती है, तो उनका इस्तेमाल करें। अगर ऐसा विकल्प नहीं है, तो action layer को approved operations के छोटे समूह तक सीमित रखें और shared account के वास्तविक owner का record रखें।

Agent को अपने-आप नया OAuth browser flow शुरू करने की अनुमति न दें। वह legitimate provider page दिखा सकता है, लेकिन human को व्यापक account, बड़े scope selection या किसी दूसरे tenant की ओर भी मोड़ सकता है। Connection शुरू करना administrative action है। इसे action layer से human द्वारा शुरू करवाएँ और consent से पहले account तथा scope list की जाँच कराएँ।

Action layer को approved action पूरा करने के लिए ही refresh करना चाहिए

Controlled action layer refresh token को तभी exchange करे, जब उसके पास ऐसा authorized request हो जिसके लिए current access token ज़रूरी है। उसे «just in case» हर credential refresh करने वाला background loop नहीं चलाना चाहिए। Preemptive refresh code में व्यवस्थित दिखता है, लेकिन incident response को कठिन बनाता है, क्योंकि वह किसी human या agent action के बिना grants को जीवित रखता है।

Request path सरल रह सकता है:

1. Agent session किसी named operation का अनुरोध करे और सामान्य action parameters दे।
2. Action layer उस operation से जुड़ा grant पहचाने और जाँचे कि session उसका इस्तेमाल कर सकता है या नहीं।
3. Cached access token न हो या expiry करीब हो, तो layer refresh token provider के token endpoint को भेजे।
4. Layer access token से destination API call करे और filtered result agent को लौटाए।
5. Layer credential material दर्ज किए बिना action और refresh event record करे।

Agent कभी token endpoint, client identifier, callback URL या scope string खुद न चुने। ये values उस connection definition का हिस्सा हैं जिसे human ने approve किया है। Agent को ये values देने से आपका gateway open token relay बन जाता है।

मान लीजिए agent से project tracker में release note पोस्ट करने को कहा गया। वह action layer से named project में एक issue बनाने का अनुरोध करता है। Layer देखती है कि इस operation के लिए उस project का tracker grant चाहिए, requesting session की जाँच करती है, ज़रूरत होने पर access token renew करती है और note पोस्ट करती है। परिणाम provider से लौटने वाला नया issue ID और URL-जैसा reference हो सकता है, वह bearer token नहीं जिससे issue बनाया गया।

अब prompt बदलें। कोई malicious repository instruction agent से कहती है कि «access verify» करने के लिए organization के हर project की सूची बनाए और हर project में test issue बनाए। Agent के पास refresh token हो तो instruction सीधे API calls की श्रृंखला बन सकती है। Agent के पास केवल named operation interface हो तो layer approved project से बाहर के requests अस्वीकार कर सकती है या session आगे बढ़ने से पहले दूसरी human authorization माँग सकती है।

इसके लिए जटिल policy language ज़रूरी नहीं है। आपको कुछ छोटे और समझने योग्य फैसले चाहिए: अनुरोध कौन-सा process कर रहा है, कौन-सा grant इस्तेमाल किया जा सकता है और इस action के लिए human approval चाहिए या नहीं। अधिक options design को अपने-आप सुरक्षित नहीं बनाते। अक्सर operator के लिए यह समझना असंभव हो जाता है कि कौन-सा rule लागू हुआ।

Sallyport इसी अलगाव का पालन करता है। वह API credentials अपने encrypted vault में रखता है और credentials agent को लौटाने के बजाय अपने MCP connection के ज़रिए HTTP या SSH actions चलाता है।

Grant type तय करता है कि automation कितनी सुरक्षित हो सकती है

Desktop या local application में human account connection के लिए authorization code flow with PKCE इस्तेमाल करें। Human provider पर sign in करता है, consent request देखता है और registered redirect path के ज़रिए local application पर लौटता है। PKCE authorization response को flow शुरू करने वाले client से बाँधता है और intercepted authorization code की उपयोगिता घटाता है।

RFC 9700, OAuth 2.0 Security Best Current Practice, कहता है कि public clients को PKCE इस्तेमाल करना चाहिए। यह भी कहता है कि public-client refresh tokens को sender constraint या refresh token rotation में से किसी एक का इस्तेमाल करना चाहिए। Agent integrations में यह सलाह महत्वपूर्ण है, क्योंकि local application अक्सर public client की तरह व्यवहार करता है। Desktop app में client secret भेजने से वह confidential client नहीं बन जाता। App रखने वाला कोई भी व्यक्ति वह secret निकाल सकता है।

जिस identity को जोड़ रहे हैं, उसी के अनुसार flow चुनें:

• Human के provider account के लिए authorization code with PKCE इस्तेमाल करें।
• ऐसे service identity के लिए client credentials इस्तेमाल करें जिसे provider support करता हो और जिसके लिए human account delegation की ज़रूरत न हो।
• जब provider इससे project या organization तक अधिक सीमित access देता हो, तो उसका installation या application model चुनें।
• Device authorization तभी इस्तेमाल करें जब provider और operating environment इसकी माँग करें, और human को ठीक-ठीक दिखाएँ कि वह किस identity और scope set को approve कर रहा है।

Client credentials से आम तौर पर refresh tokens नहीं मिलते, क्योंकि client दोबारा authenticate करके नया access token माँग सकता है। अगर service identity की permissions सीमित हों और client authentication material action layer के भीतर रहे, तो autonomous job के लिए यह अधिक सुरक्षित हो सकता है। Client credentials को coding agent को broad privileges वाला client secret देने का बहाना न बनाएँ।

Offline access पर खास ध्यान दें। कुछ OpenID Connect providers refresh token जारी करने से पहले offline_access scope माँगते हैं। इसे तभी माँगें जब interactive session खत्म होने के बाद सचमुच कोई action चलना हो। अगर हर operation के समय कोई व्यक्ति मौजूद रहेगा, तो fresh authorization वाला छोटा access token अधिक उपयुक्त हो सकता है। Teams अक्सर expiry संभालने से बचने के लिए default रूप से offline access माँगती हैं। इससे असुविधा की जगह durable credential आ जाता है।

Resource owner password credentials से पूरी तरह बचें। RFC 9700 इस grant को deprecate करता है, क्योंकि इसमें user का password client को देना पड़ता है। Action layer इसे स्वीकार्य नहीं बनाती। वह केवल password खोने की एक और जगह बनाती है।

Rotation तभी उपयोगी है जब storage replacement को सही ढंग से संभाले

Refresh token rotation copied token से होने वाले नुकसान को घटाती है, क्योंकि हर सफल refresh पिछला token बदल देता है। Provider पुराने token के reuse का पता लगाकर प्रभावित grant family को invalidate कर सकता है। यह detection उपयोगी है, लेकिन आपकी refresh logic खराब हो तो legitimate integration को भी lock out कर सकती है।

सबसे आम failure race है। दो agent sessions लगभग एक ही समय access token चाहते हैं। दोनों वही पुराना refresh token पढ़ते हैं। पहला session सफलतापूर्वक refresh करके नया value पाता है। दूसरा कुछ क्षण बाद पुराने value को submit करता है। Provider के अनुसार दूसरा request fail हो सकता है या reuse detection सक्रिय करके पूरी family revoke कर सकता है, जिसमें नया token भी शामिल हो।

हर grant के लिए एक refresh owner रखकर race रोकें। Action layer को हर grant ID के लिए refresh work serialize करना चाहिए। दूसरा caller पहले refresh के परिणाम का इंतज़ार करे और दूसरा token request भेजने के बजाय नया cached access token इस्तेमाल करे। यह optimization नहीं, correctness requirement है।

Future work के लिए refresh को सफल मानने से पहले replacement token store करें। सुरक्षित क्रम इस तरह है:

1. पुराने refresh token को TLS के ज़रिए token endpoint पर भेजें।
2. Token response की जाँच करें और उसे अपेक्षित provider तथा grant से जोड़ें।
3. नए refresh token और metadata को encrypted storage में एक durable update के रूप में लिखें।
4. Local state में पुराने token को unusable चिह्नित करें।
5. Waiting calls को नए access token या नए request path के साथ आगे बढ़ाएँ।

अगर provider token rotate करने के बाद process crash हो जाए और local storage replacement record करने से पहले रुक जाए, तो grant खो सकता है। Retries से यह ठीक नहीं होगा। Recovery path human-led reconnection है, इसलिए owner और revoker records महत्वपूर्ण हैं।

कुछ providers कभी-कभी नया refresh token देते हैं। दूसरे वही token लौटाते हैं। आपका code दोनों व्यवहार स्वीकार करे और किसी एक को मानकर न चले। Provider response और durable write सफल होने तक पिछली value को ही रखें। Debugging के दौरान किसी भी value को log न करें। कई token leaks एक अस्थायी debug statement से शुरू होते हैं जो release में रह जाता है।

Sender-constrained tokens token को client के पास मौजूद cryptographic key से बाँधकर replay risk घटा सकते हैं। RFC 9449 में परिभाषित DPoP एक तरीका है। इससे custody की ज़रूरत खत्म नहीं होती। अगर agent के पास refresh token और private signing key दोनों का इस्तेमाल है, तो उसके पास अब भी durable authority है। दोनों materials को action layer के पीछे रखें और constraint पर निर्भर होने से पहले provider का व्यवहार test करें।

Revocation के लिए named operator और tested path चाहिए

Revocation कोई ऐसी setting नहीं है जिसे एक बार enable करके भूल जाएँ। यह ऐसी कार्रवाई है जिसे किसी को दबाव के समय कर पाना चाहिए, जब provider dashboard धीमा हो और किसी को याद न हो कि किस account ने integration authorize की थी।

Account owner और designated backup को direct revocation path दें। Grant revoke करने पर action layer को स्थानीय refresh token हटाना, cached access tokens invalidate करना और उन sessions को रोकना चाहिए जो उस grant का अनुरोध जारी रख सकती हैं। Agent का user interface बंद कर देना और credential को stored छोड़ देना अधूरा revocation है।

RFC 7009 OAuth token revocation request को परिभाषित करता है। Provider अपना endpoint प्रकाशित करता है, लेकिन request आम तौर पर ऐसी दिखती है:

POST /revoke HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client authentication>

token=<refresh-token>&token_type_hint=refresh_token

RFC 7009 servers से कहता है कि submitted token पहले से invalid या unknown होने पर भी successful response लौटाएँ। इससे attacker endpoint का इस्तेमाल token validity oracle की तरह नहीं कर सकता। इसका मतलब यह भी है कि operator केवल HTTP success देखकर यह साबित नहीं कर सकता कि grant के पास active access था। Record करें कि revocation request भेजी गई, local credential हटाएँ और फिर harmless provider call या उपलब्ध provider audit trail से जाँच करें।

इन घटनाओं के लिए revocation तैयार रखें: account owner का जाना, agent session के compromise का संदेह, repository instruction से unexpected external call, integration का retire होना या provider द्वारा token reuse report करना। Leak होने तक यह तय करने का इंतज़ार न करें कि button दबाने का अधिकार किसके पास है।

पहले जारी किया गया access token expire होने तक usable रह सकता है। कुछ providers उसे तुरंत revoke करते हैं, कुछ नहीं। आपकी local layer नए actions देना तुरंत रोक सकती है, और यही वह control है जो आपके हाथ में है। Provider के दस्तावेज़ और आपके test के बिना instant global invalidation का वादा न करें।

Provider revocation को local disablement से अलग रखें। Local disablement action layer को grant इस्तेमाल करने से रोकता है। Provider revocation provider से भी उसे reject करने को कहता है। Incident में दोनों करें, इस क्रम में: पहले अपना execution path बंद करें, फिर provider request भेजें। पहला कदम आपके नियंत्रण में है और बाहरी network call पर निर्भर नहीं होना चाहिए।

Audit record को केवल traffic नहीं, intent भी समझाना चाहिए

HTTP calls की सूची यह नहीं बता सकती कि refresh उचित था या नहीं। आपको ऐसा record चाहिए जो human decision, requesting agent session, grant reference और resulting external action को जोड़ सके।

Refresh tokens, access tokens, authorization codes, client assertions या पूरे API bodies को audit log में न लिखें। Token strings secrets हैं। Full response bodies में customer data, repository contents या personal information हो सकती है। सुविधा के लिए उन्हें log करना दूसरा, अधिक अव्यवस्थित credential और data store बना देता है।

उपयोगी event record में event ID, समय, session ID, requesting process identity, grant ID, connected account reference, operation name, provider host, requested resource, connection के समय record किया गया scope set, approval reference, result class और error होने पर error code शामिल हो। Refresh के लिए यह record करें कि refresh हुआ और सफल रहा या नहीं। जाँच के लिए token value की ज़रूरत नहीं है।

Action record और credential record का अंतर महत्वपूर्ण है। Action record कहता है कि किसी खास agent session ने named environment से deployment status माँगा और action layer ने उसे अनुमति दी। Credential record बताता है कि उस request को कौन-सा grant support करता था और उसका owner कौन है। दोनों को opaque grant ID से जोड़ा जा सके, लेकिन हर action-history operator को account connection details देखने की अनुमति न दें।

Tamper evidence investigation की गुणवत्ता बदल देता है। अगर compromised local process उसी log को बदल सकता है जिसे वह लिखता है, तो attacker महत्वपूर्ण entries मिटा सकता है। Append-only event handling और integrity checks इस्तेमाल करें, और log को उसे बनाने वाले process से स्वतंत्र रूप से verify करें।

Sallyport अपने Sessions और Activity journals को encrypted, hash-chained audit log से बनाता है। sp audit verify vault key के बिना offline इस chain की जाँच करता है।

Grant की शक्ति के अनुसार review schedule रखें। Personal issue tracker grant की कभी-कभी समीक्षा पर्याप्त हो सकती है। Production infrastructure बदल सकने वाले grant की हर नई connection, हर scope change और agent के किसी भी unexpected behavior के बाद समीक्षा करें। Action layer records को इतना स्पष्ट बनाए कि owner जवाब दे सके: «मेरे account का इस्तेमाल किस agent ने, किस काम के लिए और किसकी मंज़ूरी के तहत किया?»

Browser profiles और generic token brokers छिपे हुए bypass बनाते हैं

Browser profile agent के लिए खराब credential store है। इसमें session cookies, cached access tokens, refresh tokens, account selectors और असंबंधित browsing state हो सकती है। Agent को उस profile तक access देना एक API action delegate करने से कहीं व्यापक है। Cleanup भी कठिन हो जाता है, क्योंकि provider state और browser state एक-दूसरे में मिल जाते हैं।

Generic token broker भी यही समस्या पैदा कर सकता है, अगर वह callers से मनमाने token endpoint parameters स्वीकार करे। Teams अक्सर getToken(scope) नाम की एक API बनाती हैं और सुरक्षित महसूस करती हैं, क्योंकि token अब agent process में नहीं रहता। अगर कोई भी session किसी भी connected account या arbitrary scope के लिए पूछ सकता है, तो broker अब भी token vending machine है।

Caller से token नहीं, operation का अनुरोध करवाएँ। «Project A में release note बनाओ» के साथ owner, destination और जाँचने योग्य scope requirement जुड़ी होती है। «tracker.write के लिए token दो» में caller के पास बहुत अधिक authority छोड़ दी जाती है।

Operations को समझने से पहले enormous rules engine न बनाएँ। Named grants और human approval points से जुड़ी approved actions की छोटी catalogue review करने में आसान और bypass करने में कठिन होती है। वास्तविक operating need होने पर ही complexity जोड़ें।

Development, staging और production में एक ही refresh token share करने की आदत से भी बचें। अलग grants से revocation कम गंभीर और audit records कम अस्पष्ट रहते हैं। केवल इसलिए staging agent को production तक रास्ता नहीं मिलना चाहिए कि दोनों environments ने एक ही identity provider इस्तेमाल किया।

Ownership table और एक revocation drill से शुरुआत करें

पहला उपयोगी artifact code नहीं, grant inventory है। हर उस refresh token के लिए एक row बनाएँ जिसे agents इस्तेमाल करवा सकते हैं। Provider, account reference, grant ID, scopes, action layer location, account owner, backup revoker, creation method, last confirmed use और local disable procedure शामिल करें। अगर कोई column खाली है, तो अभी उस grant पर आपका नियंत्रण नहीं है।

इसके बाद low-risk integration के साथ revocation drill करें। Owner से grant को locally disable करवाएँ, provider पर revoke करवाएँ और सामान्य agent action चलाने का प्रयास करें। पुष्टि करें कि action layer request रोकती है, reconnect के लिए स्पष्ट human action चाहिए और audit trail पिछली session की पहचान करता है। इस अभ्यास से missing provider endpoints, अज्ञात account ownership, पुराने developer machines में रखे tokens और local expectations से अधिक समय तक जीवित cached access tokens जैसी धारणाएँ जल्दी सामने आती हैं।

जिन grants पर provider-enforced limits नहीं हैं, उनके लिए expiry review तय करें। Unattended work के लिए long-lived access कभी-कभी आवश्यक होता है, लेकिन indefinite access एक स्पष्ट अपवाद होना चाहिए और उसका named owner होना चाहिए। जब team owner का नाम नहीं बता सकती, तो grant usable नहीं रहना चाहिए।

मानक सरल है: agent work का अनुरोध कर सकता है, लेकिन उसे account की खुद को हमेशा renew करते रहने की क्षमता नहीं मिलनी चाहिए। Refresh credential को ऐसी जगह रखें जहाँ human उसके इस्तेमाल को नियंत्रित कर सके और revocation को browser tabs में emergency search के बजाय अभ्यास की हुई कार्रवाई बनाएँ।