Unsigned local builds को approval कैसे मिलनी चाहिए?

Unsigned local build अपने-आप संदिग्ध नहीं होता। लेकिन उससे कोई पहचानी हुई identity भी नहीं मिलती। इन दोनों बातों को साथ समझना ज़रूरी है, वरना approval flow दो खराब आदतों में बदल जाता है: developers काम चलाने के लिए हर anonymous process को मंज़ूरी देने लगते हैं, या agents को direct credentials के साथ चलाते हैं।

सही सवाल थोड़ा सीमित है: locally compiled agent के इस खास run को मंज़ूर करने के लिए कौन-सा evidence पर्याप्त है, बिना यह मान लिए कि परिचित folder से आने वाला हर process समान trust का हकदार है? इसका उत्तर session boundaries, launch provenance, credential scope और ऐसे requests को नकारने वाली workflow में है जो अपना कारण स्पष्ट नहीं कर सकते।

Unsigned होना risk rating नहीं, missing claim है

Unsigned code ने certificate chain से verify की जा सकने वाली publisher-backed identity claim नहीं की है। इससे अपने-आप यह पता नहीं चलता कि code malicious है, reviewed है, locally modified है या आपके खुले repository से अभी बनाया गया है। इससे केवल एक तरह का evidence हटता है।

Teams दोनों दिशाओं में गलती करती हैं। एक समूह हर unsigned executable को hostile मानता है, जिससे सामान्य development side channels और personal API keys की ओर चला जाता है। दूसरा समूह unsigned को «मेरा local code» का संक्षिप्त रूप मानता है, जिससे ऐसा broad approval category बनता है जिसका कोई असंबंधित process फायदा उठा सकता है।

इन distinctions को अलग रखें:

• Publisher identity बताती है कि distributed build पर किसने sign किया।
• Build provenance बताती है कि executable किस source, revision, machine और command से बना।
• Runtime provenance बताती है कि access माँगने वाले process को अभी किसने launch किया।
• Action authority बताती है कि वह process कौन-सा credential या remote access इस्तेमाल कर सकता है।

Signature पहले सवाल में मदद कर सकता है। साफ़ local workflow को बाकी तीन सवालों का उत्तर देना होगा। Developer जब worktree से agent client compile करता है, तो उसका भरोसा आम तौर पर repository state और अभी चलाए गए command से आता है, public certificate से नहीं। Approval experience को यह evidence दिखाना चाहिए, certificate न होने को verdict नहीं बनाना चाहिए।

Apple का code-signing documentation भी यही सीमा स्पष्ट करता है। Designated requirement उस policy के तहत signed code के एक instance की पहचान करती है जो उसे जाँचती है; यह साबित नहीं करती कि code हर resource या भविष्य के हर action के लिए उपयुक्त है। Apple यह भी कहता है कि macOS का हर subsystem अपनी trust policy लागू करता है। इसलिए action gateway को code-signing status को universal permission decision नहीं बनाना चाहिए।

Local-build lane को ऐसा evidence चाहिए जिसे दूसरा process उधार न ले सके

Locally compiled agent clients के लिए अलग approval lane रखें। उन्हें «unsigned», «development» या «terminal» नाम वाले bucket में न डालें। ये labels इतने processes का वर्णन करते हैं कि उपयोगी नहीं रहते।

Developer के session approve करने से पहले lane को चार बातें दिखानी चाहिए:

1. Executable path developer के नियंत्रण वाले checkout या build output directory के अंदर हो।
2. Parent process अपेक्षित launcher हो, आम तौर पर terminal, IDE task या team के नियंत्रण वाली wrapper script।
3. Repository state और build command को याददाश्त के सहारे दिन दोबारा बनाए बिना जाँचा जा सके।
4. Requested destination और credential चल रहे काम से मेल खाते हों।

इनमें से कोई signal अकेला perfect नहीं है। साथ में ये किसी random download, background helper या compromised dependency के लिए routine local run का रूप लेना कठिन बना देते हैं।

यहीं teams अक्सर policy engine का सहारा लेती हैं: किसी directory के नीचे के paths allow करना, agent से शुरू होने वाले commands की अनुमति देना या किसी खास IDE से launch हुए हर process को exempt करना। ऐसा न करें। Static rule आकर्षक लगता है क्योंकि interruptions कम हो जाते हैं, लेकिन आसान निर्णय को लंबे समय के exception में बदल देता है। जो process सही path या parent chain बना सके, उसे exception मिल जाता है।

इसके बजाय session boundary पर human approval लें। Approval card में code-signing authority हो तो वह दिखाएँ, लेकिन unsigned build के लिए उसके साथ executable path, parent command, working directory और target भी दिखाएँ। तब developer असली सवाल का जवाब दे सकता है: «क्या यह वही client है जिसे मैंने इस task के लिए अभी बनाया है?»

Sallyport का per-session authorization इस lane के लिए उपयुक्त है, क्योंकि वह नए agent process के लिए एक बार पूछता है और process exit होने तक approval रखता है। Decision unit unsigned software की अस्पष्ट category नहीं, process identity है।

परिचित pathname identity नहीं, evidence है

~/src/agent-client/dist/agent जैसा path भरोसा दिलाता है, क्योंकि वह एक plausible कहानी बताता है। लेकिन यह identity boundary नहीं है। कोई malicious process वहाँ से चल सकता है, यदि वह वहाँ लिख सकता हो, output बदल सकता हो, symlink बदल सकता हो या launcher को अलग executable resolve करने के लिए मजबूर कर सकता हो।

पहले legitimate story को सरल और दोहराने योग्य बनाएं। हर developer का सामान्य checkout location हो। Build output checkout के अंदर या ऐसी predictable directory में रहे जिसमें केवल developer का account लिख सके। Shared build directories, Downloads, temporary directories, synced folders और ऐसे project roots से बचें जहाँ package scripts executables को बार-बार rewrite करती हों।

एक practical launch contract इतना छोटा हो सकता है:

#!/bin/zsh
set -eu

repo="$HOME/src/agent-client"
cd "$repo"

git status --short
git rev-parse --short HEAD
exec ./build/agent-client --mcp

महत्वपूर्ण हिस्सा shell syntax नहीं है। यह पीछे कौन-सा evidence छोड़ता है, वह महत्वपूर्ण है। Parent shell की script path ज्ञात है, working directory checkout की ओर इशारा करती है, client शुरू होने से पहले Git revision print होता है और exec shell को intended program से replace करता है, जिससे confusing process chain नहीं बचती।

इस script को release download करने, environment variable से branch चुनने, package manager hook चलाने या checkout के बाहर की mutable configuration file पढ़ने न दें। ऐसी सुविधाएँ launch contract को कम उपयोगी बनाती हैं, क्योंकि reviewer यह नहीं बता पाता कि script ने वास्तव में क्या चुना।

यदि agent client को generated code चाहिए, तो उसे explicit build command का हिस्सा बनाएं। Local configuration file चाहिए तो उसका path साफ़ तौर पर दें और उसे repository से बाहर केवल तब रखें जब उसमें machine-specific settings हों। Credentials उसमें न छिपाएँ। Gateway का उद्देश्य ही यह है कि client को credentials की ज़रूरत न पड़े।

Session approve करने से पहले process inspect करें

अच्छा approval decision कुछ seconds लेता है, लेकिन याददाश्त पर निर्भर नहीं होना चाहिए। जब नया local process API call या SSH खोलने की माँग करे, approve करने से पहले उसका executable और parent chain देखें।

macOS पर ये commands उपयोगी first pass देती हैं। Sample PID को process viewer या terminal में दिख रहे PID से बदलें:

pid=48271

ps -o pid=,ppid=,user=,lstart=,command= -p "$pid"
ps -o pid=,ppid=,command= -p "$(ps -o ppid= -p "$pid" | tr -d ' ')"
lsof -a -p "$pid" -d cwd -Fn

Output कुछ ऐसा दिखना चाहिए:

48271 47990 alex Tue Jul 22 10:14:03 2026 /Users/alex/src/agent-client/build/agent-client --mcp
47990 23112 /bin/zsh /Users/alex/src/agent-client/scripts/run-local-agent
n/Users/alex/src/agent-client

आप trivia इकट्ठी नहीं कर रहे, chain जाँच रहे हैं। Binary अपेक्षित build location में होना चाहिए। Parent आपका ज्ञात launcher होना चाहिए। Current directory checkout से मेल खानी चाहिए। /private/var/folders, ~/Downloads, अपरिचित package cache या अनपेक्षित wrapper से आया process review में fail है, भले ही उसका command name सही दिखे।

फिर executable inspect करें:

client="$HOME/src/agent-client/build/agent-client"
file "$client"
codesign --display --verbose=4 "$client" 2>&1 | sed -n '1,18p'
shasum -a 256 "$client"

Unsigned binary पर codesign बता सकता है कि वह signed ही नहीं है। Ad hoc signed binary signature दिखाता है, लेकिन public signing authority नहीं। यह उपयोगी जानकारी है, पर इसे team identity न समझें। Apple ad hoc signing को «Sign to Run Locally» कहता है और बताता है कि इसकी designated requirement उसी code version से जुड़ी है। Rebuild evidence बदल देता है, इसलिए session approval process replacement के बाद बची नहीं रहनी चाहिए।

Hash comparison tool है, trust signal नहीं। दो developers को यह तय करने में मदद मिल सकती है कि उन्होंने उसी revision से बना वही output चलाया। 64 hexadecimal characters होने से binary सुरक्षित नहीं हो जाती।

यदि chain का कोई हिस्सा चौंकाने वाला हो तो developer को request deny करनी चाहिए। API call होने के बाद जाँच करने के लिए पहले approve न करें। Approval वह क्षण है जब uncertainty की कीमत कुछ minutes होनी चाहिए, incident review नहीं।

एक build और अगले build के बीच boundary के रूप में session इस्तेमाल करें

Session boundary उस समस्या को हल करती है जिसे path allowlists हल नहीं कर सकतीं: local code लगातार बदलता रहता है। Developer एक घंटे में client को दस बार rebuild कर सकता है। हर output का dependency graph, command handling या temporary debug branch अलग हो सकता है जो requests को अप्रत्याशित जगह भेजे।

Launch process को disposable रखें। एक task के लिए agent client शुरू करें, review के बाद उस process को approve करें और exit होते ही approval समाप्त होने दें। Developer rebuild करे, branch बदले, wrapper बदले या client restart करे तो नया process और नया approval decision मिले।

यह तभी असुविधाजनक लगता है जब session ठीक से define न हो। यदि agent client हर individual tool call पर start और stop होता है, तो client lifecycle ठीक करें या ऐसा purposeful local supervisor इस्तेमाल करें जो process tree में साफ़ दिखाई दे। Approval permanent बनाकर churn हल न करें। Short-lived process short-lived ही होना चाहिए।

Test environment के विरुद्ध locally compiled coding agent चलाने वाले developer के लिए यह workflow उपयोगी है:

1. Checkout से build करें और revision तथा uncommitted changes print करें।
2. Checked-in wrapper script से launch करें।
3. पहली authorization request पर displayed process path, parent command और target service confirm करें।
4. Details task से मेल खाएँ तो session approve करें।
5. Task खत्म होने पर client exit करें, फिर अगले अलग task के लिए rebuild या relaunch करें।

इस workflow से साफ़ recovery path मिलता है। Build संदिग्ध लगे तो उसे रोक दें। कोई hidden allowance नहीं जिसे बाद में समझना पड़े और कोई ऐसी rules file नहीं जिसमें चुपचाप exceptions जुड़ते गए हों।

Session approval को repository approval न समझें। Repository clean हो सकती है, launch command गलत हो सकता है। Launch command सही हो सकता है, branch experimental हो सकती है। Session decision केवल यह कहता है कि इस context वाला यह process current run में ordinary calls कर सकता है।

ऐसे consequences के लिए per-call approval रखें जिन्हें वापस नहीं लिया जा सकता

Repeatable development traffic के लिए session approval अच्छा default है: issue metadata पढ़ना, sandbox API query करना, SSH से repository fetch करना या disposable test record update करना। हर call पर human gesture माँगने से लोग बिना पढ़े approve करना सीख जाते हैं।

कुछ credentials के हर इस्तेमाल पर approval फिर भी ज़रूरी होना चाहिए। Secret की sensitivity के बजाय remote action के consequence के आधार पर निर्णय लें।

इन credentials के लिए per-call approval रखें:

• production environment में write कर सकने वाले;
• package, release या deployment artifact publish कर सकने वाले;
• customer data export या किसी concentrated sensitive dataset तक पहुँचने वाले;
• organization membership, authentication settings या recovery controls बदल सकने वाले;
• production SSH host तक पहुँचने वाले।

हर development API token को ऐसा न बनाएं। इससे approval fatigue पैदा होती है और careful reviewer button operator बन जाता है। Gate को dangerous moments इतना अलग दिखाना चाहिए कि लोग उन्हें notice करें।

Request detail second prompt जितनी ही महत्वपूर्ण है। HTTP के लिए method और destination दिखाएँ, फिर path का उतना हिस्सा दिखाएँ जिससे action पहचाना जा सके, लेकिन sensitive request content approval surface में न डालें। GET /v1/test-runs/123 और DELETE /v1/projects/123 कभी interchangeable नहीं दिखने चाहिए। SSH के लिए host और account दिखाएँ और developer से confirm कराएँ कि वह host current task से क्यों जुड़ा है।

Per-call requirement locally modified client पर भी उपयोगी brake है। Staging service से पढ़ने वाले नए experimental build के session को approve करना आपको ठीक लग सकता है। फिर भी उसी build को production release publish करने देने से पहले रुकना चाहिए। यही रुकना उद्देश्य है।

Rebuilds, branch switches और wrappers को नया evidence मानें

Developers अक्सर सुबह एक approval decision लेते हैं और दिनभर facts बदलते रहते हैं। वे branch pull करते हैं, code generator चलाते हैं, dependencies update करते हैं, prompt file बदलते हैं, shell alias जोड़ते हैं या wrapper script बदलते हैं। Binary का नाम और path वही रह सकता है, जबकि behavior काफी बदल जाए।

सरल rule अपनाएँ: executable, launcher या intended environment बदले तो session समाप्त करके relaunch करें। हर edit के लिए formal ceremony ज़रूरी नहीं। ज़रूरी यह है कि कल का context नई build के साथ carry न हो।

आपकी workflow में इन तीन घटनाओं पर automatic pause होना चाहिए:

• Branch, commit, dependency lockfile या generated output बदला हो।
• Client शुरू करने वाली script या उसके behavior को प्रभावित करने वाले environment variables बदले हों।
• Agent अब अलग API host, अलग SSH host या अधिक गंभीर consequences वाले credential की माँग कर रहा हो।

Branch switch को कम आँका जाता है क्योंकि binary name स्थिर रहता है। लेकिन feature branch में experimental integration, बदला हुआ tool manifest या debugging endpoint हो सकता है। Branches पर रोक लगाने के बजाय नई run की पहली request को visible और reviewable बनाएं।

Environment variables भी executable arguments जितनी ही सावधानी माँगते हैं। API_BASE_URL, SSH_AUTH_SOCK, PATH, DYLD_* या custom configuration location के साथ शुरू किया गया client आपके inspect किए source से अलग व्यवहार कर सकता है। Wrapper को केवल आवश्यक variables सेट करने चाहिए, routing को प्रभावित करने वाले non-secret values print करने चाहिए और sprawling shell profile source करने के बजाय missing values पर fail होना चाहिए।

उदाहरण के लिए यह reviewable है:

export AGENT_ENVIRONMENT=staging
export AGENT_API_ORIGIN=https://staging.example.internal
exec ./build/agent-client --mcp

यह reviewable नहीं है:

source "$HOME/.agent-env"
eval "$(tooling configure-agent)"
exec "$AGENT_BIN" "$@"

दूसरा रूप सुविधाजनक हो सकता है, लेकिन executable, configuration source, arguments और side effects छिपाता है। Process approve करने वाले व्यक्ति को indirection के ढेर पर भरोसा करना पड़ता है। Local development में पहले ही पर्याप्त moving parts हैं।

Client आपका अपना हो, फिर भी credentials उससे बाहर रखें

Locally compiled client पर भरोसा करना आसान है जब उसे इस्तेमाल करने वाला credential कभी मिले ही नहीं। यदि client environment variable से API token या file से SSH key पढ़ता है, तो वह उसे print, forward, cache या crash report में शामिल कर सकता है, अथवा subprocess को दे सकता है। अपने build पर developer का भरोसा इस exposure को नहीं बदलता।

Secret action gateway में रखें और client को reference के आधार पर action माँगने दें। Client वह HTTP request या SSH command context दे जिसे काम करने के लिए ज़रूरी है। Gateway credential inject करे, call चलाए और result लौटाए। इससे approval action पर केंद्रित रहता है, इस पर नहीं कि client indefinite bearer token अपने पास रख सकता है या नहीं।

HTTP के लिए अलग environments और purposes के लिए अलग credentials रखें। Staging token को केवल इसलिए production की ओर route नहीं होना चाहिए कि client ने अलग host दिया है। SSH के लिए अलग roles के लिए अलग host entries या credential records रखें। एक all-powerful key और सही target चुनने के human promise पर निर्भर न रहें।

Sallyport API और SSH credentials को encrypted vault में रखता है और action खुद चलाता है, इसलिए agent को plaintext secrets के बजाय results मिलते हैं। Local builds में यह separation खास तौर पर महत्वपूर्ण है, क्योंकि source changes अपेक्षित होते हैं और leaked environment variable से debugging print तक की दूरी बहुत कम होती है।

यह incident response भी बेहतर बनाता है। Client अजीब व्यवहार करे तो उसके session को रोक या revoke किया जा सकता है, बिना हर उस secret को rotate किए जिसे उसने memory में लोड किया हो। Vault locked होने पर gate absolute रहता है और developer intent का अनुमान लगाने के बजाय actions deny करता है।

Audit trail को असहमति दूर करनी चाहिए, केवल events जमा नहीं करने चाहिए

जब local-build approval flow ठीक काम करता है, लोग कभी पूछेंगे कि agent ने service access क्यों की या handoff के बाद process चल रहा था या नहीं। उत्तर guesses, terminal history या बाद में लिखे chat message से नहीं, event trail से मिलना चाहिए।

एक ही underlying activity के दो views record करें। एक agent runs दिखाए और तत्काल revocation support करे। दूसरा individual HTTP और SSH actions दिखाए। Evidence को इस तरह जोड़ें कि reviewer suspicious request से उसे authorize करने वाले session और फिर decision का कारण बने process context तक पहुँच सके।

यहाँ tamper-evident log खास उपयोगी है, क्योंकि local builds को वही लोग बदल सकते हैं जो उनकी समीक्षा कर रहे हैं। Sallyport के Sessions और Activity journals एक encrypted, hash-chained audit log से project होते हैं, और sp audit verify vault key के बिना ciphertext पर offline chain जाँचता है। इससे team secrets तक access दिए बिना integrity check कर सकती है।

Review या incident drill के हिस्से के रूप में verification चलाएँ:

sp audit verify

Expected outcome स्पष्ट success या chain problem बताने वाली report है। जब तक कारण समझ न आए, verification failure को operational issue मानें। Journal delete न करें, app reinstall न करें और affected records सुरक्षित किए बिना fresh baseline स्वीकार न करें।

Journal approval-time review का विकल्प नहीं है। यह जाँचने का तरीका है कि आपकी process ऐसा evidence बना रही है या नहीं जिसका सचमुच उपयोग हो सके। यदि log केवल यह कहता है कि «एक unsigned client» ने call की, तो launch contract और approval context सुधारें। यदि उसमें process, session, destination, time और action दिखते हैं, तो team हर developer machine को forensic project बनाए बिना जाँच कर सकती है।

Team conventions approval prompts को background noise बनने से रोकती हैं

Local-build approval workflow का सबसे कठिन हिस्सा command line नहीं है। कठिनाई यह है कि महीनों के सामान्य काम के बाद भी approval का human meaning बना रहे।

एक छोटी local-agent convention लिखें और उसे repository के पास रखें, security handbook में न दबाएँ। इसमें supported checkouts का स्थान, launcher scripts का रूप, ordinary development माने जाने वाले environments, per-call approval वाले credentials और unexpected process दिखने पर developer की कार्रवाई स्पष्ट होनी चाहिए।

Deny path को सामान्य बनाएं। Parent process अजीब दिखने पर deny करने वाले developer को यह महसूस नहीं होना चाहिए कि उसने progress रोक दी। उसे process रोकना, जाँच करना, known wrapper से relaunch करना और साफ़ run approve करना चाहिए। Mystery process को normal मानकर बाद में समझाने से यह तेज़ है।

किसी वास्तविक surprise के बाद convention की समीक्षा करें: package script ने output rewrite किया हो, IDE ने अनपेक्षित helper launch किया हो, branch गलत environment की ओर इशारा कर रही हो या agent ने task से बाहर का credential माँगा हो। ऐसी failures बताती हैं कि कौन-सा evidence missing था। Permanent allow rule जोड़कर प्रतिक्रिया न दें। Launch contract कड़ा करें, approval surface में बेहतर context दिखाएँ या credential का scope छोटा करें।

जो developer अपना agent compile करता है, उसे security theater और लगातार interruptions में से किसी एक को चुनना नहीं चाहिए। उसे visible process के लिए specific session approval दें, consequential calls को अलग decision के पीछे रखें और local build story बदलने पर fresh review ज़रूरी करें। यह गलत process पकड़ने जितना strict और इतना practical है कि लोग इसे इस्तेमाल करते रहें।