# अस्थायी प्रोडक्शन एक्सेस: ऐसे ग्रांट जो कार्य के साथ समाप्त हो जाएँ

AI coding agent का प्रोडक्शन एक्सेस इसलिए समाप्त होना चाहिए क्योंकि ऑथराइज़ेशन सिस्टम उसे समाप्त करता है, न कि इसलिए कि कोई व्यक्ति बाद में लौटने का इरादा रखता था। उद्देश्य, समय-सीमा और समाप्ति के बाद की जाँच किसी जोखिम भरे अपवाद को सीमित ग्रांट में बदल देते हैं, जिसकी समीक्षा दूसरा इंजीनियर कर सकता है।

मैंने एक्सेस कंट्रोल को अक्सर साधारण तरीके से विफल होते देखा है: घटना सुलझ जाती है, कार्य बंद हो जाता है, लेकिन क्रेडेंशियल उपयोगी बना रहता है। उस दिन कुछ नाटकीय नहीं होता। महीनों बाद वही क्रेडेंशियल किसी असंबंधित स्क्रिप्ट में दिखाई देता है, पुरानी एजेंट प्रक्रिया फिर चल पड़ती है या कोई व्यक्ति सुविधा के लिए उसका उपयोग करता है। मूल अपवाद लापरवाही के कारण स्थायी प्रोडक्शन एक्सेस बन जाता है।

अस्थायी प्रोडक्शन एक्सेस के लिए तीन बातें ज़रूरी हैं, जिन्हें enforcement point जाँच सके: एजेंट क्यों कार्रवाई कर सकता है, वह किन चीज़ों को छू सकता है और उसे कब रुकना होगा। अंतिम बात पहली दो जितनी ही महत्वपूर्ण है। यदि आप कार्य बंद होने के बाद अस्वीकृति दिखा नहीं सकते, तो कार्य पूरा नहीं हुआ है।

## समय-सीमा को अनुरोध अस्वीकार करना चाहिए, केवल टिकट सजाना नहीं

समाप्ति समय तभी प्रभावी होता है, जब कार्रवाई करने या अधिकृत करने वाला घटक हर अनुरोध पर उसकी जाँच करे। प्रोजेक्ट ट्रैकर, कैलेंडर प्रविष्टि या चैट रिमाइंडर किसी पुरानी प्रक्रिया को 02:00 बजे API कॉल करने से नहीं रोक सकते।

कई टीमों को यह अंतर तब पता चलता है, जब उनकी बदलाव प्रक्रिया अनुशासित दिखती है। वे टिकट, समीक्षक और क्लोज़र स्टेटस अनिवार्य करते हैं, फिर एजेंट को ऐसा क्रेडेंशियल दे देते हैं जो किसी के मैन्युअली रोटेट करने तक वैध रहता है। वर्कफ़्लो इरादा दर्ज करता है, जबकि क्रेडेंशियल अधिकार बनाए रखता है।

समाप्ति को उस जगह लागू करें जहाँ अनुरोध प्रोडक्शन में प्रवेश करता है। आपके डिज़ाइन के अनुसार यह short-lived token जारी करने वाला identity provider, grant database जाँचने वाला access gateway, SSH certificate validator या क्रेडेंशियल रखकर कार्रवाई करने वाला broker हो सकता है। सुरक्षित सेवा को ऐसा अनुरोध मिलना चाहिए, जिसे समय-सीमा के बाद वह अस्वीकार कर सके।

NIST SP 800-207 zero trust architecture के वर्णन में उपयोगी बात कहता है: enterprise resource का session स्थापित होने से पहले access decision का मूल्यांकन होना चाहिए और access प्रति-session दिया जाना चाहिए। इसका अर्थ यह नहीं कि हर application को पूरा zero trust product अपनाना होगा। इसका अर्थ यह है कि एक बार session देकर उसे हमेशा उपयुक्त मान लेना इस मॉडल के विपरीत है।

एजेंट के लिए कम से कम हर कार्रवाई की शुरुआत पर जाँच करें। लंबे समय तक चलने वाले काम के लिए अलग निर्णय लें: शुरू हो चुकी कार्रवाई को सीमित lease के भीतर पूरा होने दें या lease समाप्त होने पर उसे रद्द करें। यह व्यवहार outage से पहले तय करें, क्योंकि database repair के बीच अचानक कटऑफ भी अनियंत्रित एक्सेस जितना नुकसान कर सकता है।

समय-सीमा एक ही समय-आधार, सामान्यतः UTC, में timestamp होनी चाहिए। «दिन खत्म होने तक» न लिखें और यह उम्मीद न करें कि हर सिस्टम उसी दिन का अर्थ समझेगा। `2025-04-18T16:30:00Z` संग्रहित करें, मंज़ूरी देने वाले व्यक्ति को स्थानीय समय दिखाएँ और अनुरोध पथ की तुलना संग्रहित timestamp से कराएँ।

## उद्देश्य को ग्रांट की सीमा तय करनी चाहिए

उद्देश्य तभी उपयोगी है, जब वह एजेंट की कार्रवाइयों को सीमित करे। «प्रोडक्शन में मदद करें» और «अलर्ट की जाँच करें» अनुमति की सीमा नहीं बताते।

उद्देश्य इस तरह लिखें कि मंज़ूरी न देने वाला इंजीनियर भी तय कर सके कि कोई अनुरोध उसके दायरे में आता है या नहीं। अच्छे विवरण में triggering work item, लक्ष्य, अनुमत कार्रवाई और पूरा होने की शर्त होती है। उदाहरण के लिए:

> Incident INC-482 में checkout failures बढ़ने की जाँच करें। checkout service के logs और deployment status पढ़ें। incident commander की मंज़ूरी मिलने पर ही checkout worker को restart करें। INC-482 हल होते ही या 16:30 UTC पर, जो पहले हो, access समाप्त करें।

ऐसा विवरण स्पष्ट निर्णय संभव बनाता है। Billing database पढ़ना इसके दायरे में नहीं आता। असंबंधित application बदलाव भेजना भी नहीं आता। Worker को restart करने के लिए नामित मंज़ूरी चाहिए। एजेंट को खुला चेक दिए बिना भी उपयोगी काम कराया जा सकता है।

दायरे के लिए केवल «production» लेबल पर्याप्त नहीं है। ग्रांट को ठोस लक्ष्यों से बाँधें:

- नामित API hosts, repositories या SSH hosts
- नामित methods या commands, जैसे `GET /health` या deployment status query
- नामित environments और account identifiers
- जहाँ बार-बार अनुरोध संभव हों, वहाँ अधिकतम action count या request rate
- काम रोक सकने वाला मानव owner

यह लोकप्रिय सलाह न मानें कि एजेंट को व्यापक read access दें क्योंकि «read-only सुरक्षित है»। Read access से customer records, configuration, topology, deployment history या पुराने logs में मौजूद credentials उजागर हो सकते हैं। एजेंट आवश्यकता से कहीं अधिक context भी इकट्ठा कर सकता है। उसे कार्य के लिए ज़रूरी विशिष्ट observability endpoints और log query range दें।

एक और सीमा अक्सर धुंधली हो जाती है: task purpose और prompt एक ही चीज़ नहीं हैं। Prompt एजेंट को बताता है कि आपने उससे क्या करने को कहा। Authorization purpose enforcement point को बताता है कि prompt बदलने, model के गलत अनुमान लगाने या tool output में hostile instructions आने पर भी वह क्या अनुमति दे सकता है। Prompt को access decision के लिए untrusted input मानें।

## क्रेडेंशियल और अधिकार अलग तरह से समाप्त होते हैं

क्रेडेंशियल यह साबित करता है कि caller के पास कोई चीज़ है। Authorization तय करता है कि caller अभी यह अनुरोध कर सकता है या नहीं। काम समाप्त होने पर दोनों समाप्त होने चाहिए।

`exp` claim वाला bearer token अच्छा समय-नियंत्रण हो सकता है, यदि प्राप्त करने वाली API हर अनुरोध पर signature, audience और expiry जाँचती हो। यह सार्वभौमिक समाधान नहीं है। कुछ सेवाएँ authentication cache करती हैं, opaque tokens स्वीकार करती हैं या server-side state के आधार पर token को अधिकृत करती हैं, जो सक्रिय रहती है। 15 मिनट में समाप्त होने वाला token भी task boundary को पूरा नहीं करता, यदि चार मिनट में समाप्त हो चुके कार्य के लिए उसे जारी किया गया था।

SSH में भी यही समस्या आती है। OpenSSH validity interval वाले signed user certificates का समर्थन करता है। `ssh-keygen` manual में `-V` validity interval विकल्प है। Short-lived certificate, agent workspace में long-lived private key रखने से बेहतर है, लेकिन expiry केवल समय का प्रश्न हल करती है। Principals, destination hosts और command behavior भी सीमित करने होंगे।

20 मिनट के लिए वैध certificate का उदाहरण:

```sh
ssh-keygen -s ./user_ca -I agent-run-7f3a \\
  -n deploy-readonly -V +20m ./agent-run-7f3a.pub
```

आउटपुट सामान्यतः signed public key file का नाम दिखाता है, जैसे:

```text
Signed user key ./agent-run-7f3a-cert.pub: id "agent-run-7f3a" serial 0 for deploy-readonly valid from 2025-04-18T16:00:00 to 2025-04-18T16:21:00
```

इस certificate को पूरा task grant न समझें। यदि remote account मनमाने commands चला सकता है, तो certificate 16:21 तक मनमाने commands की अनुमति देता रहेगा। आवश्यकतानुसार constrained account, forced command या host-side command allowlist इस्तेमाल करें।

Revocation और expiry अलग हैं। Expiry अनुमानित होती है और central revocation service उपलब्ध न होने पर भी काम करती है। Revocation घटना सुलझने, एजेंट के अप्रत्याशित व्यवहार या approver द्वारा सहमति वापस लेने पर अधिकार जल्दी समाप्त करती है। अच्छा डिज़ाइन दोनों का समर्थन करता है: कम maximum lifetime और तत्काल revocation।

## कार्य बंद होने पर machine-readable event चाहिए

कार्य बंद करने पर ऐसा event बनना चाहिए, जिसे access component पढ़ सके। Connected revocation path के बिना ticket status बदलने से पूरा होने का झूठा भरोसा पैदा होता है।

दो termination conditions रखें। पहली, grant बनाते समय तय hard end time। दूसरी, work system या ज़िम्मेदार व्यक्ति से आने वाला पहले का closure signal। Effective end इन दोनों में जो पहले हो, वह है। Reopened ticket पुराने grant को चुपचाप बहाल न करे। इसके लिए नई मंज़ूरी और नया end time चाहिए।

Authorization को task identifier के साथ immutable run identifier से भी बाँधें। एक task कई दिनों में कई runs कर सकता है। हर run का अपना start, end और owner होना चाहिए। Run समाप्त होते ही grant revoke करें। Task बंद होने पर उससे जुड़े सभी सक्रिय runs revoke करें।

Closure event का receiver idempotent होना चाहिए। Systems webhooks दोबारा भेजते हैं और operators बटन दो बार दबाते हैं। Revocation request को repeated delivery स्वीकार करनी चाहिए और पहले effective timestamp को बनाए रखना चाहिए।

Closure का स्रोत दर्ज करें। Ticketing system का status change, incident commander का manual stop, process exit और hard expiry जाँच के दौरान अलग अर्थ रखते हैं। Access के लिए परिणाम समान है, लेकिन audit record में समाप्ति का कारण रहना चाहिए।

Deadline के पास एजेंट अधिक tool calls करे तो उसे automatic extension न दें। इससे व्यस्त process को अधिक अधिकार मिलते हैं। मानव से नई मंज़ूरी लें और काम बदलने पर उद्देश्य भी संशोधित करें।

## Grant record अस्पष्ट मंज़ूरियों को रोकता है

Structured grant record मंज़ूरी को enforce करने योग्य और review करने योग्य बनाता है। इससे एजेंट के production छूने से पहले छूटे हुए निर्णय भी सामने आते हैं।

यह उदाहरण जानबूझकर सरल है। यह policy language नहीं, record format है। इसके fields किसी एजेंट run को अस्पष्ट और दोबारा इस्तेमाल होने वाली permission विरासत में लेने से रोकते हैं।

```yaml
grant_id: grant_01JQ7P8V6R
agent_run_id: run_7f3a2c
purpose: "INC-482: inspect checkout worker failures"
owner: "on-call engineer"
created_at: "2025-04-18T16:00:00Z"
ends_at: "2025-04-18T16:30:00Z"
ends_on_task_close: "INC-482"
targets:
  - "https://ops.example.internal/checkout/status"
  - "ssh://checkout-worker-03.internal"
allowed_actions:
  - "GET /checkout/status"
  - "journalctl -u checkout-worker --since 20m"
closure_required: true
verification_action: "GET /checkout/status"
```

Record «production access: yes» नहीं कहता। वह उन महत्वपूर्ण विकल्पों को छिपा देता। Record बताता है कि निर्णय का मालिक कौन है, इसे कौन-सा run पाता है और grant समाप्त होने का प्रमाण किस अनुरोध से मिलेगा।

दायरा इतना स्पष्ट रखें कि approver उसे अस्वीकार कर सके। Wildcard paths की लंबी सूची को लोग दबाव में समझ नहीं पाते और access को बिना सोचे मंज़ूर कर देते हैं। यदि एजेंट को बीस असंबंधित targets चाहिए, तो काम को अलग grants में बाँटें या मानें कि उद्देश्य बहुत व्यापक है।

इस record में secret न रखें। Grant identifier और target description पर्याप्त हैं। Executor grant जाँचने के बाद protected credential प्राप्त कर सकता है। इससे उपयोगी audit data रखा जा सकता है, बिना उस सामग्री को बचाए जिससे production access फिर बनाया जा सके।

Record restart के बाद भी उपलब्ध और agent चलाने वाले व्यक्ति के दृष्टिकोण से append-only होना चाहिए। यदि एजेंट `ends_at` बदल सकता है, targets संशोधित कर सकता है या closure signal मिटा सकता है, तो सुरक्षा निर्णय उसी process को दे दिया गया है जिसे सीमित करना था।

पहले से चल रही कार्रवाइयों के लिए स्पष्ट निर्णय लें। Log query expiry के बाद पूरी हो सकती है। Deployment, migration या restart के लिए cancellation rule, transaction boundary या human takeover procedure की आवश्यकता हो सकती है। सबसे खराब विकल्प है यह व्यवहार परिभाषित न करना और recovery के दौरान पता लगाना।

## Negative request से expiry साबित करें

Access समाप्त होने का प्रमाण उसी path से भेजे गए ऐसे request से मिलता है, जिसे अब fail होना चाहिए। Closed ticket, admin console में expired badge और database में revoked row सहायक प्रमाण हैं, मुख्य प्रमाण नहीं।

Task closure या expiry, जो पहले हो, उसके तुरंत बाद जाँच schedule करें। ऐसा harmless endpoint इस्तेमाल करें, जिसे अभी भी grant चाहिए, जैसे service status request। Public health check से test न करें, क्योंकि वह access समाप्त हुआ हो या नहीं, सफल रहेगा।

सरल test sequence:

```sh
# This call succeeded while the grant was active.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

# After task closure, repeat the exact protected operation.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status
```

दूसरे command का output इस तरह होना चाहिए:

```text
request_id=req_92a1
status=403
reason=grant_ended
ended_at=2025-04-18T16:12:09Z
```

आपका implementation `401`, `403` या connection refusal दे सकता है। एक अर्थ चुनकर उसे document करें। Audit entry में स्पष्ट होना चाहिए कि access layer ने grant समाप्त होने के कारण request अस्वीकार किया, न कि DNS failure या target unavailable होने के कारण।

वे paths भी test करें जिन्हें लोग भूल जाते हैं। यदि एजेंट HTTPS और SSH दोनों इस्तेमाल कर सकता है, तो दोनों जाँचें। यदि service API exchange के बाद cookie जारी करती है, तो देखें कि cookie grant से अधिक समय तक जीवित न रहे। यदि worker actions को locally queue करता है, तो सुनिश्चित करें कि executor queued action भेजते समय authorization जाँचता हो, केवल job स्वीकार करते समय नहीं।

Production पर भरोसा करने से पहले non-production में scheduled expiry test चलाएँ। बहुत कम lifetime वाला grant बनाएँ, allowed request करें, expiry तक प्रतीक्षा करें और वही request फिर करें। फिर दूसरे active grant को जल्दी revoke करके अनुरोध दोहराएँ। ये दोनों अलग दोष पकड़ते हैं: clock handling और early revocation।

Deadline जाँचने वाला component trusted system clock इस्तेमाल करे और evaluation time log करे। यदि laptop की clock पीछे करके access बढ़ाया जा सकता है, तो deadline लागू करने योग्य नहीं है। Central broker यह जोखिम घटा सकता है, लेकिन उसके time source की निगरानी फिर भी आवश्यक है।

## Agent process की अपनी सीमा होनी चाहिए

Task retries, terminals और model turns के पार जारी रह सकता है, लेकिन agent process access control की व्यावहारिक इकाई है। Per-run authority से मंज़ूरी, व्यवहार की निगरानी और तत्काल revocation स्पष्ट हो जाते हैं।

Conversation को process न समझें। Model restart के बाद या tool द्वारा child process शुरू करने के बाद user एजेंट से कह सकता है, «जाँच जारी रखें»। यदि access नई authorization event के बिना conversation का पीछा करता है, तो operator यह नहीं जान पाएगा कि permission किस executable के पास है।

Run शुरू करने वाले process की पहचान दर्ज करें। macOS पर code-signing authority, user द्वारा दिए गए process name से अधिक उपयोगी जानकारी देती है। `agent` नाम का process लगभग कुछ नहीं बताता। Recorded signing identity, executable path, parent process और launch time बाद की समीक्षा संभव बनाते हैं।

Sallyport डिफ़ॉल्ट रूप से नए agent process के लिए session approval इस्तेमाल करता है और उसका approval card process की code-signing authority को सबसे ऊपर दिखाता है। यह अच्छी process boundary है, लेकिन session approval फिर भी end time वाले task grant के भीतर होना चाहिए।

Normal process exit पर kill या revoke करें, लेकिन केवल exit पर निर्भर न रहें। Processes crash करते हैं, machines sleep होती हैं और parent-child संबंध जटिल हो जाते हैं। Hard deadline और task closure event backstop बने रहें। यदि process task closure के बाद जीवित है, तो operating system की सफाई से पहले ही request path को उसे अस्वीकार करना चाहिए।

Human operator के terminal access को agent access से अलग रखें। Agent को operator का authenticated shell inherit करने देना आसान लगता है, लेकिन इससे attribution बेकार हो जाती है और उस दिन operator द्वारा जमा की गई हर privilege agent को मिल सकती है। Agent को अलग identity दें और उसे अपने path से अनुरोध करने दें।

## Approval prompts scope की आवश्यकता समाप्त नहीं करते

Approve पर क्लिक करने वाला व्यक्ति स्पष्ट रूप से गलत request पकड़ सकता है, लेकिन prompts बहुत बार आएँ या बहुत कम विवरण दें तो approvals कमजोर हो जाती हैं। «allow API call» जैसा prompt मानव से परिणाम का अनुमान लगाने को कहता है।

Approver को purpose, target, method या command, grant end time और agent identity दिखाएँ। यदि system request को इन terms में समझा नहीं सकता, तो जिम्मेदारी से मंज़ूरी माँगने के लिए पर्याप्त जानकारी एकत्र नहीं हुई है।

Irreversible effects वाली कार्रवाइयों, जैसे data deletion, credential rotation, payment run या unreviewed change deployment, के लिए per-call approval उपयोगी है। हर log read के लिए इसे सामान्य नियंत्रण न बनाएँ। Incident के दौरान लोग दोहराए जाने वाले prompts को reflex से approve करते हैं।

Per-call approval flag वाली call पर Sallyport हर उपयोग के लिए approval माँगता है, लेकिन यह end time का विकल्प नहीं होना चाहिए। मानव 16:29 पर valid request approve कर सकता है, फिर भी grant समाप्त होने के बाद access path को हर request अस्वीकार करनी चाहिए।

ऐसा तेज़ emergency stop रखें, जिसके लिए मूल approver खोजने की ज़रूरत न हो। Agent loop करे, output गलत समझे या गलत target छूने लगे, तो on-call engineer run समाप्त कर सके। Stop का उपयोग करने वाला व्यक्ति और कारण दर्ज करें।

## Audit trail को असहज सवालों के जवाब देने चाहिए

Production घटना के बाद लोग पूछते हैं कि access कब शुरू हुआ, किसने अनुमति दी, किस process ने उसका उपयोग किया, कौन-से requests सफल हुए और क्या access सचमुच रुक गया। केवल successes दर्ज करने वाले logs अंतिम प्रश्न का उत्तर नहीं दे सकते।

Denied calls भी दर्ज करें, खासकर expiry या revocation के बाद की denials। Denial साबित करती है कि enforcement point को request मिली और उसने सीमा लागू की। इससे ऐसा अटका हुआ agent भी दिख सकता है जो task closure के बाद लगातार प्रयास कर रहा है।

Grant decision और individual actions को identifiers से जोड़ें। Reviewer को `grant_01JQ7P8V6R` से approving owner, संबंधित task, run identity, allowed scope, closure source और हर request तक पहुँचना चाहिए।

Tamper evidence महत्वपूर्ण है, क्योंकि access records को बदलने की किसी की इच्छा हो सकती है। Sallyport अपने session और activity journals को encrypted, hash-chained audit log से बनाता है और `sp audit verify` ciphertext पर offline chain जाँच सकता है। यह तय नहीं करता कि request उचित थी, लेकिन recorded sequence में छेड़छाड़ छिपाना कठिन बनाता है।

हर prompt और model thought को action logs का विकल्प न बनाएँ। इससे privacy और retention समस्याएँ बढ़ती हैं और वास्तविक network request फिर भी स्पष्ट नहीं हो सकती। Authorization decision और action result से शुरू करें। Prompt context तभी जोड़ें, जब operational और privacy rules उसे उचित ठहराएँ।

Reviewers के लिए fixed closure record रखें। इसमें grant identifier, effective end timestamp, termination source, सफल actions की संख्या, end के बाद denied actions की संख्या और verification request का परिणाम होना चाहिए।

## नियंत्रण को छोटी, testable sequence में बनाएँ

Temporary access लागू करने के लिए general policy engine आवश्यक नहीं है। एक सीमित mechanism चाहिए, जिससे हर agent action गुज़रे, और refusal path चाहिए, जिसे test किया जा सके।

सबसे पहले production में agents द्वारा की जाने वाली कार्रवाइयों की सूची बनाएँ। Read operations, reversible writes और irreversible या व्यापक प्रभाव वाली कार्रवाइयों को अलग करें। हर action के लिए वास्तविक credential holder और enforcement point पहचानें। यह exercise अक्सर environment variables, shell profiles, CI logs या copied configuration files में पड़े credentials सामने लाती है।

Minimum lifecycle इस तरह रखें:

1. अलग run identity और purpose तथा hard end time वाला structured grant बनाएँ।
2. हर protected HTTP या SSH action को ऐसे executor से भेजें, जो उपयोग से पहले grant जाँचे।
3. Early closure या revoke event स्वीकार करें और उसका effective timestamp दर्ज करें।
4. Termination के बाद harmless protected request भेजें और denial result रखें।
5. Expired और revoked grants की नियमित समीक्षा करें, ताकि access समाप्त होने के बाद जारी प्रयास दिख सकें।

हर संभव command को classify करने वाले जटिल rules से शुरुआत न करें। Teams syntax पर सप्ताह बिताती हैं, जबकि agents के पास long-lived credentials बने रहते हैं। Named targets, short lifetimes, per-run identity और denial के प्रमाण से शुरू करें। जहाँ action history दिखाए कि broad scopes माँगे जा रहे हैं, वहीं finer restrictions जोड़ें।

मानक सरल और कठोर है: task बंद होने पर पुराना agent process production boundary पर fail होना चाहिए और आपको यह दिखा पाना चाहिए कि वह क्यों fail हुआ। जब तक यह जाँच नहीं चलती, access केवल कागज़ पर temporary है।