Coding agents के लिए staging और production access अलग रखें

Coding agents को एक variable, URL या अस्पष्ट instruction बदलकर staging और production के बीच कभी नहीं जाना चाहिए। अलग credentials और अलग destinations accidental cross-environment call की संभावना घटाते हैं। Production boundary पर human decision intentional action को जवाबदेह बनाता है।

मैंने teams को अपने setup को «separate environments» कहते देखा है, क्योंकि repository में दो hostnames थे। फिर deploy script ने production token अपना लिया, test fixture live project की ओर इशारा करने लगा या agent को shell session में credential मिल गया और उसने वही रास्ता इस्तेमाल किया जो चल रहा था। Hostname staging था, authority production की। यह separation नहीं है।

सीधा नियम यह है: staging access agent को बदलाव के सही होने का प्रमाण देने दे, लेकिन उसके पास production को प्रभावित करने वाली कोई authority न हो। Production access अलग और सीमित capability होनी चाहिए, जिसे कोई व्यक्ति खास run के लिए दे और run के दौरान वापस ले सके।

Environment names security boundary नहीं बनाते

Staging label अपने आप किसी चीज की रक्षा नहीं करता। Security boundary तब बनती है जब staging के लिए किया गया call production में authenticate न कर सके और production तक पहुंचने वाला call अलग से दी गई production identity के बिना meaningful काम न कर सके।

Teams अक्सर तीन अलग चीजों को मिला देते हैं:

• Routing तय करता है कि request कहां जाएगी, जैसे https://api.staging.example।
• Authentication तय करता है कि service किस principal को देखेगी, जैसे service account या SSH key।
• Authorization तय करता है कि authentication सफल होने के बाद वह principal क्या कर सकता है।

केवल routing बदलने से बाकी दोनों वैसे ही रहते हैं। केवल credential बदलना भी पर्याप्त नहीं है, क्योंकि staging credential production में authenticate कर सकता है, अगर administrator ने दोनों जगह client, role या key दोबारा इस्तेमाल किया हो। साफ environment boundary तीनों को बदलती है।

जहां underlying service अनुमति दे, अलग provider accounts, projects, tenants, namespaces या subscriptions से शुरुआत करें। इससे जांचने के लिए मजबूत identifier मिलता है। अलग databases, object stores, queues और deployment targets स्वाभाविक अगला कदम हैं। अगर provider staging और production को एक account में रखने पर मजबूर करता है, तो अलग principals और resource scopes बनाएं और shared account को स्वीकार की गई कमजोरी मानकर अतिरिक्त review करें।

Staging को realistic बनाने के लिए production customer data इस्तेमाल न करें। बिना deliberate sanitization के उसकी copy बनाना access control की समस्या को privacy exposure में बदल देता है। सामान्य development के लिए synthetic data लें। अगर test को production-जैसे records चाहिए, तो छोटा, साफ किया हुआ dataset बनाएं और उसके उपयोग की approval दर्ज करें।

एक व्यावहारिक boundary में reviewer के लिए जांच योग्य evidence होना चाहिए:

Environment और authorization domain का फर्क महत्वपूर्ण है। एक authorization domain में कई environments चल सकते हैं, लेकिन broad shared credential वाला agent उनके बीच जा सकता है। यह operations में मदद करता है, containment में नहीं।

Production credential एक अलग identity होना चाहिए

Production access के लिए अलग principal चाहिए, staging credential पर लगा दूसरा label नहीं। अगर एक ही API token, cloud role, database user या SSH key दोनों जगह काम कर सकता है, तो routing की गलती incident बन सकती है।

Identities को उस action के आसपास बनाएं जो agent को करना है। Deployment देखने वाले coding agent को identity settings बदलने, storage हटाने, हर database table पढ़ने या हर host पर interactive shell खोलने की अनुमति नहीं मिलनी चाहिए। «Agent को जरूरत पड़ सकती है, इसलिए Administrator» अनजाने code paths को production authority देने का आसान रास्ता है।

Access को job title के बजाय consequence के आधार पर बांटें। सामान्य विभाजन इस तरह हो सकता है:

• Staging deploy identity, जो केवल staging resources में लिख सके।
• Production observation identity, जो छोटी health या release surface पढ़ सके।
• Production deploy identity, जो एक service या release channel update कर सके।
• Humans के लिए अलग break-glass identity, routine agent workflows से बाहर।

Agent को human developer का personal token न दें। Personal tokens समय के साथ permissions जमा करते हैं, role बदलने के बाद भी चलते रहते हैं और अक्सर owner की याद से अधिक systems में काम करते हैं। Audit trail भी अस्पष्ट हो जाता है: log में व्यक्ति दिखता है, जबकि request autonomous process ने की होती है।

Provider workload identity, short-lived credentials या scoped service accounts देता हो तो उनका उपयोग करें। कम duration मदद करती है, लेकिन broad scope की भरपाई नहीं करती। दस मिनट का administrator credential भी पहले minute में production database हटा सकता है।

NIST Special Publication 800-53 के control AC-6 में least privilege बताया गया है: organizations को assigned tasks के लिए जरूरी access ही देना चाहिए। यह बात obvious लगती है, जब तक agent को quick fix की जरूरत न पड़े और कोई owner role न चुन ले। Standard आपके लिए exact permission तय नहीं करता, लेकिन सही review question सामने रखता है: यह permission हटाने पर कौन-सा एक action असफल होगा?

SSH के लिए अलग keys जरूरी हैं, पर पर्याप्त नहीं। Production key को named hosts या restricted account तक सीमित करें, जहां संभव हो broad forwarding paths बंद करें और एक deployment command के लिए बने credential के पीछे general shell न रखें। Unrestricted production shell खोलने वाली key agent को बड़ा और कठिन-to-review action surface देती है।

Endpoint separation की executable जांच जरूरी है

Configuration ऐसी होनी चाहिए कि API request machine से निकलने से पहले cross-environment mixup असफल हो जाए। Agent से यह याद रखने को न कहें कि वह किस environment में है। Selected profile में destination और identity name दोनों रखें और अनचाहे combinations अस्वीकार करें।

यह shell pattern secrets store नहीं करता। Wrapper या credential broker request करने से पहले secret और endpoint चुनने वाले values को validate करता है:

#!/usr/bin/env sh
set -eu

case "${AGENT_ENV:?set AGENT_ENV}" in
  staging)
    API_BASE="https://api.staging.example.internal"
    CREDENTIAL_REF="agent-staging-deploy"
    ;;
  production)
    API_BASE="https://api.example.com"
    CREDENTIAL_REF="agent-production-deploy"
    ;;
  *)
    printf '%s\n' "AGENT_ENV must be staging or production" \u003e\u00262
    exit 64
    ;;
esac

printf 'environment=%s\nendpoint=%s\ncredential_ref=%s\n' \
  "$AGENT_ENV" "$API_BASE" "$CREDENTIAL_REF"

Staging invocation का output कुछ ऐसा होगा:

environment=staging
endpoint=https://api.staging.example.internal
credential_ref=agent-staging-deploy

इस output को preflight record मानें, authorization का प्रमाण नहीं। Script केवल गलत local pairing रोकती है। Credential store या action gateway को तब भी agent-production-deploy resolve करने से मना करना चाहिए, जब तक human ने production access न दिया हो।

Agent से arbitrary URLs स्वीकार करने वाली configuration से बचें। curl "$TARGET" जैसा request interface, bearer token के साथ, हर generated string को संभावित destination बना देता है। सावधान agents भी गलती करते हैं और repository का untrusted text उनके tool calls को प्रभावित कर सकता है। इसके बजाय named actions या fixed endpoint profiles दें।

यही सिद्धांत SSH पर भी लागू होता है। Production key के साथ generic host argument उपलब्ध न कराएं। Production deployment action को expected host group और remote command से बांधें या approval के समय human से target चुनवाएं।

केवल production जैसे string की तुलना करने में एक कमजोरी है: names झूठ बोल सकते हैं। Provider identifiers भी जांचें। Cloud account number, project ID, subscription ID, repository owner या database cluster ID configuration copy होने पर कम drift करते हैं।

Prompts live change को authorize नहीं कर सकते

«Never touch production» जैसी instruction उपयोगी context है, access control नहीं। Agents tool output, repository files, task descriptions और अपने intermediate plans का पालन करते हैं। इनमें से कोई भी conflict या confusion पैदा कर सकता है। Prompt network request के सामने बैठकर उसे deny नहीं करता।

Production decision के लिए agent process के बाहर enforcement point चाहिए। उसे पता होना चाहिए कि action किस process ने मांगा, कौन-सी production identity चाहिए, call कहां जाएगी और action क्या है। फिर उसे explicit human choice मांगनी चाहिए या call reject करनी चाहिए।

Per-session approval और per-call approval अलग समस्याएं हल करते हैं।

Per-session approval तब उपयोगी है जब human ने bounded run की समीक्षा की हो, जैसे reviewed deployment plan को एक service पर लागू करना। इससे repeated interruptions घटती हैं और authority खास process से जुड़ी रहती है। Process exit होते ही approval समाप्त होनी चाहिए, terminal खुला रहने के कारण पूरे दिन नहीं।

Per-call approval irreversible या high-impact actions के लिए उपयुक्त है: data हटाना, credentials rotate करना, network exposure बदलना, release publish करना या production database में लिखना। हर उपयोग पर click या local authentication मांगना जानबूझकर धीमा है। यह friction बताती है कि action पर ध्यान चाहिए।

लोगों को opaque cards approve करने की आदत न डालें। Approval screen में process identity, destination, credential identity, method और request summary साफ दिखनी चाहिए। «Agent requests access» reviewer को कुछ नहीं बताता। «Signed coding process requests POST to production deploy endpoint using production deploy identity» mismatch पकड़ने के लिए पर्याप्त है।

Sallyport इसी विभाजन का उपयोग करता है: local authentication से vault खुलने तक वह locked रहता है, फिर नया agent process default रूप से session authorization मांगता है, जबकि individual credentials पर हर उपयोग के लिए approval लगाया जा सकता है। Agent को API या SSH secret कभी नहीं मिलता।

यह design एक लोकप्रिय recommendation को खारिज करता है: production token को tightly controlled environment variable में रखें और careful prompt पर भरोसा करें। यह तरीका लोकप्रिय है क्योंकि existing scripts में जोड़ना आसान है। यह विफल होता है क्योंकि authority agent process के पास रहती है और environment पढ़ सकने या process reuse कर सकने वाला कोई भी tool call उसे खर्च कर सकता है।

Failure अक्सर harmless convenience से शुरू होती है

Cross-environment incidents आम तौर पर production पर हमला करने के निर्णय से शुरू नहीं होते। वे छोटी convenience से शुरू होते हैं, जो एक check हटा देती है।

मान लें release repository में दो profiles हैं। Team test runs के लिए DEPLOY_ENV=staging और live runs के लिए DEPLOY_ENV=production इस्तेमाल करती है। दोनों profiles उसी developer shell से DEPLOY_TOKEN लेते हैं, क्योंकि शुरुआती testing आसान थी। Token को दोनों deployment projects का access मिला हुआ है।

Agent को staging rollout validate करने का task मिलता है। वह endpoint बनाने वाली script पढ़ता है। उसी terminal में पिछली command ने DEPLOY_ENV=production छोड़ा था, जबकि बाद का helper अलग configuration file से staging label दिखाता है। Agent label देखकर helper चलाता है और request production endpoint पर ऐसे token के साथ जाती है जो वहां स्वीकार होता है।

इस chain में न malice चाहिए, न कोई exotic exploit। Team के पास दो labels, एक shared credential, truth के दो sources और कोई approval point नहीं था। Logs में normal developer account भी दिख सकता है, क्योंकि shared token उसी developer का था।

केवल DEPLOY_ENV=staging को अधिक सावधानी से set करना design ठीक नहीं करता। Structural repair यह है:

1. Shared token को environment-specific identities से बदलें।
2. हर identity को उसके allowed account, project या resource set से बांधें।
3. Identity को agent के shell environment के बजाय broker या vault से resolve करें।
4. Production identity के call से पहले human authorization जरूरी करें।
5. Process, target, identity reference, action, result और approval decision log करें।

जहां संभव हो production और staging settings को एक reviewed source of truth में रखें, लेकिन उन्हें interchangeable न बनाएं। बदले हुए hostname वाला copied block quiet drift की शुरुआत होता है। हर profile में account ID, credential reference और allowed operations इतने स्पष्ट रखें कि reviewer उन्हें side by side compare कर सके।

Production approval एक bounded run का वर्णन करे

Human approval तभी उपयोगी है जब human उसे intended work से जोड़ सके। «इस agent के लिए production allow करें» बहुत व्यापक है। इससे ऐसी capability मिलती है जिसका कोई पहचानने योग्य endpoint नहीं है।

Production run की concrete सीमाएं तय करें: agent process, repository या task, intended service, permitted action class और expiration condition। Tools के अनुसार mechanics बदल सकती है, लेकिन पहली call से पहले decision को इन सवालों का जवाब देना चाहिए:

• कौन-सा local process मांग कर रहा है, और क्या उसकी code-signing authority या executable पहचाना जा सकता है?
• कौन-सा production account या endpoint request प्राप्त करेगा?
• Action किस credential identity से होगा?
• इस run के दौरान agent कौन-सा action कर सकता है?
• Authorization कब खत्म होगी और इसे अभी कौन revoke कर सकता है?

Process identity पर अधिक ध्यान चाहिए। Terminal label या agent name की claim आसानी से copy की जा सकती है। Managed developer machine पर code-signing authority यह समझने में मदद करती है कि कौन-सा program request खोल रहा है। इससे task sensible साबित नहीं होता, लेकिन अलग local process को परिचित नाम का लाभ लेने से रोकने में मदद मिलती है।

Approval fatigue design failure है। अगर हर harmless staging request click मांगेगी, तो लोग पढ़े बिना approve करेंगे। सामान्य staging work को अपने narrow credentials से उपलब्ध रखें। Production prompts केवल उन calls के लिए रखें जिनका destination और consequence interruption को उचित बनाता है।

उलटी गलती और खराब है: एक approval चुपचाप हर future agent process पर लागू हो। कुछ दिनों बाद यह permanent production access से अलग नहीं रहेगा। Approval को run से बांधें, run समाप्त होते ही expire करें और revocation को तत्काल बनाएं, किसी बाद के ticket पर निर्भर नहीं।

कई production resources बदलने वाले deploy के लिए पांच independent approvals को बेहतर review न मानें। Plan bounded और visible हो तो एक session authorization मांगें। हर call अलग irreversible effect पैदा कर सकती हो तो per-call approval रखें। Control action के अनुरूप होना चाहिए, केवल ritual पूरा करने के लिए नहीं।

Audit records को बताना चाहिए कि authority किसने इस्तेमाल की

Production audit log से action को agent के अपने account पर भरोसा किए बिना reconstruct किया जा सके। Chat transcript या terminal history investigation में मदद कर सकते हैं, लेकिन वे अधूरे या edited हो सकते हैं और वास्तविक call करने वाले credential से जुड़े न हों।

Enforcement point पर request path capture करें, जहां credential इस्तेमाल होता है। Agent process identity, session identifier, requested credential reference, resolved destination, method या SSH command class, timestamp, approval result, response status और revocation event दर्ज करें। Secrets और sensitive request bodies redact करें। उपयोगी audit record customer data leak का नया source नहीं बनना चाहिए।

NIST SP 800-53 control AU-2 में log किए जाने वाले events को define करने की बात है। «हम agent activity log करते हैं» definition नहीं है। तय करें कि denied request, approval, credential use, destination mismatch और session revoke events माने जाएंगे या नहीं। Denial दिखे बिना आप नहीं जान सकते कि boundary ने गलती रोकी या request कभी पहुंची ही नहीं।

Incident के बाद tamper evidence महत्वपूर्ण है, क्योंकि ordinary application logs ऐसी जगह हो सकते हैं जहां administrator या compromised process उन्हें बदल सके। Hash-chained journal stored records के विरुद्ध chain verify करने पर बदलाव पकड़ने देता है। यह खराब decisions को अच्छा नहीं बनाता और backups, access review या external retention की जगह नहीं लेता। यह investigators को alteration पहचानने का तरीका देता है।

Sallyport अपने encrypted, hash-chained audit log से Sessions और Activity views लिखता है। sp audit verify vault key के बिना offline chain जांच सकता है। जब सवाल यह हो कि record बदला है या नहीं, तो यह agent के दावे पर निर्भर रहने से बेहतर है।

Risk के अनुसार review habit बनाएं। Meaningful agent runs के बाद production authorizations और denied attempts देखें। समय-समय पर इस्तेमाल हो रही production identities की तुलना उनके वास्तविक actions से करें। Log में कभी न दिखने वाली permissions हटाने की उम्मीदवार हैं। जिन permissions को समझाया नहीं जा सकता, वे पहले ही बहुत broad हैं।

Rotation और revocation incident के दौरान काम करने चाहिए

अलग credentials तभी नुकसान सीमित करते हैं जब production credential का उपयोग जल्दी रोक सकें। ऐसा rotation plan जिसमें हर script और workstation ढूंढना, उन्हें edit करना और weekly deployment window का इंतजार करना पड़े, incident control नहीं है।

हर production agent identity के लिए owner, issue होने की जगह, allowed targets और documented revocation path रखें। यह जानकारी secret value से अलग रखें। Incident में responders को credentials वाली files खोले बिना पता होना चाहिए कि क्या disable करना है।

जरूरत से पहले यह sequence test करें:

1. Harmless, reversible operation कर सकने वाला approved production agent run शुरू करें।
2. Session revoke करें या उसका production credential disable करें।
3. Agent से वही operation फिर कराएं।
4. Confirm करें कि enforcement point उसे deny करता है और denial audit record में दिखती है।
5. Replacement credential जारी करें और confirm करें कि staging access स्वतंत्र रूप से काम करता है।

यह test एक आम operational flaw पकड़ता है: UI «revoked» दिखाती है, लेकिन cached token, persistent SSH connection या long-lived process काम करता रहता है। APIs के लिए token lifetime और refresh behavior जांचें। SSH के लिए existing connections और multiplexing जांचें। Revoke button तभी credible है जब अगला action fail हो।

Staging और production identities को अलग-अलग rotate करें। Staging secret leak होने पर production रोकनी न पड़े। Production authority संदिग्ध हो तो exposure छोटा लगने पर भी उसे revoke और replace करें। लोग अक्सर कम आंकते हैं कि token shell history, debug output, copied logs या agent tool context में कितनी दूर जा चुका है।

Live access देने से पहले boundary बनाएं

Teams को production access prompt या agent model पर confidence के बजाय evidence से अर्जित करना चाहिए। Coding task में अक्सर staging route, dry run, read-only query या human-operated release path होता है, जिससे अधिकांश काम पहले साबित किया जा सकता है।

नया production action देने से पहले यह readiness test चलाएं:

• Staging और production में अलग credentials हों, जो एक-दूसरे के environment में authenticate न कर सकें।
• Agent files, environment variables, prompts या tool output से plaintext secrets न पढ़ सके।
• Request path fixed destination और provider account या project identifier जांचे।
• Human production action देखे और agent process के बाहर authority दे।
• Revocation, denial logging और audit verification को assumption के बजाय वास्तव में test किया गया हो।

एक भी item fail हो तो action staging में रखें या production work human से सीधे कराएं। यह agent automation की हार नहीं है। यह सही निष्कर्ष है कि control path अभी अधूरा है।

शुरुआती production permission अक्सर non-sensitive status endpoint पर narrow observation action होनी चाहिए। इससे agent को customer-facing state बदलने दिए बिना destination selection, identity separation, approval, logging और revocation test हो जाते हैं। यह path वास्तविक उपयोग में सफल हो जाए तो एक-एक write action जोड़ें और agent को कभी जरूरत न पड़ने वाली permissions हटाएं।

Approvals असुविधाजनक लगने पर staging और production access बाद में merge न करें। Production boundary का friction यह जानने की कीमत है कि live action को किसने authorize किया, किस process ने किया और उसे कैसे रोका जा सकता है। इस boundary को जानबूझकर बनाए रखें।