Break-glass runbook: AI agents का control वापस पाएं

Agent-controlled systems को किसी और permission setting की जरूरत पड़ने से पहले एक emergency procedure चाहिए। जब कोई agent API call कर सकता हो, SSH session खोल सकता हो, deployment बदल सकता हो या किसी external service को data भेज सकता हो, तब किसी इंसान के पास काम रोकने, authority हटाने और दबाव के बीच हुई घटना को दोबारा समझने का तरीका होना चाहिए।

Break-glass runbook किसी unsafe design को सुरक्षित नहीं बनाता। यह uncertainty को नुकसान बनने से पहले सीमित करने का रास्ता देता है। इसका उपयोगी version पहले पंद्रह मिनट के लिए एक पेज पर आ जाना चाहिए, इसमें केवल job titles नहीं बल्कि वास्तविक authority रखने वाले लोग होने चाहिए, और इसे ऐसे लोगों ने test किया होना चाहिए जो इसे लिखने में शामिल न रहे हों।

Emergency authority नामित roles के पास होनी चाहिए

Break-glass runbook तभी काम करता है जब उसमें साफ लिखा हो कि बिना आगे permission मांगे कौन कार्रवाई कर सकता है।

«Platform team» और «security» 02:00 बजे पर्याप्त जवाब नहीं हैं, खासकर तब जब कई लोग यह मान रहे हों कि निर्णय किसी और की जिम्मेदारी है।

चार roles तय करें, फिर हर role को मौजूदा लोगों और alternates से जोड़ें। छोटी team में एक व्यक्ति दो roles संभाल सकता है, लेकिन एक ही व्यक्ति को सभी roles न दें।

• Incident lead emergency mode घोषित करता है, तत्काल लक्ष्य तय करता है और decisions record करता है।
• Access revoker agent session, उसका action channel या उन credentials को disable करता है, जिन तक agent पहुंच सकता है।
• Service owner तय करता है कि critical workload को सुरक्षित तरीके से रोका जा सकता है या नहीं और recovery को validate करता है।
• Recorder timestamp वाला event log संभालता है और evidence package को सुरक्षित रखता है।

Incident से पहले access revoker के पास technical authority होनी चाहिए। इसका मतलब है कि वह संबंधित agent process को disable कर सके, action boundary पर access हटा सके और जरूरत पड़ने पर credential rotation का अनुरोध कर सके। जरूरी console access दिए बिना केवल emergency phone number देना एक दिखावटी role बनाता है।

जहां संभव हो, दो revokers रखें, एक primary और एक alternate, और उन्हें अलग reporting lines से चुनें। Service owner लंबे outage पर आपत्ति कर सकता है, लेकिन जब incident lead को लगे कि active agent unsafe हो सकता है, तब वह initial containment को veto न कर सके। स्थिति समझने के बाद service बहाल की जा सकती है। External API request या destructive SSH command को वापस नहीं लिया जा सकता।

हर role के लिए runbook में ये विवरण रखें: नाम, alternate, काम के समय संपर्क का तरीका, अगर आपकी व्यवस्था में हो तो out-of-hours तरीका और वे systems जिन्हें वह वास्तव में control कर सकता है। Team में बदलाव के बाद सूची की समीक्षा करें। पुरानी contact list छोटी administrative समस्या नहीं है। यह responders को उस समय improvisation करने पर मजबूर करती है, जब उन्हें तय प्रक्रिया लागू करनी चाहिए।

Authority और consultation को अलग रखें। प्रभावित काम के अनुसार legal, compliance, customer support और senior leadership को सूचना देनी पड़ सकती है। उन्हें containment के सामने queue में खड़ा नहीं होना चाहिए। किसी खास legal obligation के उलट निर्देश न होने पर incident lead पहली सुरक्षित कार्रवाई के बाद उन्हें जानकारी दे।

Stop, revoke और preserve अलग-अलग कार्रवाइयां हैं

Agent process को रोकना, उसकी authority रद्द करना और evidence सुरक्षित रखना अलग समस्याएं हल करते हैं। Teams अक्सर इन्हें एक ही समझ लेती हैं और फिर मान लेती हैं कि inactive process की access भी खत्म हो गई, जबकि ऐसा नहीं होता।

Stop उस process से आगे का काम रोकता है। इसका मतलब local process terminate करना, scheduled task disable करना, agent runner pause करना या repository trigger हटाना हो सकता है। अगर process अभी active है और उसका behavior अनिश्चित है, तो पहले stop करें।

Revoke उस authority को हटा देता है, जिसने action को संभव बनाया था। इसमें action session disable करना, service identity वापस लेना, access vault lock करना, upstream token बदलना या किसी सीमित integration को block करना शामिल हो सकता है। आज रोका गया agent कल retry queue या किसी दूसरी machine से फिर शुरू हो सकता है। उसकी authority गलती से भी उपलब्ध नहीं रहनी चाहिए।

Preservation उन चीजों को capture करता है, जिनकी responders को जरूरत होगी, इससे पहले कि routine recovery उन्हें overwrite कर दे। Process identity, source revision या जरूरत पड़ने पर prompt context, operator account, start और stop times, destination services और आखिरी confirmed action record करें। अपनी retention rules के अनुसार logs और configuration snapshots सुरक्षित रखें। Evidence जुटाते समय incident ticket में secrets paste न करें।

पहले मिनटों में इस decision card का इस्तेमाल करें:

Incident ID:
Declared by / time:
Affected agent process or session:
Immediate risk: active calls / possible credential exposure / unknown

[ ] Stop current run
[ ] Revoke agent authorization
[ ] Lock or rotate affected credential path
[ ] Preserve process identity and action records
[ ] Notify service owner

Revoker / time:
Recorder / time:
Recovery is prohibited until incident lead approves it.

आखिरी पंक्ति एक आम गलती रोकती है। Developer देखता है कि production work रुक गया है, queue चलाने के लिए agent को फिर शुरू कर देता है और responders द्वारा बनाई गई साफ सीमा मिटा देता है। Recovery के लिए अलग decision चाहिए, क्योंकि इससे risk फिर बदल जाता है।

Responders से कार्रवाई करने से पहले malicious behavior साबित करने को न कहें। अजीब destination, failed approval flow, ऐसा agent जो रुक नहीं रहा, या expected और observed actions के बीच अंतर, पहले containment के लिए पर्याप्त है। बाद की review defect, गलत configuration और attack में अंतर कर सकती है।

Urgent work के लिए सीमित approval path चाहिए

कभी-कभी urgent work normal owner की प्रतीक्षा नहीं कर सकता, लेकिन «urgent» शब्द का इस्तेमाल अक्सर उन्हीं controls को छोड़ने के लिए होता है, जो खराब request को सामने ला सकते हैं। Runbook को blanket approval बनाए बिना एक सीमित exception की अनुमति देनी चाहिए।

Urgent work को ऐसे specific service outcome के रूप में परिभाषित करें, जिसे normal path की प्रतीक्षा से वास्तविक नुकसान होगा। कोई deployment केवल इसलिए pending है कि कोई lunch से पहले काम खत्म करना चाहता है, तो वह urgent नहीं है। Failed production dependency को restore करना urgent हो सकता है। Description में exact action, target, expected result और latest useful completion time होना चाहिए।

इस approval sequence का इस्तेमाल करें:

1. Requester service impact, exact proposed action, affected account या environment और expiry time बताता है।
2. Incident lead पुष्टि करता है कि containment लागू है और scope validate करने के लिए service owner या delegate नियुक्त करता है।
3. Revoker केवल उस action के लिए जरूरी authority देता है, साथ में स्पष्ट expiry और recorded approver रखता है।
4. Requester काम करता है, जबकि recorder resulting action record और outcome capture करता है।
5. Result verify होते ही revoker temporary authority हटा देता है।

Approval record नीरस और पूरा होना चाहिए। Chat में «approved, please fix» स्वीकार न करें। इस तरह का statement मांगें:

Emergency work authorization
Request ID: IR-2025-041
Requested action: restart payment-worker deployment in production
Scope: one named deployment, no repository writes, no account changes
Reason: queue is failing and manual recovery window expires at 14:30 UTC
Approver: service owner delegate
Granting revoker: access revoker
Expires: 14:30 UTC
Result and removal time:

यह example किसी responder को कुछ भी restart करने की permission नहीं देता। यह उस specificity का स्तर दिखाता है, जो scope creep रोकता है। «Restore production» दर्जनों संभावित actions छिपाता है। Named deployment और expiry को जांचा जा सकता है।

अगर संभव हो तो इस path के लिए standing emergency credential का इस्तेमाल न करें। Standing emergency access तेज महसूस होती है, इसलिए teams इसे पसंद करती हैं। लेकिन इससे हमेशा उपलब्ध high-value target बनता है और लोग सुविधा के कारण इसे सामान्य काम में इस्तेमाल करने लगते हैं। ऐसी authority दें जो सीमित action के लिए हो और फिर हटा दें।

अगर कोई authorized व्यक्ति urgent action approve नहीं कर सकता, तो containment लागू रखें और ownership chain के जरिए escalation करें। Delayed recovery नुकसान पहुंचा सकती है। Unauthorized recovery, जो incident को बढ़ा दे, उससे कहीं ज्यादा नुकसान हो सकता है।

पहले पंद्रह मिनट mechanical होने चाहिए

Stress में लोग timestamps छोड़ देते हैं, terminology पर बहस करते हैं और मान लेते हैं कि किसी colleague ने कोई action कर दिया है। Runbook में ordered first-response sequence होना चाहिए, जो cause अज्ञात होने पर भी काम करे।

Minute zero पर concern देखने वाला व्यक्ति incident record बनाता है और observable fact लिखता है। «Agent process ने unrecognized endpoint को requests भेजीं» लिखें, «agent compromised है» नहीं। बाद की review में facts शुरुआती theories से ज्यादा टिकते हैं।

फिर incident lead दो states में से एक घोषित करता है: investigation या emergency containment। Investigation का मतलब है कि active unsafe authority का कोई संकेत नहीं है और team काम रोके बिना जांच कर सकती है। Emergency containment का मतलब है कि team agent की current authority या actions को सुरक्षित तरीके से तय नहीं कर सकती। दूसरी state revoker को कार्रवाई का अधिकार देती है।

अगले पंद्रह मिनट में ये काम क्रम से करें:

1. Active process या session पहचानें और उसकी visible identity, host, owner, start time और current task record करें।
2. अगर execution जारी है या scheduler उसे फिर शुरू कर सकता है, तो आगे का execution रोकें।
3. उस process के पास उपलब्ध authority revoke करें और सबसे महत्वपूर्ण external action path से शुरू करें।
4. Affected service owner को बताएं कि containment active है और operational consequence साफ शब्दों में बताएं।
5. Unrelated settings बदलने से पहले action records और configuration context सुरक्षित रखें।

इस अवधि में broad cleanup से बचें। Hosts rebuild न करें, working directories delete न करें, company के हर secret को rotate न करें और स्थिति डरावनी लगने पर deployment settings न बदलें। बाद में ये actions सही हो सकते हैं, लेकिन वे evidence दबा देते हैं और unrelated outages पैदा करते हैं।

Recorder को एक shared place में simple timeline रखनी चाहिए:

14:07  Observer reported unexpected outbound request from agent run A-184.
14:09  Incident lead declared emergency containment.
14:10  Revoker stopped run A-184 and disabled its action authorization.
14:12  Service owner confirmed order processing may pause.
14:14  Recorder saved action records and configuration digest.
14:18  Team began scope review. No recovery authority granted.

यह बाद में लिखे गए लंबे narrative से ज्यादा उपयोगी है। इससे दिखता है कि team को क्या पता था, किसने कार्रवाई की और authority कब बदली। Opinions और hypotheses को अलग investigation note में रखें।

Approval fatigue design failure है

जब harmless और consequential work के लिए एक ही prompt बार-बार आता है, तो लोग warnings को bypass कर देते हैं। बार-बार approval मांगने से सावधानी नहीं बढ़ती। लोग card पर click करके आगे बढ़ना सीख जाते हैं।

Emergency runbook में साफ लिखें कि किन actions के लिए explicit human decision चाहिए और कौन-से काम normal authority में आगे बढ़ सकते हैं। Boundary को meaningful बनाएं। Infrastructure बदलने वाली action, नए external destination तक पहुंच, account में बदलाव या expected service path से बाहर credential का इस्तेमाल, known scope में रहने वाली read operation से ज्यादा scrutiny मांगता है।

इसे conditions से भरी बहुत बड़ी written policy से हल करने की कोशिश न करें। Incident के दौरान responder को कुछ स्पष्ट choices चाहिए: deny, stop, revoke, एक सीमित emergency action grant करना या normal operation restore करना। अगर procedure को बीस exception clauses की व्याख्या चाहिए, तो हर responder के लिए यह अलग तरीके से fail होगा।

Approval screen या record में caller की इतनी जानकारी होनी चाहिए कि इंसान expected run और unexpected run में अंतर कर सके। केवल process name कमजोर evidence है, क्योंकि names आसानी से copy किए जा सकते हैं। Process origin, जहां operating system यह उपलब्ध कराए वहां code-signing identity, launch context और session identifier capture करें। इससे approver कह सकता है, «यह इस path से launch हुआ expected developer tool है», न कि «label जाना-पहचाना लग रहा है»।

एक आम खराब recommendation कहती है कि हर sensitive call के लिए व्यक्ति की approval जरूरी होनी चाहिए। यह सुरक्षित लगता है, क्योंकि हर loop में इंसान आ जाता है। लेकिन legitimate task में बहुत calls होने पर यह fail हो जाता है: operator बिना देखे approve करता है, agent सीमित maintenance पूरी नहीं कर पाता और team अंततः setting बंद कर देती है। Single-use approval को meaningful consequence वाली authority के लिए रखें और session-level approval तभी इस्तेमाल करें, जब session identity स्पष्ट हो और उसका scope स्वीकार्य हो।

Sallyport इस practical split को vault gate, default per-session authorization और optional per-key requirement के जरिए follow करता है, जिसमें हर उपयोग पर approval मांगी जा सकती है। इससे runbook की जगह नहीं ली जा सकती, क्योंकि किसी इंसान के पास फिर भी काम रोकने और urgent exception उचित है या नहीं, यह तय करने का अधिकार होना चाहिए।

Logs को बताना चाहिए कि किसने action किया और किसने approve किया

«Agent ने किया» कहने वाला incident record अधूरा है। Agents processes, identities, action channels और human approval paths के जरिए काम करते हैं। आपके evidence में हर link दिखना चाहिए।

हर महत्वपूर्ण call के लिए agent session या process identity, इसे शुरू करने वाला human या system, target service या host, requested action, authorization state, result और भरोसेमंद time सुरक्षित रखें। Emergency work के लिए approver, revoker, requested scope, expiry और removal time को call record के साथ दर्ज करें।

Approval record को action result से अलग रखें, फिर incident या request identifier के जरिए दोनों को correlate करें। यह अंतर महत्वपूर्ण है। Approval का मतलब है कि किसी ने सीमित attempt को authorize किया। इससे यह साबित नहीं होता कि attempt सफल हुआ, केवल intended object को छुआ या expiry पर रुक गया।

Review के दौरान ये सवाल पूछें:

• Request किस process ने किया और वह शुरू कैसे हुआ?
• उस समय request को कौन-सी authority ने अनुमति दी?
• Emergency work को किसने approve किया और exact scope क्या था?
• क्या result उस scope से मेल खाता था?
• क्या कोई independent reviewer बदले हुए या missing records का पता लगा सकता है?

NIST Special Publication 800-61 Revision 2, Computer Security Incident Handling Guide, preparation, detection and analysis, containment, eradication and recovery और post-incident activity को जुड़े हुए काम के रूप में देखता है। Incident data को document और preserve करने की उसकी guidance आज भी उपयोगी है, लेकिन agent operations में एक ऐसी detail जुड़ती है, जो पुराने runbooks अक्सर छोड़ देते हैं: delegated machine authority का record भी चाहिए, केवल human logins का नहीं।

Ordinary application logs को audit trail न समझें। Application logs authorization context छोड़ सकते हैं, broad administrative changes की अनुमति दे सकते हैं या machine rebuild होने पर गायब हो सकते हैं। उन्हें सुरक्षित रखें, लेकिन document करें कि हर record क्या साबित कर सकता है और क्या नहीं।

जिन systems में cryptographic audit chain होती है, उनमें verification को drill का हिस्सा बनाएं। Sallyport sp audit verify के जरिए offline verification देता है, जिससे reviewer vault key के बिना उसके encrypted, hash-chained audit log की जांच कर सकता है। Rehearsal के दौरान copied evidence set पर यह command चलाएं, incident commander के जवाब की प्रतीक्षा करते समय पहली बार नहीं।

Recovery को authority दोबारा अर्जित करनी चाहिए

Service restore करना incident close करने के बराबर नहीं है। Team को केवल वही authority restore करनी चाहिए, जिसे वह समझा सके, और यह काम इतने छोटे steps में होना चाहिए कि recurrence की सीमा साफ दिखाई दे।

Recovery से पहले incident lead के पास तीन answers होने चाहिए: containment decision का कारण क्या था, कौन-सी authority exposed या used हुई और repeat रोकने वाला control अब क्या है। Full root cause तुरंत पता न हो, फिर भी चलेगा। लेकिन पहले restored action को safe कहने के लिए पर्याप्त confidence होना चाहिए।

Service को सीमित stages में restore करें। जहां संभव हो read-only validation से शुरू करें, फिर एक known action और उसके बाद छोटा monitored run करें। केवल एक service recover होने पर हर agent, integration और credential को फिर से enable न करें। जब तक service owner और incident lead सहमत न हों कि affected path समझ में आ गया है, incident boundary बनाए रखें।

Urgent-work approval से अलग recovery authorization इस्तेमाल करें। Emergency approval incident के दौरान जरूरी action की अनुमति देता है। Recovery approval यह पुष्टि करता है कि containment के बाद normal authority लौट सकती है। इसके लिए अलग record रखें:

Recovery authorization
Incident ID:
Cause or remaining uncertainty:
Authority to restore:
Validation performed:
Monitoring owner and review time:
Approved by incident lead and service owner:

यहां भी expiry महत्वपूर्ण है। Successful test के बाद temporary recovery grant उपलब्ध रह गया, तो वह undocumented standing access बन जाता है। Recovery record के हिस्से के रूप में revoker को उसके removal की पुष्टि करनी चाहिए।

Credential rotation को केवल औपचारिकता नहीं, judgment की तरह लें। Credential किसी untrusted process, destination, repository, log या व्यक्ति तक पहुंचा हो सकता है, या उसकी use boundary तय न की जा सके, तो उसे rotate करें। अगर agent को उसी unsafe path से replacement हासिल करने का रास्ता अब भी मिल रहा है, तो यह दावा न करें कि rotation ने incident ठीक कर दिया। पहले वह path ठीक करें।

Post-incident review में केवल observations नहीं, edits निकलने चाहिए। «Communication अस्पष्ट थी» को «Recorder incident timeline template इस्तेमाल करेगा और service owner page पर alternate दर्ज होगा» में बदलें। «Access कठिन थी» को missing permission, उसे देने वाले owner और अगली drill date के exact विवरण में बदलें।

Rehearsal उन हिस्सों को सामने लाती है जिनकी जिम्मेदारी किसी के पास नहीं

जिस runbook का अभ्यास नहीं हुआ, वह केवल proposal है। पहली live use में stale contacts, missing authority और इस बात पर disagreement सामने आएगा कि काम फिर कौन शुरू कर सकता है। Rehearsal कम जोखिम के समय इन unknowns को fixable defects में बदल देती है।

पहले tabletop exercise करें, फिर controlled technical drill। Tabletop में participants को अधूरी जानकारी वाला छोटा scenario दें, जैसे deployment के दौरान agent का unexpected SSH connection। उनसे call tree लागू करने, containment का निर्णय लेने, approval record भरने और यह बताने को कहें कि वे कौन-सा evidence सुरक्षित रखेंगे। Runbook के author को हर सवाल का जवाब न देने दें।

Technical drill में nonproduction target या स्पष्ट रूप से isolated test path इस्तेमाल करें। Known agent process शुरू करें, harmless action authorize करें, containment लागू करें, पुष्टि करें कि आगे के actions fail हो रहे हैं, records सुरक्षित रखें और limited recovery करें। Actions का समय record करें, लेकिन exercise को speed contest न बनाएं। Fast response जो revocation छोड़ दे, उस slower response से खराब है जो साफ boundary बनाता है।

Drill को observable checks से score करें:

• क्या observer documented methods से incident lead और revoker तक पहुंच सका?
• क्या revoker के पास जरूरी authority थी, बिना किसी administrator के access की improvisation किए?
• क्या team ने process रोकने और उसकी authority हटाने में अंतर किया?
• क्या reviewer emergency approval को resulting action record से मिला सका?
• क्या temporary access बताई गई expiry या removal time पर गायब हो गई?

NIST SP 800-61 incident response capabilities test करने की स्पष्ट recommendation देता है और व्यावहारिक कारण भी बताता है: Exercises procedures, training और technical controls की gaps सामने लाती हैं। Testing को केवल incident response team तक सीमित न रखें। Agent चलाने वाले, affected service के owner और urgent work approve करने वाले लोगों को भी शामिल करें। आमतौर पर process इन्हीं लोगों की assumptions पर टूटता है।

Drill के तुरंत बाद runbook update करें, जब names, delays और confusing instructions ताजा हों। फिर अगली exercise schedule करें और हर correction का owner तय करें। अगर किसी correction का owner नहीं है, तो आपने defect record करके उसे ठीक न करने का चुनाव किया है।

First-action card वहां रखें जहां failure छिप न सके

पूरा runbook आपके controlled documentation system में रह सकता है, लेकिन responders को एक छोटा card चाहिए, जो ordinary tools slow या affected होने पर भी उपलब्ध रहे। इसे ऐसी जगह रखें जहां team agent environment के बिना पहुंच सके और card में volatile details copy करने के बजाय current contacts तक पहुंचने का तरीका हो।

Card में observer को बताया जाना चाहिए कि किसे call करना है, incident lead को बताया जाना चाहिए कि containment कब declare कर सकता है, revoker को बताया जाना चाहिए कि पहले कौन-सी authority हटानी है और सभी को बताया जाना चाहिए कि recovery के लिए नया decision जरूरी है। इसमें evidence record और वह जगह भी लिखी हो, जहां recorder timeline लिखेगा।

Agent runners, action channels, ownership या access देने वाले systems में बदलाव होने पर card की समीक्षा करें। Yearly audit का इंतजार न करें। जिस क्षण team agent के बाहरी दुनिया तक पहुंचने का तरीका बदलती है, उसी क्षण उसकी emergency procedure fiction बन सकती है।

अच्छी drill के अंत में छूटी हुई assumptions की थोड़ी शर्मिंदगी वाली सूची मिलती है। उसे संभालकर रखें। जो team अपनी failures rehearsal में खोज लेती है, उसने उन्हें outage के दौरान खोजने से बचने के लिए जरूरी काम कर लिया है।