# Agent binary updates पर भरोसा कब खत्म होना चाहिए?

किसी local agent के लिए दी गई स्वीकृति उसी executable पर लागू होनी चाहिए जिसकी आपने जाँच की थी, उसी process पर जिसे आपने approve किया था और उसी access के लिए जिसे उसने उस समय माँगा था। Executable बदलते ही पुरानी स्वीकृति व्यावहारिक रूप से समाप्त हो जाती है, भले ही उसका filename, bundle identifier और icon वही रहें।

यह नियम तब सख्त नहीं लगता जब आपको ऐसी approval की जाँच करनी पड़े जो version 1.8 को दी गई थी, लेकिन चुपचाप version 1.9 इस्तेमाल कर रहा था। अधिकांश गलत फैसले जरूरत से ज़्यादा व्यापक identity check से शुरू होते हैं: path, product name या परिचित signing Team ID। ये checks कुछ प्रमाण दे सकते हैं। इनमें से कोई भी अकेले code बदलने के बाद privileged trust जारी रखने के लिए पर्याप्त नहीं है।

## Trust देखे गए executable का होना चाहिए

Local agent कोई publisher identity नहीं है। यह एक specific signed program है, जो किसी खास path पर लोड होता है और जिसका parent process, arguments, environment और requested actions निश्चित होते हैं। कोई publisher कई programs जारी कर सकता है। एक ही program releases के बीच बहुत बदल सकता है। स्थिर नाम से इनमें से किसी बात का लगभग कोई पता नहीं चलता।

यह अंतर खास तौर पर तब महत्वपूर्ण है जब agent paid APIs कॉल कर सकता हो, SSH credentials इस्तेमाल कर सकता हो, repository बदल सकता हो या machine के बाहर data भेज सकता हो। Approval vendor के लिए प्रशंसा नहीं है। यह किसी process को परिणाम वाले actions करने की अनुमति है।

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

- File identity disk पर मौजूद signed code और उसके digest की पहचान है।
- Signing identity वह authority है जिसे macOS उस code के लिए report करता है।
- Publisher provenance यह प्रमाण है कि file उस release path से आई है जिसकी आपको उम्मीद थी।
- Runtime identity में वह process और उसके द्वारा माँगा गया access शामिल है जिसने इसे launch किया।

Teams अक्सर इन चारों को एक ही बात मान लेते हैं: «यह हमारा agent है।» इसी तरह उसी pathname पर रखे गए replacement को ऐसा access मिल जाता है जिसे उसने कभी अर्जित नहीं किया। सुरक्षित नियम सरल है: executable का replacement एक नया trust decision शुरू करता है।

Hash replacement का पता लगाता है, लेकिन यह नहीं बताता कि replacement पर किसने हस्ताक्षर किए। Signature signer की पहचान करती है, लेकिन download channel का प्रमाण नहीं देती। साफ़-सुथरा download यह नहीं बताता कि नए version को व्यापक access चाहिए या नहीं। आपको तीनों checks चाहिए, क्योंकि हर check अलग तरह की समस्या पकड़ता है।

उलटी गलती भी न करें और हर byte को हमेशा के लिए pin न कर दें। Builds सामान्य रूप से बदलते हैं, certificates rotate होते हैं और releases को updates चाहिए। मुद्दा permanence नहीं है। मुद्दा यह है कि कोई व्यक्ति बदलाव देखे, समझे कि क्या बदला है और स्पष्ट रूप से तय करे कि माँगा गया authority अब भी उचित है या नहीं।

## Code signing का उत्तर उस सवाल से सीमित है जो अक्सर लोग समझते हैं

macOS code signing operating system को यह जाँचने देता है कि signer द्वारा signature बनाने के बाद signed code बदला नहीं है। Developer ID distribution के लिए Gatekeeper developer identity और item के अपने assessment को भी देखता है। यह उपयोगी evidence है, लेकिन पूरी supply-chain verdict नहीं।

Apple का Technical Note TN2206, «macOS Code Signing In Depth», code identity को उन व्यापक शर्तों से अलग करता है जिनके आधार पर system code स्वीकार करता है। Designated requirements पर इसकी चर्चा यहाँ खास तौर पर उपयोगी है: macOS किसी future version को उसी code identity का हिस्सा मानने के लिए requirement का उपयोग कर सकता है। यह continuity सामान्य app updates में मदद करती है। लेकिन ऐसे agent के लिए, जो money खर्च कर सकता है या private infrastructure इस्तेमाल कर सकता है, इसे अकेली शर्त बनाना बहुत कमजोर है।

Valid signature इन सवालों का जवाब नहीं देती:

- क्या publisher ने इसी exact release को आपकी machine तक पहुँचाने का इरादा किया था?
- क्या किसी compromised publisher release credential ने इस पर हस्ताक्षर किए?
- क्या नए version ने ऐसी capability जोड़ी है जिससे उसका risk बदल गया?
- क्या installer, updater या launch script ने आपके जाँचे हुए हिस्से को बदले बिना कोई component बदल दिया?

Gatekeeper और notarization से macOS द्वारा साफ़ तौर पर untrusted software चलाने की संभावना घटती है। वे validly signed agent को आपकी operational authority रखने के लिए approved नहीं बना देते। Operating-system admission और privileged-action approval को अलग फैसले मानें।

यही बात certificate renewal पर भी लागू होती है। Renewed certificate सामान्य administrative घटना हो सकती है। फिर भी इससे आपके भरोसे के evidence में बदलाव आता है। अगर Team ID, identifier और expected publisher path consistent रहें, तो operator समीक्षा के बाद update approve कर सकता है। अगर signing authority किसी दूसरी organization को चली जाए, तो रुकें और publisher से स्पष्ट explanation लें। केवल इसलिए अचानक identity shift स्वीकार न करें कि app बिना warning के launch हो रहा है।

## Publisher provenance signature से अलग है

Provenance यह पूछती है कि binary आप तक कैसे पहुँची और क्या वह रास्ता publisher की सामान्य release practice से मेल खाता है। Unknown chat attachment से copy की गई file पर signature आपको बताती है कि उस copy पर किसने हस्ताक्षर किए। वह यह नहीं बताती कि file आपको वहाँ क्यों मिली।

Production agent के लिए install या update करते समय छोटा release receipt रखें। यह उस repository में text file हो सकती है जो agent को manage करती है, कोई change record या internal release log की entry हो सकती है। Receipt में version, install source, observed signing authority, Team ID, digest, review date और उसे स्वीकार करने वाले व्यक्ति का नाम दर्ज होना चाहिए। Publisher release digest देता हो, तो उसे भी दर्ज करें।

Release channel की मानवीय sanity check भी करें। क्या updater अपेक्षित application से आया? क्या publisher ने इस version के release notes प्रकाशित किए? क्या archive name, package signature और destination path सामान्य installation method से मेल खाते हैं? नए channel से आया अचानक update उतने ही संदेह के योग्य है जितना अचानक बदला हुआ signer।

Public source repository को release artifact न समझें। Repository source history दिखा सकती है, जबकि release pipeline कोई अलग binary बनाती है। दूसरी ओर, signed binary legitimate हो सकती है, भले ही आप उसका build reproduce न कर सकें। ये अलग assurance levels हैं। एक को दूसरे का प्रमाण बताने के बजाय साफ़ लिखें कि आपके पास कौन-सा level है।

Digest comparison तब मदद करता है जब publisher आपको authenticated checksum देता है। अगर checksum और binary दोनों उसी untrusted page से copy किए गए हों, तो इसका कोई लाभ नहीं। उपयोगी comparison किसी independent publisher-controlled release record, trusted package manager record या पहले से स्थापित internal source से मिलता है।

## Update के साथ requested access की भी समीक्षा करें

Binary update वही signing authority बनाए रख सकता है और फिर भी पुराने release से कम access का हकदार हो सकता है। समीक्षा की वजह सिर्फ malicious code का डर नहीं है। नया behavior पुराने permission को अनुचित बना सकता है।

पूछें कि update के बाद process कौन-सी external actions करेगा। जो agent पहले issue metadata पढ़ता था, वह अब pull requests बना सकता है। जो disposable test token इस्तेमाल करता था, वह अब shared host पर SSH commands चला सकता है। नया plugin, बदला हुआ configuration format या अलग default command, operating system से नया entitlement माँगे बिना process की वास्तविक पहुँच बदल सकता है।

Requested-access review में वास्तविक action boundary शामिल होनी चाहिए:

- Process किन HTTP hosts, account scopes और credential records का उपयोग करेगा?
- वह किन SSH destinations और remote commands तक पहुँच सकता है?
- उसे कौन-सी working directory, repository hooks, arguments और environment variables के साथ launch किया जाता है?
- क्या अब उसे किसी अलग source से input मिलता है, जैसे pull request comment या build log?
- क्या वह किसी ऐसे local executable को चला सकता है जो पिछली review का हिस्सा नहीं था?

यहीं broad standing approval विफल होती है। «इस agent को अनुमति दें» जैसे फैसले उस हिस्से को छिपा देते हैं जो महत्वपूर्ण है: इसे क्या करने की अनुमति है, किसके credential के साथ और किस input के जवाब में?

Agent processes के लिए input provenance पर भी उतना ही ध्यान दें। अगर update coding agent को untrusted issue text पर कार्रवाई करने देता है, तो सामान्य repository access prompt injection का रास्ता बन सकता है। Code signing उन instructions की जाँच नहीं करती जिन्हें process प्राप्त करता है। वह केवल उस program को cover करती है जो instructions को समझता है।

Approval screens और internal records को concrete रखें। Process authority, destination, credential class और यह नाम से लिखें कि action remote state बदलती है या नहीं। «Agent requests access» जैसे alert से operator sound decision नहीं ले सकता।

## नए code के act करने से पहले पुराना session समाप्त करें

सबसे साफ़ नियम यह है कि approval को एक running process से बाँधें और process exit होते ही समाप्त कर दें। Replacement binary नया process बनाती है, इसलिए उसे नया approval मिलता है। इससे यह तय करने की मुश्किल और नाज़ुक कोशिश बचती है कि कौन-सा package update पिछली grant को inherit करने के लिए पर्याप्त छोटा है।

किसी process को खुद को in place update करने और replacement से पहले मिला authorization जारी रखने न दें। कुछ updaters ठीक यही करते हैं: पुराना process archive download करता है, पुराने path पर नया executable लिखता है, फिर helper launch करता है या खुद को reexecutes करता है। अगर authorization layer केवल pathname या long-lived client record जाँचती है, तो नया code पुराने decision के तहत चलता रहता है।

एक practical decision record ऐसा दिख सकता है:

```text
process path: /Users/dev/tools/agent/bin/agent
observed digest: 8a4b...e19c
identifier: dev.example.agent
TeamIdentifier: A1B2C3D4E5
parent: interactive shell in approved repository
requested actions: issue API read, test-host SSH command
approval scope: this process only
expires: process exit
```

Digest को permanent allowlist entry न मानें। इसे इसलिए record करें ताकि आप पहचान सकें कि अगली approval अलग code से संबंधित है। Update के बाद process restart होने पर fresh observation की तुलना पिछली observation से करें और operator को महत्वपूर्ण differences दिखाएँ।

Same-version restart में भी review की ज़रूरत हो सकती है, अगर उसका launch context बदल गया हो। Checked-out repository में interactive shell से launch किया गया binary उस binary के बराबर नहीं है जिसे बड़े environment वाले build job ने unattended तरीके से launch किया हो। Executable subject का एक हिस्सा है। Process context उसे पूरा करता है।

## Replacement approve करने से पहले macOS evidence देखें

Privileged call करने देने से पहले आप built-in macOS tools से candidate executable की जाँच कर सकते हैं। Commands उसी executable पर चलाएँ जो launch होगा, न कि Downloads में रखी उसी नाम वाली किसी copy पर और न ही उस outer application bundle पर जिसके अंदर उसके होने का आप अनुमान लगा रहे हैं।

```sh
codesign -d -vvv /Users/dev/tools/agent/bin/agent 2>&1
spctl -a -t exec -vv /Users/dev/tools/agent/bin/agent
shasum -a 256 /Users/dev/tools/agent/bin/agent
```

Typical `codesign` output में इस तरह के fields होते हैं:

```text
Identifier=dev.example.agent
Authority=Developer ID Application: Example Publisher (A1B2C3D4E5)
TeamIdentifier=A1B2C3D4E5
CDHash=8a4b9c0d...
```

`spctl` अपना assessment report करता है और accepted Developer ID software के लिए आम तौर पर origin भी report करता है। `shasum` पूरा SHA-256 digest और उसके बाद pathname छापता है। Relevant output को release receipt के साथ सहेजें। Exact wording macOS release के अनुसार बदल सकती है, इसलिए whitespace या field order के बजाय identity fields और assessment की तुलना करें।

Bundled application के लिए nested code की भी जाँच करें। Signed outer bundle में helpers, frameworks या command-line tools हो सकते हैं। अगर agent किसी helper को सीधे launch करता है, तो उसी helper की सीधे जाँच करें। जो file access माँगती है, decision को उसी file की identity से बाँधना चाहिए।

Successful `codesign` verification का मतलब यह नहीं है कि executable notarized है या आपके उपयोग के लिए उपयुक्त है। इसका मतलब केवल यह है कि command के verification rules के अनुसार signature की जाँच सफल हुई। Incident notes में यह अंतर बनाए रखना उपयोगी है। वरना बाद में कोई «signature valid» पढ़कर उसे «release reviewed and approved» समझ सकता है, जबकि वह बहुत बड़ा दावा है।

## Stable path गलत code को approve करने का आसान तरीका है

मान लें कि `/Users/dev/bin/agent` पर एक local wrapper है। Developer इसे एक बार approve करता है क्योंकि यह read-only project API कॉल करता है। बाद में wrapper automatic update चलाता है, नया helper download करता है और वही path बनाए रखता है। Approval component path पहचानकर नए helper को पुरानी grant दे देता है।

इस sequence में malicious attacker की कोई ज़रूरत नहीं है। Release genuine हो सकती है। समस्या यह है कि approval record कहता है «path equals allowed path», जबकि वास्तविक decision पुराने program के बारे में था जिसका behavior सीमित था।

Wrapper खुद script हो तो समस्या और बढ़ जाती है। Shell scripts अक्सर stable symlink के नीचे versioned binaries चलाती हैं, writable directory से configuration पढ़ती हैं या `PATH` से helper चुनती हैं। अगर wrapper check के बाद execution को redirect कर सकता है, तो wrapper पर signature check final executable के बारे में बहुत कम बताती है।

Operations का क्रम ठीक करें। Final executable resolve करें। उसकी signature और digest inspect करें। Parent process और arguments capture करें। फिर उस running process को authorize करें। अगर launcher approval के बाद किसी दूसरे executable को replace या select कर सकता है, तो action gateway को connection time पर देखे गए process से बाँधें और mismatch होने पर उसे reject करें।

लोकप्रिय विकल्प यह है कि उसी Team ID से signed किसी भी update को automatic inheritance दे दी जाए। Teams यह इसलिए चुनती हैं क्योंकि prompts developers को परेशान करते हैं और release certificates आम तौर पर स्थिर रहते हैं। Privileged agents के लिए यह गलत है, क्योंकि यह publisher credential को हर future behavior के लिए blank check बना देता है। Prompt fatigue को session-scoped approval, सीमित access और स्पष्ट update notices से कम करें, updates को अदृश्य बनाकर नहीं।

## Publisher बदलने पर स्पष्ट migration record चाहिए

Signing authority में बदलाव legitimate हो सकता है। Companies products acquire करती हैं, अलग Developer ID account पर जाती हैं या पुरानी distribution process बदलती हैं। इन घटनाओं को routine update नहीं, migration मानें।

ऐसा explicit record रखें जिसमें prior identity, new identity, बदलाव वाला version और उसे स्वीकार करने के लिए इस्तेमाल किए गए evidence लिखे हों। अच्छे evidence में publisher के स्थापित release channel में signed announcement, expected repository में matching release notes और सामान्य delivery path से प्राप्त package शामिल हैं। बिना explanation वाला popup evidence नहीं है।

बदली हुई Team ID को default रूप से deny करें, जब तक कोई migration की review न कर ले। उसी Team ID के तहत certificate बदलने पर सामान्य provenance और access review के बाद fresh approval दी जा सकती है। उसी certificate के साथ digest बदलने पर भी fresh approval चाहिए, क्योंकि code नया है, भले ही बाकी सभी fields match करते हों।

«इस app name के लिए सभी future identities स्वीकार करें» जैसा broad exception न दें। इससे one-time migration स्थायी security hole बन जाती है। New identity को तभी store करें जब reviewer ने किसी particular release को accept किया हो। अगला बदलाव फिर वही review trigger करे।

अगर आपकी team internal agents distribute करती है, तो expected signing identity, release digest और update procedure ऐसी जगह प्रकाशित करें जहाँ operators उन्हें agent पर निर्भर हुए बिना ढूँढ सकें। जब replacement ही review का subject हो, तब agent अपने replacement की विश्वसनीय पुष्टि नहीं कर सकता।

## छोटी approval protocol बड़ी exception list से बेहतर है

Update decisions को predictable बनाने के लिए आपको complicated rules engine की ज़रूरत नहीं है। एक छोटा protocol चाहिए जो executable बदलने पर हर बार लागू हो।

1. पुराने process को रोकें और उसका active session revoke करें।
2. उस final executable को resolve करें जो connect या act करेगा।
3. उसके digest, identifier, signing authority और Team ID की तुलना पिछले release receipt से करें।
4. Expected release channel जाँचें और identity में किसी भी बदलाव का कारण दर्ज करें।
5. Requested destinations और credentials की review करें, फिर नए process session को approve करें या deny करें।

यह protocol सामान्य maintenance update और वास्तविक anomaly को अलग करता है। सामान्य release provenance के साथ नया digest और वही authority review event है, emergency नहीं। अपरिचित authority, unexpected installer और production SSH credential की माँग rollout रोकने और जाँच शुरू करने का कारण हैं।

Sallyport का session authorization process boundary को स्पष्ट कर सकता है, क्योंकि यह agent process की पहचान करके उसके run की अनुमति देता है। इसका per-call approval setting sensitive credentials को और कड़े decision के पीछे रख सकता है। इससे updated agent को inspect करने की ज़रूरत खत्म नहीं होती, लेकिन पुराना run चुपचाप बाद वाले run को अपनी approval देने से रुकता है।

Record इतना छोटा रखें कि लोग उसे maintain करते रहें। उपयोगी evidence है: देखी गई file, उसका signer, उसका source, उसका launch context और approved actions। इनमें से कोई भी चीज़ release में बदले, तो risk के owner को agent के act करने से पहले वह बदलाव दिखाएँ।

## Audit records में actor और publisher अलग दिखने चाहिए

केवल «agent used credential» कहने वाला audit trail post-incident review को बेवजह कठिन बना देता है। Record करें कि request किस process ने की, macOS ने कौन-सी signing authority report की, किस session ने उसे authorize किया और वास्तव में कौन-सी action हुई। Publisher identity बताती है कि code पर किसने हस्ताक्षर किए। Process record बताता है कि कार्रवाई किसने की।

जब agent run गलत हो जाए, तब यह अंतर महत्वपूर्ण होता है। आपको पता लगाना होता है कि क्या नए release ने behavior बदला, क्या पुराना binary unexpected location से चला, क्या किसी व्यक्ति ने अपनी समझ से अलग access request approve की या untrusted input ने अपेक्षित process को निर्देशित किया। अकेला publisher field इन सवालों का जवाब नहीं दे सकता।

Integrity को readability से अलग रखें। Tamper-evident record यह बता सकता है कि पुराने entries बदले गए हैं या नहीं। वह घटना के बाद missing facts पैदा नहीं कर सकता। Approval के समय executable digest और decision context capture करें, जब आप उन्हें अभी भी देख सकते हैं।

Sallyport अपने Sessions और Activity journals को एक encrypted, hash-chained audit log से project करता है और `sp audit verify` ciphertext पर उस chain को offline जाँच सकता है। ऐसे evidence का उपयोग record verify करने के लिए करें, फिर उसे ऐसे release receipt के साथ जोड़ें जो समझाता हो कि executable को access क्यों दिया गया था।

सबसे पहला operational बदलाव जो मैं करूँगा, वह है किसी path, display name या publisher से match होने वाली approval rule हटाना। उसकी जगह current process के लिए approval दें, process exit पर उसे expire करें और binary replacement के बाद fresh decision ज़रूरी बनाएं। यही एक boundary उस update path को पकड़ लेती है जिसे broad allowlists अक्सर नहीं पकड़ पातीं।