# Live Task के दौरान AI Agent Access को सुरक्षित रूप से रद्द कैसे करें

सक्रिय AI एजेंट को incident पैदा करने के लिए दुर्भावनापूर्ण इरादे की ज़रूरत नहीं होती। गलत instruction, जरूरत से ज़्यादा व्यापक tool grant, संक्रमित repository file या भ्रमित operator उसे destructive loop में भेज सकता है, जबकि उसके पास अभी भी access हो। Response को नए actions जल्दी रोकने चाहिए, लेकिन उस record को मिटाना नहीं चाहिए जो बताता है कि हुआ क्या था।

आम तौर पर गलत प्रतिक्रिया होती है terminal बंद करना, दिखने वाले हर credential को revoke करना और अगली सुबह याददाश्त के आधार पर घटना को फिर से बनाना। इससे outage बढ़ जाता है और अक्सर यह फर्क मिट जाता है कि agent ने क्या करने की कोशिश की, remote service ने क्या स्वीकार किया और वास्तव में क्या बदला। Agent incident को छिपाने लायक शर्मनाक रुकावट नहीं, बल्कि evidence handling वाला containment काम समझें।

## Revocation को scene मिटाने से पहले future authority रोकनी चाहिए

Agent को revoke करने का मतलब है उसे अगला privileged action करने से रोकना और साथ ही इतनी state सुरक्षित रखना कि यह पता चल सके कि पहले के actions सफल हुए या नहीं। दिखाई देने वाली chat या terminal window बंद करना दोनों में से कोई भी काम पूरा नहीं कर सकता। Process के child processes हो सकते हैं, agent का remote connection खुला हो सकता है और local process गायब होने के बाद भी HTTP request चल रही हो सकती है।

Controls को छूने से पहले इन चार चीज़ों को अलग-अलग समझें:

- Agent process वह local program है जो decisions और tool calls बनाता है।
- Session उस खास process run को दी गई authority है।
- Credential वह secret या identity है जिसे external system स्वीकार करता है।
- Remote operation वह काम है जिसे API, queue, host या cloud control plane पहले ही स्वीकार कर चुका है।

लोग अक्सर session revocation और credential rotation को एक ही समझ लेते हैं। इसका नतीजा महँगा पड़ता है। किसी एक agent को रोकने के लिए shared deployment token rotate करने पर production automation टूट सकती है, जबकि agent का पहले से स्वीकार किया गया request चलता रह सकता है। दूसरी ओर, अगर token को workspace में कॉपी करने के बाद केवल agent process को kill किया, तो reusable secret वहीं बच सकता है।

इसलिए containment को agent के सबसे नज़दीकी भरोसेमंद control से शुरू करें। पहले active run को deny करें। फिर remote systems तक पहुँच चुके काम को रोकें या cancel करें। जब evidence बताए कि secret अब सीमित नहीं रहा, या session boundary पर भरोसा न किया जा सके, तब credential disablement तक जाएँ।

पहले से एक साफ incident rule लिख लें: suspicious behavior देखने वाला व्यक्ति meeting की प्रतीक्षा किए बिना agent को तुरंत रोक सकता है। Review बाद में करें। Delayed approval process deployment के लिए ठीक है, live process से authority वापस लेने के लिए नहीं।

## पहले incident से पहले action map बनाएँ

जिसे पहचान नहीं सकते, उसे revoke नहीं कर सकते। हर agent run की एक पहचान होनी चाहिए जो उसके local process record, tool logs और remote systems तक पहुँचने वाले requests में दिखाई दे। अगर उसे लगातार pass किया जाए तो random run ID पर्याप्त है। Human name या `coding-agent` जैसे अस्पष्ट label का इस्तेमाल न करें, क्योंकि दोनों अलग-अलग activity को एक ही bucket में मिला देते हैं।

हर उस route के लिए जिससे agent action कर सकता है, इन पाँच operational सवालों के जवाब दर्ज करें:

1. Route का मालिक कौन-सा local process है और हम उसे कैसे रोकेंगे?
2. Action gateway के सामने उस process को कौन-सा session या token दर्शाता है?
3. Local revocation के बाद कौन-से remote operations चलते रह सकते हैं?
4. वे operations independent service logs में कहाँ दर्ज होते हैं?
5. सामान्य owner उपलब्ध न हो तो route को कौन disable कर सकता है?

यह केवल औपचारिकता नहीं है। Incident के दौरान operator को यह खोजने में समय नहीं लगना चाहिए कि database migration shell child, CI job, HTTP request या अलग cloud workflow से चलती है।

जहाँ API अनुमति दे, request header के रूप में run ID इस्तेमाल करें। `run_2025_04_18_7f3c` run ID वाले agent के लिए wrapper agent के prompt या environment में secret रखे बिना correlation header जोड़ सकता है:

```sh
export AGENT_RUN_ID="run_2025_04_18_7f3c"
curl -sS -X POST "$ACTION_ENDPOINT" \
  -H "X-Agent-Run-ID: $AGENT_RUN_ID" \
  -H "Content-Type: application/json" \
  --data @request.json
```

Receiving service को run ID के साथ अपना सामान्य request ID, caller identity, endpoint, response status और समय भी log करना चाहिए। उपयोगी record का रूप कुछ ऐसा हो सकता है:

```text
time=2025-04-18T14:12:09Z request_id=req_91a run_id=run_2025_04_18_7f3c caller=agent-gateway method=POST path=/deployments status=202
```

`202` महत्वपूर्ण है। इसका अर्थ है कि service ने काम स्वीकार किया, यह नहीं कि काम पूरा हो गया। Incident reviews अक्सर यहीं गलत हो जाती हैं: teams agent के आखिरी tool output को outcome मान लेती हैं, जबकि remote system ने केवल queue submission स्वीकार किया था।

SSH के लिए remote account, target hosts, forced commands, यदि कोई हों, और login तथा command activity दर्ज करने वाली जगह को map करें। Local terminal transcript उपयोगी है, लेकिन यह साबित नहीं करता कि command remote तौर पर नहीं चली। इस सवाल का जवाब host के अपने logs और संबंधित service audit trail देते हैं।

## Active run को ऐसे रोकें कि control सुरक्षित रहे

पहले समय और revocation का तत्काल कारण दर्ज करें, फिर नए actions deny करें और agent को terminate करें। Exact commands operating system और runtime के अनुसार बदलेंगे, लेकिन sequence नहीं बदलना चाहिए, क्योंकि इससे containment और cleanup अलग रहते हैं।

1. Incident record में run ID, local process ID, operator, दिखाई दे रहा behavior और वर्तमान समय दर्ज करें। Interface बंद करने से पहले agent के current transcript और आखिरी visible tool call की copy लें।
2. Actions को authorize करने वाले gateway पर active session को revoke या lock करें। अगर कोई safe read-only operation उपलब्ध हो, तो पुष्टि करें कि उसी process से किया गया नया test call denial प्राप्त करता है।
3. जहाँ operating system अनुमति दे, process को kill करने से पहले suspend करें। Suspension से stable process tree और open file list मिलती है। State capture करने के बाद ही kill करें, जब तक कि execution जारी रहने से तुरंत नुकसान न हो।
4. Child processes, background jobs, containers और उस run से जुड़े remote sessions खोजकर रोकें।
5. Service के अपने cancellation mechanism से स्वीकार किए गए remote work को cancel करें और response तथा status सुरक्षित रखें।

macOS या Linux पर blind `kill -9` के बजाय inspection से शुरुआत करें। Example process ID को दर्ज किए गए ID से बदलें:

```sh
ps -o pid,ppid,pgid,lstart,command -p 48192
pgrep -P 48192 -a
lsof -nP -p 48192
kill -STOP 48192
```

पहली command parentage और start time दर्ज करती है। `pgrep` direct children दिखाता है और `lsof` अक्सर खुले workspace files, sockets और सुरक्षित रखने योग्य pipes दिखाता है। `kill -STOP` cooperative process को freeze कर देता है, जिससे उसे cleanup command जारी करने का एक और मौका नहीं मिलता। यह पहले से detached child, remote job या network boundary पार कर चुकी API request को freeze नहीं करता।

Outputs को incident folder में copy करने के बाद process group को enumerate करें। कोई process ऐसा child शुरू कर सकता है जो अपना process group बदल ले, इसलिए एक command पर न रुकें। जहाँ agent इनका उपयोग कर सकता है, वहाँ container runtimes और background job managers भी देखें। अगर agent के पास SSH access है, तो हर target host पर active sessions भी जाँचें।

जब task remote work करता है, तो remote system का operation ID इस्तेमाल करें। उदाहरण के लिए, request स्वीकार करते समय API यह लौटा सकती है:

```json
{
  "operation_id": "op_4e2b7c",
  "status": "queued"
}
```

उस response को सुरक्षित रखें, फिर documented cancellation endpoint को call करें या human control में service console का इस्तेमाल करें। Cancellation result दर्ज करें। `cancel_requested` response का अर्थ है कि operation के `cancelled`, `completed` या किसी अन्य terminal state तक पहुँचने की पुष्टि के लिए polling जारी रखनी होगी। Local process गायब हो गया, इसलिए incident notes में «stopped» न लिखें।

## Workspace reset करने से पहले evidence सुरक्षित रखें

Branches हटाने, services restart करने या automatic cleanup script चलाने से पहले evidence को अलग incident directory में capture करें। आपको समय के क्रम में ऐसा record चाहिए जिसे दूसरा developer operator की याददाश्त पर निर्भर हुए बिना देख सके।

निम्न सामग्री इकट्ठी करें और जहाँ संभव हो original timestamps सुरक्षित रखें:

- Agent transcript, tool inputs, tool outputs और run में इस्तेमाल की गई configuration।
- Process inspection output, parent और child process IDs, open connections और run से संबंधित shell history।
- Gateway session records और action logs, revocation के बाद की denials सहित।
- Remote service audit events, operation IDs, cancellation results और बदले गए resource identifiers।
- Repository state: current commit, diff, untracked files और generated artifacts।

Collection के बाद files का hash बनाएँ। एक simple manifest बाद के reviewers को accidental modification पहचानने देता है, जब copies on-call engineer, security staff और प्रभावित system के owner developer के बीच जाएँ:

```sh
mkdir -p incident-run_2025_04_18/evidence
cp agent-transcript.txt incident-run_2025_04_18/evidence/
ps -o pid,ppid,pgid,lstart,command -p 48192 > incident-run_2025_04_18/evidence/process.txt
shasum -a 256 incident-run_2025_04_18/evidence/* > incident-run_2025_04_18/SHA256SUMS.txt
```

Output manifest कुछ ऐसा दिखना चाहिए:

```text
8f7c...  incident-run_2025_04_18/evidence/agent-transcript.txt
30b1...  incident-run_2025_04_18/evidence/process.txt
```

Hash किसी file को truthful नहीं बनाता। यह साबित करता है कि reviewer को वही file मिली थी जिसका आपने hash बनाया था। इसे उन systems के logs से cross-check करें जिन्हें agent edit नहीं कर सकता था, जैसे API provider का audit trail या append-only central logging service।

NIST की Computer Security Incident Handling Guide, SP 800-61, containment, eradication, recovery और post-incident work को अलग activities मानती है। यह separation agent incidents पर अच्छी तरह लागू होती है। Teams अक्सर working directory हटाकर या token rotate करके सीधे eradication पर चली जाती हैं। बाद में पता चलता है कि deleted transcript में वही exact request body थी जिसकी मदद से remote resource ढूँढा जा सकता था।

Context सुरक्षित रखने के नाम पर secrets को incident folder में copy न करें। Credential identifiers, ownership, scope, creation time और last-use records capture करें। Actual secret values तभी रखें जब आपकी मौजूदा incident process इसकी स्पष्ट अनुमति देती हो और उन्हें सुरक्षित रख सकती हो। Incident archive को uncertainty घटानी चाहिए, दूसरा secret spill नहीं बनाना चाहिए।

## Dead parent process से यह साबित नहीं होता कि काम रुक गया

जब तक इसका उलटा साबित न हो, मानकर चलें कि active agent काम पीछे छोड़ सकता है। सबसे मुश्किल मामले dramatic shell commands नहीं होते। वे साधारण asynchronous actions होते हैं जिन पर normal work के दौरान developer शायद ध्यान भी न दे।

एक coding agent deployment request post करता है, background migration शुरू करने वाली SSH command चलाता है और फिर tests का इंतज़ार करता है। Operator को unexpected production target दिखाई देता है और वह parent agent रोक देता है। Deployment service request पहले ही स्वीकार कर चुकी है, जबकि remote shell ने `nohup` के तहत command शुरू कर दी है। दोनों चलते रहते हैं। Terminal की आखिरी line शायद केवल यह कहे कि connection बंद हो गया।

Review में तीन अलग checks चाहिए:

### APIs द्वारा स्वीकार किए गए काम की जाँच करें

Affected service में run ID, request ID, account identity और time window से search करें। हर request का status तय करें: rejected, queued, running, completed या cancelled। Completed changes के लिए concrete resource IDs की सूची बनाएँ और resulting state की तुलना requested state से करें।

केवल HTTP status पर निर्भर न रहें। `200` synchronous change, status document या intermediary के response को दर्शा सकता है। `202` आम तौर पर accepted processing बताता है, लेकिन अंतिम अर्थ service documentation तय करती है। Service के लिए cancellation playbook लिखने से पहले वह documentation पढ़ें।

### Agent से अलग हुए काम की जाँच करें

Target systems पर remote account के sessions, process tree, scheduled jobs, temporary directories और service logs देखें। Recorded command line, working directory, run ID या किसी unique generated file से search करें। अगर remote task job scheduler इस्तेमाल करता है, तो shell को kill करने के बजाय उसी scheduler से cancel करें, क्योंकि shell का उस task पर अब ownership न हो सकती है।

Callbacks भी देखें। Generated script ने webhook configure किया हो, pull request workflow बनाया हो या CI trigger किया हो सकता है। ये अपने credentials और schedules वाले अलग actors हैं। Original agent को revoke करने से वे revoke नहीं होते।

इसी कारण broad environment वाले general shell की तुलना में narrow action gateway अधिक सुरक्षित है। आप सीमित channels को enumerate कर सकते हैं और हर privileged call को control point से गुजरने के लिए बाध्य कर सकते हैं। Inherited credentials से भरा shell हर subprocess को incident की अलग branch बना देता है।

## Exposure के अनुसार ही credentials rotate करें

Credential को तब rotate करें जब यह मानने का कारण हो कि agent, उसके subprocesses, logs या workspace ने secret को रख लिया हो सकता है। केवल response दिखाने के लिए rotate न करें। Wide rotation legitimate users को तोड़ सकती है और review कठिन बना सकती है, क्योंकि इससे वे records बदल जाते हैं जिन्हें अभी देखना ज़रूरी है।

इन स्थितियों में तुरंत disablement या rotation उचित है:

- Agent को prompt, environment variable, config file, command line या tool output में plaintext secret मिला।
- Credential transcript, repository diff, temporary file या incident team से बाहर access वाले CI log में दिखाई दिया।
- आप ऐसे child process, remote session या outbound connection का हिसाब नहीं दे सकते जो secret पढ़ सकता था।
- Credential के privileges व्यापक हैं और per-use logs भरोसेमंद नहीं हैं।
- Affected provider बताता है कि credential का इस्तेमाल किसी अनजान identity या location से हुआ।

अगर gateway ने credential inject किया और agent को केवल action result लौटाया, तो स्थिति काफी अलग है। Agent ने unauthorized action किया हो सकता है, लेकिन उसके पास reusable secret होना ज़रूरी नहीं। Active session और प्रभावित action route को disable करें, audit record देखें और तभी underlying credential rotate करें जब review को boundary के आसपास कोई route या provider-level concern मिले।

हर agent mistake के बाद हर secret rotate करने की सलाह से बचें। यह लोकप्रिय है क्योंकि निर्णायक लगती है और leaked credentials के गंभीर परिणाम होते हैं। Default के रूप में यह गलत है, क्योंकि यह unauthorized use और credential disclosure को मिला देती है, avoidable production failures पैदा करती है और teams को careful scoping छोड़ना सिखाती है। Disclosure संभव हो तो aggressively rotate करें। अन्यथा compromised run को बाकी सभी से अलग पहचानने की क्षमता सुरक्षित रखें।

Rotation ज़रूरी हो तो पुराने credential identifier, disable time, उसका इस्तेमाल करने वाले downstream systems, replacement owner और यह साबित करने वाला test दर्ज करें कि पुराना credential अब काम नहीं करता। किसी ticket या transcript में दोनों values न रखें। Replacement का काम secret manager या provider के protected rotation mechanism को करने दें।

## Incident record को skeptical review का साथ देना चाहिए

Incident review ऐसा होना चाहिए कि जो developer on call नहीं था, वह एक mutable log पर भरोसा किए बिना sequence फिर से बना सके। Agent के intent और local process record से शुरुआत करें, फिर उस कहानी की gateway records और remote service evidence से तुलना करें।

Explicit confidence labels के साथ timeline बनाएँ। उदाहरण के लिए, «agent ने request प्रस्तावित किया» transcript से आता है। «gateway ने request execute किया» gateway action record से आता है। «provider ने operation स्वीकार किया» provider audit entry से आता है। «resource बदला» resource की final state और change history से आता है। ये अलग-अलग claims हैं और इनके लिए अलग evidence चाहिए।

Write-blind, hash-chained audit log यहाँ उपयोगी है: actions execute करने वाला component बाद में अपनी history को चुपचाप बदल नहीं सकता। Ciphertext पर verification reviewer को हर secret या action payload तक access दिए बिना continuity जाँचने देती है। इससे log complete नहीं हो जाता। यह अभी भी केवल वही activity record करता है जो gateway से गुज़री, इसलिए remote service logs review का हिस्सा बने रहते हैं।

Sallyport agent sessions और individual actions को एक encrypted, hash-chained audit log में record करता है और `sp audit verify` vault key के बिना chain को offline जाँचता है। इससे incident reviewer को exported log copy पर चलाने के लिए साफ test मिलता है:

```sh
sp audit verify /path/to/exported-audit-log
```

Successful verification आपके पास मौजूद encrypted record की continuity स्थापित करती है। Verification fail हो तो casual cleanup रोकें और evidence handling शुरू करें, क्योंकि यह पता लगाना होगा कि break export damage, storage corruption या जानबूझकर किए गए बदलाव से हुआ।

Review को vague observations की सूची नहीं, answers देने चाहिए। Triggering instruction या input, run को मिली authority, हर confirmed external action, अभी uncertain हर action, बाहर निकल चुके संभावित credentials और वह control change पहचानें जो घटना को पहले रोक सकता था। अगर team पहले fail हुए control का नाम नहीं बता सकती, तो exposed route ठीक करने के बजाय noisy approval prompt जोड़ने की संभावना है।

## Development को reopened session से नहीं, fresh boundary से resume करें

Containment के बाद developers काम जारी रख सकते हैं, लेकिन उन्हें उसी process, workspace state या authority grant के जरिए resume नहीं करना चाहिए। Interrupted run की memory में unreviewed instructions, stale task context, generated scripts या ऐसा child process हो सकता है जिसे पहली response ने miss कर दिया।

नई session identity के साथ नया run बनाएँ। New run को credentials या production targets देने से पहले repository diff और generated files की समीक्षा करें। अगर पहले वाला task जारी रखना हो, तो नए run को एक छोटा written handoff दें जिसमें बताया गया हो कि कौन-से remote actions पूरे हुए, कौन-से cancelled हैं और किन resources की जाँच बाकी है।

Resumed task के लिए permissions और संकरी रखें। Code review task को deployment authority की शायद ही ज़रूरत होती है। Production query करने वाले task को आम तौर पर write access नहीं चाहिए। उद्देश्य हर developer को जटिल policy language में बाँधना नहीं, बल्कि incident के बाद शुरू हुए run में पिछली broad grant को आगे न ले जाना है।

Per-session authorization तब खास तौर पर उपयोगी है जब stop event के बाद नया local process शुरू हो, क्योंकि इससे इंसान को पहचानना पड़ता है कि यह अलग run है। जहाँ गलत write की कीमत interruption को उचित ठहराती हो, वहाँ per-call approval उपयोगी है। अगर approval card calling process और specific action की पहचान नहीं बताता, तो incident के दौरान उस पर भरोसा करने से पहले उसे ठीक करें।

पहली drill पंद्रह मिनट की होनी चाहिए: harmless agent task शुरू करें, API call के दौरान उसका session revoke करें, local और remote records सुरक्षित रखें और पुष्टि करें कि task पुरानी authority के तहत resume नहीं हो सकता। Drill disposable target पर करें। इससे missing request IDs, detached children और log access की समस्याएँ वास्तविक production mistake के दौरान नहीं, कम लागत वाली स्थिति में सामने आएँगी।

## Revocation को सामान्य operator action बनाएँ

जो team revocation को दुर्लभ emergency मानती है, वह agent के अजीब behavior पर झिझकेगी। Controls safe decision को तेज़ बनाएँ: action boundary lock करें, session revoke करें, जो पहले boundary पार कर चुका है उसे जाँचें और ऐसा record छोड़ें जो cleanup के बाद भी बचा रहे।

सबसे मजबूत design choice सरल separation है। Agents plan कर सकते हैं और actions का अनुरोध कर सकते हैं। Local control point credentials अपने पास रखता है, request करने वाले process की पहचान करता है, request record करता है और secret दिए बिना उस process को deny कर सकता है। Operator के stop दबाते ही अगली privileged call fail होनी चाहिए और पहले की calls review योग्य रहनी चाहिए।

इस दावे को उन वास्तविक tools के साथ test करें जिनका आपके agents इस्तेमाल करते हैं। अगर team shared credential rotate किए बिना एक live run रोक नहीं सकती, remote operation को उस run से correlate नहीं कर सकती या बाद में अपनी action history verify नहीं कर सकती, तो incident workflow अभी अधूरा है।