Locked local vault access: agent work के लिए runbook

Autonomous काम तब बहुत अनुमानित तरीके से विफल होता है जब लोग लॉक्ड स्थानीय वॉल्ट को केवल असुविधा समझते हैं। किसी task के बीच एजेंट को credential boundary मिलती है, काम पूरा करने का दबाव बढ़ता है और कोई secret shell variable, configuration file या chat message में कॉपी कर देता है। Task पूरा हो जाता है, लेकिन टीम एक ऐसा untracked credential path बना देती है जो task के बाद भी मौजूद रहता है।

एजेंट शुरू होने से पहले ही लॉक्ड वॉल्ट को work plan का हिस्सा बनना चाहिए। ऑपरेटर को तीन अलग फैसले लेने होते हैं: access कब unlock होगा, इस run में कौन सा agent process काम कर सकता है और किन individual actions के लिए अब भी मानव निर्णय चाहिए। इन फैसलों को एक अस्पष्ट «आगे बढ़ो» में मिला देने पर या तो prompts की बाढ़ आ जाती है या controls को bypass किया जाता है।

इसका मतलब यह नहीं कि किसी व्यक्ति को हर command पर निगाह रखनी होगी। मानव ध्यान वहां लगना चाहिए जहां उससे परिणाम बदलता है। Read-only discovery अक्सर सीमित session में चल सकती है। Production deletion, permission change या release publication के समय नया निर्णय लेना चाहिए। बाकी काम के लिए ऐसा run plan चाहिए जिसे एजेंट शुरू होने से पहले ऑपरेटर समझ सके।

Unlock window का मालिक और समाप्ति समय तय करें

ऑपरेटर को स्थानीय वॉल्ट एक तय work window के लिए unlock करना चाहिए। इस फैसले की जिम्मेदारी एक व्यक्ति की हो और window बंद करने की स्पष्ट शर्त भी हो। «जब तक मैं काम कर रहा हूं, इसे खुला रखो» सुनने में आसान है, लेकिन meeting, lunch, laptop sleep या context switch के दौरान यह तरीका विफल हो जाता है। खुला वॉल्ट ऐसी authority बन जाता है जिस पर कोई सक्रिय रूप से ध्यान नहीं दे रहा।

Unlock करने से credentialed actions की अनुमति की सबसे व्यापक परत खुलती है। वॉल्ट लॉक होने पर कोई agent session या individual request आगे नहीं जानी चाहिए। इससे lock state उपयोगी बनती है, लेकिन तभी जब टीम इसे औपचारिक login नहीं बल्कि operational boundary माने।

Window को task की स्वाभाविक गति के अनुसार रखें। छोटा repair एक छोटी window में हो सकता है। Planned migration के लिए preparation, execution और verification की window चाहिए, साथ में irreversible phase से पहले scheduled pause। केवल logs पढ़ने वाली investigation के लिए production settings बदलने वाले follow-up से अलग window रखें।

Access खोलने से पहले पांच बातें लिखें:

• authorization decision का मालिक कौन है;
• एजेंट कौन सा काम कर सकता है;
• किन environments और accounts को छुआ जा सकता है;
• window किस स्थिति में समाप्त होगी;
• मालिक के जाने पर परिणाम की समीक्षा कौन करेगा।

यह रिकॉर्ड औपचारिक समारोह नहीं होना चाहिए। वास्तविक सीमाएं लिखी हों तो ticket comment या run note पर्याप्त है। «Deployment issue ठीक करें» पर्याप्त नहीं है। «Failed staging deployment की जांच करें, फिर केवल तभी named deployment को retry करें जब image digest approved build से मेल खाए» जैसी पंक्ति reviewer को जांचने योग्य सीमा देती है।

समाप्ति की शर्त केवल घड़ी पर निर्भर न रखें। Hard closing time उपयोगी है, पर agent को unexpected dependency मिल जाने से काम देर तक चल सकता है। Time limit को state limit के साथ जोड़ें: planned verification के बाद, पहली unexpected target मिलने पर या owner के हटते ही window बंद करें। Task सीमा से आगे जाए तो नई window मांगे। यह छोटा विराम किसी व्यक्ति को फिर तय करने पर मजबूर करता है कि पुरानी authorization अभी भी लागू है या नहीं।

दिन की शुरुआत में unlock और अंत में lock करना autonomous work के लिए सही default नहीं है। इससे unlock के interruptions कम होते हैं, लेकिन एजेंट machine speed से काम करता रहता है जबकि access को उचित ठहराने वाला मानव ध्यान कहीं और जा चुका होता है। बार-बार unlock करना कठिन लगे तो batching और approval design सुधारें, boundary हटाएं नहीं।

Vault unlock, run approval और action approval अलग सवालों के जवाब हैं

तीन अलग फैसले जरूरी हैं क्योंकि वे अलग जोखिम नियंत्रित करते हैं। Unlocking बताता है कि credentialed actions हो भी सकती हैं या नहीं। Run approval बताता है कि पहचाना गया agent process सीमित काम के दौरान उपलब्ध action path इस्तेमाल कर सकता है या नहीं। Individual call approval बताता है कि किसी खास credential का यह खास उपयोग नए मानव निर्णय के योग्य है या नहीं।

अक्सर teams पहले दो फैसलों को मिला देती हैं। वे वॉल्ट unlock करके मान लेती हैं कि मशीन का हर process अब काम कर सकता है। इससे local presence check एक broad software authorization बन जाता है। दूसरी गलती हर harmless request को approve करना है क्योंकि session approval का अर्थ पहले तय नहीं किया गया। तब operators routine reads को बिना पढ़े approve करने लगते हैं।

फर्क तब सबसे महत्वपूर्ण होता है जब task का स्वरूप बदलता है। मान लें एजेंट को failed build की जांच, deployment API query और logs इकट्ठा करने की अनुमति मिली। उसे लगता है कि missing permission failure का कारण हो सकती है। Original run में access controls बदलना शामिल नहीं था। वॉल्ट खुला हो और process session approved हो, तब भी एजेंट को रुककर नया निर्णय मांगना चाहिए। काम diagnosis से administration बन गया है।

एक व्यावहारिक विभाजन ऐसा हो सकता है:

• जिम्मेदार व्यक्ति planned work की निगरानी कर सकता हो, तभी access unlock करें।
• बताए गए run के लिए एक पहचाने गए agent process को approve करें, जिसमें run contract में आने वाली सामान्य कार्रवाइयां शामिल हों।
• Publishing, deletion, permission change, credential rotation या production write जैसी high-consequence calls के लिए अलग approval लें।

Categories टीम के अनुसार बदल सकती हैं। उन्हें API calls की संख्या से नहीं, परिणाम की गंभीरता से वर्गीकृत करें। Production account revoke करने वाली एक request, build metadata की पचास reads से अधिक ध्यान मांगती है।

Sallyport का fixed decision ladder जानबूझकर संकीर्ण है: vault gate लॉक रहने पर हर action रोकता है, per-session authorization नए agent process को उसके lifetime के लिए approve करता है और per-key setting हर उपयोग पर approval मांग सकती है। इससे operator को ऐसी policy language नहीं लिखनी पड़ती जो outage के दौरान debug करने के लिए अलग security program बन जाए।

Per-call gate किसी credential को अपने आप सुरक्षित नहीं बनाता। वह केवल उपयोग के समय मानव निर्णय का अवसर देता है। Operator के पास request को समझने के लिए पर्याप्त context होना चाहिए। Prompt में केवल «production token इस्तेमाल करें» लिखा हो तो control का अधिकतर मूल्य पहले ही खत्म हो चुका है। Run plan में target, action और intended effect लिखें और request की उससे तुलना करें।

Access को office hours नहीं, work states के अनुसार तय करें

Agent work को ऐसे states की श्रृंखला बनाएं जिनमें authority शुरू, pause, सीमित या समाप्त हो सके। Office hours staffing में मदद करते हैं, पर वास्तविक काम नहीं बताते। Task staffed hours में शुरू हो सकता है, external system पर रुक सकता है और approver के जाने के बहुत बाद फिर चल सकता है।

Task record में चार states रखें: preparation, active execution, held और review। Preparation में credentialed action नहीं होती। Agent repository देख सकता है, commands तैयार कर सकता है, inputs validate कर सकता है और vault access के बिना intended calls समझा सकता है। Active execution तभी शुरू हो जब operator access window खोले और run approve करे। Held का अर्थ है कि agent wait condition, unexpected decision या approved scope की सीमा तक पहुंच गया है। Review में संबंधित follow-up को authority देने से पहले चक्र पूरा किया जाता है।

यह model एक आम failure रोकता है। Engineer 4:30 पर deployment cleanup शुरू करता है। Agent tests चलाता है, stale resources पहचानता है और cloud operation पूरी होने की प्रतीक्षा करता है। 5:15 पर वह फिर चलता है, दूसरे account में cleanup की जरूरत पाता है और session मौजूद होने के कारण आगे बढ़ता रहता है। Original operator जा चुका है। हर API call सफल होने पर भी task बिना accountable decision के नए scope में चला गया।

Run से पहले pause rules लिखें। अच्छी pause rules देखी और जांची जा सकती हैं:

• target account, host या environment run note से अलग हो तो रुकें;
• plan में न बताई गई credential class चाहिए तो रुकें;
• create, delete, publish या permission change से पहले रुकें;
• failed write के बाद returned error की समीक्षा होने तक रुकें;
• named operator उपलब्ध न रहे तो रुकें।

Pause failure नहीं, साफ state transition है। Agent को intended command या request, gathered inputs और रुकने का कारण सुरक्षित रखना चाहिए। अगला operator noisy chat transcript खंगाले बिना तय कर सके कि आगे बढ़ना है या नहीं।

After-hours urgency को भी इसी तरह ईमानदार रखें। अगर job को action चाहिए तो किसी व्यक्ति को तय करना होगा कि business impact नई access window खोलने योग्य है या नहीं। केवल इसलिए हर blocked task को urgent न कहें कि agent पहले ही दस मिनट काम कर चुका है। Credential boundary बदलती परिस्थितियों में मानव को फिर से चुनने पर मजबूर करती है।

Run पर भरोसा करने से पहले process identity दिखनी चाहिए

Approval को agent process की पहचान केवल terminal label या user-provided name से नहीं करनी चाहिए। «deploy-agent» नाम expected executable, local script या compromised dependency से शुरू हुआ कोई program भी हो सकता है। Operator को यह संकेत चाहिए कि authority मांगने वाला program किसने बनाया और शुरू किया।

Code-signing identity उपयोगी है क्योंकि इससे approval text के बजाय executable authority से जुड़ती है, जिसे कोई भी process print कर सकता है। इससे यह साबित नहीं होता कि agent को दिए गए हर prompt में समझदारी थी। लेकिन incident के मूल सवाल का बेहतर उत्तर मिलता है: vault इस्तेमाल करने की अनुमति किस process को मिली?

Run note में agent entry point और working directory या repository लिखें। Approval से पहले operator दो चीजें जांच सके: system द्वारा दिखाई गई process identity और टीम की अपेक्षा वाला task context। दोनों अलग हों तो request deny करें और machine की जांच करें। केवल task परिचित लगने पर पहले approve न करें।

साफ approval flow में सीमित friction रहता है। नए process की पहली credentialed call approval trigger करती है। Operator process authority और run purpose की पुष्टि करता है। Process अपने approved session में तब तक चल सकता है जब तक वह exit न करे, operator उसे revoke न करे या vault lock न हो जाए। नया process फिर approval मांगता है।

यह detail एक सूक्ष्म workaround रोकती है। अगर टीम process के बजाय named terminal session approve करे, तो उसी terminal में unrelated program चलाकर पहले run का trust हासिल किया जा सकता है। Authorization को actual agent process से जोड़ें, window, user account या project folder से नहीं।

Sallyport per-session authorization मांगते समय process की code-signing authority दिखाता है। यह वही जानकारी है जिसकी operator को agent run approve करने से पहले जरूरत होती है। फिर भी written run purpose साथ रखें, क्योंकि identity बताती है कि कौन पूछ रहा है, जबकि run contract बताता है कि request इस काम की है या नहीं।

Irreversible authority पर per-call gates रखें

Per-call approval उन actions पर अच्छा काम करता है जिन्हें कोई व्यक्ति कुछ सेकंड में समझ सकता है, लेकिन जिनका पछतावा बहुत लंबे समय तक रह सकता है। इसे ऐसे credentials पर लगाएं जो बाहरी commitments बना सकते हैं, access बदल सकते हैं, data मिटा सकते हैं या production service को प्रभावित कर सकते हैं। आदत के कारण हर credential पर इसे न लगाएं।

आम गलती पूरे production account को «dangerous» मानकर हर request पर approval मांगना है। Agent कई harmless reads करता है, operator उन्हें जल्दी-जल्दी approve करता है और destructive write परिचित prompts के बीच आ जाती है। Control metronome बन जाता है। बार-बार कम जानकारी वाले confirmations पर ध्यान बनाए रखना लोगों के लिए कठिन है।

Provider अनुमति दे तो authority अलग करें। Discovery के लिए read credential, सामान्य maintenance के लिए सीमित write credential और per-call निर्णय वाले high-consequence actions के लिए अधिक अधिकार वाला credential रखें। एक ही broad token उपलब्ध हो तो उसके हर उपयोग को broad authority मानें। केवल HTTP method के आधार पर उसे low risk न समझें। खराब API में POST data fetch कर सकता है और GET endpoint काम शुरू कर सकता है।

RFC 6750 bearer token को सीधे समझाता है: जिसके पास token है, वह उसे इस्तेमाल कर सकता है। इसी कारण «सिर्फ इस task के लिए» agent को token देना तत्काल operation से बड़ी समस्या बनाता है। Agent का prompt context, shell history, logs, plugins और future handoffs possession leak होने की जगह बन सकते हैं। Token को local vault में रखें और केवल operation result लौटाएं।

SSH में local control के आसपास shortcut के रूप में agent forwarding से बचें। OpenSSH ssh_config manual चेतावनी देता है कि authentication agent forwarding से remote host local agent का इस्तेमाल कर सकता है और user को remote host पर भरोसा होना चाहिए। Autonomous work में जोखिम बढ़ता है क्योंकि agent ऐसे host से जुड़ सकता है जिसकी configuration या destination उसने पूरी तरह नहीं जांची। Direct SSH action path रखें, run contract में allowed host लिखें और jump host या नया destination दिखे तो रुकें।

Per-call gate credential पर लगाएं, «production mode» जैसी अस्पष्ट धारणा पर नहीं। बाद की समीक्षा में यह चुनाव समझना आसान रहेगा। Reviewer देख सकेगा कि इस credential पर हमेशा निर्णय जरूरी था, चाहे request किस agent ने की हो या prompt किस project से आया हो।

Run contract approval को अनुमान से बचाता है

Run contract छोटा ticket comment होना चाहिए और approval decision को जांचने योग्य बनाना चाहिए। यह project plan नहीं है। इसमें इतने ही तथ्य हों कि operator पूरी agent transcript पढ़े बिना काम approve, deny, pause और review कर सके।

Access unlock करने से पहले यह template इस्तेमाल करें:

Run ID: 2025-03-incident-cleanup-01
Owner: name of approving operator
Purpose: inspect failed release and remove only the listed temporary resource
Agent process: expected executable and repository directory
Targets: staging account, api.example.internal, named SSH host
Allowed actions: read deployment state; delete resource tmp-4821 after match check
Per-call actions: delete request, any permission change, any production request
Stop conditions: target mismatch; unexpected credential; failed write; owner unavailable
Expected evidence: request IDs, resource IDs, command output, final status
Review owner: name of reviewer

Example में date जैसा identifier केवल readability के लिए है, security control के लिए नहीं। ऐसा identifier चुनें जिसे team task system और activity records में खोज सके। सबसे महत्वपूर्ण lines targets, allowed actions और stop conditions हैं। यही lines agent को मिलने वाले अगले संभावित task के कारण run को अनजाने में फैलने से रोकती हैं।

Contract खराब plans को जल्दी दिखाता है। «Repair permissions» में target, allowed change और review evidence नहीं है। Operator इसे जिम्मेदारी से approve नहीं कर सकता। «Staging में group X को role Y में जोड़ें, फिर read request से role binding verify करें» review के लिए पर्याप्त स्पष्ट है। अगर group X मौजूद न हो या role Y production का हो तो agent को रुकना होगा।

Template को इतना लंबा न बनाएं कि लोग काल्पनिक precision भरने लगें। Endpoints की बड़ी सूची control का झूठा भरोसा दे सकती है, जबकि वास्तविक जोखिम publishing build या account हटाने जैसा business operation हो। Boundary स्पष्ट करने के लिए endpoint लिखें, अन्यथा resource, environment और effect लिखना पर्याप्त है।

बार-बार होने वाले chores के लिए revision history वाला stable contract रखें। इसका अर्थ permanent authority नहीं है। Operator फिर भी window खोलता है और particular process run approve करता है। Stable text ambiguity घटाता है, blanket permission नहीं बनना चाहिए।

Blocked task के लिए सुरक्षित pause path रखें

जब blocked agent के पास सम्मानजनक तरीके से रुकने का विकल्प नहीं होता, teams workaround बनाने लगती हैं। Agent आधे inputs जुटा चुका होता है, operator उपलब्ध नहीं होता और task पूरा होने के करीब लगता है। अगर विकल्प केवल «अभी पूरा करो» या «सारी progress खो दो» हों, तो कोई secret export कर देगा।

ऐसा pause path बनाएं जो context बचाए, credentials नहीं। Agent observed facts, exact external action, resume करने के लिए जरूरी nonsecret inputs और approval boundary रुकने का कारण दर्ज करे। Token, private key, authorization header या secret वाली command line कभी record न करे।

HTTP operation के लिए pause record में method, host, route, resource identifier, expected status class और redacted body shape हो सकते हैं। SSH operation के लिए host alias, अगर संवेदनशील न हो तो remote username, intended command, expected output और host verification result रखें। अगली window खोलने से पहले operator इस record की समीक्षा कर सकता है।

एक उपयोगी handoff note ऐसा हो सकता है:

State: held
Reason: planned cleanup target was absent; agent found a second temporary resource.
Observed: tmp-4821 absent, tmp-5930 created by the same failed release.
Requested next action: delete tmp-5930 after operator confirms it belongs to this incident.
No external write occurred after the original target check failed.
Evidence to review: deployment query result and resource metadata IDs.

यह note अगले operator को वास्तविक चुनाव देता है। वह दूसरी deletion approve कर सकता है, उसे reject कर सकता है या और discovery मांग सकता है। Agent «listed temporary resource हटाएं» को चुपचाप «ऐसी दिखने वाली हर चीज हटाएं» में नहीं बदल सकता।

Denied operation को agent बार-बार retry न करे। Denial mismatch, locked vault या pending per-call decision का संकेत हो सकता है। Retry loop साफ pause को prompts के ढेर में बदल देता है। Denial को stop state मानें, जब तक operator उसी action को स्पष्ट रूप से फिर approve न करे।

Write request के बाद API call timeout हो जाए तो भी यही नियम लागू है। Agent failure मानकर request दोबारा न भेजे। जहां संभव हो safe read से resulting state जांचे, ambiguity दर्ज करे और operation सफल हो सकने पर इंतजार करे। Duplicate writes कई कठिन incidents का कारण बनती हैं, क्योंकि command log में वे harmless लगती हैं और external system बाद में परिणाम दिखाता है।

अगली access window से पहले evidence की समीक्षा करें

Related work के लिए नई authority देने से पहले run के अंत में परिणामों की समीक्षा करें। इससे drift जल्दी पकड़ा जाता है, जब operator को action का कारण अभी याद रहता है। सप्ताह के अंत तक इंतजार करने पर ticket, chat, terminal और agent transcript अलग-अलग कहानी सुना सकते हैं।

Reviewer को evidence की तुलना run contract से करनी चाहिए, इस सामान्य एहसास से नहीं कि task पूरा लगता है। Actual targets, सफल और विफल actions, returned identifiers और expected sequence से बाहर की calls जांचें। Failure स्वीकार्य हो सकता है। Unexplained target नहीं।

Review को छोटा लेकिन ठोस रखें:

• क्या agent ने केवल approved environments और hosts से संपर्क किया?
• क्या हर write allowed action से मेल खाती थी या उसे अलग approval मिला?
• क्या external system ने अपेक्षित resource या request identifiers लौटाए?
• क्या agent हर stated stop condition पर रुका?
• क्या follow-up task को इस contract के extension के बजाय नया contract चाहिए?

Output review और authority review अलग हैं। Session record बता सकता है कि process को 10:02 पर approval मिली और 10:19 पर session खत्म हुआ। Action record दिखा सकता है कि उस दौरान कौन सी API और SSH operations हुईं। यह जानने के लिए दोनों views चाहिए कि process ने केवल अनुमत काम किया या नहीं।

Hash-chained audit log अलग लाभ देता है: बाद में alteration का पता लगाया जा सकता है। Sallyport session और activity views को write-blind encrypted audit log से project करता है, और sp audit verify vault key के बिना ciphertext पर offline chain verify कर सकता है। इससे event के बाद record बदला गया या नहीं, यह जांचने में मदद मिलती है। फिर भी facts ताजा रहते हुए operator को परिणाम पढ़ना जरूरी है।

अगले contract को बेहतर बनाने के लिए review का उपयोग करें। अगर harmless metadata lookup छूटने के कारण हर run pause होता है, उसे अगली बार शामिल करें। अगर read-only endpoint पर recurring job बार-बार per-call approval मांगती है, तो credential को सामान्य session class में रखें। अगर reviewers को बार-बार unexpected writes मिलती हैं, तो दोबारा चलाने से पहले agent instructions और credential scopes सीमित करें।

Tamper evidence विवाद के बाद मदद करता है, उससे पहले नहीं

Tamper-evident record यह जांचने का तरीका देता है कि history की continuity बनी हुई है या नहीं। यह तय नहीं करता कि action authorized, समझदार या सुरक्षित थी। Audit evidence को preventive control मानकर broad runs approve करना गलत है।

वास्तविक incident में फर्क साफ दिखता है। मान लें agent expected deployment API से संपर्क करता है और फिर unexpected resource delete करता है। Chained log यह स्थापित करने में मदद कर सकता है कि deletion request recorded sequence में आई थी। वह deleted resource वापस नहीं ला सकता, broad authority मिलने का कारण नहीं बता सकता और यह साबित नहीं कर सकता कि operator ने उस resource को scope में रखना चाहा था।

Incident बढ़ाने, investigation handoff करने या suspicious run की समीक्षा से पहले record बचाने के लिए audit verification करें। Retained log material पर verifier चलाएं, परिणाम दर्ज करें और verification result को incident notes के साथ रखें। Activity entries को report पढ़ने में आसान बनाने के लिए edit या manually «clean up» न करें। Explanatory notes record के पास हों, उसके अंदर नहीं।

Teams कभी-कभी मानती हैं कि encryption के कारण immediate decryption के बिना record बेकार है। Ciphertext पर chain continuity जांचने वाला verifier investigator को vault खोले बिना एक सीमित लेकिन महत्वपूर्ण तथ्य देता है: retained encrypted record अभी भी sequence से मेल खाता है या नहीं। यह फर्क स्पष्ट रखें। Verification integrity continuity जांचता है, decryption content दिखाता है और इनमें से कोई भी अगली action लेने का अधिकार नहीं देता।

जो team unlock windows plan करती है, agent processes पहचानती है, गंभीर authority पर per-call gates लगाती है और परिणामों की तुरंत समीक्षा करती है, उसे audit evidence कम बार चाहिए होगा। जब record की जरूरत पड़ेगी, तब run contract और pause notes उसे समझने का context भी देंगे। बिना approval context का log केवल बताता है कि क्या हुआ। अनुशासित work plan से जुड़ा log बताता है कि team ने उसे किस कारण अनुमति दी।

पहला बदलाव छोटा है: agent के लिए local credentials unlock करने से पहले लिखित stop condition अनिवार्य करें। यह एक पंक्ति टीम को तय करने पर मजबूर करती है कि task योजना से अलग होने पर agent क्या करेगा। इससे असुविधा आने पर secret export करने का आम बहाना भी खत्म होता है।