कौन-सा असली agent process approval मांग रहा है?

जो approval prompt केवल «Terminal» या «zsh» कहता है, वह आमतौर पर वास्तविक निर्णय के लिए बहुत अस्पष्ट होता है। ये programs launch path का हिस्सा हो सकते हैं, लेकिन अक्सर shared plumbing होते हैं। Reviewer को यह जानना जरूरी है कि action करने का अनुरोध किस agent run ने किया, उसे किसने शुरू किया और क्या उस chain में कोई ऐसी चीज है जो request को स्थायी पहचान देती हो।

समस्या यह है कि process tree एक साथ कई अलग-अलग सवालों के जवाब देती है। इससे पता चल सकता है कि किसने किसे fork किया। यह ऐसा task runner दिखा सकती है जिसकी किसी को उम्मीद नहीं थी। यह भी दिखा सकती है कि graphical IDE ने terminal शुरू किया। लेकिन अकेली process tree यह साबित नहीं कर सकती कि signed parent ने उस child द्वारा चलाए जाने वाले code की हर line को approve किया था। अच्छी approval design tree को evidence की तरह इस्तेमाल करती है और फिर उतना ही सीमित दावा करती है जितना evidence संभाल सकता है।

Approval terminal को नहीं, actor को मिलना चाहिए

Reviewer जिस actor को approve करता है, वह वह process run है जिसने action का अनुरोध किया, और उसे उसके launch chain के संदर्भ में समझना चाहिए। Terminal window वह जगह है जहां processes चलते हैं। वह अपने आप responsible program नहीं बन जाती।

यह अंतर तब साफ होता है जब एक team के कई agents एक ही shell से चल रहे हों। एक developer iTerm2 में terminal खोलता है, एक tab में interactive coding agent चलाता है, दूसरे में repository task शुरू करता है और तीसरे में background watcher छोड़ देता है। इन तीनों descendants के ऊपर कहीं न कहीं वही terminal application हो सकती है। हर request को «iTerm2» कहना reviewer को लगभग कोई जानकारी नहीं देता।

उलटी गलती भी आम है। Reviewer node, python या zsh देखकर मान लेता है कि request के सबसे पास मौजूद binary ही पूरी identity है। वह binary agent package का interpreter, package manager hook, IDE extension द्वारा बनाई गई temporary script या team tool का wrapper हो सकती है। नाम तकनीकी रूप से सही होता है, लेकिन काम के लिए बेकार।

आंतरिक रूप से तीन labels रखें, भले approval card पर केवल दो दिखें:

• Requester: वह process जिसने protected channel का इस्तेमाल करने के लिए वास्तव में request की।
• Execution chain: वे relevant parent processes जो बताते हैं कि requester वहां तक कैसे पहुंचा।
• Recognizable authority: सबसे निकट का ऐसा ancestor जिसे reviewer उचित रूप से पहचान सके और जिसकी code signature की जांच की जा सके।

ये labels उस समस्या को हल करते हैं जिसे कई approval systems धुंधला कर देते हैं। Requester का उत्तर है, «यह call किस process ने किया?» Recognizable authority का उत्तर है, «यह run किस व्यक्ति या organization के माध्यम से आया?» दोनों जुड़े हुए हैं, लेकिन एक-दूसरे के बदले इस्तेमाल नहीं किए जा सकते।

उदाहरण के लिए request ऐसी दिख सकती है:

Code Helper (signed application)
  └─ zsh -l
      └─ npm run agent
          └─ node ./tools/start-agent.mjs
              └─ agent-cli --workspace /Users/maya/src/payments

अगर agent-cli HTTP request करता है, तो requester वही है। Shell और npm launch path समझाते हैं। Signed Code Helper process सबसे अच्छी recognizable authority हो सकता है, बशर्ते वह live ancestry में सचमुच मौजूद हो और desktop पर केवल खुला न हो। «agent-cli, launched from Code Helper» कहना ईमानदार है। केवल «Code Helper wants access» कहने से वह जानकारी मिट जाती है जो इस run को किसी दूसरे extension या task से अलग कर सकती थी।

Process tree evidence है, intent का बयान नहीं

Parent process यह साबित करता है कि उसने child बनाया या उसके साथ relationship inherit की। इससे यह साबित नहीं होता कि parent को child के बाद के arguments, prompt, repository instructions या remote response की जानकारी थी।

यह सीमा तब महत्वपूर्ण होती है जब लोग signing की भाषा लापरवाही से इस्तेमाल करते हैं। Apple के अनुसार designated requirement वह mechanism है जिसका उपयोग macOS यह तय करने के लिए करता है कि अलग-अलग versions में code वही है या नहीं। इसमें आमतौर पर identifier और signing authority शामिल होते हैं। Apple यह सीमा भी स्पष्ट करता है: unsigned code की कोई स्थायी designated requirement नहीं होती और ad hoc local signatures versions के बीच stable identity नहीं देतीं।

Approval के लिए यह उपयोगी evidence है, action का endorsement नहीं। Signed IDE unsigned repository script चला सकता है। Signed terminal downloaded binary चला सकता है। Signed task runner hostile environment variables को सामान्य interpreter तक पहुंचा सकता है। Signature reviewer को code publisher पहचानने में मदद करती है। इससे chain के नीचे का code सुरक्षित या साफ नहीं हो जाता।

इन claims को अलग-अलग समझें:

व्यावहारिक नतीजा यह है कि इन चारों claims को friendly app icon और एक sentence में न समेटें। Reviewer को दिखना चाहिए कि वह किस claim को स्वीकार कर रहा है।

जब chain अस्पष्ट हो, तो ऐसा ही कहें। «Terminal session से unsigned script द्वारा शुरू» कहना terminal application को request का author बताने से बेहतर approval label है। गलत precision लोगों को card को नजरअंदाज करना सिखाती है।

Approval card बनाने से पहले live chain की जांच करें

सही actor खोजने का सबसे तेज तरीका है कि कोई वास्तविक run जीवित रहते हुए inspect किया जाए। Agent से harmless operation करवाकर यह करें, क्योंकि startup के बाद task runner या child helper में काम जाने पर chain बदल सकती है।

macOS पर, अगर gateway requester PID रिकॉर्ड करता है, तो उसी से शुरुआत करें। यह command process, उसका parent PID, start time, executable name और arguments दिखाती है:

ps -p "$PID" -o pid=,ppid=,lstart=,user=,comm=,args=

Representative result का रूप ऐसा हो सकता है:

81234 80991 Tue Jul 21 14:08:31 2026 maya /usr/local/bin/agent-cli agent-cli --workspace /Users/maya/src/payments

फिर ऊपर की ओर जाएं। ps अपने आप recursion नहीं करता, इसलिए छोटा shell function inspection को दोहराने योग्य बनाता है:

ancestry() {
  local pid="$1"
  while [ "$pid" -gt 1 ] 2>/dev/null; do
    ps -p "$pid" -o pid=,ppid=,user=,comm=,args=
    pid=$(ps -p "$pid" -o ppid= | tr -d ' ')
  done
}

ancestry "$PID"

Output जानबूझकर साधारण है। आप यह देख रहे हैं कि process का प्रकार कहां बदलता है: agent executable से interpreter, interpreter से package manager, package manager से shell, और shell से terminal या IDE helper। किसी नाम को पहचानते ही रुक न जाएं। तब तक चलते रहें जब तक कोई ऐसा process न मिले जो reviewer को meaningful provenance दे, या local chain समाप्त न हो जाए।

जब कई descendants मौजूद हों, तो broad snapshot उपयोगी है:

ps -ax -o pid=,ppid=,user=,lstart=,comm=,args= | sort -n

इसे investigation के लिए इस्तेमाल करें, approval prompt के लिए नहीं। पूरी process listing में बहुत-सी irrelevant detail और बहुत कम structure होता है। Implementation को जरूरत पड़ने पर इसे collect करना चाहिए, फिर requester, immediate parent, recognizable authority और उन intermediary hops तक सीमित करना चाहिए जो किसी असामान्य launch को समझाते हैं।

यहां timing के दो traps हैं। पहला, process के exit होने के बाद process IDs दोबारा इस्तेमाल हो सकते हैं। PID के साथ start time भी रिकॉर्ड करें और पुराने sample पर भरोसा करने के बजाय request के समय chain resolve करें। दूसरा, task runner worker fork करके protected call से पहले exit कर सकता है। अगर parent पहले ही जा चुका है, तो process creation से देखी गई chain सुरक्षित रखें या missing link बताएं। अनुमान से parent न भरें।

VS Code launch path बदलता है, requester नहीं बनता

VS Code का integrated terminal shell integration के लिए supported shells शुरू करते समय arguments या environment variables inject कर सकता है। उसके documentation के अनुसार automatic injection हर setup में नहीं होती, जिसमें कुछ subshell, SSH और complex shell cases शामिल हैं। यह याद दिलाता है कि terminal UI metadata और Unix parentage evidence के अलग स्रोत हैं।

सरल स्थिति में chain ऐसी दिखती है:

Visual Studio Code
  └─ terminal helper
      └─ login shell
          └─ agent-cli

Terminal helper इसलिए मौजूद है क्योंकि IDE को pseudoterminal और उसके child shell को manage करना होता है। Login shell ऐसी profile source कर सकता है जो PATH बदले, language runtime activate करे, shell hooks लगाए या project-specific script शुरू करे। इसी वजह से standalone terminal और IDE terminal में एक ही command का behavior अलग हो सकता है।

Approval decision को इन details की अनदेखी नहीं करनी चाहिए। Agent executable को requester के रूप में दिखाएं। VS Code को launch authority तभी दिखाएं जब वह current ancestry में मौजूद हो। अगर shell और task command run को महत्वपूर्ण रूप से अलग करते हैं, तो उन्हें expandable path में शामिल करें।

एक आम failure ऐसा दिखता है:

Visual Studio Code
  └─ zsh
      └─ make test-agent
          └─ sh -c ./scripts/bootstrap-agent
              └─ python3 tools/agent.py

Naive implementation zsh देखकर request को «VS Code terminal» कहती है। दूसरी python3 देखकर उसे «Python» कहती है। इनमें से कोई भी reviewer को यह तय करने में मदद नहीं करता कि यह known repository task है या उसी shell से शुरू हुआ कोई मनमाना process।

उपयोगी statement कुछ ऐसा होगा:

Requester: python3 tools/agent.py
Run path: make test-agent > scripts/bootstrap-agent
Launched from: Visual Studio Code integrated terminal

इस label की एक कीमत है: इससे पता चलता है कि request repository-controlled code से आई। ऐसा ही होना चाहिए। अगर reviewer signed editor पर भरोसा करता है लेकिन current checkout पर नहीं, तो card में यह निर्णय लेने की जगह होनी चाहिए।

Terminal escape sequences, environment variables या window title से VS Code ownership का अनुमान न लगाएं। ये inherited, copied या stale हो सकते हैं। Live parentage मजबूत evidence है। IDE द्वारा दिया गया process context ancestry स्थापित होने के बाद display को बेहतर बना सकता है, उसकी जगह नहीं ले सकता।

Standalone terminal context देता है, blanket authority नहीं

iTerm2, Terminal और ऐसे ही apps इंसान को deliberate entry point देते हैं। अगर developer clean terminal खोलता है, agent command type करता है और तुरंत approval prompt पाता है, तो terminal application की पहचान उपयोगी context है। इससे पता चलता है कि run कहां से शुरू हुआ।

फिर भी इससे उस session के हर child को blanket approval नहीं मिलना चाहिए। Shells children बनाने के लिए ही designed हैं और लंबे समय तक खुले tabs अक्सर उस वजह से ज्यादा जीवित रहते हैं जिसके लिए उन्हें खोला गया था। Terminal tab में 9:00 बजे शुरू किया गया command lunch तक worker चला सकता है, इस दौरान cd, branch switch, environment change और तीन असंबंधित commands भी हो सकते हैं।

अंतर स्पष्ट रखें:

Requester: agent-cli --workspace /Users/maya/src/payments
Parent: zsh -l
Interactive origin: signed terminal application
Session started: Tue Jul 21 14:08:31 2026

Interactive origin supporting context है। Session असल process run से संबंधित है। Process exit होते ही session approval revoke करें, भले terminal tab खुला रहे। उसी tab में शुरू किया गया नया agent process नया run है, जिसमें नए arguments और PATH पर संभवतः अलग executable हो सकता है।

यहीं reviewer-recognizable identity कठिन हो जाती है। Terminal app किसी known publisher द्वारा signed हो सकता है, जबकि project directory में installed agent-cli unsigned executable हो। ईमानदार card को दोनों facts बताने चाहिए। Terminal की signature को unsigned child पर इस तरह न चढ़ाएं जैसे terminal ने उसकी गारंटी दी हो।

Shell functions और aliases में भी यही समस्या होती है। agent जैसा दिखने वाला command किसी function में expand हो सकता है जो directory बदलता है, environment file load करता है, package script चलाता है और अंत में दूसरा binary शुरू करता है। Process collector को केवल resulting children दिखेंगे। अगर typed command को optional context के रूप में रखना है, तो उसे shell integration या shell hook से capture करें और user-entered command history के रूप में label करें, process identity के रूप में नहीं।

Scripts और task runners सबसे भ्रामक chains बनाते हैं

Task runners लोकप्रिय हैं क्योंकि वे जटिल local setup को याद रखने योग्य command में बदल देते हैं। यही सुविधा अक्सर उनकी process chains को वास्तविकता से अधिक trustworthy दिखाती है।

एक सामान्य launch देखें:

zsh -l
  └─ just agent
      └─ /bin/sh -cu 'npm run agent -- --mode write'
          └─ npm run agent -- --mode write
              └─ sh -c node ./scripts/launch-agent.js --mode write
                  └─ node ./scripts/launch-agent.js --mode write
                      └─ agent-cli --mode write

हर मध्यवर्ती process का वैध उद्देश्य है। just recipe चुनता है। /bin/sh recipe body को interpret करता है। npm package script चुनकर shell शुरू करता है। Node launch script evaluate करता है। फिर भी इनमें से कोई नाम reviewer को यह नहीं बताता कि protected request किसी known agent run से आई है या उसी runtime का इस्तेमाल करने वाले किसी दूसरे command से।

Audit record से middle layers न हटाएं। Investigation में यही जगह modified package script, अजीब pre या post lifecycle hook, बदला हुआ PATH या किसी दूसरे executable को चुनने वाली repository script दिखा सकती है। Approval display में इन्हें तभी छोटा करें जब immutable event record में पूरी chain सुरक्षित रखी गई हो।

एक समझदार display rule यह है:

1. सबसे पहले requester executable और arguments रखें।
2. Direct launcher दिखाएं जब वह interpretation बदलता हो, जैसे npm run deploy-agent या make migration-bot।
3. पहली recognizable signed ancestor को launch authority बताएं।
4. पूरी observed ancestry event detail में उपलब्ध रखें।

यह rule दो खराब आदतों से बचाता है। पहली, हर wrapper छिपा देना, जिससे modified task अदृश्य हो जाता है। दूसरी, reviewer के request समझने से पहले सात-line tree दिखा देना। जब approval cards पढ़ने योग्य नहीं होते, लोग action नहीं, card के आकार को approve करते हैं।

मैं इस recommendation को स्वीकार नहीं करता: task name इंसानों के लिए आसान है, इसलिए agent के बजाय task runner को approve करें। Task names अक्सर repository text होते हैं। Checkout बदल सकने वाला कोई भी व्यक्ति task के behavior को बदल सकता है। Task name को context की तरह इस्तेमाल करें, लेकिन approval session को observed agent process run से जोड़ें और नया run शुरू होने पर फिर से मूल्यांकन करें।

Signed boundary सावधानी से चुनें

Nearest signed ancestor आमतौर पर सबसे अच्छी recognizable authority होती है, लेकिन «nearest» के लिए judgment चाहिए। Signed system shell या interpreter सीधे unsigned script के ऊपर हो सकता है। उस shell को authority कहने से technically signed label तो मिलता है, लेकिन code किसने दिया, यह पता नहीं चलता।

Apple की code-signing guidance executable के identifier और signing identity में अंतर करती है और code identity स्थापित करने के लिए designated requirement का उपयोग करती है। codesign tool इस requirement को दिखा सकता है। इसका output signed app या helper पहचानने के लिए इस्तेमाल करें, लेकिन अकेले identifier string को publisher relationship का proof न मानें।

Bundled application के लिए ancestry में दिखने वाले executable या app bundle की जांच करें:

codesign --display --verbose=4 --requirements - "/Applications/Example.app" 2>&1 \
  | sed -n '/Identifier=/p;/TeamIdentifier=/p;/Authority=/p;/designated =>/p'

Typical result में ऐसे fields हो सकते हैं:

Identifier=com.example.editor
TeamIdentifier=AB12CDE345
Authority=Developer ID Application: Example Software (AB12CDE345)
designated => anchor apple generic and identifier "com.example.editor" and certificate leaf[subject.OU] = "AB12CDE345"

Exact fields signature और distribution path के अनुसार बदलते हैं। महत्वपूर्ण बात यह है कि जब macOS stable code identity दे सकता हो, तो approval system उसे capture करे और raw evidence छिपाए बिना reviewer-friendly रूप में दिखाए।

Displayed authority चुनते समय ये rules अपनाएं:

• ऐसे signed graphical app या dedicated signed helper को प्राथमिकता दें जो requester ancestry में सचमुच मौजूद हो।
• Unsigned script के बदले generic signed interpreter को authority न बनाएं।
• Executable directory, repository name या shell prompt से authority का अनुमान न लगाएं।
• Unsigned और ad hoc-signed stages को साफ-साफ mark करें, उन्हें recognizable parent के नीचे न छिपाएं।
• अगर कोई recognizable signed authority नहीं है, तो बताएं कि run की verified local publisher identity नहीं है।

Conceptually किसी process से कई signatures जुड़ी हो सकती हैं: app bundle signature, nested helper signature और interpreter signature। उस executable की समीक्षा करें जो process list में वास्तव में दिख रहा है। Signed app अलग signed helper शुरू कर सकता है। Helper user-installed binary शुरू कर सकता है। हर stage अलग identity question है।

कुछ launch chains में confidence कम होना चाहिए

Clean parent-child chain हमेशा उपलब्ध नहीं होती और missing cases कोई मामूली edge detail नहीं हैं। इन्हीं जगहों पर approval systems सबसे गंभीर attribution errors करते हैं।

Remote execution local ancestry तोड़ता है

अगर local agent SSH invoke करता है, तो आपका Mac local SSH client और उसके parents की पहचान कर सकता है। Remote command का process tree दूसरे host पर अलग होता है। जब तक remote machine पर evidence collect और verify न करें, यह न कहें कि remote agent-cli local IDE ने शुरू किया था।

Local approval card फिर भी उपयोगी हो सकता है। उसमें local requester, destination, ज्ञात हो तो remote account और SSH को दिया गया exact command दिखाएं। इससे यह तय किया जा सकता है कि local agent connection शुरू कर सकता है या नहीं। इससे remote process identity स्थापित नहीं होती।

Detached work को नई identity decision चाहिए

Child setsid call कर सकता है, double-fork कर सकता है या supervisor से original launcher के exit होने के बाद काम जारी रखने को कह सकता है। उस बिंदु के बाद केवल terminal या initial shell से जुड़ी approval काल्पनिक हो जाती है। Detached worker को अपना process record, अपना start time और fresh approval scope चाहिए, जब तक reviewers inspect कर सकने वाला deliberately designed supervisor relationship मौजूद न हो।

Environment inheritance tree बदले बिना actor बदल सकती है

वही node path अलग agent package load कर सकता है क्योंकि PATH, NODE_OPTIONS, language-specific module paths, proxy settings या working directory बदल गए हैं। Process ancestry हर inherited value नहीं दिखाती। Investigation के लिए restricted context fingerprint capture करें: executable path, arguments, current directory, redaction के बाद चुने हुए environment names और values, और जरूरत पड़ने पर executable का digest।

पूरे environment को approval card या journal में dump न करें। Environments में tokens, endpoints और personal paths हो सकते हैं। उद्देश्य runs को अलग करना है, logs में दूसरा secret store बनाना नहीं।

Reviewer को छोटा claim और inspectable evidence चाहिए

Approval prompt के पास ध्यान खींचने के लिए कुछ ही seconds होते हैं। सबसे ऊपर decision-relevant claim रखें, फिर reviewer को यह inspect करने का रास्ता दें कि system उस claim तक कैसे पहुंचा।

एक practical card ऐसा हो सकता है:

Agent process requests an HTTP call

Requester
agent-cli --workspace /Users/maya/src/payments
PID 81234, started 14:08:31

Launched through
npm run agent > node scripts/launch-agent.js
from a signed editor process

Destination
api.example.internal / POST /deployments

यह पढ़ने के लिए पर्याप्त compact और चुनौती देने के लिए पर्याप्त specific है। Reviewer workspace गलत होने, task runner अनपेक्षित होने, destination अजीब लगने या request unsigned stage से आने पर reject कर सकता है। Action रोकने के ये वास्तविक कारण हैं।

पूरे evidence को card के पीछे रखें। Requester PID और start time, executable path, arguments, parent chain, चुनी गई authority के signing facts और approval decision सुरक्षित रखें। अगर वही agent approved run में बाद में दूसरी request करता है, तो record साफ बताए कि session decision उस process lifetime पर लागू था, किसी process से अलग floating app name पर नहीं।

Sallyport का per-session authorization इसी practical boundary पर आधारित है: नए agent process की पहली call approval मांगती है और approval केवल उस process के exit होने तक रहती है। इसका approval card process की code-signing authority से शुरू होता है। Reviewer को इससे पहचानने योग्य starting point मिलता है, बिना यह दिखावा किए कि signature हर child command को समझाती है।

Process lifetime के आधार पर revoke करें और exceptions स्पष्ट रखें

Session approval को agent process lifetime का अनुसरण करना चाहिए, क्योंकि request करने वाली unit वही process है। Terminal खुला रहने, IDE window दिखाई देने या task का वही नाम होने के कारण approval reuse करना ऐसा scope बनाता है जिसे कोई ईमानदारी से inspect नहीं कर सकता।

यह rule short-lived wrappers के लिए friction जरूर पैदा करता है। Package manager हर subcommand के लिए नया agent process शुरू कर सकता है। इसे npm के हर future child या terminal के हर process तक approval चुपचाप बढ़ाकर ठीक न करें। तय करें कि workflow को stable signed agent host, स्पष्ट identity वाले longer-lived process या sensitive credential के लिए per-call confirmation में से किसकी जरूरत है।

जब risk launch identity के बजाय हर use में हो, तब per-call approval सही उत्तर है। Production deployment token, sensitive host तक पहुंचने वाली SSH private key या write-capable administrative API हर बार human decision मांग सकते हैं, भले process identity परिचित हो। Process recognition confusion कम करता है। इससे judgment समाप्त नहीं होता।

Implementation test सरल है: approved process को kill करें, वही command फिर शुरू करें और confirm करें कि दूसरे run को अपनी approval चाहिए। फिर उसी terminal tab में अलग command शुरू करें और confirm करें कि वह पहले run का decision inherit नहीं कर सकता। अगर इनमें से कोई test fail होता है, तो system ने actor के बजाय location या label approve किया है।

Reviewer को process identity के बदले terminal name पर भरोसा नहीं करना चाहिए। Chain सुरक्षित रखें, requesting run की पहचान करें, जिस strongest recognizable authority का बचाव कर सकते हैं उसे दिखाएं और missing evidence को दिखाई देने दें। यह broad «trusted IDE» rule से कम आकर्षक है। लेकिन जब task script, shell wrapper या remote hop असली महत्वपूर्ण हिस्सा निकलता है, तभी यह टिकता है।