सुरक्षित production changes के लिए planning और execution agents

Planning agent को अपनी recommendation को production change में बदलने की क्षमता नहीं होनी चाहिए। उसे inspect करने, तुलना करने और अपने तर्क रखने की पर्याप्त गुंजाइश दें। अलग execution agent को actions के छोटे सेट के अधिकार दें, फिर उससे यह साबित करवाएं कि मांगा गया action approved change से मेल खाता है।

यह अलगाव तब तक bureaucratic लगता है, जब तक आप किसी agent को API boundary के पार एक plausible लेकिन गलत assumption ले जाते हुए नहीं देख लेते। ज्यादातर failures किसी cartoon attack जैसे नहीं होते। Agent outdated runbook पढ़ता है, staging hostname को production समझ लेता है या issue में मौजूद untrusted text का पालन करता है। अगर उसी process के पास credential और action लेने का अधिकार दोनों हों, तो गलती किसी के notice करने से पहले ही change बन जाती है।

Plan evidence है, authorization नहीं

Planning और execution agents को अलग authority चाहिए, क्योंकि planning दुनिया के बारे में एक claim तैयार करती है, जबकि execution दुनिया को बदलता है। अच्छा plan भी stale data, अधूरे repository context या untrusted source से copy की गई instructions पर आधारित हो सकता है। Plan को permission मानने से दो ऐसे decisions एक हो जाते हैं जिनकी अलग-अलग जांच होनी चाहिए।

Planner को facts जुटाने, uncertainty समझाने, alternatives सुझाने और bounded request तैयार करने का काम दें। उसे केवल इसलिए production token न दें कि report में किसी endpoint का उल्लेख करना है। अगर उसे protected system से facts चाहिए, तो ऐसा purpose-built read operation दें जो केवल जरूरी facts लौटाए, या human से relevant output उपलब्ध कराएं।

Executor का काम अलग है। उसे specific request मिलती है और वह तय करता है कि request उसकी सीमित authority के भीतर है या नहीं। वह design discussion फिर से शुरू नहीं करता, arbitrary tickets browse नहीं करता और «deployment ठीक करो» जैसी sentence स्वीकार नहीं करता। बातचीत के लिए यह sentence पर्याप्त हो सकती है। Credential वाले process के contract के रूप में यह बेकार है।

यह फर्क उस आदत को भी ठीक करता है जिसे teams «human in the loop» कहते हैं, जबकि उनका मतलब होता है «किसी व्यक्ति ने लंबे chat transcript पर एक नजर डाल ली»। Reviewer prose से भरोसे के साथ यह reconstruct नहीं कर सकता कि agent कौन-कौन से tool calls कर सकता है। वह एक short, structured request की review कर सकता है, जिसमें target, operation, inputs, expected effect और reversal path साफ लिखे हों।

NIST SP 800-53 का control AC-5 duties को अलग रखने की बात करता है, ताकि कोई एक व्यक्ति बिना detection के system का दुरुपयोग न कर सके। Wording लोगों को संबोधित करती है, लेकिन यही reasoning agents पर भी लागू होती है। पुराने approval hierarchy को prompt में copy न करें। Actual credentials और tool interfaces में capabilities को अलग रखें।

Executor का दायरा plan से छोटा होना चाहिए

Executor को planner से कम freedom मिलनी चाहिए, केवल अलग prompt नहीं। अगर अलग agent arbitrary shell commands चला सकता है और उसके पास broad cloud credential है, तो risk वास्तव में कम नहीं हुआ। वह अब भी vague request की अपनी व्याख्या कर सकता है, दूसरे resources खोज सकता है और असंबंधित changes कर सकता है।

Action catalog से शुरुआत करें। हर action में एक operation और parameters का छोटा set होना चाहिए। उदाहरण के लिए, deploy_service_revision service name, immutable revision identifier और target environment स्वीकार कर सकता है। उसे shell fragment या arbitrary URL स्वीकार नहीं करना चाहिए।

सबसे उपयोगी restriction अक्सर technical के बजाय semantic होती है। Credential deployment की अनुमति दे सकता है, लेकिन executor wrapper फिर भी latest जैसे mutable tag को reject कर सकता है, change ID के बिना production को reject कर सकता है और allowlist से बाहर के service को भी रोक सकता है। इन checks से runbook में रहने वाली assumptions ऐसे code में बदल जाती हैं जो unsafe request को refuse कर सकता है।

Restricted tool को restricted outcome न समझें। billing-api को update करने वाला API token traffic allocation, environment variables और autoscaling settings भी बदल सकता है। अगर API अनुमति दे, तो इन operations को अलग करें। अगर API ऐसा नहीं करता, तो उसके सामने एक छोटा gateway रखें जो केवल वही operation स्वीकार करे जिसे आप automate करने के लिए तैयार हैं।

एक credible executor की सामान्य सीमाएं ये होती हैं:

• हर environment के लिए अलग identity इस्तेमाल करता है।
• General shell के बजाय केवल named actions प्राप्त करता है।
• Provider को call करने से पहले target names और immutable inputs validate करता है।
• इसकी lifetime छोटी होती है और broader credentials mint करने का कोई रास्ता नहीं होता।
• Request और result का durable record बनाता है।

Teams अक्सर generic tools को जल्दी wire up करने के कारण इन सीमाओं का विरोध करती हैं। पहले demo के लिए वे सचमुच तेज होते हैं। लेकिन किसी ticket में copy किए गए command को पढ़ने के बाद agent ने गलत resource delete क्यों किया, यह समझाना पड़े, तो broad run_command tool महंगा साबित होता है।

Handoff के लिए machine-checkable change request चाहिए

Planner को ऐसा structured artifact hand off करना चाहिए जिसे executor intent की व्याख्या किए बिना validate कर सके। Free-form plans executor को gaps अपनी reasoning से भरने के लिए प्रेरित करते हैं। इससे planning authority फिर action path में लौट आती है।

एक practical request इस तरह दिख सकती है:

{
  "request_id": "chg-2025-0417-redis-timeout",
  "environment": "production",
  "action": "deploy_service_revision",
  "target": {
    "service": "checkout-api",
    "revision": "sha256:8f31c2..."
  },
  "expected_effect": "Run the approved checkout-api revision",
  "rollback": {
    "action": "deploy_service_revision",
    "revision": "sha256:31aa09..."
  },
  "approval": {
    "approved_by": "release-manager",
    "approved_request_hash": "b2c4..."
  }
}

Hash महत्वपूर्ण है। इसके बिना reviewer उस request को approve कर सकता है जो उसने देखी थी, जबकि executor को बदला हुआ version मिले। Approval record को exact fields के canonical representation से bind होना चाहिए, जिनका इस्तेमाल executor करेगा। अगर आपका system अलग-अलग जगह JSON को अलग तरह से serialize करता है, तो पहले canonicalization तय करें। Field ordering या omitted defaults payload बदल सकते हों, तो casual string hash एक trap है।

Executor को स्पष्ट कारणों के साथ request reject करनी चाहिए। एक उपयोगी response shape secret दिखाए बिना failed check बता सकती है:

{
  "status": "denied",
  "request_id": "chg-2025-0417-redis-timeout",
  "reason": "revision must be an immutable digest",
  "executed": false
}

यह refusal design का हिस्सा है, कोई शर्मनाक edge case नहीं। Teams test करती हैं कि agents actions कर सकते हैं या नहीं, लेकिन यह साबित करने वाले tests छोड़ देती हैं कि वे अपनी सीमा से आगे नहीं जा सकते। दोनों paths test करें।

Planner को executor की action definition चुनने न दें। Platform owner को catalog, validation rules और credential mapping तय करनी चाहिए। Planner supported actions में से चुन सकता है। किसी task के urgent लगने पर वह deploy_anything नहीं बना सकता।

अलग processes accidental authority sharing रोकते हैं

एक ही process के भीतर दो agent roles को अलग रखना भी आसान नहीं होता। Shared environment variables, token caches, working directories और tool registrations आपकी intended boundary के आसपास accidental paths बना देते हैं। Planner और executor को अलग launch configurations वाले distinct processes के रूप में चलाएं।

Planner के process को research tools और संभव हो तो narrowly filtered read interfaces मिलनी चाहिए। उसे अपने environment, configuration files या tool descriptions में executor credentials दिखाई नहीं देने चाहिए। किसी model को token का plaintext दिखना जरूरी नहीं कि वह उसका दुरुपयोग कर सके। अगर process उस tool को invoke कर सकता है जिसके पास token है, तो वही tool boundary वास्तविक capability boundary है।

Executor को approved structured request और सबसे छोटी संभव tool inventory मिलनी चाहिए। उसे original ticket body, arbitrary web content, repository-wide search tool या planner का conversation transcript न दें। इन materials में prompt injection, खराब commands या casual instructions हो सकती हैं जिन्हें executor को मानने की कोई वजह नहीं है।

इससे debugging के लिए एक सरल rule मिलता है: अगर executor को तय करने के लिए ज्यादा context चाहिए कि कौन-सा operation चलाना है, तो handoff artifact अधूरा है। Broad discovery access देकर इसे हल न करें। Request में missing field, validation rule या human decision जोड़ें।

Process separation incident response में भी मदद करता है। Planner का research record खोए बिना executor session revoke किया जा सकता है। आप देख सकते हैं कि planner ने approved target से अलग target प्रस्तावित किया था या नहीं। अगर दोनों roles एक ही session और identity share करते हैं, तो यह reconstruction अनुमान पर निर्भर हो जाती है।

जब MCP-capable agent को underlying API या SSH credentials दिए बिना HTTP या SSH actions की जरूरत हो, तब Sallyport इस boundary में फिट बैठता है। App इन secrets को अपने encrypted vault में रखता है और call खुद execute करता है। इसलिए instructions गलत हो जाने पर भी planner credential extract नहीं कर पाता।

Approval वहीं होना चाहिए जहां consequences बदलते हैं

Human approval को किसी specific decision को cover करना चाहिए, agent आगे जो भी करे उसके लिए vague blessing नहीं देनी चाहिए। Session approval यह स्थापित करने के लिए उपयोगी है कि कोई known agent process एक run के दौरान bounded low-risk actions का set इस्तेमाल कर सकता है। जब action production data, identity, network exposure या money बदल सकता हो, तब यह review का कमजोर विकल्प है।

Per-call approval उन credentials पर होना चाहिए जिनके इस्तेमाल के महत्वपूर्ण consequences हों। Call irreversible, unusual या undo करने में महंगी हो, तो extra click उचित है। इसे production deletion key, access control बदलने वाले credential या payment operation पर लगाएं। हर harmless status request पर न लगाएं। लगातार दिखने वाला prompt background noise बन जाता है और लोग उसे पढ़े बिना approve करने लगते हैं।

ऐसे approvals इस्तेमाल करें जिनमें reviewer के लिए वास्तविक judgment की जानकारी दिखाई दे: action name, target environment, target resource, immutable input और planned rollback। «Agent requests access» कहने वाला dialog दिखावा है। वह reviewer को consequence के बारे में कुछ नहीं बताता।

Approval scope की समय-सीमा होनी चाहिए। Process run से जुड़ा approval process exit होने पर खत्म हो जाना चाहिए। Change request से जुड़ा approval उसके content से bind होना चाहिए और बाद के revision को चुपचाप authorize नहीं करना चाहिए। Long-lived approval grants आकर्षक होते हैं क्योंकि वे friction हटाते हैं, लेकिन वे उसी standing privilege को वापस ले आते हैं जिसे split करके हटाना था।

Sallyport की decision ladder इस model के लिए उपयोगी shape देती है: vault locked होने पर उसका gate हर action deny करता है, session authorization नए agent process की पहचान करती है और चुनी हुई per-call keys हर इस्तेमाल पर confirmation मांग सकती हैं। यह जानबूझकर policy engine से अधिक narrow है। Teams को फिर भी तय करना होगा कि किन credentials की per-call जांच जरूरी है।

Prompt injection planners तक executors से पहले पहुंचता है

Prompt injection अक्सर planner के सामान्य काम के दौरान आती है। Repository comment command चलाने को कहता है। Support ticket में configuration exfiltrate करने की fake instruction होती है। Web page agent से earlier directions को ignore करने को कहता है। Planning agents को executors की तुलना में कहीं अधिक untrusted text दिखाई देता है।

आम तौर पर खराब response यह होता है कि महीनों तक perfect instruction लिखने की कोशिश की जाए, जो planner को fooled होने से रोक सके। Model behavior बेहतर हो सकता है, लेकिन text instructions authority boundaries का विकल्प नहीं हैं। मानकर चलें कि planner अपनी plan में bad instruction दोहरा सकता है। फिर executor को catalog, scope और approval binding से बाहर की हर request reject करने दें।

एक परिचित failure पर विचार करें। Planner latency की जांच करते हुए पुराना incident note पढ़ता है, जिसमें traffic drain करने से पहले service का replica count zero करने की सलाह है। Note में copied hostname होने के कारण वह गलत environment का नाम लेकर plan लिख देता है। अगर planner general deployment tool call कर सकता है, तो stale suggestion downtime में बदल सकती है।

Split design में failure कई जगह रुकती है। Handoff request में production स्पष्ट रूप से लिखा होना चाहिए। Executor केवल deployment revision action स्वीकार करता है, replica-count mutation नहीं। Human reviewer को actual target और requested effect दिखता है। Request fit न होने पर executor log denial record करता है। इनमें से किसी control के लिए planner का poisoned या obsolete text को perfectly पहचानना जरूरी नहीं है।

Planner output को execution path के लिए untrusted input के रूप में label करके रखें। यह केवल UI में warning नहीं, data handling को प्रभावित करने वाला नियम होना चाहिए। Planner की prose को shell commands में interpolate न करें। Type checks और allowlists के बिना उसे HTTP paths, headers या query fields भरने न दें। JSON schema मदद करती है, लेकिन केवल schema validation यह नहीं बताती कि production authorized target है या नहीं।

Read access भी damage का रास्ता खोल सकता है

Teams अक्सर planners को broad read access यह सोचकर देती हैं कि «यह कुछ बदल नहीं सकता»। इस वाक्य ने बहुत-सी टाली जा सकने वाली परेशानियां पैदा की हैं। Read access customer data, internal hostnames, deployment histories, feature flags, access patterns और privileged systems के नाम उजागर कर सकता है। यह attacker को convincing action request तैयार करने के लिए जरूरी जानकारी भी दे सकता है।

Reads को sensitivity और उनके द्वारा संभव होने वाले काम, दोनों के आधार पर classify करें। Service status लौटाने वाला health endpoint उस database export endpoint से अलग है जो data निकाल सकता है। Public names की सूची देने वाली service inventory उस credential manager API से अलग है जो secret identifiers और metadata लौटाती है। दोनों को एक generic read_only tool के पीछे न रखें।

जहां संभव हो, planner को derived facts दें। हर deployment event तक access देने के बजाय ऐसा operation दें जो किसी named service के लिए current revision, health state और last approved change ID लौटाए। Broad database query rights देने के बजाय ऐसा metric दें जो diagnostic question का उत्तर दे। इससे accidental disclosure और hostile instructions ले जाने वाले material, दोनों कम होते हैं।

यहीं teams जरूरत से ज्यादा प्रतिक्रिया देकर useful planning को cripple कर देती हैं। समाधान agent को blind बनाना नहीं है। तय करें कि task को किन facts की जरूरत है और उन facts के लिए read interface बनाएं। Planner को नियमित रूप से कोई extra field चाहिए, तो use case की review के बाद उसे जानबूझकर जोड़ें। हर gap को production console देकर न भरें।

Logs से disagreement को reconstruct कर पाना चाहिए

Audit trail को केवल «क्या API call हुई?» का जवाब नहीं देना चाहिए। Disputed change के बाद आपको planner के proposed artifact, human-approved artifact, executor के validated request, exact external call और response की तुलना करनी होगी। इनमें से कोई एक भी missing हो, तो evidence के बजाय कहानी बचती है।

पूरे path में stable request ID record करें। Planner उसे assign या receive करता है। Approval उससे और उसके content hash से bind होती है। Executor उसे अपनी process identity और action result के साथ लिखता है। External gateway उसे outbound destination और response status के साथ record करता है। Correlation आसान बनाने के लिए bearer tokens, passwords, private keys या full sensitive payloads log न करें।

Tamper evidence महत्वपूर्ण है, क्योंकि सामान्य application logs अक्सर ऐसे stores में रहते हैं जिन्हें administrators edit कर सकते हैं। Hash-linked event sequence बाद में alteration को detectable बनाती है, अगर आप expected chain state सुरक्षित रखते हैं। इससे हर event अपने आप सच साबित नहीं होता। लेकिन recorded history में चुपचाप बदलाव छिपाना कठिन हो जाता है। जब log store तक पहुंच review किए जा रहे लोगों के पास भी हो, तो यही property जरूरी है।

Sallyport अपने Sessions और Activity journals को encrypted, hash-chained audit log से project करता है, और sp audit verify vault key के बिना ciphertext पर offline chain check करता है। Investigation में यह उपयोगी है, क्योंकि verification के लिए reviewer को action credentials देने की जरूरत नहीं होती।

Incident से पहले reconstruction drill करें। कोई approved change चुनें और colleague से records के आधार पर पांच सवालों के जवाब देने को कहें: इसे किस agent ने propose किया, exact request को किसने approve किया, किस executor ने इसे चलाया, कौन-सा outbound operation हुआ और क्या result आया। अगर किसी जवाब के लिए memory या chat transcript पर निर्भर रहना पड़े, तो records बेहतर करें।

पहला automated action उबाऊ और reversible होना चाहिए

ऐसे action से split की शुरुआत करें जिसका owner स्पष्ट हो, target set छोटा हो और reversal का अभ्यास पहले से किया गया हो। Immutable revision का इस्तेमाल करके non-production environment में deployment करना access rules बदलने या stale accounts delete करने से बेहतर पहला case है। Boring work आपको production को demo पर दांव लगाए बिना design की कमियां खोजने का मौका देता है।

जब तक trivial कारणों से request schema बदलना बंद न हो जाए, उसी task को workflow से बार-बार चलाएं। Predictable failures पर ध्यान दें: planners target छोड़ देते हैं, reviewers generic description approve करते हैं, executors को undeclared context चाहिए होता है और logs approval को call से associate नहीं कर पाते। हर failure बताती है कि roles के बीच authority अभी कहां leak हो रही है।

Success को इस आधार पर न मापें कि approval clicks कितने कम रह गए। देखें कि executor wrong target, unapproved revision और unsupported action को refuse करता है या नहीं, और intended action पूरा करता है या नहीं। जो system हर action को आसान बनाता है, उसने शायद बहुत ज्यादा actions संभव कर दिए हैं।

Workflow ठीक से काम करने लगे, तो एक बार में एक action family बढ़ाएं। Planner को curious और executor को boring रखें। Production automation तब भरोसा कमाती है, जब उसकी refusals उसकी successes जितनी ही सोच-समझकर बनाई गई हों।