# AI coding workflows के लिए local action control: यह कहां सही बैठता है

AI coding workflow में local action control तब सही बैठता है, जब मशीन का मालिक एक डेवलपर हो, जो किसी run को मंज़ूरी देने के लिए पर्याप्त रूप से मौजूद रहे, और agent को मूल secrets दिए बिना repository के बाहर कार्रवाई करनी हो। यह एक सीमित लेकिन आम समस्या का अच्छा समाधान है: agent workspace में code को पर्याप्त सुरक्षा के साथ बदल सकता है, लेकिन उसे API query करने, private artifact लाने या SSH से command चलाने की भी ज़रूरत है।

जब लोग इसे fleet authorization तक बढ़ाने की कोशिश करते हैं, तब यह खराब समाधान बन जाता है। Mac पर दी गई मंज़ूरी यह बता सकती है कि किसी खास local process को credential के साथ कार्रवाई करने की अनुमति है। लेकिन इससे production service यह तय नहीं कर सकती कि resulting request के लिए कौन-सा tenant, environment, change window या business rule लागू होना चाहिए। ये फैसले उसी जगह होने चाहिए जहां resource मौजूद है।

सीमा सीधी है: local control developer machine पर credentials की सुरक्षा करता है और इंसानी मंशा को फिर से नियंत्रण में लाता है। Server-side control shared resources की रक्षा करता है और तब भी काम करता है जब उस मशीन पर कोई developer बैठा न हो। परेशानी तब शुरू होती है जब किसी एक पक्ष से दूसरे पक्ष का काम कराने की कोशिश की जाती है।

## Local control व्यक्ति के स्वामित्व वाले execution point पर होना चाहिए

Local action control तब समझ में आता है जब agent चलाने वाली मशीन का स्पष्ट मालिक हो, जो काम को पहचान सके और उसे रोक सके। आम तौर पर इसका मतलब interactive coding session चलाने वाला developer Mac है, न कि friendly hostname वाला unattended build worker।

Ownership का सवाल तब तक आसान लगता है, जब तक टीम यह नहीं देखती कि काम वास्तव में कैसे चलता है। Laptop किसी व्यक्ति को दिया गया हो सकता है, लेकिन remote desktop से नियमित रूप से access किया जा सकता है। Shared lab Mac पर पूरे सप्ताह कई engineers login कर सकते हैं। Managed build host developer के account से चल सकता है, लेकिन jobs किसी pull request से शुरू हो सकती हैं। इनमें से कोई भी तथ्य अकेले meaningful human control साबित नहीं करता।

Local approvals जोड़ने से पहले ये चार ठोस सवाल पूछें:

- मशीन को physically unlock करके request को मंज़ूरी कौन दे सकता है?
- Agent किस executable से शुरू होता है, और क्या owner उसकी code-signing authority पहचान सकता है?
- Agent का काम interactive session तक सीमित रहता है, या व्यक्ति के चले जाने के बाद भी जारी रह सकता है?
- अगर मशीन compromise हो जाए, तो remote service पर credential की पहुंच कितनी सीमित रहेगी?

पहले दो सवाल बताते हैं कि approval का कोई वास्तविक मानवीय subject है या नहीं। आखिरी दो यह बताते हैं कि approval का blast radius उचित है या नहीं। अगर developer ऐसे process के लिए approve क्लिक करता है, जो रातभर चलकर हर environment में deploy कर सकता है, तो उस क्लिक में शायद उसकी मंशा से कहीं ज्यादा authority होगी।

Local gateway को secret अपने पास रखना चाहिए और outbound action खुद करनी चाहिए। Agent को environment variable, config file या tool response के ज़रिए token देने पर local gate लगभग औपचारिकता बन जाता है। Agent उसे transcript में दोहरा सकता है, patch में लिख सकता है, shell history file में रख सकता है या किसी दूसरे tool को भेज सकता है। Credential agent के context में पहुंचने के बाद उसे भरोसेमंद तरीके से वापस लेना संभव नहीं रहता।

इसी वजह से केवल proxy जैसा arrangement पर्याप्त नहीं है। HTTP proxy traffic को route कर सकता है, लेकिन routing यह साबित नहीं करती कि secrets client process में कभी पहुंचे ही नहीं। Design ऐसा होना चाहिए कि agent action का अनुरोध करे, local component credential जोड़े और agent को केवल remote result मिले।

## Machine ownership सिर्फ login name से तय नहीं होती

Developer account का नाम यह साबित नहीं करता कि मंज़ूर किया गया process ही असल काम कर रहा है। macOS पर coding agent terminal, editor extension, helper process या repository में लिखी script से शुरू हो सकता है। इन origins पर भरोसे का स्तर बहुत अलग होता है।

किसी harmless run के दौरान actual process tree देखकर शुरुआत करें। यह command process IDs, parents, users, elapsed time और command lines दिखाती है:

```sh
ps -axo pid,ppid,user,etime,command | grep -i '[a]gent'
```

Output में ऐसी chain दिखनी चाहिए जिसे आप पहचानते हों। उदाहरण के लिए, interactive terminal approved agent process के parent के रूप में दिख सकता है। Untrusted repository की shell script, background launch item या अज्ञात helper आपका फैसला बदल देना चाहिए। केवल इसलिए किसी process को approve न करें कि उसकी command line में आपकी अपेक्षित tool का नाम है।

इसके बाद filename पर भरोसा करने के बजाय executable की जांच करें:

```sh
codesign -dv --verbose=4 /path/to/executable 2>&1 | \
  grep -E '^(Identifier|TeamIdentifier|Authority)='
```

Signed binary में bugs हो सकते हैं, लेकिन signing authority operator को पहचानने के लिए एक स्थिर संकेत देती है। Writable project directory के अंदर पड़ा bare path ऐसा संकेत नहीं देता। Code-signing authority से शुरू होने वाला session approval उस dialog से कहीं बेहतर है, जिसमें सिर्फ «agent wants access» लिखा हो। इससे व्यक्ति credential वाली action से पहले copied binary, local wrapper या unexpected update को अस्वीकार कर सकता है।

इसीलिए shell aliases और wrapper scripts पर भी ध्यान देना चाहिए। वे काम के लिए उपयोगी हैं, लेकिन कोई alias उस executable के बजाय कुछ और चला सकता है, जिसे व्यक्ति approved समझ रहा है। Action-gateway launch commands को agent-writable repositories के बाहर रखें। अगर agent उस script को बदल सकता है, जो उसका अपना access path तय करती है, तो gate operator के निर्णय को व्यक्त नहीं करता।

Model Context Protocol specification बताती है कि MCP client और server tool calls का आदान-प्रदान कैसे करते हैं। यह स्थापित नहीं करती कि tool caller approved local process है। MCP compatibility interface का सवाल हल करती है। Process identity, credential custody और authorization अलग-अलग काम हैं।

## Session approval तब काम करता है जब run की स्पष्ट सीमा हो

Interactive coding run के लिए per-session approval एक व्यावहारिक default है, क्योंकि नया agent process शुरू होने पर एक बार पूछा जाता है और फिर काम में अनावश्यक रुकावट नहीं आती। इससे हर harmless read के लिए confirmation dialog नहीं खुलता और व्यक्ति के पास यह देखने का अवसर रहता है कि request कौन कर रहा है।

यह सीमा वास्तविक process lifetime होनी चाहिए, «आज दोपहर के काम» जैसी अस्पष्ट धारणा नहीं। Session process के exit होते ही खत्म हो जाता है। यह नियम समझाना और revoke करना आसान है, और agent के लिए इसकी नई व्याख्या करना कठिन है। Process फिर शुरू होगा तो दोबारा पूछेगा। व्यक्ति approval revoke करेगा तो future calls fail होंगी, पहले क्लिक से trust अपने-आप आगे नहीं जाएगा।

Approval fatigue बताती है कि सीमा गलत है। अगर developer को हर बार issue tracker check करने, package लाने और staging API पढ़ने पर request दिखती है, तो वह mechanically approve करने लगेगा। बार-बार दी गई warnings बेहतर judgment पैदा नहीं करतीं। वे लोगों को windows हटाने की आदत डालती हैं, ताकि काम चलता रहे।

Session approval का उद्देश्य policy engine से छोटा है। इसका अर्थ है, «मैं इस local process को पहचानता हूं और इसके जीवित रहने तक allowed action path इस्तेमाल करने की अनुमति देता हूं।» इसे यह अनुमान लगाने की कोशिश नहीं करनी चाहिए कि SQL query सुरक्षित है या नहीं, ticket title असली लगता है या नहीं, या current branch production access की हकदार है या नहीं। ये remote authorization decisions या workflow rules हैं, और natural-language prompts उन्हें रखने की बेहद खराब जगह हैं।

कुछ मामलों में interactive session को भी blanket grant नहीं देना चाहिए। जो agent arbitrary local workspaces खोलता है, chat से tasks स्वीकार करता है या unreviewed repositories के plug-ins चलाता है, उसका input surface tightly scoped repository session से कहीं बड़ा है। ऐसे में या तो run के लिए उपलब्ध action set घटाएं, या risk वाले specific credential के लिए approval मांगें।

Approval dialogs में failure behavior भी भरोसेमंद होना चाहिए। Vault locked हो तो हर action fail हो। Mac locked या asleep होने के कारण approval UI न दिख पाए तो भी हर action fail हो। UI error के दौरान requests को आगे बढ़ाने वाला छिपा fallback human gate को केवल दिखावा बना देता है।

## Per-call approval उन कार्रवाइयों के लिए है जिनके परिणाम महंगे हो सकते हैं

Per-call approval उस credential के लिए उचित है, जिसके इस्तेमाल से production change हो सकता है, पैसा खर्च हो सकता है, data delete हो सकता है या ऐसी सीमा पार हो सकती है, जिस पर developer को हर बार ध्यान से विचार करना चाहिए। हर डरावने नाम वाले credential के लिए यह जरूरी नहीं है।

Action को protocol से नहीं, उसके परिणाम से वर्गीकृत करें। HTTP POST केवल disposable preview record बना सकता है। SSH command केवल deployment log पढ़ सकती है। GET request पूरा customer dataset export कर सकती है। Approval mode method या transport तय नहीं करते।

Per-call gate तब इस्तेमाल करें जब action में इनमें से एक या अधिक गुण हों:

- Remote service result को भरोसेमंद तरीके से undo न कर सके।
- Credential shared production resource को प्रभावित कर सकता हो।
- Request sensitive data को अपेक्षित destination से बाहर भेज सकती हो।
- Operation इतनी कम होती हो कि सोच-समझकर की गई confirmation routine न बन जाए।

चौथा बिंदु महत्वपूर्ण है। बार-बार होने वाली action पर per-call confirmation वही mechanical clicking पैदा करती है, जो जरूरत से ज्यादा session prompts करते हैं। जहां संभव हो, credentials अलग रखें। Routine development work के लिए development resources तक सीमित credential दें और production-capable credential को उन थोड़ी-सी कार्रवाइयों के लिए बचाकर रखें, जिन पर interruption उचित है।

Agent को कभी यह तय नहीं करना चाहिए कि उसकी कौन-सी calls के लिए confirmation चाहिए। अगर agent request को «read only» कह सकता है या credential class खुद चुन सकता है, तो prompt injection या साधारण implementation mistake उसे आसान रास्ते की ओर मोड़ सकती है। Account का मालिक agent के workspace से बाहर approval requirement तय करे।

Confirmation इतनी स्पष्ट हो कि वास्तविक निर्णय लिया जा सके। व्यक्ति को credential का नाम या purpose, destination, request method या command form और call शुरू करने वाले process की identity दिखनी चाहिए। Raw request bodies secrets उजागर कर सकती हैं या व्यक्ति को जानकारी से भर सकती हैं। केवल «Approve action?» दिखाने से कोई उपयोगी context नहीं मिलता। अच्छी confirmation design कम जानकारी दिखाती है, लेकिन operator को unexpected call अस्वीकार करने के लिए पर्याप्त context देती है।

## Secrets को local रखना एक समस्या हल करता है, सभी समस्याएं नहीं

Local vault agent को API keys और private SSH keys plaintext में रखने से रोकता है। इससे prompts, transcripts, tool logs, copied files और agent द्वारा लिखे गए code के ज़रिए accidental disclosure का जोखिम काफी घटता है। Operator active run को तुरंत credential rotate किए बिना revoke भी कर सकता है।

लेकिन remote credential क्या कर सकता है, यह नहीं बदलता। अगर API token हर project delete कर सकता है, तो local approval के बाद service delete request स्वीकार करेगी। अगर SSH account के पास व्यापक sudo rights हैं, तो private key की सुरक्षा उस account को सीमित deployment identity में नहीं बदलती। अधिकतम नुकसान अब भी remote least privilege तय करता है।

इन दो बातों को अलग रखें:

1. Credential custody पूछती है कि agent secret प्राप्त या दोबारा बना सकता है या नहीं। Local vault इसका अच्छा समाधान दे सकता है।
2. Resource authorization पूछती है कि मौजूदा परिस्थितियों में service को action स्वीकार करनी चाहिए या नहीं। इसका जवाब API, host, identity provider या deployment system को देना होगा।

Teams अक्सर इन दोनों को इसलिए मिला देती हैं क्योंकि agent के API call करने पर दोनों विषय सामने आते हैं। नतीजा साफ होता है। वे local secret holder लगा देते हैं, लेकिन उसके पीछे long-lived administrator token छोड़ देते हैं। Token अब उतनी आसानी से leak नहीं होता, फिर भी action path जरूरत से कहीं ज्यादा व्यापक रहता है।

SSH इस अंतर को बहुत स्पष्ट कर देता है। Local machine private key की रक्षा कर सकती है, लेकिन host तय करता है कि public key का account क्या चला सकता है। जहां संभव हो, automation के लिए अलग accounts या forced-command restrictions बनाएं। Host access सीमित रखें। Engineer की personal administrator key को agent की general-purpose key के रूप में इस्तेमाल न करें। Personal keys समय के साथ exceptions जमा करती हैं, और autonomous process को ठीक इन्हीं exceptions का उत्तराधिकारी नहीं बनना चाहिए।

Sallyport API और SSH credentials को encrypted app vault में रखकर और secret को agent में भेजे बिना HTTP या SSH action खुद करके इस local model का इस्तेमाल करता है। यह गुण developer machine पर मददगार है, लेकिन teams को फिर भी narrow credentials और server-side permissions की जरूरत होगी।

## भरोसा करने से पहले action path की जांच करें

Production capability से जोड़ने से पहले action gateway को harmless endpoint और temporary credential के साथ test करें। Test में तीन बातें स्पष्ट होनी चाहिए: agent को secret नहीं मिला, gateway ने call record की और remote service ने अपेक्षित identity देखी।

ऐसा temporary HTTP credential बनाएं, जो non-sensitive endpoint को call कर सके, जैसे caller identity लौटाने वाला test resource। Agent से वही एक action करने को कहें। उसके transcript और tool result में literal token तथा token जैसे strings खोजें। Agent को response body या redacted error मिलना चाहिए, authentication के लिए इस्तेमाल किए गए header का value कभी नहीं।

फिर जानबूझकर denial test करें। Local vault lock करके action दोहराएं। Approved agent process को kill करें और नया process शुरू करें। अगर gateway revocation support करता है, तो live session revoke करके original process से दोबारा कोशिश करें। हर retry को local boundary पर fail होना चाहिए। अगर calls फिर भी सफल हों, तो पता लगाएं कि किसी अलग process ने credential रखा है, environment variable gateway को bypass कर रहा है या remote service के पास कोई दूसरा cached authorization path है।

एक उपयोगी audit record में इतनी जानकारी होनी चाहिए कि secret सुरक्षित रखते हुए event को दोबारा समझा जा सके। HTTP action के लिए timestamp, process या session identity, credential label, destination, method, result status और remote service द्वारा दिए जाने पर request identifier record करें। SSH के लिए destination, account label, command outcome और आपकी sensitivity rules के अनुसार command representation record करें। Audit trail को पूरा दिखाने के लिए bearer values, private keys या पूरी sensitive payloads log न करें।

Hash chaining बदले गए local history का पता लगाने में मदद करती है, लेकिन यह साबित नहीं करती कि मूल action समझदारी भरी थी। Gateway के record को receiving service के audit log के साथ रखें। अगर दोनों में अंतर हो, तो उसे investigation मानें, किसी एक source को अपने-आप सही घोषित करने का कारण नहीं।

Sallyport encrypted, hash-chained audit log से session और activity journals बनाता है, और `sp audit verify` vault key के बिना offline उस chain की जांच कर सकता है। Incident review या release handoff के हिस्से के रूप में verification चलाएं, लेकिन integrity checking को authorization न समझें।

## जब लोग मौजूद न हों या resources shared हों, server-side controls संभाल लेते हैं

जब action को किसी खास developer की मंज़ूरी के बिना जारी रहना हो, तब server-side controls आवश्यक हैं। इसमें CI jobs, scheduled remediation, server-hosted agents, shared runners और deployment workers शामिल हैं। Laptop की battery खत्म होने, यात्रा, sleep या व्यक्ति के company छोड़ने के बाद भी चलने वाले काम के लिए local Mac अंतिम authority नहीं हो सकता।

इनमें से कोई स्थिति हो तो authorization decision को protected resource के पास रखें:

- एक ही workflow को कई लोग या systems शुरू कर सकते हों।
- Target production, customer data, financial activity या regulated system हो।
- Agent किसी व्यक्ति की interactive machine के बजाय infrastructure पर चलता हो।
- Service को tenant boundaries, change windows, environment rules या separation of duties लागू करनी हो।
- Workflow को किसी व्यक्ति द्वारा dialog approve किए बिना high availability के साथ चलना हो।

इन मामलों में narrow permissions वाली workload identity इस्तेमाल करें, और identity system support करे तो validity कम रखें। Server-side audit records बनाए रखें। Deployment system या API में environment boundaries लागू करें। Organization को human approval चाहिए तो वहीं change record या approval आवश्यक करें। Local machine developer को change तैयार करने और उसकी जांच करने में मदद कर सकती है, लेकिन production action के लिए enforcement point नहीं बन सकती।

NIST Special Publication 800-207 zero trust को ऐसे model के रूप में बताती है, जिसमें access decisions network location पर भरोसा करने के बजाय resources की सुरक्षा पर केंद्रित होते हैं। Agent workflows के लिए उपयोगी सीख यह नहीं है कि हर local tool को complicated policy language चाहिए। सीख यह है कि production API या host को caller और requested resource के बारे में अपना निर्णय खुद लेना होगा। Mac-side approval उस निर्णय की जगह नहीं ले सकती।

इस समस्या को developer का local credential CI में forward करके हल न करें। इससे human-controlled credential unattended service credential बन जाता है और दोनों models की स्पष्टता भी खत्म हो जाती है। अलग workload identity बनाएं और job को केवल जरूरी permissions दें।

## Approval prompts के अंदर policy engine दोबारा न बनाएं

Teams अक्सर ऐसे rules मांगती हैं: «GET requests allow करो, लेकिन office hours के बाद नहीं» या «SSH तभी allow करो जब branch name में release हो।» यह मांग लोकप्रिय है क्योंकि इससे clicks घटते हुए और control local रहते हुए दिखता है। आम तौर पर इससे ऐसा fragile policy system बनता है, जिसे दबाव के समय कोई ठीक से समझा नहीं सकता।

Local action control में छोटी और स्पष्ट decision ladder होनी चाहिए: vault locked है या unlocked, session approved है या नहीं, credential को per-call approval चाहिए या नहीं। हर state के साथ operator की सीधी action जुड़ी हो। व्यक्ति अनुमान लगा सके कि क्या होगा, test कर सके और revoke कर सके।

जब local tool branch names, prompt text, URL patterns, ticket labels और agent-provided intent parse करने लगता है, तो वह ऐसे inputs के आधार पर authorization decisions लेने लगता है, जिन्हें agent प्रभावित कर सकता है। Rules में exceptions बढ़ती जाती हैं। Exceptions permissions बन जाती हैं। कुछ समय बाद developer ने laptop पर partial server authorization system बना लिया होता है, लेकिन उसे सही काम करने के लिए जरूरी service context नहीं मिलता।

Local decisions को उन facts से जोड़कर रखें, जिन्हें local machine स्थापित कर सकती है: vault खुला है या नहीं, किस signed process ने action मांगी, उसका session approved है या नहीं और इस credential को fresh confirmation चाहिए या नहीं। Remote decisions को उन facts से जोड़ें, जिन्हें service स्थापित कर सकती है: target resource, caller identity, tenant, current environment, request contents और organizational controls।

इस separation से failures को समझना भी आसान होता है। Denied local call का मतलब है कि vault, session या per-call gate ने उसे रोका। Denied server call का मतलब है कि remote policy ने उसे reject किया। जब denial overlapping local rules की भूलभुलैया से आ सकता है, तो developers controls सुधारने के बजाय उन्हें disable कर देते हैं।

## Mixed workflow हर control को स्पष्ट काम देता है

अधिकांश teams को local और server-side दोनों controls चाहिए। व्यावहारिक design all-or-nothing choice नहीं है।

Developer staging API inspect करने, private package metadata पढ़ने या सीमित SSH diagnostics चलाने के लिए interactive agent local रूप से चला सकता है। Process identity जांचने के बाद developer run को approve करता है। Local vault ऐसा credential देता है, जिसे agent कभी नहीं देखता। Activity records बाद की review को संभव बनाते हैं।

वही agent deployment change तैयार कर सकता है, लेकिन उसे deploy करने का अधिकार नहीं मिलना चाहिए। इसके बाद server-side pipeline अपनी workload identity के साथ चलती है, production restrictions लागू करती है और resulting deployment record करती है। Pipeline को human approval चाहिए तो वह approval उसी system में रखें, जिसके पास production change का ownership है, ताकि उस environment के जिम्मेदार लोगों को वह दिखाई देता रहे।

Handoff को ऐसी सीमा मानें जिसे बचाकर रखना जरूरी है। Local agent patch, test result या review के लिए signed request तैयार कर सकता है। उसे developer की session authority unattended job में छिपाकर नहीं भेजनी चाहिए। Server job को काम पूरा करने के लिए unlocked laptop पर निर्भर नहीं होना चाहिए।

एक मौजूदा workflow में हर credential वाली action का नक्शा बनाकर शुरुआत करें। लिखें कि इसे शुरू करने वाला process कौन-सा है, secret रखने वाली machine कौन-सी है, इसे प्राप्त करने वाला resource कौन-सा है, इसे रोक सकने वाला व्यक्ति कौन है और क्या job को उस व्यक्ति के बिना चलना होगा। आपको जल्दी पता चल जाएगा कि कौन-सी actions local control के लिए सही हैं, किन्हें server enforcement चाहिए और किनके पास फिलहाल दोनों में से कोई भी control नहीं है।