क्या AI agents के लिए script approval किसी signed interpreter पर भरोसा कर सकता है?

हस्ताक्षरित इंटरप्रेटर यह साबित नहीं करता कि आपने कौन-सी स्क्रिप्ट मंजूर की थी। वह इससे छोटी-सी बात साबित करता है: operating system ने एक खास इंटरप्रेटर बाइनरी शुरू की, जिसके हस्ताक्षर की वह जांच कर सका। इसके बाद इंटरप्रेटर कई बदल सकने वाली फाइलें पढ़ सकता है, command string से source ले सकता है, package resolver के जरिए code लोड कर सकता है और ऐसे credentials के साथ काम कर सकता है जो स्क्रिप्ट के पास खुद कभी नहीं थे।

यह फर्क तब छिप जाता है जब approval card पर «Python» या «Node» लिखा हो और साथ में भरोसा जगाने वाला signing badge दिखे। मैंने reviewers को उस prompt को मंजूर करते देखा है क्योंकि binary का नाम जाना-पहचाना था। फिर दोपहर का बाकी समय यह पता लगाने में निकलता है कि code वास्तव में किस repository checkout, symlink, environment setting या package preload से आया था। परिचित executables को executables के अनुरूप ही भरोसा मिलना चाहिए। इससे arbitrary source भरोसेमंद नहीं बन जाता।

हस्ताक्षरित इंटरप्रेटर केवल इंटरप्रेटर की पहचान करता है

Code signing किसी executable file के provenance से जुड़ा सवाल हल करता है। macOS पर codesign tooling executable के signature और designated requirement की जांच कर सकती है। Gatekeeper और platform की runtime protections software का आकलन करते समय इससे जुड़ी जानकारी का इस्तेमाल करती हैं। इनमें से कोई भी mechanism यह नहीं कहता कि command line पर दी गई Python file उसी developer से आई है, review के बाद बदली नहीं है, या उसके imports सुरक्षित हैं।

इन दो invocations पर ध्यान दें:

/usr/bin/python3 /Users/dev/work/release/publish.py
/usr/bin/python3 -c "import os; os.system('curl ...')"

दोनों मामलों में interpreter identity एक जैसी हो सकती है। Source identity पूरी तरह अलग है। पहली call में ऐसा path है जो reviewer को code ढूंढने में मदद कर सकता है। दूसरी में कोई script file ही नहीं है। अगर prompt दोनों में से किसी call को «signed Python requests network access» तक सीमित कर देता है, तो वह वही हिस्सा हटा देता है जिसे किसी व्यक्ति को निर्णय लेने के लिए देखना जरूरी है।

Python documentation file चलाने, -c से command execute करने, -m से module चलाने और standard input से source पढ़ने के लिए अलग-अलग command-line forms बताती है। यह interpreter का सामान्य व्यवहार है, कोई कमी नहीं। गलती तब होती है जब इन सभी forms को ऐसा माना जाता है मानो इनके पीछे एक ही स्थिर, signed program हो।

यही गलती process identity के साथ भी होती है। Approval system आपको सही तरीके से बता सकता है कि agent process किसी पहचानी हुई code-signing authority से आया है। फिर भी वह यह निष्कर्ष नहीं निकाल सकता कि interpreter से execute करने के लिए process जिन local files को कहता है, वे सभी उसी मंजूरी की हकदार हैं। Caller identity और source identity अलग सवालों का जवाब देते हैं:

• Caller identity पूछती है कि request किसने शुरू की।
• Interpreter identity पूछती है कि source को parse करने वाली binary कौन-सी है।
• Source identity पूछती है कि interpreter किन bytes को parse करेगा।
• Action identity पूछती है कि resulting request किस host, API route, account या command तक पहुंचेगी।

अगर review screen पर केवल पहले दो के लिए जगह है, तो वह specificity का झूठा एहसास देती है। व्यवहार में source और action तय करते हैं कि request स्वीकार्य है या नहीं।

Review target एक execution tuple है

Reviewer को friendly label नहीं, exact execution का स्थिर विवरण चाहिए। मैं इस विवरण को execution tuple कहता हूं: resolved interpreter, उसके arguments, source artifact, execution context और मांगी गई बाहरी action। Tuple के किसी महत्वपूर्ण हिस्से को बदलें और आपके पास अलग execution होगा, जिसके लिए नया निर्णय चाहिए।

File-based Python call के लिए न्यूनतम उपयोगी tuple कुछ ऐसा दिखता है:

{
  "caller": {
    "pid": 48172,
    "signing_authority": "Example Development Team"
  },
  "interpreter": {
    "resolved_path": "/usr/local/bin/python3.12",
    "signing_identity": "Python Software Foundation",
    "sha256": "c44e...9a10"
  },
  "argv": ["/usr/local/bin/python3.12", "/private/var/run/gateway-src/publish.py"],
  "source": {
    "display_path": "/Users/dev/work/release/publish.py",
    "sha256": "6ab1...ee42"
  },
  "context": {
    "working_directory": "/Users/dev/work/release",
    "environment": {"DEPLOY_ENV": "staging"}
  },
  "requested_action": "POST https://api.example.invalid/releases"
}

Digest के छोटे रूप approval card में रखें, लेकिन पूरा digest journal में होना चाहिए। Reviewer को आम तौर पर readable path और diff या source preview चाहिए। Investigator को ऐसा स्पष्ट value चाहिए जिसकी बाद में तुलना की जा सके।

हर environment variable को card में न डालें। इससे decision लेने के बजाय reviewer को आंखें गड़ाकर पढ़ना पड़ेगा। वे values capture करें जो code selection, command resolution, credentials, proxy routing, target selection और feature switches को प्रभावित करती हैं। Python के लिए इनमें PYTHONPATH, PYTHONHOME और स्पष्ट रूप से दी गई configuration path शामिल हो सकती है। Shell execution में अक्सर PATH, current directory और command में शामिल किए गए variables आते हैं। अगर आपका threat model ऐसा मांगता है, तो पूरा environment protected audit data में रखें और व्यक्ति को उसका महत्वपूर्ण हिस्सा दिखाएं।

यहीं teams एक दूसरे फर्क को भी धुंधला कर देती हैं: reproducibility authorization नहीं है। Lockfile, Git commit या container image से यह दोहराने में मदद मिल सकती है कि क्या चला था। इससे यह तय नहीं होता कि उस code को production call करनी चाहिए, remote branch delete करनी चाहिए या SSH session खोलना चाहिए। Source identity को स्पष्ट action request के साथ जोड़ें।

Python सामान्य launchers के पीछे code छिपा सकता है

Python में plain file invocation वास्तविकता से ज्यादा सरल दिखती है। python deploy.py बताता है कि execution कहां से शुरू होता है, लेकिन interpreter script directory, installed packages, configured search paths और application logic से चुने गए code से modules import कर सकता है। Virtual environment यह भी बदल सकता है कि बिना qualification वाला python किस interpreter तक पहुंचे।

Signature जांचने से पहले executable को resolve करें। python, python3 या venv/bin/python कोई identity नहीं हैं। Launcher symlink, shim या toolchain update के बाद कोई दूसरी binary हो सकता है। Gateway को उस object को resolve करना चाहिए जिसे kernel launch करेगा, उस object की जांच करनी चाहिए और उसका path तथा digest दर्ज करना चाहिए।

इसके बाद source path को security boundary नहीं, display aid समझें। Review record के लिए symlinks को canonical location तक resolve करें, लेकिन review के बाद mutable original को execute न करें। Repository checkout path बदले बिना deploy.py को replace कर सकता है। Symlink किसी दूसरे target की ओर इशारा कर सकता है। अकेले path check से इनमें से कोई घटना नहीं पकड़ेगी।

एक व्यावहारिक sequence यह है:

1. मांगी गई script bytes पढ़ें और SHA-256 निकालें।
2. उन bytes को restrictive permissions वाली private, gateway-owned directory में copy करें।
3. Approval के लिए caller का path, canonical path, digest और source preview दिखाएं।
4. Verified interpreter को private copy के साथ चलाएं और result को उसी digest से जोड़कर दर्ज करें।

यह copy बेवजह का काम नहीं है। इससे time-of-check और time-of-use के बीच का gap बंद होता है। अगर reviewer ने digest 6ab1...ee42 को मंजूर किया है, तो interpreter को उन्हीं bytes को पढ़ना चाहिए जिनका digest 6ab1...ee42 है। Repository file का hash बनाकर बाद में Python से उसी repository file को दोबारा पढ़वाने पर replacement के लिए छोटा, लेकिन वास्तविक मौका बचा रहता है।

Imports के लिए भी निर्णय चाहिए। अगर publish.py, local release_helpers.py को import करती है, तो बदला हुआ helper entry file स्थिर रहने पर भी व्यवहार बदल सकता है। सख्त विकल्प यह है कि source manifest में उस execution के लिए अनुमति वाले हर local module को शामिल किया जाए। रोजमर्रा के काम के लिए अधिक व्यावहारिक विकल्प है कि entry script और उसकी घोषित local package tree को साथ stage करें, staged tree के बाहर के imports अस्वीकार करें और manifest digest बदलने पर नई मंजूरी मांगें।

यह दिखावा न करें कि इससे dynamic imports, native extensions, sitecustomize या runtime पर मनमाने ढंग से fetch किए गए code पकड़े जाते हैं। ऐसा नहीं होता। जहां ऐसी allowances मौजूद हों, approval screen को उनका नाम देना चाहिए। importlib.import_module(os.environ["PLUGIN"]) वाली script को केवल इसलिए वही व्यापक मंजूरी नहीं मिलनी चाहिए कि दोनों की शुरुआत उसी signed interpreter से होती है।

Node की entry file program का केवल एक हिस्सा है

Node एक अलग तरह की अस्पष्टता जोड़ता है। node task.js में entry file होती है, लेकिन module resolution package.json, package exports, lockfiles, symlinks और current directory के जरिए code चुन सकता है। Node CLI documentation --require और --import जैसे preloads का भी वर्णन करती है। ये entry file शुरू होने से पहले code चला सकते हैं।

इसका मतलब है कि review system को केवल अंतिम .js path नहीं, पूरा argument vector दिखाना चाहिए। इन calls की अलग-अलग तरह से जांच होनी चाहिए:

node tools/publish.mjs
node --import ./tools/setup.mjs tools/publish.mjs
node --require ./tools/patch.cjs tools/publish.mjs
node -e "require('child_process').execSync(process.argv[1])" "git push --force"

जो reviewer केवल tools/publish.mjs देखता है, वह दूसरी और तीसरी call में पहले चलने वाले code को नहीं देख पाता। आखिरी call में कोई reviewed entry file है ही नहीं। Command string ही source artifact है और उसे उसी रूप में दिखाना, सहेजना और hash करना होगा।

Node का NODE_OPTIONS environment variable भी इसी तरह महत्वपूर्ण है। Node documentation इसे environment के जरिए अनुमत command-line options भेजने के तरीके के रूप में बताती है। अगर process वहां preloads या debugging behavior दे सकता है, तो उसे अनदेखा करने वाला gateway अधूरी command की जांच कर रहा है। Reviewers को हर runtime setting से डराने की जरूरत नहीं है, लेकिन उन settings को जरूर दिखाएं जो code load करती हैं या target selection बदलती हैं।

Package managers एक और जाल बनाते हैं। npm run publish अक्सर किसी named task जैसा लगता है, लेकिन उसका व्यवहार mutable package.json, उसके scripts, lockfile, package-manager hooks और project dependency tree में मिली binaries से आता है। Approval से पहले task name का विस्तार करें। Resolved command, project revision या staged manifest और चलने वाले हर lifecycle hook को दिखाएं। अगर यह expansion उपलब्ध नहीं है, तो संकरी मंजूरी मांगें या request अस्वीकार करें। जब package file आपके नीचे बदल सकती हो, तब «Run package script» कोई अर्थपूर्ण action description नहीं है।

बार-बार होने वाले Node automation के लिए reviewed workspace snapshot stage करें या immutable build artifact इस्तेमाल करें। केवल publish.mjs का hash तभी पर्याप्त है जब script की कोई local dependencies और कोई preload path न हो। ज्यादातर जटिल projects इस शर्त को पूरा नहीं करते।

Shell strings को source की तरह देखें

जब कोई shell request को program के बजाय command कहता है, तब review में समस्या आती है। sh -c expansions, substitutions, redirects, pipelines, functions और command lookup के साथ source string parse करता है। String छोटी हो सकती है, लेकिन वह दूसरे programs का अनगिनत sequence चला सकती है।

इन requests की तुलना करें:

/bin/sh -c 'curl -fsS "$RELEASE_URL" | sh'
/bin/sh /private/var/run/gateway-src/release.sh

पहली request के लिए exact command string, हर महत्वपूर्ण environment value और downstream program को मिलने वाली चीज का विवरण चाहिए। दूसरी के लिए Python या Node जैसा ही script path और content treatment चाहिए। /bin/sh पर signature केवल यह बताती है कि parser किसने दिया। इससे किसी भी source input को मंजूरी नहीं मिलती।

Shell command को उसके पहले verb से मंजूर न करें। git status किसी एक exact argument vector में harmless हो सकता है, जबकि git -c credential.helper=... उन inputs को बदल देता है जिन्हें Git load करेगा। curl data fetch कर सकता है, file लिख सकता है या bytes को किसी दूसरे interpreter में pipe कर सकता है। Reviewer को syntax का इतना हिस्सा दिखना चाहिए कि redirection और substitution दिखाई दें, और execution context का इतना हिस्सा कि यह पता चले कि programs कहां resolve होंगे।

PATH को अक्सर नजरअंदाज कर दिया जाता है। जो script बिना absolute path के deploy चलाती है, वह executable selection environment को सौंप देती है। अगर request agent workspace से आई है, तो उस workspace को बदल सकने वाला attacker PATH में पहले आने वाला program रख सकता है। जहां संभव हो, हर security-sensitive subcommand के लिए resolved executable path capture करें। जब पूरा shell evaluation खुद असुरक्षित या बहुत अनिश्चित हो, तो perfect shell parser बनाने की कोशिश करने के बजाय constrained command interface इस्तेमाल करें।

इसी वजह से एक लोकप्रिय सलाह सही नहीं है: «Just allow a signed shell and prompt on each call.» यह सलाह लोकप्रिय है क्योंकि shell हर जगह मौजूद है और approval आसान लगता है। यह गलत है क्योंकि single approval के पीछे कोई स्थिर source object नहीं होता, जब तक system exact string या immutable script और महत्वपूर्ण context दर्ज न करे। Per-call approval भी गलत चीज को बड़ी निरंतरता के साथ मंजूर कर सकता है।

Content hash को ऐसी file से जुड़ना चाहिए जिसे वह सच में bind कर सके

Hash bytes के बारे में evidence है, यह प्रमाण नहीं कि intended program उन्हीं bytes का इस्तेमाल करेगा। Implementation को reviewed bytes को execution से जोड़ना होगा। यही वह जगह है जहां कई सावधानी से बनाए गए designs टूट जाते हैं।

Unsafe pattern पहचानना आसान है:

1. Read /workspace/scripts/publish.py
2. Calculate and display SHA-256
3. Wait for approval
4. Run python /workspace/scripts/publish.py

Step 2 और 4 के बीच कोई दूसरा process file edit कर सकता है, symlink replace कर सकता है या mounted directory बदल सकता है। Approval record इस बारे में सही रहता है कि reviewer ने क्या देखा था, लेकिन इस बारे में बेकार हो जाता है कि वास्तव में क्या चला।

इसके बजाय इनमें से कोई model अपनाएं:

• Reviewed bytes को private execution directory में copy करें, permissions ऐसी रखें कि requesting process उन्हें बदल न सके और copy चलाएं।
• पहले से बनाए गए immutable artifact को चलाएं, जिसका digest review और record किया गया हो।
• Check और execution path के दौरान खुले हुए file object को तभी बनाए रखें जब interpreter और operating system आपको उस exact object को mutable path को दोबारा resolve किए बिना चलाने दें।

Private-copy model आम तौर पर समझाना और audit करना आसान होता है। इससे incident review के लिए stable artifact भी मिलता है। Original display path को context के रूप में रखें, क्योंकि लोगों को यह जानना जरूरी है कि run के लिए project की कौन-सी file ने request पैदा की थी। लेकिन इसे execute हुए bytes के साथ न मिलाएं।

Content hashing की सीमाएं स्पष्ट रहनी चाहिए। यह तय नहीं कर सकता कि source सुरक्षित है या नहीं। यह remote responses, time-dependent behavior, random values या hash के बाद load होने वाले code को स्थिर नहीं कर सकता। लेकिन यह approval mistake की एक खास श्रेणी को रोकता है: local script के एक revision की review करके दूसरे revision को execute करना। यह उपयोगी सीमा है, बशर्ते आप इसे ईमानदारी से बताएं।

SHA-256 या किसी दूसरे मौजूदा cryptographic digest का इस्तेमाल करें, fixed encoding रखें और records में algorithm name हमेशा शामिल करें। केवल hexadecimal string भविष्य में भ्रम पैदा कर सकती है। Digest record में sha256:6ab1...ee42 लिखा होना चाहिए, केवल 6ab1...ee42 नहीं।

Approval cards में वह evidence दिखाएं जिसका व्यक्ति इस्तेमाल कर सके

अच्छा approval card reviewer को जरूरी तथ्यों को छिपाए बिना जल्दी निर्णय लेने देता है। शुरुआत file hash से न करें। कोई व्यक्ति केवल देखकर hash का आकलन नहीं कर सकता। पहले मांगी गई action और caller दिखाएं, फिर interpreter, source location, source state और महत्वपूर्ण execution context।

Deployment request के लिए compact card कुछ ऐसा हो सकता है:

Caller: signed process from Example Development Team, PID 48172
Action: POST release data to api.example.invalid
Interpreter: /usr/local/bin/python3.12, signed by Python Software Foundation
Source: /Users/dev/work/release/publish.py
Reviewed bytes: sha256:6ab1...ee42
Execution copy: /private/var/run/gateway-src/6ab1...ee42/publish.py
Context: DEPLOY_ENV=staging, working directory /Users/dev/work/release

Card में source preview या last approved digest के मुकाबले diff देना चाहिए। Repeated work के लिए diff अक्सर बेहतर होता है क्योंकि वह ध्यान बदली हुई lines पर ले जाता है। फिर भी पूरी source मांगने पर उपलब्ध कराएं। भ्रामक रूप से काटा गया preview, preview न होने से भी खराब है।

«Allow deployment tooling» या «Allow Python access» जैसे अस्पष्ट approval labels से बचें। वे लोगों को brand recognition के आधार पर click करने की आदत डालते हैं। Decision में उसका lifetime भी स्पष्ट होना चाहिए। One execution, one process session और reviewed artifact release अलग-अलग scopes हैं। Agent process के लिए session approval prompt fatigue कम कर सकती है, लेकिन digest बदलने वाली किसी भी script को outside authority दोबारा इस्तेमाल करने से पहले नया source decision लेना चाहिए।

यह rules engine से अलग है। लोगों के लिए «allow safe scripts» जैसी conditions लिखने की language की जरूरत नहीं है। आपको एक fixed review object चाहिए जो approval के बाद चुपचाप बड़ा न हो सके। System को resolved inputs से यह object बनाना, दिखाना और execution को उसी से bind करना चाहिए।

Dependency boundaries स्पष्ट होनी चाहिए

Entry script digest तभी पर्याप्त हो सकता है जब program की code boundary सचमुच उसी एक file तक सीमित हो। इसे default नहीं, exception समझें। Python imports, Node modules, shell source commands, templates, configuration files और executable plugins entrypoint के review से गुजरने के बाद भी behavior बदल सकते हैं।

Boundary को action के परिणाम के अनुसार तय करें। Development service पर low-risk read के लिए आप staged entry script के साथ यह स्पष्ट statement स्वीकार कर सकते हैं कि वह installed packages import कर सकती है। Production write या SSH command के लिए local source dependencies को manifest में शामिल करें, external dependencies pin करें और executable code के runtime downloads अस्वीकार करें। तब record investigator को बताता है कि «the script» से आपका क्या मतलब था।

एक simple manifest में relative paths और digests हो सकते हैं:

sha256  publish.py  6ab1...ee42
sha256  release_helpers.py  9d07...1a3c
sha256  config/targets.json  743e...64b1

Gateway को यह manifest staged copies या controlled build input से बनाना चाहिए, उसी mutable workspace से मिले manifest को स्वीकार नहीं करना चाहिए। अगर project lockfile को अपनी boundary का हिस्सा घोषित करता है, तो उस lockfile का hash भी बनाएं। Lockfile तभी मदद करता है जब runtime उसका पालन करे और reviewed process किसी अलग dependency tree को substitute न कर सके।

एक बिंदु पर interpreter-based local execution one-click decision के लिए बहुत व्यापक हो जाता है। अगर code arbitrary directories से plugins खोज सकता है, remote content fetch करके चला सकता है या generated scripts लिखकर चला सकता है, तो काम को अलग हिस्सों में बांटें। ऐसे build को मंजूर करें जो immutable artifact बनाता हो, artifact की घोषित action की जांच करें और फिर उस action को मंजूर करें। यह अतिरिक्त boundary accidental production change को दोबारा समझने की लागत से सस्ती है।

Logs को बताना चाहिए कि क्या चला, UI ने उसे क्या नाम दिया यह नहीं

जब कोई action गलत हो जाती है, तो पहला उपयोगी सवाल आम तौर पर यही होता है, «उस authority के साथ वास्तव में क्या चला?» «Python approved» कहने वाली journal entry इसका जवाब नहीं दे सकती। Execution tuple, decision scope, reviewer interaction, timestamps और observed result सुरक्षित रखें। Record से secrets redact करें, लेकिन source artifact या target action की identity redact न करें।

एक sound record संबंधित events को जोड़ता है। Session entry agent process और उसकी authority की पहचान करती है। Action entry interpreter, staged source digest, arguments, target और result की पहचान करती है। अगर reviewer session revoke करता है, तो वह event उसी session identity से जुड़ना चाहिए। वरना operators यह नहीं बता सकते कि revocation ने उस requester को रोका या नहीं जिसने call की थी।

Tamper evidence record की quality बदल देता है। Hash-chained journal बाद के बदलावों को detectable बना सकता है, लेकिन यह missing fields को ठीक नहीं करता। Chain verify करने के साथ यह भी पूछें कि resolved path, source digest, context और actual action दर्ज हैं या नहीं। Integrity evidence को सुरक्षित रखती है, लेकिन ऐसा evidence नहीं बना सकती जिसे system ने कभी capture ही नहीं किया।

Sallyport के split journals यहां उपयोगी हैं क्योंकि वे agent run को individual HTTP या SSH calls से अलग रखते हैं, जबकि दोनों को एक encrypted, hash-chained audit log से project करते हैं। इसका sp audit verify command ciphertext पर offline chain verify कर सकता है। बाद में retained evidence बदला गया है या नहीं, यह जांचने के लिए यही सही property है।

Source changes को नई authority समझें

सबसे सुरक्षित default सरल है: source digest बदलने पर outside action के लिए नया decision मांगें। केवल इसलिए पिछली script approval को चुपचाप आगे न बढ़ाएं कि path, interpreter, project name या process signature जाना-पहचाना लगता है।

Active development के दौरान इस rule से कुछ अधिक prompts आएंगे। ऐसा होना चाहिए। जब code किसी credential को खर्च कर सकता है, remote service बदल सकता है या SSH command चला सकता है, तब code review authority बदलता है। समाधान हर prompt को दबाना नहीं है। Review artifact बेहतर बनाएं, deterministic source stage करें और व्यापक process session केवल वहां दें जहां source की अलग से पहचान बनी रहे।

Action gateway इस्तेमाल करने वाली teams के लिए gate को उस बिंदु पर केंद्रित रखें जहां credentials local machine से बाहर जाते हैं। Agent को source-bound review record के साथ HTTP call या SSH command मांगनी चाहिए, जबकि gateway credential अपने पास रखकर result लौटाए। इससे secrets mutable script को सौंपने से बचते हैं, लेकिन फिर भी यह स्पष्ट होना चाहिए कि action की request किस code ने की थी।

सबसे संवेदनशील interpreter call से शुरुआत करें। Binary resolve करें, पूरे arguments दिखाएं, वास्तविक source bytes का hash बनाकर उन्हें stage करें, महत्वपूर्ण context दर्ज करें और बदले हुए digest को बदली हुई approval मानें। यह record बनने के बाद signed interpreter किसी अज्ञात script पर चिपके भरोसेमंद label के बजाय पूरी तरह तैयार decision में उपयोगी evidence बन जाता है।