AI agent actions के approver: शिफ्ट के अनुसार ownership

एक AI एजेंट की कार्रवाई को मंजूर करने वाला व्यक्ति वही होना चाहिए जो संबंधित शिफ्ट के दौरान प्रभावित सिस्टम की जवाबदेही संभालता हो। यह जिम्मेदारी उस डेवलपर को अपने-आप नहीं मिलनी चाहिए जिसने संयोग से कोडिंग सेशन खोला है। अक्सर ये अलग-अलग लोग होते हैं। उन्हें एक ही मानने पर ऐसी मंजूरियां मिलती हैं जो तब तक सही लगती हैं, जब तक प्रोडक्शन में कुछ गलत न हो जाए।

मैंने यह समस्या किसी नाटकीय sabotage के जरिए नहीं, बल्कि रोजमर्रा के तरीके से होते देखी है। एक डेवलपर एजेंट से build की समस्या की जांच करने को कहता है। एजेंट को उससे जुड़ा production endpoint मिलता है, सेटिंग बदलने के लिए write का अनुरोध करता है और डेवलपर मंजूरी दे देता है, क्योंकि प्रॉम्प्ट उसके terminal में आया था। सर्विस का मालिक इस बदलाव को बाद में अपनी on-call शिफ्ट के दौरान देखता है। उसके पास संदर्भ नहीं होता और इस सवाल का उपयोगी जवाब भी नहीं होता कि «यह जोखिम किसने स्वीकार किया?»

जिम्मेदारी सिस्टम, उसकी वर्तमान स्थिति और pager संभालने वाले व्यक्ति के साथ चलनी चाहिए। अच्छी मंजूरी व्यवस्था कार्रवाई चलने से पहले ही यह बात स्पष्ट कर देती है।

सेशन शुरू करने वाला व्यक्ति आमतौर पर परिणाम का मालिक नहीं होता

एजेंट शुरू करने वाला व्यक्ति अपने लिखे अनुरोध की जिम्मेदारी लेता है। इसका मतलब यह नहीं कि वह उस database, vendor account, deployment target या customer data का भी मालिक है, जिसे एजेंट छू सकता है।

यह फर्क तब तक बहुत बारीक लगता है, जब तक coding task किसी दूसरी सीमा को पार न कर जाए। Repository में deployment scripts, operational credentials, migration tools और कई टीमों द्वारा संभाले जाने वाले सिस्टम के links हो सकते हैं। किसी repository को अच्छी तरह जानने वाले इंसान से एजेंट इन रास्तों पर कहीं तेज चल सकता है। Codebase से परिचय होने पर भी लॉन्च करने वाले व्यक्ति को हर reachable system पर operational authority नहीं मिलती।

अपनी व्यवस्था में तीन भूमिकाएं अलग रखें:

• Requester एजेंट से किसी चीज की जांच, बदलाव या deployment करने को कहता है।
• System owner अपनी assigned shift के दौरान target service का operational risk स्वीकार करता है।
• Executor मंजूरी मिलने के बाद call या command चलाने की क्षमता रखता है।

छोटी टीम में एक व्यक्ति तीनों भूमिकाएं निभा सकता है। जब यह बात स्पष्ट हो, तो इसमें कोई समस्या नहीं। गलती तब होती है जब एजेंट के किसी एक डेवलपर की मशीन पर चलने के कारण इन भूमिकाओं को चुपचाप एक कर दिया जाता है।

इससे एक आम बहस भी साफ हो जाती है: «डेवलपर अपने एजेंट के लिए जिम्मेदार है।» वह एजेंट को निर्देशित करने और जमा किए गए code के लिए जिम्मेदार है। On-call owner service behavior, data handling, rollback decisions और customer impact के लिए जिम्मेदार है। Permission prompt उस व्यक्ति तक जाना चाहिए जो दूसरा निर्णय ले सकता हो।

NIST SP 800-53 Rev. 5 का control AC-2 designated account managers और account management procedures की मांग करता है। इसमें agent approval screen का निर्देश नहीं है, लेकिन मूल अनुशासन यहां सीधे लागू होता है: access की जिम्मेदारी तय करें, उसे इस बात की स्वाभाविक संपत्ति न मानें कि इस समय कौन logged in है। Agent actions के लिए relevant account manager अक्सर current service owner होता है, workstation user नहीं।

Service ownership में शिफ्ट की सीमा भी होनी चाहिए

स्थायी ownership record में service और इस समय जिम्मेदार व्यक्ति, दोनों का नाम होना चाहिए। 02:00 बजे, छुट्टी के दौरान या incident के बीच केवल static team name पर्याप्त नहीं है।

हर उस system के लिए जिसे agent प्रभावित कर सकता है, चार fields वाला छोटा roster रखें: primary owning team, active shift owner, backup और escalation route। Roster on-call system, repository या internal directory में रह सकता है। जगह से ज्यादा महत्वपूर्ण यह है कि लोग उसे अपडेट रखें और approval system उसे देख सके।

वही service boundary इस्तेमाल करें जिसे operator alert मिलने पर पहचानते हैं। «Payments API production» उपयोगी target है। «Backend» नहीं। एक broad team label अलग-अलग databases, vendors, data classifications और rollback procedures को छिपा देता है।

एक न्यूनतम record ऐसा हो सकता है:

service: billing-api-production
active_owner: billing-oncall
backup_owner: payments-duty-manager
escalation: incident-commander
approval_rules:
  read_customer_records: session
  change_remote_configuration: per_call
  production_database_write: per_call
  create_vendor_credentials: prohibited

यह agent के लिए समझने की policy language नहीं है। यह इंसानों के स्वामित्व वाली घोषणा है, जो बताती है कि निर्णय कौन ले सकता है और किसी कार्रवाई को कितनी जांच चाहिए। यह उस परिचित समस्या को रोकती है जिसमें approval request general engineering channel में पहुंचता है, कोई repository का नाम पहचान लेता है और production system को कोई नहीं पहचानता।

Roster को operational data मानें। Team reorganization, नई managed service या on-call rotation में बदलाव इसे अमान्य कर सकता है। अगर approval routing ऐसी spreadsheet पर निर्भर है जिसे केवल एक manager edit कर सकता है, तो आपने एक शांत single point of failure बना दिया है।

कार्रवाई का जोखिम verb से नहीं, target से तय होता है

«Read» और «write» approval rights तय करने के लिए बहुत मोटी श्रेणियां हैं। Public status endpoint पर होने वाला read उस read से अलग है जो customer export, deployment secret या internal hosts की पूरी सूची लौटाता है। Temporary branch बनाने वाला write उस write से अलग है जो payment provider की setting बदलता है।

कार्रवाइयों को सफल परिणाम के प्रभाव के आधार पर वर्गीकृत करें। पहले target system और data देखें, फिर reversibility और blast radius पर विचार करें। इससे owners को approval scope चुनने का वास्तविक आधार मिलता है।

व्यावहारिक श्रेणियां कम रखी जा सकती हैं:

• Routine operational reads कोई sensitive material नहीं लौटाते और state नहीं बदलते।
• Scoped changes एक ज्ञात resource को प्रभावित करते हैं और उनके लिए documented rollback होता है।
• High-impact changes production configuration, customer data, access या external commitments को प्रभावित करते हैं।
• Prohibited actions autonomous agent channel से कभी नहीं चलनी चाहिए।

किसी कार्रवाई को केवल इसलिए low risk न कहें कि HTTP method GET है। मैंने diagnostic endpoints को environment variables, signed links और ऐसी operational details लौटाते देखा है, जो coding agent तक कभी नहीं पहुंचनी चाहिए थीं। Endpoint को समझने वाला owner ही उसका classification करे।

इसी तरह हर harmless status check के लिए manual confirmation न मांगें। इससे approval fatigue पैदा होती है। लोग routine prompt को routine मानकर जल्दी click करने लगते हैं और फिर उस call को भी मंजूर कर देते हैं जो routine नहीं थी। Credentials और उन targets के लिए per-call approval रखें जहां हर invocation पर सोच-समझकर निर्णय चाहिए।

Approval text में concrete target साफ दिखना चाहिए। «Agent requests API access» से owner को कुछ पता नहीं चलता। «Agent process requests PATCH to production billing configuration using the billing-admin credential» पढ़कर वह रुक सकता है और सही सवाल पूछ सकता है।

सीमित सेशन, blank check नहीं होता

Session approval एक तय अवधि के लिए एक पहचानी गई agent process तक सीमित होनी चाहिए। इसे उसी repository या user account से भविष्य में शुरू होने वाली हर process की मंजूरी न बनाएं।

यह फर्क तब महत्वपूर्ण है जब handoff के दौरान terminal खुला रह जाए, developer instructions बदलने के बाद agent restart करे या कोई malicious local process किसी परिचित command की नकल करे। केवल user identity से जुड़ी approval बहुत व्यापक है। स्पष्ट identity के बिना process से जुड़ी approval को गलत समझना आसान है।

अच्छी session approval साधारण भाषा में पांच बातें बताती है: किस process ने अनुरोध किया, उस process को किसने sign या supply किया, वह कौन सा action channel इस्तेमाल कर सकती है, कौन सा service scope लागू है और उसकी permission कब खत्म होगी। Process exit होते ही session खत्म होना चाहिए। नई process के लिए नया निर्णय चाहिए।

Sallyport की per-session authorization इसी तरीके से काम करती है। वह requesting process का code-signing authority दिखाती है और उस run को केवल उसके exit होने तक मंजूर करती है। यह terminal tab पर भरोसा करने से बेहतर default है, क्योंकि terminal tab identity boundary नहीं है।

High-impact credentials को session grant से बाहर रखें। Production database write या vendor access change के लिए current owner को हर बार prompt मिलना चाहिए, भले ही उसने दस मिनट पहले agent का diagnostic session मंजूर किया हो। पहली approval कहती है, «यह process इस system पर काम कर सकती है।» बाद की approval कहती है, «मैं इस खास irreversible या sensitive action को स्वीकार करता हूं।» ये अलग-अलग निर्णय हैं।

«Developer tools» नाम से permanent approvals न बनाएं। वे ऐसे entitlement pools बन जाते हैं जिन पर किसी का ध्यान नहीं रहता। Incident review भी कठिन हो जाता है, क्योंकि कोई यह नहीं बता पाता कि मंजूरी देने वाले व्यक्ति ने इस खास agent को उस capability का इस्तेमाल करते हुए सोचा भी था या नहीं।

Shift handoff में केवल जानकारी नहीं, अधिकार भी منتقل होना चाहिए

«Alex अब on call है» कहने वाला handoff message agent approvals को ठीक नहीं करता, अगर कल के sessions और approvals अभी भी पुराने owner के अधिकार से चलते रहें।

Outgoing owner को active agent work उसी तरह hand over करना चाहिए जैसे partially mitigated alert hand over किया जाता है। Process identity, target services, requested scope, expiration और confirmation की प्रतीक्षा कर रही कार्रवाइयां दर्ज करें। Incoming owner को shift स्वीकार करने से पहले यह record दिखना चाहिए।

यह handoff sequence अपनाएं:

1. उन sessions को खत्म या revoke करें जिन्हें outgoing owner अब sponsor नहीं करना चाहता।
2. जारी रहने वाले active sessions की सूची दें, उनके target और expiry के साथ।
3. Service roster incoming owner को transfer करें और उसका notification path पक्का करें।
4. नई high-impact calls के लिए incoming owner से नए निर्णय लेने को कहें।

केवल इसलिए broad approval को एक शिफ्ट से दूसरी शिफ्ट में न सौंपें कि engineering task अभी खत्म नहीं हुआ है। Incoming person के पास अलग incident context, maintenance constraints या चल रही vendor problem की जानकारी हो सकती है। उसकी approval उसी का अपना निर्णय होनी चाहिए।

Handoff के समय पहले से चल रही कार्रवाई सबसे असहज स्थिति होती है। अगर वह reversible और observable है, तो उसे recorded authorization के तहत पूरा होने दें और परिणाम नए owner को दिखाएं। अगर वह destructive, externally visible या दूसरी call की प्रतीक्षा में है, तो सीमा पर रोकें और फिर से पूछें। कुछ मिनट की देरी उस जोखिम से कम महंगी है जिसमें किसी अजनबी को बिना review के production change विरासत में मिल जाए।

Incidents में authority कम नहीं, अधिक सीमित होनी चाहिए

Incident के दौरान टीमें स्वाभाविक रूप से speed चाहती हैं। अक्सर वे इसका जवाब agent को «production ठीक करने» के लिए broad, long-lived permission देकर देती हैं। यह permission urgency खत्म होने के बाद भी रहती है और अंततः unexplained hole बन जाती है।

Approval को incident commander या प्रभावित system के लिए उस commander द्वारा औपचारिक रूप से delegated व्यक्ति को दें। Service का normal on-call owner संभव हो तो शामिल रहे, लेकिन जब एक ही dependency पर कई टीमें काम कर रही हों, तो incident में एक decision-maker होना चाहिए।

Approval record में incident reference लिखें। Scope को service और remediation action तक सीमित रखें। काम के अनुरूप short expiration तय करें और incident खत्म होते ही उसे close या revoke कर दें।

मान लीजिए agent को runaway queue को संभालने के लिए कहा गया है। वह metrics देखता है, configuration change सुझाता है और messages purge करने वाली command का अनुरोध करता है। Incident commander rollback देखकर temporary concurrency adjustment मंजूर कर सकता है। उसे केवल इसलिए message deletion मंजूर नहीं करनी चाहिए कि वह तेज है। Request में साफ होना चाहिए कि कौन सी queue, कौन से messages, कौन सा recovery path उपलब्ध है और क्या customers अपना काम खो देंगे।

Speed तैयार authority paths, स्पष्ट owners और पढ़ने योग्य requests से आती है। हर responder को दोपहर भर production administrator बना देने से नहीं।

Approval prompts को उपयोगी निर्णय के लिए मजबूर करना चाहिए

Prompt तब विफल होता है जब competent owner कुछ सेकंड में यह नहीं समझ पाता कि वह किस चीज को मंजूर कर रहा है। वह तब भी विफल होता है जब सामान्य कार्रवाई के लिए नई security analysis की मांग की जाती है। Prompt में वे decision points दिखने चाहिए जिन्हें owner normal operations में पहले से इस्तेमाल करता है।

Requester identity, agent process identity, action channel, credential label, target, operation और scope शामिल करें। Command के लिए exact command और remote host दिखाएं। HTTP call के लिए method, host, path और body का सुरक्षित description दिखाएं। Credential मौजूद है, इसका प्रमाण देने के लिए secret को कभी न दिखाएं।

Useful और बेकार prompt का अंतर देखें:

Request: production configuration change
Process: signed coding-agent process, session 8f3a
Owner: billing-oncall
Credential: billing-admin
Action: PATCH https://api.internal.example/v1/routing/default
Body: {"provider":"secondary"}
Scope: one call
Reason supplied: mitigate provider timeout during INC-482

केवल «Allow tool access?» कहने वाला prompt owner को ritual approval की ओर धकेलता है। उसमें न target पता चलता है, न प्रभाव। अगर आपका tooling निर्णय के लिए पर्याप्त context नहीं दे सकता, तो requester के जानकारी देने तक action deny कर दें।

Safety की जिम्मेदारी free-form «reason» field को न दें। Agent आसानी से convincing prose बना सकते हैं। Reason को human के लिए context मानें और target, credential तथा approval scope को system से enforce कराएं।

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

Unexpected change के बाद लोग पूछते हैं कि इसे किसने मंजूर किया, किस process ने किया, कौन सा credential इस्तेमाल हुआ, कौन से target तक पहुंचा और क्या बाद में किसी ने record बदला। जो audit trail इन सभी सवालों का जवाब नहीं दे सकता, वह केवल debugging aid है।

Session decisions को individual action events से अलग रखें, लेकिन दोनों को आपस में जोड़ें। Session record process और approving owner की पहचान स्थापित करता है। Activity record हर call या command और उसके result को स्थापित करता है। Denials और revocations भी शामिल करें। Failed attempts बाद के workaround को समझा सकती हैं या boundaries जांच रही process का संकेत दे सकती हैं।

Record को tamper-evident बनाएं। Hash-chained log removal और modification को detectable बनाता है, जब कोई chain को independently verify कर सके। इससे खराब approval अच्छी नहीं बनती और access controls की जगह भी नहीं लेता। यह investigators को जांचने का तरीका देता है कि history अभी भी recorded sequence से मेल खाती है या नहीं।

Sallyport session और activity journals को write-blind encrypted, hash-chained log से project करता है, और sp audit verify ciphertext पर offline chain verify कर सकता है। यह design उपयोगी है, क्योंकि reviewer को record की integrity जांचने के लिए operational secrets तक access की जरूरत नहीं होती।

Agent actions को generic application logs में न दबाएं। ऐसे logs अक्सर human decision छोड़ देते हैं, जल्दी rotate होते हैं और event trail में असंबंधित शोर मिला देते हैं। ऐसा record रखें जिसे on-call owner, security reviewer और incident commander छह अलग-अलग systems से कहानी जोड़ने के बजाय सीधे पढ़ सकें।

Ownership failures अक्सर एक सुविधाजनक अपवाद से शुरू होती हैं

खतरनाक pattern एक उचित shortcut से शुरू होता है। Senior developer को migration पूरा करना है। Service owner दूसरे time zone में है। कोई general approval group जोड़ देता है, reusable credential दे देता है या weekend तक session चालू रखता है। अपवाद काम कर जाता है और unofficial process बन जाता है।

फिर agent को बड़ा task मिलता है। वह original request से अधिक targets तक पहुंच सकता है। Original developer सो रहा हो सकता है, owner बदल चुका हो सकता है और broad group मान सकता है कि किसी और ने prompt देख लिया होगा। हर individual decision अपने-आप में बचाव योग्य लगता है। साथ मिलकर वे accountability हटा देते हैं।

इसका समाधान informal exceptions के बजाय structured exceptions हैं। किसी exception में service, approver, reason, end time और review point का नाम होना चाहिए। उसका visible record बनना चाहिए। वह developer की standing permissions को चुपचाप बड़ा न करे।

इसे sprawling rule engine से हल करने की लोकप्रिय सलाह से सावधान रहें। Rules आकर्षक लगते हैं, क्योंकि टीमें सोचती हैं कि हर repository, branch, endpoint, time window और job title को encode किया जा सकता है। व्यवहार में कोई यह नहीं समझा पाता कि कोई खास call match क्यों हुई और stale rules ऐसी permissions बन जाती हैं जिन्हें कोई रखना नहीं चाहता था। छोटे decision model से शुरू करें: vault access, bounded session decision और उन actions के लिए per-call confirmation जिन्हें इसकी जरूरत है।

यह model टीमों को कठिन बात साफ शब्दों में तय करने पर मजबूर करता है: इस समय इस system का मालिक कौन है और वह वास्तव में किस चीज को authorize करने को तैयार है?

Ownership model को वास्तविक शिफ्ट टेस्ट से जांचें

किसी गंभीर incident से पहले एक controlled exercise चलाकर design की अधिकांश कमियां खोजी जा सकती हैं। ऐसी nonproduction system इस्तेमाल करें जो वास्तविक on-call rotation वाली service जैसी हो। Planned shift handoff के पास agent session शुरू करें, routine read का अनुरोध करें और फिर ऐसी change मांगें जिसके लिए individual confirmation चाहिए।

जहां लोग रुकते हैं, उन बिंदुओं पर ध्यान दें। क्या outgoing owner active sessions देख सकता है? क्या incoming owner जानता है कि अब कौन सी service उसके नियंत्रण में है? क्या approval request process और target की पहचान करती है? क्या दोनों में से कोई session revoke कर सकता है? क्या audit record denied, approved और executed actions को सही क्रम में दिखाता है?

«हम chat में इसे सुलझा लेंगे» को उत्तर न मानें। Chat coordination के लिए उपयोगी है, लेकिन यह decision boundary स्थापित नहीं करती और complete action record सुरक्षित नहीं रखती। Memory पर निर्भर handoff सबसे व्यस्त रात में विफल होगा।

पहले उस production service के लिए active owner और backup लिखें जिसे आपके agents छू सकते हैं। फिर किसी agent से उसके विरुद्ध एक bounded action का अनुरोध करवाएं। अगर यह पता लगाने के लिए कि उस call को कौन मंजूर करे, आपको लोगों से पूछताछ करनी पड़े, तो agent आपके ownership model से पहले production तक पहुंच चुका है।