कॉन्ट्रैक्टर द्वारा चलाए जाने वाले AI एजेंट: production access को सही तरीके से खत्म करें

एक कॉन्ट्रैक्टर AI coding agent के साथ शानदार काम कर सकता है और फिर भी आपके production environment को पहले से खराब स्थिति में छोड़ सकता है। समस्या आम तौर पर किसी malicious prompt से शुरू नहीं होती। शुरुआत तब होती है, जब हर कोई मान लेता है कि एजेंट प्रोसेस, अनुमोदन और cleanup की जिम्मेदारी कोई और संभाल रहा है।

कॉन्ट्रैक्टर द्वारा चलाए जाने वाले एजेंट को अस्थायी production operator मानें। उसे जवाबदेह आंतरिक sponsor, पहचान योग्य process identity, सीमित अधिकार वाला रास्ता और ऐसी removal procedure दें जिसका किसी ने अभ्यास किया हो। यदि आप उस कर्मचारी का नाम नहीं बता सकते जो आज इसे रोक सकता है, तो आपने काम delegate नहीं किया है। आपने एक orphan बनाया है।

कॉन्ट्रैक्टर की identity production agent की मालिक नहीं हो सकती

Production system की मालिक कंपनी को एजेंट के अधिकार की मालिक भी होना चाहिए, भले ही process कॉन्ट्रैक्टर शुरू और supervise करे। कॉन्ट्रैक्टर का employment relationship, निजी account, laptop और calendar invitation सभी ऐसी शर्तों पर खत्म होते हैं जिन पर आपका सीधा नियंत्रण नहीं होता। Production access इनमें से किसी पर निर्भर नहीं हो सकती।

टीमें अक्सर दो सवालों को मिला देती हैं:

• इस engagement के दौरान एजेंट कौन चलाएगा?
• एजेंट को मिली हर capability के लिए जवाबदेह कौन रहेगा?

पहले सवाल का उत्तर कॉन्ट्रैक्टर दे सकता है। दूसरे का उत्तर किसी internal employee को देना होगा। उस कर्मचारी के पास इतना अधिकार होना चाहिए कि वह काम रोक सके, scope बदल सके, records देख सके और कॉन्ट्रैक्टर के जवाब का इंतजार किए बिना access खत्म कर सके।

मैंने इसे बहुत सामान्य तरीके से गलत होते देखा है। किसी issue की जांच के लिए कॉन्ट्रैक्टर को source repository का invitation और production API token मिलता है। वह अपनी मशीन से agent चलाकर code देखता है, API query करता है और fix तैयार करता है। Contract खत्म होता है, कॉन्ट्रैक्टर का repository account disable कर दिया जाता है और सबको लगता है कि काम पूरा हो गया। कुछ हफ्तों बाद भी एक automated terminal profile में token मौजूद रहता है। Agent की पुरानी working directory में अब भी ऐसे instructions होते हैं जो उसे token इस्तेमाल करना बताते हैं। कंपनी ने एक system से व्यक्ति को हटाया है, production तक जाने वाला operational path नहीं।

Agent work के लिए कॉन्ट्रैक्टर के user account को स्थायी identity न बनाएं। Company-owned engagement record बनाएं और access को उससे जोड़ें। Record में internal sponsor, technical custodian, operator, approved environments, process identity और end condition दर्ज होनी चाहिए। कोई व्यक्ति नौकरी बदल सकता है या सप्ताहांत में संपर्क से बाहर हो सकता है। Record फिर भी अगले on-call engineer को बता सकता है कि क्या मौजूद है और उसे कैसे बंद करना है।

यह केवल औपचारिकता नहीं है। इससे सबसे महंगी अस्पष्टता रुकती है: ऐसी incident जिसमें टीम यह तय नहीं कर पाती कि request approved agent से आई, पुराने contractor setup से या भूली हुई access दोबारा इस्तेमाल करने वाले attacker से।

Delegation के निर्णय की जिम्मेदारी एक कर्मचारी को दें

हर contractor engagement में ऐसा sponsor होना चाहिए जो agent को काम करने देने के निर्णय का owner हो, केवल कॉन्ट्रैक्टर को hire करने के निर्णय का नहीं। Sponsor आम तौर पर engineering manager, service owner या incident commander होता है, जिसके पास प्रभावित production area का अधिकार हो।

Agent को production authority मिलने से पहले sponsor को चार स्पष्ट सवालों के जवाब देने चाहिए। Agent कौन सा काम करेगा? वह किस environment तक पहुंच सकता है? उसके काम में कौन सी कार्रवाइयां शामिल हैं? Permission कब खत्म होगी?

"service को maintain करने में मदद" या "deployment में सहायता" जैसे अस्पष्ट scope से बचें। जब agent tools के माध्यम से इन शब्दों की व्याख्या कर सकता है, तो वे खतरनाक बन जाते हैं। काम को ऐसे terms में लिखें जिन्हें देखा और जांचा जा सके: इस service के error responses देखें, pull request खोलें, यह approved diagnostic command चलाएं, या नामित endpoint के लिए change request भेजें।

Sponsor को पूरे दिन कॉन्ट्रैक्टर के पास बैठने की जरूरत नहीं है। लेकिन boundaries की जिम्मेदारी उसी की होनी चाहिए। यदि कॉन्ट्रैक्टर कहता है कि काम के लिए अब database write, नई infrastructure role या किसी दूसरी service की access चाहिए, तो यह नया delegation decision है। पुरानी मंजूरी को चुपचाप नई request तक न खींचें।

NIST Special Publication 800-207 की zero trust guidance में एक उपयोगी बात है: किसी actor को केवल इसलिए implicit trust नहीं मिलना चाहिए कि वह किसी खास network पर है या पहले किसी resource तक पहुंच चुका है। यही तर्क agent work पर लागू करें। कॉन्ट्रैक्टर का आपके chat channel में होना, VPN पर होना या पहले read operation के लिए अनुमोदित होना किसी अलग process को production write करने की अनुमति नहीं देता।

यहीं टीमें अक्सर गलत सरल रास्ता चुनती हैं। बार-बार अनुमोदन धीमा लगता है, इसलिए वे कॉन्ट्रैक्टर को broad standing access दे देती हैं। अनुमोदन धीमे लगते हैं क्योंकि काम ठीक से define नहीं किया गया था। पहले work boundary ठीक करें। Broad standing access planning problem को incident response problem में बदल देता है।

Sponsor के लिए स्पष्ट replacement process रखें। यदि वह चला जाता है, तो engagement record नए sponsor को transfer करें और उसके अधिकार को फिर से approve करें। जिस process का कोई वर्तमान sponsor नहीं है, उसकी access अपने-आप खत्म होनी चाहिए या उसे तुरंत manually disable करना चाहिए। Unattended contractor engagement को production authority देते रहने का कोई वैध कारण नहीं है।

हर approval में process provenance शामिल करें

किसी व्यक्ति को approve करना और किसी process को approve करना अलग बातें हैं। यह फर्क अक्सर धुंधला हो जाता है और reviewer के इरादे से अधिक software को approval मिल जाता है।

Human identity बताती है कि किसने authenticate किया। Process identity बताती है कि किस executable ने action मांगा, वह कहां चला और क्या वह वही process है जिसकी अपेक्षा थी। जब AI agent shells, extensions, MCP servers, background helpers और scripts के माध्यम से काम करता है, तो credential path तक वास्तव में process ही पहुंचता है।

नए agent process के approved process होने का evidence मांगें। macOS पर code signing authority उपयोगी starting point है। यह executable द्वारा प्रस्तुत signing authority पहचान सकती है। लेकिन इससे यह साबित नहीं होता कि production request इसी contractor engagement की है, और न ही यह तय होता है कि action उचित है। इसे process evidence मानें, blanket permission नहीं।

Practical approval card में कॉन्ट्रैक्टर का display name ही नहीं होना चाहिए। उसमें process या launcher, उपलब्ध होने पर code signing authority, active engagement, target environment और requested capability भी होनी चाहिए। यदि reviewer known agent process और copied script में फर्क नहीं कर सकता, तो approval बहुत कमजोर है।

इससे एक सामान्य failure पकड़ा जाता है। कॉन्ट्रैक्टर एक terminal में approved coding agent शुरू करता है। बाद में कोई shell script या दूसरा agent process environment variables inherit करता है, local configuration पढ़ता है और उसी credential के माध्यम से वही request करता है। केवल व्यक्ति पर आधारित approval यह नहीं बता सकती कि callers अलग हैं। दूसरा process harmless हो सकता है, लेकिन किसी ने इसे स्थापित नहीं किया है।

सही उपाय reviewers से असंभव certainty मांगना नहीं है। एक approval में शामिल मात्रा घटाएं। Approval को session या process run से जोड़ें, उस run की स्पष्ट पहचान करें और run समाप्त होते ही approval expire कर दें। नए process को फिर से अपना परिचय देना चाहिए।

Process command, working directory, launch time, sponsor और expected exit condition का local record रखें। कॉन्ट्रैक्टर के हर private prompt या पढ़ी गई हर file को जमा करने की जरूरत नहीं है। Incident के एक बुनियादी सवाल का उत्तर देने जितना operational evidence चाहिए: यह action किस approved process ने, किसके अधिकार में किया और क्या वह अभी भी assigned engagement के भीतर था?

Approval ownership का दायरा blast radius के अनुसार रखें

Agent action को approve करने वाले व्यक्ति की भूमिका उस action के परिणाम से मेल खानी चाहिए। कॉन्ट्रैक्टर delegated और सीमित task के भीतर routine actions approve कर सकता है। उसे चुपचाप ऐसे actions का अंतिम authority नहीं बनना चाहिए जो production data, permissions, customer communications या infrastructure बदल सकते हैं।

Approval को दो layers में बांटें। Sponsor काम की category और उसकी अवधि authorize करे। Action approver किसी खास operation को तब approve करे, जब उसके प्रभाव के कारण human decision जरूरी हो। छोटी टीम में एक ही employee दोनों roles निभा सकता है। फिर भी record में जिम्मेदारियां अलग रखें, क्योंकि बाद में दोनों अलग सवालों का जवाब देती हैं।

सरल ownership model अपनाएं:

• Sponsor engagement का purpose, scope और expiration संभालता है।
• Contractor operator task की quality और scope के भीतर actions का अनुरोध संभालता है।
• Action approver sensitive call की अनुमति देने का निर्णय संभालता है।
• Technical custodian credential path और shutdown procedure संभालता है।
• Security या operations यह verify करता है कि revocation पूरी हुई।

हर harmless read के लिए approval ritual न लगाएं, केवल human control दिखाने के लिए। Reviewers उसे बिना पढ़े click करेंगे और फिर उस request को चूक सकते हैं जिस पर ध्यान जरूरी था। Friction वहां रखें जहां action state बदलता है, authority बढ़ाता है, restricted data दिखाता है या नए production target तक पहुंचता है।

Per-call approval उन operations के लिए अच्छा है जिन्हें पहचानना आसान और वापस लेना कठिन हो: customer record में write, production deployment, administrative प्रभाव वाली SSH command या permissions बदलने वाली request। Session approval सीमित investigative work के लिए ठीक है, जहां process को कई संबंधित reads करने हों। काम शुरू होने से पहले record में यह स्पष्ट होना चाहिए कि कौन सा तरीका लागू है।

Approval screen में target भी स्पष्ट होना चाहिए। "Allow agent to use API" reviewer को लगभग कुछ नहीं बताता। "Allow this approved process to send a POST request to the production billing endpoint" ऐसा decision देता है जिसकी जिम्मेदारी reviewer ले सकता है। अच्छा reviewer फिर भी इसे reject कर सकता है, change request मांग सकता है या कॉन्ट्रैक्टर को staging इस्तेमाल करने को कह सकता है।

Approval fatigue design failure है, approval छोड़ने का कारण नहीं। Queue शोर बन जाए तो tools सीमित करें, safe operations को छोटे session में group करें या investigation को nonproduction environment में ले जाएं। Production authority को permanent बनाकर समस्या न सुलझाएं।

Credentials को agent के context से बाहर रखें

Agent को secret रखना नहीं, action का अनुरोध करना चाहिए। यही वह सीमा है जो offboarding को संभव बनाती है।

यदि कॉन्ट्रैक्टर के agent को plaintext API token, SSH private key या configuration file में copied secret मिल जाता है, तो आप पहले ही यह नियंत्रण खो चुके हैं कि credential कहां जा सकता है। Token terminal history, agent memory, logs, temporary files, code patch या किसी दूसरी service को भेजे गए prompt में पहुंच सकता है। Rotation credential को साफ कर सकती है, लेकिन यह पता नहीं लगा सकती कि वह कहां-कहां गया।

ऐसा action gateway इस्तेमाल करें जो credentials को company-controlled side पर रखे और agent की ओर से approved HTTP या SSH actions चलाए। Agent को secret नहीं, result मिले। इससे unsafe action सुरक्षित नहीं बनता। लेकिन टीम को approval लगाने, call record करने और contractor filesystem खंगाले बिना authority revoke करने की जगह मिलती है।

Sallyport HTTP API calls और SSH commands के लिए इसी model का पालन करता है: secrets उसके encrypted vault में रहते हैं और agent credentials पाने के बजाय MCP connection से actions मांगता है। यहां उपयोगी गुण separation है, कोई जादू नहीं। Compromised या careless agent अपने scope के भीतर harmful actions मांग सकता है, इसलिए ownership और approvals अब भी जरूरी हैं।

हर credential path को inventory item मानें। Credential owner, target, permitted action type, engagement reference और shutdown method दर्ज करें। "production token used by contractor" जैसी note पर निर्भर न रहें। इससे incident responder को यह नहीं पता चलता कि token कहां है, उसकी copy बनी है या कौन सा path disable करना है।

SSH पर विशेष ध्यान दें, क्योंकि टीमें अक्सर मान लेती हैं कि contractor temporary है तो host login भी temporary होगा। Authorized keys, certificates, local agent forwarding, jump-host access, shell profiles, scheduled jobs और deployment scripts की remote copies जांचें। एक public key हटाने से वह private key revoke नहीं होती जो किसी दूसरे trusted hop तक अब भी पहुंच सकती है।

यही नियम HTTP credentials पर भी लागू होता है। Action path हटाएं या disable करें, फिर verify करें कि target नई request अस्वीकार कर रहा है। केवल इसलिए काम पूरा न मानें कि access management screen पर user disabled दिख रहा है। Action gateway, service account, API credential और network route के lifecycle अलग हो सकते हैं।

Access देने से पहले revocation design करें

टीम को कॉन्ट्रैक्टर से सहयोग मांगे बिना contractor-run agent revoke करने में सक्षम होना चाहिए। यदि procedure के लिए उसका laptop, password manager या memory जरूरी है, तो वह revocation procedure नहीं है।

पहली production action से पहले shutdown path लिखें। इसमें agent process, approval session, credential route, source और infrastructure access, scheduled work और audit preservation शामिल होने चाहिए। हर item के लिए named operator और completion verify करने का तरीका तय करें।

Disable और revoke का फर्क महत्वपूर्ण है। Disable किसी खास account या credential का भविष्य का उपयोग रोकता है। Revoke सक्रिय authority relationship खत्म करता है और उसे वापस बनाने वाले paths हटाता है। Contractor account disabled हो सकता है, जबकि पहले से चल रहा process live session बनाए रखे। Token revoke हो सकता है, जबकि SSH connection खुला रहे। दोनों स्थितियों को संभालें।

Engagement खत्म होने या तुरंत रोकने पर यह क्रम अपनाएं:

1. Credential gateway या authorization point पर नई agent actions रोकें, फिर engagement से जुड़े active sessions revoke करें।
2. ज्ञात local और remote agent processes रोकें, जिनमें terminal multiplexers, launch agents, CI jobs और scheduled tasks शामिल हैं।
3. Engagement को दिए गए company credentials disable या rotate करें और repository, cloud, VPN, bastion और ticketing access हटाएं।
4. Engagement inventory में copied configuration, generated scripts, deploy keys और temporary service accounts खोजें और हटाएं।
5. Harmless authorized-path check करके rejection verify करें और engagement बंद करने से पहले action records सुरक्षित रखें।

क्रम महत्वपूर्ण है। यदि आप records delete करने या contractor account disable करने से शुरुआत करते हैं, तो active sessions खोजने के लिए जरूरी जानकारी खो सकते हैं। पहले action paths रोकें, evidence सुरक्षित रखें और फिर access साफ करें।

हर checkbox के owner होने से सफलता का दावा न करें। Engagement के दौरान procedure test करें। Custodian से कहें कि contractor के मौजूद रहते nonproduction session revoke करे। पुष्टि करें कि agent दूसरी call नहीं कर सकता, कॉन्ट्रैक्टर समझता है कि क्या रुका और activity record denial दिखाता है। Team को पहली बार missing shutdown path security incident या contract dispute के दौरान नहीं मिलना चाहिए।

छोटा engagement record missing decisions सामने लाता है

एक छोटा, reviewable record उस लंबी access policy से ज्यादा वास्तविक समस्याएं पकड़ता है जिसे कोई पढ़ता नहीं। इसे private chat thread में नहीं, work ticket या controlled operations repository के साथ रखें।

यह उदाहरण जानबूझकर सरल है। Placeholder values को अपने identifiers से बदलें, लेकिन engagement temporary लगे इसलिए fields न हटाएं।

engagement: contractor-search-repair-2025-04
sponsor: employee-ops-owner
technical_custodian: employee-platform-owner
contractor_operator: external-developer
purpose: diagnose production search indexing failures
agent_process:
  approved_launcher: signed-local-agent-process
  allowed_workstation: managed-mac-asset-184
  expires_at: 2025-04-30T17:00:00Z
scope:
  environments: [staging, production-read]
  permitted_actions:
    - GET search-service health endpoint
    - GET indexing queue depth endpoint
  prohibited_actions:
    - production writes
    - credential administration
approval:
  session_owner: employee-ops-owner
  per_call_owner: employee-platform-owner
credential_routes:
  - search-api-read-route
  - bastion-diagnostic-route
revocation_owner: employee-platform-owner
verification_owner: employee-security-owner

यह record उन चीजों को अलग रखता है जिन्हें लोग आम तौर पर एक ही label में मिला देते हैं। contractor_operator, sponsor नहीं है। session_owner, जरूरी नहीं कि per_call_owner भी हो। revocation_owner, उस व्यक्ति से अलग है जिसने तय किया कि काम जरूरी था। यह separation कॉन्ट्रैक्टर को अपना authority scope बढ़ाने का approval खुद देने से रोकता है और absent manager को access रोकने वाला एकमात्र व्यक्ति बनने से भी बचाता है।

permitted_actions field में verbs और targets होने चाहिए। किसी service में export शुरू करने, personal data दिखाने या capacity खर्च करने वाले endpoints हों, तो "Read-only" बहुत ढीला शब्द है। "Production-read" को भी सावधानी से समझें। Read से regulated data या ऐसे operational details उजागर हो सकते हैं जो attack को आसान बनाएं।

Contract की exact end date न हो, तब भी expiration तय करें। काम जारी रहे तो नए decision के माध्यम से इसे extend करें। Explicit renewal sponsor को यह जांचने पर मजबूर करता है कि production access अब भी जरूरी है या नहीं और मूल process ही अभी इस्तेमाल हो रहा है या नहीं।

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

Agent work का audit trail यह बताए कि action किसने authorize किया, किस process ने request की, वह किस target तक पहुंची, सफल हुई या नहीं और authority कब revoke की गई। Chat transcript भरोसे के साथ इन सभी सवालों का उत्तर नहीं दे सकता।

जहां संभव हो, दो views रखें। एक view agent run या session को follow करे, ताकि investigator authorization lifecycle देख सके और live run रोक सके। दूसरा individual actions को follow करे, ताकि operator किसी खास API call या SSH command की जांच कर सके। दोनों views को एक ही underlying event record से जोड़ें, हाथ से अलग-अलग stories न बनाएं।

Audit log को उसी process से सुरक्षित रखें जिसे वह record करता है। जो process अपनी history बदल सकता है, वह सबसे महत्वपूर्ण evidence छिपा सकता है। Append-only storage, restricted write access और cryptographic chaining सभी मदद करते हैं, लेकिन हर mechanism का काम अलग है। Chain यह दिखा सकती है कि records बदले या हटाए गए हैं। यह नहीं बता सकती कि मूल request अच्छा विचार था या नहीं।

Sallyport encrypted, hash-chained audit log से projected session और activity journals रखता है। उसका sp audit verify command ciphertext पर offline chain verify कर सकता है। यह तब उपयोगी है जब vault रखने वाली machine locked हो या investigator को secrets खुद नहीं पढ़ने चाहिए।

हर engagement के लिए तय करें कि records की समीक्षा कौन और कब करेगा। Sensitive production write के लिए कॉन्ट्रैक्टर के आगे काम जारी रखने से पहले review जरूरी हो सकता है। छोटा diagnostic task closure पर review से चल सकता है। फिर भी incident के दौरान events खोजने का तरीका टीम को पता होना चाहिए।

Denials भी सुरक्षित रखें। Denied action यह दिखा सकती है कि agent ने scope से बाहर जाने की कोशिश की, कॉन्ट्रैक्टर ने task गलत समझा या offboarding के बाद भी कोई stale process जीवित है। केवल सफल calls रखने पर आप वह evidence फेंक देते हैं जो अक्सर अगली incident को समझाता है।

Contract की भाषा access design से मेल खानी चाहिए

Contract API token revoke नहीं कर सकता, लेकिन वह उस अस्पष्टता को दूर कर सकता है जिसके कारण टीमें access छोड़ देती हैं। Operational obligations को उन वास्तविक controls के अनुरूप लिखें जिन्हें आपकी टीम इस्तेमाल करती है।

स्पष्ट लिखें कि company credentials, process registrations, audit records और engagement के लिए बनाई गई access configuration की मालिक है। यह भी लिखें कि contractor production actions के लिए approved company-controlled paths इस्तेमाल करेगा और credentials को local files, prompts, repositories या third-party services में copy नहीं करेगा। Exception जरूरी हो तो उसके होने से पहले sponsor की written approval अनिवार्य करें।

Work materials वापस करने और हटाने की obligation शामिल करें, लेकिन attestation को अपना एकमात्र control न बनाएं। Contractor अच्छे इरादे से काम करते हुए भी shell history file, cached environment variable या backup भूल सकता है। Technical revocation उन चीजों को संभालती है जिन्हें आप control कर सकते हैं। Contract terms आपके systems के बाहर बची obligations को cover करती हैं।

Engagement का अंत operational terms में define करें: sponsor work बंद करे, custodian action paths disable करे, verification owner denial test की पुष्टि करे और team सामान्य retention rules के तहत audit record रखे। बाद में support access चाहिए तो पुराने engagement को फिर से चालू करने के बजाय नया engagement खोलें।

ऐसी clause से बचें जिसमें लिखा हो कि contractor "security के लिए responsible" है, लेकिन decisions और controls का नाम न हो। यह wording मजबूत लगती है, पर शाम 6 बजे production change मांगने पर कठिन सवाल अनुत्तरित छोड़ देती है। लिखें कि change approve कौन कर सकता है, उसे करेगा कौन और रोक सकता कौन है।

पहला document कोई broad AI policy नहीं होना चाहिए। यह उस अगले contractor का engagement record होना चाहिए जिसे production के पास agent की जरूरत है। Sponsor और custodian के साथ एक ही कमरे में इसे भरें। कोई भी blank field उस काम की ओर सीधे इशारा करता है जिसे access देने से पहले आपकी टीम को अभी करना है।