# Incident response agents: बिना chaos के production access

Production incident response agents को पहले जांच करनी चाहिए और recovery तभी करनी चाहिए, जब कोई व्यक्ति छोटी, नामित action list में से किसी action को approve करे। यह सीमा केवल औपचारिकता नहीं, व्यावहारिक ज़रूरत है। Outage के दौरान agent थके हुए responder से तेज़ी से बिखरे हुए evidence जुटा सकता है, लेकिन live state बदलने का निर्णय उसे अपने हाथ में नहीं लेना चाहिए।

खराब design में agent को production shell, व्यापक cloud role और runbook में «अपने विवेक का इस्तेमाल करें» जैसी एक पंक्ति मिलती है। यह design तब तक तेज़ लगता है, जब तक agent गलत worker pool restart न कर दे, खराब deployment को scale न कर दे, ऐसा credential rotate न कर दे जिसकी किसी dependency को अभी भी ज़रूरत है, या isolated fault को बड़े outage में न बदल दे। अच्छे design में उसे diagnostic map मिलता है और recovery actions इतनी कम होती हैं कि इंसान हर action को समझ सके।

## Diagnostic authority और recovery authority अलग permissions हैं

Diagnostic work system से पूछता है कि क्या हुआ। Recovery work system को बदलने का निर्देश देता है। Teams अक्सर यह सीमा मिटा देती हैं, क्योंकि `restart` जैसा command routine लगता है और कई dashboards एक ही screen से resource को inspect और mutate करने देते हैं। दोनों को एक permission मानना ही उपयोगी incident assistant को अस्पष्ट accountability वाले production operator में बदल देता है।

Diagnostic actions को service behavior अपरिवर्तित रखना चाहिए। वे metrics पढ़ सकती हैं, तय time window के भीतर logs query कर सकती हैं, deployment metadata ला सकती हैं, health endpoints देख सकती हैं, configuration revisions की तुलना कर सकती हैं और सीमित database facts जुटा सकती हैं। Diagnostic action sensitive information दिखा सकती है, इसलिए उसके लिए भी scope और audit records चाहिए। उसे application state बदलने की authority नहीं चाहिए।

Recovery actions running system के किसी हिस्से को बदलती हैं। इनमें rollback, restart, traffic shifting, scaling, feature-flag changes, credential rotation, queue replay, failover, database repair और integration disable करना शामिल हैं। कुछ actions reversible होती हैं, लेकिन कोई भी default रूप से harmless नहीं है। Restart lease रखने वाली एकमात्र process को खत्म कर सकता है। Scaling shared dependency को समाप्त कर सकती है। Queue replay से customer messages दोबारा भेजे जा सकते हैं।

किसी action को classify करते समय यह test अपनाएं: अगर उसी समय वही action दोहराने पर state बदलने के कारण परिणाम अलग हो सकता है, तो उसे recovery में रखें। अगर कोई action cache बदलता है, support ticket बनाता है, message भेजता है, alert mute बदलता है या ऐसी annotation लिखता है जिसे अन्य automation पढ़ती है, तो वह भी state बदलता है। केवल इसलिए इन्हें read न कहें कि ये primary database को नहीं छूते।

NIST SP 800-61 Revision 2 containment, eradication और recovery को detection और analysis से अलग करता है। यहां यह विभाजन उपयोगी है। Agent detection और analysis को काफी तेज़ कर सकता है। जैसे ही वह containment या recovery का प्रस्ताव देता है, जिम्मेदार इंसान को action चुनना और उसके परिणाम स्वीकार करना चाहिए। यह document आपके authorization model को हल नहीं करता, लेकिन incident phases एक खतरनाक भ्रम रोकते हैं: investigation और intervention एक ही काम नहीं हैं।

Read-only role अपने आप सुरक्षित नहीं होता। Log queries में access tokens हो सकते हैं। Trace attributes account identifiers उजागर कर सकते हैं। Configuration endpoint credentials लौटा सकता है। Agent को arbitrary raw artifacts fetch करने की क्षमता देने के बजाय redaction और field limits diagnostic interface में ही बनाएं। Production visibility की अपनी सीमा होनी चाहिए।

## Agent को general production shell नहीं, सवाल दें

Pressure के समय agent बेहतर काम करता है, जब उसके tools सीधे incident questions व्यक्त करते हैं। General shell agent को system और safe operating procedure दोनों खोजने के लिए मजबूर करता है, वह भी तब जब समय कम हो। Review भी लगभग असंभव हो जाता है, क्योंकि `kubectl`, cloud CLIs, database clients और SSH में incident की ज़रूरत से कहीं अधिक क्षमता होती है।

Diagnostic actions को उस evidence के आसपास बनाएं जिसे responder शुरुआती मिनटों में मांगेगा:

- किसी नामित service और time range के लिए error rate, latency, saturation और availability लाना
- पहले error के आसपास deployment, configuration revision और dependency changes ढूंढना
- allowlisted field set और capped result size के साथ structured logs खोजना
- किसी specified component की health और recent events देखना
- canary या region की तुलना किसी ज्ञात healthy peer से करना

हर action का narrow input contract होना चाहिए। `get_service_errors(service, start, end, group_by)` reviewer को बताता है कि agent ने क्या मांगा। `run_query(text)` लगभग कुछ नहीं बताता और accidental full scans, unsafe predicates या prompt-injected query text को आमंत्रित करता है।

Hard boundaries tool में लगाएं, model से उन्हें याद रखने को न कहें। Metric tool बहुत बड़ी time range को reject करे। Log tool लौटाए गए records की संख्या सीमित करे और model तक पहुंचने से पहले configured fields redact करे। Deployment lookup को known inventory से application identifier लेना चाहिए, issue comment से आया arbitrary URL नहीं। ये limits cost घटाती हैं और incident को data exfiltration exercise बनने से रोकती हैं।

नीचे दिया गया action catalog जानबूझकर उबाऊ है। Outage में उबाऊ होना तारीफ़ है।

```yaml
incident_actions:
  diagnostics:
    - name: service_summary
      inputs: [service, start_time, end_time]
      limits: {max_window_minutes: 180}
    - name: recent_deployments
      inputs: [service, since_time]
    - name: log_sample
      inputs: [service, start_time, end_time, error_code]
      limits: {max_records: 200, redact_fields: [authorization, cookie, token]}
    - name: dependency_health
      inputs: [dependency, region]
  recovery:
    - name: rollback_release
    - name: set_traffic_weight
    - name: restart_component
    - name: disable_feature_flag
```

यह fragment internal tools में दिखने वाली एक आम failure रोकता है: supposedly read-only agent को पहले demo के लिए सुविधाजनक universal query endpoint दे दिया जाता है। बाद में पता चलता है कि वह हर service की हर log line ला सकता है या छिपे हुए write path को invoke कर सकता है। Tool names safety नहीं बनाते। Input validation, allowlist, bounded output और ऐसे credentials जो write न कर सकें, safety बनाते हैं।

सिर्फ इसलिए diagnostic agent को production SSH न दें कि SSH से inspection आसान है। Shell access में file reads, process control, network access और अक्सर credentials तक पहुंच, सब एक साथ मिलते हैं। Host facts देना ज़रूरी हो तो process status, disk utilization, चुनी हुई journal entries या controlled command wrapper जैसे focused commands दें। Wrapper pipes, redirects, command substitution और arbitrary flags को reject करे। Natural-language instruction shell को सुरक्षित नहीं बना सकती।

## Recovery catalog इतना छोटा हो कि उसका अभ्यास किया जा सके

इंसान production mutations की अंतहीन सूची को meaningful approval नहीं दे सकता। हर service class के लिए plain descriptions, जहां संभव हो fixed parameters और स्पष्ट owner वाला छोटा recovery catalog बनाएं। अगर किसी recovery action को एक approval card में समझाया नहीं जा सकता, तो agent के उसे request करने से पहले उसे छोटे हिस्सों में बांटना होगा।

एक sensible catalog में तुरंत पिछली approved release पर rollback, एक unhealthy revision के लिए traffic weight को zero करना, एक नामित stateless component को restart करना, पहले से मौजूद feature flag disable करना या नामित consumer को pause करना शामिल हो सकता है। इसमें «arbitrary remediation चलाएं», arbitrary SQL, व्यापक IAM changes या agent conversation से copy की गई ad hoc scripts नहीं होनी चाहिए।

हर catalog item के लिए incident से पहले ये पांच बातें लिखें:

1. ठीक-ठीक बताएं कि क्या बदलेगा, जिसमें environment और resource scope भी शामिल हों।
2. वे preconditions बताएं जिन्हें agent को जुटाना होगा, जैसे confirmed release identifier या healthy fallback।
3. Execution के बाद अपेक्षित observation और escalation से पहले अधिकतम wait बताएं।
4. Rollback या compensating action का नाम दें, अगर कोई मौजूद हो।
5. वह human role तय करें जो इसे approve कर सकता है।

Catalog में parameter limits ज़रूरी हैं। «Set traffic weight» बहुत व्यापक है। «Stable revision healthy होने के बाद `eu-west` में revision `orders-v184` को zero percent पर set करें» approve किया जा सकने वाला request है। Request को model को बिना constraints के region, revision और percentage चुनने की अनुमति नहीं देनी चाहिए।

Action list को complete दिखाने की कोशिश न करें। उसमें वे actions जानबूझकर न रखें जिनमें bespoke judgment चाहिए। Database migration repair, data deletion, customer communication, access grants और credential rotation में अक्सर ऐसी जानकारी होती है जिसे कोई generic incident agent infer नहीं कर सकता। Unlisted action का सही परिणाम स्पष्ट refusal और अब तक जुटाए गए evidence के साथ रुकना है।

छोटा catalog drills भी संभव बनाता है। Test incident चलाकर पूछें कि designated approver consumer pause करने के request और उसका backlog delete करने के request में अंतर समझ सकता है या नहीं। अगर उत्तर source code पढ़ने या agent के summary पर भरोसा करने पर निर्भर है, तो approval text कमजोर है।

## Approval को exact request, व्यक्ति और समय से बांधें

Human approval तभी उपयोगी है जब वह किसी specific proposed action को authorize करे, किसी अस्पष्ट incident session को नहीं। «payments के लिए remediation approve करें» agent को उस समय mutation चुनने की जगह देता है जब approve करने वाला व्यक्ति देख भी नहीं रहा हो। Approval को action type, target, parameters, incident identifier, caller identity और short expiry से बांधें।

Approval request में action के supporting evidence दिखाएं, लेकिन evidence और requested mutation को अलग रखें। Incident responders को देखना चाहिए कि release `184` के बाद error rates बढ़ीं, पिछली release अभी उपलब्ध है और selected region में healthy capacity है। उन्हें यह भी साफ़ दिखना चाहिए कि approve पर click करने से वास्तव में क्या होगा।

Immutable fields वाला request object इस्तेमाल करें और approved field में कोई बदलाव हो तो execution reject करें:

```json
{
  "incident_id": "inc-2025-041",
  "action": "rollback_release",
  "target": {"service": "orders", "environment": "production", "region": "eu-west"},
  "parameters": {"from_release": "184", "to_release": "183"},
  "evidence_refs": ["metric:err-17", "deploy:184", "health:183"],
  "requested_by": {"agent_session": "sess-8f2a", "process_identity": "signed-agent-build"},
  "expires_at": "2025-03-08T14:35:00Z"
}
```

Executor को ऐसा result लौटाना चाहिए जिसमें request identifier सुरक्षित रहे और यह दर्ज हो कि action शुरू हुआ, पूरा हुआ, failed हुआ या timeout हुआ। «rollback done» जैसा status message incident timeline के लिए बहुत अस्पष्ट है। Agent को result पढ़कर diagnostic checks फिर चलाने चाहिए। उसे यह मानकर नहीं चलना चाहिए कि successful API response ने service बहाल कर दी है।

हर बाद के action के लिए एक ही शुरुआती approval का उपयोग न करें। Approval fatigue वास्तविक है, लेकिन blanket authorization fatigue को ambiguity से बदल देता है। केवल वे actions group करें जिनका target, expected effect और risk समान हो। अगर दोनों पहले से fixed हों, तो कोई व्यक्ति एक release के लिए traffic removal और rollback को एक recovery package के रूप में approve कर सकता है। इससे database change, credential rotation या किसी दूसरे region को approval नहीं मिलता।

जब agent की hypothesis बदले, नया approval लें। इससे एक आम failure sequence पकड़ी जाती है: agent deployment को suspect करता है, rollback की approval पाता है, फिर database error देखकर पुराने authorization के तहत अलग action चलाने का निर्णय लेता है। Clock के अनुसार approval expired न भी हो, उसका वास्तविक अर्थ समाप्त हो चुका है।

## Incident sessions standing production authority को रोकते हैं

Incident agent की identity human operator और उसके chat transcript दोनों से अलग होनी चाहिए। Record करें कि किस executable या remote process ने access मांगा, वह किस incident से जुड़ा है, उसने कौन से diagnostic actions चलाए और हर recovery request को किसने approve किया। इस separation के बिना post-incident review authority के account के बजाय prose में search बन जाता है।

Session incident reference, declared environment, explicit diagnostic scope और expiry के साथ शुरू होना चाहिए। Agent process exit करते ही, expiry पार होते ही या operator revoke करते ही session समाप्त होना चाहिए। Revocation अगली action से पहले लागू हो, reads पर भी। Suspected credential या prompt-injection event में continued read access भी नुकसान बढ़ा सकता है।

हर diagnostic call को isolated prompt मानने के बजाय per-session authorization बेहतर default है। नए agent process का पहला request operator को यह देखने का अवसर देता है कि request कहां से आया और उसे production visibility क्यों चाहिए। इसके बाद agent हर graph या log sample के लिए approval मांगे बिना evidence जुटा सकता है। Recovery को अब भी per-call approval चाहिए।

Shared machines और CI-like environments में agent identity और user identity का अंतर महत्वपूर्ण है। Human account incident response के लिए authorized हो सकता है, लेकिन copied agent process या malicious tool wrapper नहीं। जहां operating environment support करे, code-signing authority या अन्य verifiable process identity capture करें। Window title और user-provided label identity नहीं हैं।

Sallyport absolute vault gate, नए agent process के लिए session authorization और हर individual use के लिए per-key option का इस्तेमाल करता है। यह arrangement incident work के लिए उपयुक्त है, क्योंकि human bounded diagnostic run की अनुमति दे सकता है और sensitive recovery credentials के लिए नया निर्णय सुरक्षित रख सकता है।

Credentials agent context में, थोड़े समय के लिए भी, पास न करें। Agent prompt में paste किया गया credential वापस नहीं लिया जा सकता और agent उसे command, transcript, log या external request में दोहरा सकता है। Executor credential अपने पास रखे, permitted API या SSH action चलाए और investigation के लिए ज़रूरी result ही लौटाए।

## Audit records intent और execution दोनों समझाएं

Incident notes अक्सर यह दर्ज करती हैं कि लोगों को क्या हुआ लगता है। वे शायद ही कभी exact agent request, उसे अनुमति देने वाली authority और downstream system से मिले result को दर्ज करती हैं। आपको ये चारों चाहिए। «agent ने orders rollback किया» वाली timeline यह नहीं बता सकती कि agent ने rollback request किया था या नहीं, क्या किसी व्यक्ति ने release `183` approve की थी, या deployment system ने command स्वीकार की थी।

Session creation, diagnostic call, recovery proposal, approval या denial, execution attempt, result, revocation और session end के लिए durable event record करें। हर event में timestamp, correlation identifiers, process identity, action name, target, normalized parameters और result code होना चाहिए। Sensitive request content सावधानी से store करें: audit को अर्थ बनाए रखना चाहिए, लेकिन उसे uncontrolled secret store नहीं बनना चाहिए।

Hash chain बाद में alteration का पता लगाने में मदद करती है, क्योंकि हर record में पिछले record का hash शामिल होता है। यह साबित नहीं करती कि collector को शुरुआत में हर event मिला था। दोनों properties के लिए design करें। Event writer को action executor द्वारा rewrite करना कठिन बनाएं, upstream request identifiers सुरक्षित रखें और chain को समय-समय पर agent के control से बाहर verify करें।

Offline verification command को सरल, inspectable result shape देना चाहिए:

```text
$ sp audit verify
verified: 1842 records
first sequence: 2025-03-08T12:01:09Z
last sequence:  2025-03-08T14:42:31Z
chain: valid
```

Sallyport एक encrypted hash-chained log से session journal और individual activity journal दोनों बनाता है, और `sp audit verify` ciphertext पर chain की जांच कर सकता है। Incident evidence के लिए यह उपयोगी है, क्योंकि history बदली है या नहीं यह देखने के लिए vault खोलना ज़रूरी नहीं होता।

Audit review को live agent loop से बाहर रखें। Agent अपने recorded action identifiers का हवाला दे सकता है, लेकिन incident lead या reviewer को record स्वतंत्र रूप से inspect करने में सक्षम होना चाहिए। वरना जो agent अपने काम को गलत तरीके से बताए, वही responder द्वारा देखे जाने वाले evidence को भी नियंत्रित कर सकता है।

## Failed rollback दिखाता है कि intervention से पहले evidence क्यों ज़रूरी है

मान लें कि किसी service की error rate release के तुरंत बाद बढ़ जाती है। Agent timing देखता है और rollback का प्रस्ताव रखता है। Broad production agent उसे तुरंत चला सकता है। यह तेज़ है, लेकिन गलत भी हो सकता है।

Disciplined agent पहले version और region के अनुसार error breakdown, हाल के deployment records, dependency health और resource saturation लाता है। Evidence दिखाता है कि केवल एक region fail हो रहा है, लेकिन वहां नई और पिछली दोनों revisions fail हैं। Rollback समय खर्च करेगा, दूसरा rollout event बनाएगा और dependency outage को नहीं बदलेगा।

Agent इसके बजाय कोई recovery action propose नहीं करता। वह report करता है कि failure regional है और dependency का health endpoint fail हो रहा है। फिर responder उस region से predefined traffic shift approve करता है, अगर capacity और service के data rules इसकी अनुमति दें। Agent approval के बाद ही उसे execute करता है, resulting error rate देखता है और request तथा result दोनों record करता है।

अब एक detail बदलें। Requested time window बहुत बड़ी होने के कारण diagnostic action error लौटाती है। Agent को broad log export चुपचाप retry करने के बजाय incomplete evidence report करना चाहिए। Limits incident के दौरान दूर की जाने वाली असुविधा नहीं हैं। वे model को uncertainty को बड़ा access request बनाने से रोकती हैं।

एक और variation अधिक असहज है: approved traffic shift API पर सफल हो जाती है, लेकिन error rate कम नहीं होती। Agent को खुद से restart, rollback या credential rotation पर नहीं जाना चाहिए। उसे अगली allowed observations जुटानी चाहिए और नया proposal तैयार करना चाहिए। इंसान भी incidents में गलत निर्णय लेते हैं, लेकिन कम से कम निर्णय वही होना चाहिए जो record में दर्ज है।

इसीलिए «केवल incidents के दौरान broad access दें» वाली लोकप्रिय सलाह विफल होती है। Incidents attention घटाते हैं, urgency बढ़ाते हैं और अक्सर partial या misleading telemetry के साथ आते हैं। इन स्थितियों में narrow interfaces और explicit approvals की ज़रूरत कम नहीं, अधिक होती है।

## अगला outage आने से पहले runbook में refusal paths रखें

Safe incident agent को यह स्पष्ट पता होना चाहिए कि कब रुकना है। Runbook में उसे unlisted mutation, declared environment से बाहर action, missing prerequisites वाला request, expired approval और session revocation के बाद किसी भी operation को refuse करने के लिए कहना चाहिए। हर refusal में condition का नाम हो और अब तक जुटाया गया evidence सुरक्षित रहे।

Refusal path को happy path जितनी ही गंभीरता से test करें। Agent से production incident investigate करने को कहें और फिर untrusted ticket से ऐसा request inject करें जिसमें secret configuration value लाने को कहा गया हो। Verify करें कि tool उसे reject करता है। Approval expire होने के बाद rollback request करें। Verify करें कि agent action text बिल्कुल दोहराए तब भी executor उसे reject करता है। Diagnostic sequence के दौरान session revoke करें और verify करें कि अगली call fail होती है।

Recovery credentials को diagnostic credentials से अलग रखें। अगर एक ही credential logs पढ़ और queue delete कर सकती है, तो approval screen underlying authority को ठीक नहीं कर सकती। Executor को ऐसी credential चुननी चाहिए जिसकी permissions catalog के एक action से मेल खाती हों। जहां system यह separation support नहीं करता, वहां safer control point जोड़ने तक उसे autonomous agent के पीछे न रखें।

इस pattern का पहला production deployment किसी परिचित failure और narrow remedy पर करें। ऐसी service चुनें जहां responders पहले से कुछ read calls और एक well-understood recovery action का इस्तेमाल करते हों। मापें कि agent का evidence facts जुटाने में लगने वाला समय घटाता है या नहीं, approvers transcript पढ़े बिना requests समझते हैं या नहीं और audit record event को फिर से बना सकता है या नहीं। Drills में ये उत्तर सही साबित होने के बाद ही catalog बढ़ाएं।

Production agent trust इसलिए कमाता है कि वह human responder से कम choices करता है, बड़ी choices करके नहीं। उसे facts खोजने का काम दें, mutation के बिंदु पर human decision बनाए रखें और pager बंद होने के बाद भी evidence से action तक हर transition को visible रखें।