एक जैसे दिखने वाले approval requests खतरनाक क्यों हैं?

मानव अनुमोदन का सुरक्षा मूल्य तभी है जब व्यक्ति समझ सके कि क्लिक करने से किस कार्रवाई की अनुमति मिलेगी। अगर स्क्रीन पर दो अनुरोध एक जैसे दिखें, लेकिन उनकी body, headers, run identity या commands अलग हों, तो अनुमोदन केवल दिखावा है। व्यक्ति ने कार्रवाई की समीक्षा नहीं की। उसने एक जाना-पहचाना label देखा और आगे बढ़ गया।

Agent tooling में ऐसी गलती करना आसान है, क्योंकि दिखाई देने वाला summary आम तौर पर सबसे कम महत्वपूर्ण fields से शुरू होता है: title, hostname, method और शायद छोटा command। ये fields व्यक्ति को संदर्भ समझने में मदद करते हैं, लेकिन अधिकार की पूरी पहचान नहीं बताते। एक ही endpoint पर भेजा गया POST harmless draft बना सकता है या production change जारी कर सकता है। SSH command version दिखा सकती है या directory हटा सकती है। किसी दूसरे tenant header के साथ भेजा गया request सीमा पार कर सकता है, भले ही URL का हर शब्द वही रहे।

मैंने अच्छे इरादों से approval flows को बेकार बनते देखा है। कोई interruptions कम करना चाहता है, इसलिए मिलती-जुलती calls को समूह में रख देता है। कोई साफ-सुथरा card चाहता है, इसलिए request body को छिपा देता है। कोई analytics के लिए स्थिर label चाहता है, इसलिए एक ही family की हर action के लिए वही label रख देता है। जब reviewer दसवां जाना-पहचाना card देखता है, तब तक system उसे सिखा चुका होता है कि details मायने नहीं रखतीं। Attacker या buggy agent को केवल एक छिपा हुआ अंतर चाहिए।

एक जैसे labels अलग-अलग अधिकार छिपा सकते हैं

Title और destination संकेत हैं, उस object का पूरा रूप नहीं जिसे व्यक्ति authorize कर रहा है। इन्हें identity मानने से collision class बनती है: कई अलग operations एक ही पहचाने जाने योग्य prompt में सिमट जाते हैं।

एक deployment service पर POST /v1/releases का एक ही endpoint मान लीजिए। Agent पहले draft release submit करता है और बाद में उसे publish करने की अनुमति मांगता है। अगर दोनों cards पर "Release request" लिखा हो और api.example.test दिखता हो, तो reviewer को detail drawer खोलकर body पढ़नी होगी। व्यवहार में बार-बार आने वाले cards लोगों को सिखा देते हैं कि drawer में हर बार वही बेकार जानकारी होती है। फिर publish request उसी आदत के बाद आती है।

यही समस्या रोजमर्रा के काम में भी दिखती है। Source-control API एक ही path से pull request का title बदल सकती है, merge setting बदल सकती है या reviewers को बदल सकती है। Cloud API एक field के जरिए उसी resource path पर dry run और वास्तविक change दोनों चला सकती है। Ticketing endpoint किसी header के आधार पर private incident या public status page में लिख सकता है। Destination बताता है कि request कहां पहुंचा। वह यह नहीं बताता कि remote service क्या करेगी।

Commands में झूठी समानता अक्सर एक सुविधाजनक display string से शुरू होती है। इन जोड़ों की approval identity कभी एक जैसी नहीं होनी चाहिए:

• find build -type f -delete और find build -type f -print
• निजी clone और release checkout से चलाया गया git push origin HEAD
• ऐसा curl -X POST जिसमें JSON body draft बनाती है और ऐसा जिसमें message भेजा जाता है
• read-only account और service files बदल सकने वाले account से चलाया गया ssh deploy@host

लोग जिस अंतर को धुंधला कर देते हैं, वह similarity और equivalence का अंतर है। Similarity का अर्थ है कि दो actions में इतना मेल है कि उन्हें देखने में एक समूह में रखा जा सके। Equivalence का अर्थ है कि एक approval सचमुच दूसरी action को भी cover कर सकता है। पहला presentation का विकल्प है। दूसरा अधिकार देता है। इन दोनों को मिलाने पर compact interface चुपचाप permission बढ़ा देता है।

Prompt readability के लिए बार-बार होने वाली actions को समूह में रख सकता है, लेकिन उस grouping को यह तय करने की अनुमति कभी नहीं मिलनी चाहिए कि पहले किया गया click अब भी लागू है या नहीं। Authorization check को card के label से अधिक सख्त object पर आधारित होना चाहिए।

Approval को चलाए गए request से जोड़ना जरूरी है

Approved object उस action का canonical description होना चाहिए जिसे executor भेजेगा, साथ ही उस identity context का भी जिसमें वह उसे भेजेगा। अधिकार से जुड़े किसी भी field में बदलाव हो, तो system को फिर से पूछना चाहिए या बदले हुए field को इतना स्पष्ट दिखाना चाहिए कि fresh decision जरूरी हो जाए।

HTTP के लिए इस description में आम तौर पर method, scheme और host, normalized path, query values, body bytes या body का तय canonical रूप, चुने गए headers, credential reference और agent run शामिल होते हैं। ऐसा करने के लिए secret values को display या log में डालना जरूरी नहीं है। payments-production जैसा credential reference token दिखाए बिना authority की पहचान कराता है। Executor approval को उस internal vault record से जोड़ सकता है जिसका वह वास्तव में उपयोग करेगा।

Headers पर अधिकांश interfaces से अधिक सावधानी चाहिए। कुछ headers केवल transport decoration को प्रभावित करते हैं। दूसरे किसी organization का चयन करते हैं, administrative mode चालू करते हैं, idempotency scope तय करते हैं, regional account चुनते हैं या receiver के body समझने का तरीका बदलते हैं। उन fields की स्पष्ट allowlist रखें जिन्हें इसलिए छोड़ा जा सकता है क्योंकि वे remote action को प्रभावित नहीं करते। बाकी हर field canonical identity में तब तक दिखना चाहिए जब तक कोई साबित न कर दे कि उसे छोड़ना सुरक्षित है।

Command के लिए description shell string से नहीं, execution plan से बनाएं। Plan में executable, argument vector, working directory, लागू होने पर target host, user identity, credential reference और behavior को प्रभावित करने वाली environment entries शामिल होती हैं। Shell string केवल display format है और उसमें जानकारी खो सकती है। Quoting rules, expansion, inherited variables और बदली हुई working directory एक जैसी दिखने वाली line को दूसरी action में बदल सकते हैं।

यहीं teams अक्सर "same destination and same verb is close enough" जैसी ढीली rule के पक्ष में तर्क देती हैं। यह लोकप्रिय है क्योंकि prompts जल्दी कम हो जाते हैं और demos smooth लगते हैं। यह गलत है, क्योंकि HTTP verbs व्यापक classes बताते हैं, consequences नहीं। POST कोई permission category नहीं है, और ssh भी नहीं।

Decision को बांधने के लिए request fingerprint इस्तेमाल करें, लेकिन fingerprint को अकेला evidence न दिखाएं। Approval engine के भीतर equality check के लिए digest बहुत अच्छा है। इंसानों को वे fields चाहिए जिनसे वह result निकला है। दोनों दें: card पर structured और पढ़ने योग्य differences, और card के पीछे exact canonical identity।

बार-बार होना इस बात का प्रमाण नहीं कि call सुरक्षित है

Retry में पहले प्रयास के सभी execution fields समान हो सकते हैं, फिर भी उसका treatment किसी unrelated duplicate से अलग होना चाहिए। Prompt छिपाने का निर्णय लेने से पहले system को यह तय करना होगा कि request दोहर क्यों रहा है।

बार-बार होने वाली call का सबसे सुरक्षित मामला transport retry है, जब executor जानता है कि पहला request remote service तक पहुंचा ही नहीं, या remote service exact operation से जुड़ा idempotency mechanism देती है। तब भी approval engine को retry को मूल approved operation से जोड़ना चाहिए और retry relationship दर्ज करनी चाहिए। उसे केवल यह देखकर काम नहीं चलाना चाहिए कि हाल के history में कहीं दो hashes मिलते हैं।

अनिश्चित network failure के बाद आने वाला duplicate अलग मामला है। Connection टूटने से पहले remote service ने पहली call स्वीकार कर ली हो सकती है। उसे दोबारा चलाने पर दूसरा email जा सकता है, दूसरी issue बन सकती है या दो बार billing हो सकती है। Reviewer को ऐसी भाषा चाहिए जो बताए कि पहले प्रयास का outcome अज्ञात है। केवल "Retrying request" कहने वाला परिचित card वह निर्णय छिपा देता है जो reviewer को लेना है।

किसी दूसरे run से बाद में आने वाली वही identical action फिर अलग मामला है। यह नया agent process, नया code, copied terminal session या उसी machine का इस्तेमाल करने वाला कोई दूसरा व्यक्ति हो सकता है। Per-run authorization इसलिए मौजूद है क्योंकि process identity और lifetime मायने रखते हैं। Runs के बीच पुराना approval दोबारा इस्तेमाल करना सीमित decision को स्थायी grant में बदल देता है।

अपने model में अलग states रखें:

1. User ने exact planned action को approve किया।
2. Executor ने उस action का प्रयास किया और उसे पता है कि request भेजा गया या नहीं।
3. Remote side ने success, failure या unknown outcome बताया।
4. बाद की action पहली action से अपने संबंध का दावा करती है।

इन states को एक green badge में न समेटें। Approval intent दर्ज करता है। Transport result delivery evidence दर्ज करता है। Remote response outcome दर्ज करता है। ये अलग सवालों के जवाब हैं और audit record को तीनों सुरक्षित रखने चाहिए।

Bodies की semantic review और byte-level binding दोनों जरूरी हैं

Request body API call का पूरा प्रभाव अपने भीतर रख सकती है, इसलिए उसे generic "payload attached" label के पीछे छिपाना design error है। Review के लिए readable form दिखाएं, फिर approval को उस exact representation से जोड़ें जिसे executor भेजता है।

JSON में यह काम कठिन हो जाता है, क्योंकि उसका appearance और meaning अलग हो सकते हैं। Object fields का order अक्सर receiver की interpretation नहीं बदलता, जबकि array का order पूरी तरह बदल सकता है। Whitespace आम तौर पर मायने नहीं रखता, लेकिन whitespace वाली string अलग बात है। 1 लिखी हुई संख्या को कोई service loose या custom decoding के कारण 1.0 से अलग समझ सकती है। Universal JSON normalizer बनाकर यह मान लेना ठीक नहीं कि वह semantics बचाए रखेगा।

एक व्यावहारिक तरीका दो layers का है। पहले, outgoing body bytes को जस का तस रखें और authorization binding के लिए उन पर cryptographic digest निकालें। दूसरे, known content types को display tree में parse करें, ताकि fields पढ़ने योग्य हों। अगर parser body को सुरक्षित रूप से समझ नहीं सकता, तो escaped excerpt, उसकी length और digest दिखाएं। Call के परिणाम महत्वपूर्ण हों, तो approval से पहले व्यक्ति से उसे expand करने को कहें।

ऐसे pairs से test करें जो लापरवाही से देखने वाले reviewer को भ्रमित कर सकें। नीचे दी गई दोनों fixture files में title, method और destination एक जैसे हैं। इनके fingerprints अलग होने चाहिए और approval view में अंतर साफ दिखना चाहिए।

{
  \"title\": \"Release request\",
  \"method\": \"POST\",
  \"url\": \"https://api.example.test/v1/releases\",
  \"headers\": {\"Content-Type\": \"application/json\"},
  \"body\": {\"version\": \"2.4.1\", \"state\": \"draft\"}
}

{
  \"title\": \"Release request\",
  \"method\": \"POST\",
  \"url\": \"https://api.example.test/v1/releases\",
  \"headers\": {\"Content-Type\": \"application/json\"},
  \"body\": {\"version\": \"2.4.1\", \"state\": \"published\"}
}

आपके test को केवल fingerprintA != fingerprintB से अधिक जांचना चाहिए। यह भी assert करें कि rendered card state में बदलाव दिखाता है, draft fixture के approval को published fixture के खिलाफ इस्तेमाल करने पर failure मिलता है और activity record body digest तथा field-level display summary सुरक्षित रखता है। आखिरी assertion एक आम खराब fix पकड़ती है: engineers authorization check तो ठीक कर देते हैं, लेकिन reviewers और investigators को बेकार log ही दिखता रहता है।

Binary और form bodies को भी यही अनुशासन चाहिए। Multipart upload में filename और content type वही रहते हुए uploaded document बदल सकता है। Encoded form में किसी compact card से छिपे field में role=user बदलकर role=admin किया जा सकता है। अगर remote action महत्वपूर्ण है, तो body भी महत्वपूर्ण है।

Headers और credentials छिपे हुए scope changes बनाते हैं

Request भेजने के लिए इस्तेमाल किया गया credential action का हिस्सा है, भले ही URL और body byte-for-byte समान हों। "Update invoice" लिखने वाला card अगर यह छिपा दे कि sandbox credential इस्तेमाल हो रहा है या production credential, तो reviewer से आंख बंद करके approval मांगा जा रहा है।

Bearer token, password, private key या custom secret header कभी display न करें। इसके बजाय हर secret record को स्थिर human label दें और वह label, account class तथा operator द्वारा जानबूझकर configured permission warning दिखाएं। Reviewer को token text की जरूरत नहीं हो सकती, लेकिन उसे पता होना चाहिए कि billing-read बदलकर billing-admin हो गया है या action अब किसी दूसरे SSH account के रूप में चल रही है।

Custom headers सबसे खतरनाक surprises पैदा करते हैं, क्योंकि वे अक्सर plumbing जैसे दिखते हैं। X-Organization value किसी परिचित request को दूसरे tenant में भेज सकती है। X-Mode: live header simulation और वास्तविक operation के बीच सीमा पार कर सकता है। Idempotency-Key तय कर सकता है कि receiver request को replay मानेगा या नया instruction। जहां ये fields scope बदलते हैं, rendered comparison में इन्हें जरूर रखें।

Redaction को change detection बनाए रखना चाहिए। हर sensitive value को *** से बदलना तभी ठीक है जब UI फिर भी बता सके कि secret reference बदला है। अगर दो अलग secrets दोनों *** के रूप में दिखें, तो आपने खुद look-alike collision बना दिया है। कोई nonsecret label या stable internal alias दिखाएं, secret material कभी नहीं।

एक उपयोगी fixture set एक समय में एक dimension बदलता है: अलग credential reference वाला वही request, दूसरे organization header वाला वही credential, दूसरी query value वाला वही header और फिर सभी बदलावों वाला पूरा case। Single-dimension cases canonicalizer में छूटे हुए fields पकड़ते हैं। Combined case उस UI code को पकड़ता है जो पहले अंतर के बाद बाकी differences काट देता है।

Sessions बताते हैं कि दोबारा कौन पूछ रहा है

Approval caller के बारे में किया गया judgment भी है। नए agent process से आई वही action उस trust को inherit नहीं करती जो आपने पिछले process को दिया था, सिर्फ इसलिए कि उसका working directory या executable name वही है।

Code-signing authority उपयोगी है, क्योंकि कोई भी process अपने लिए कोई भी friendly name बता सकता है। फिर भी इससे उस process की हर request समान नहीं हो जाती। Trusted process बदला हुआ prompt चला सकता है, poisoned repository file पढ़ सकता है या ऐसा instruction follow कर सकता है जिसका operator ने इरादा नहीं किया था। Process identity बताती है, "यह run किसने शुरू किया?" Request binding बताती है, "यह run क्या करेगा?" दोनों जरूरी हैं।

Process launch पर session identifier दर्ज करें और हर proposed तथा executed action से उसे जोड़ें। Process बंद हो तो उसकी temporary authorization भी समाप्त होनी चाहिए। नया process दिखे, तो नया approval दिखाएं, भले ही उसका title और destination हाल की action से मेल खाते हों। केवल executable path समान होने के आधार पर दो processes को एक न मानें। Updaters, copied binaries, wrappers और local development builds इस shortcut को अविश्वसनीय बना देते हैं।

Long-lived tools के साथ सावधान रहें। कई दिनों तक चलने वाला process केवल इसलिए असीमित blanket approval का हकदार नहीं हो जाता कि वह बंद नहीं हुआ है। Sensitive credentials या irreversible effects वाली actions के लिए हर call पर approval लें। कम जोखिम वाले repeated work के लिए permission को defined session तक सीमित रखें और session को journal में दिखाई देने योग्य बनाएं। System चलाने वाले व्यक्ति को व्यापक account setting में खोजे बिना unwanted requests पैदा करने वाले run की अनुमति रद्द कर सकनी चाहिए।

Sallyport default रूप से per-session authorization लागू करता है और चुनी हुई vault entry के हर उपयोग पर confirmation मांग सकता है। यह स्पष्ट विभाजन उन exceptions के ढेर से समझना आसान है जिन्हें incident के समय कोई दोबारा जोड़ नहीं सकता।

SSH commands के लिए सुंदर string नहीं, execution plan चाहिए

Shell text खुद को छिपाने में खास तौर पर माहिर है। Reviewer एक compact command देखता है, जबकि shell aliases resolve करती है, variables expand करती है, directory inherit करती है और ऐसे credential से connect करती है जिसका display में नाम ही नहीं होता।

अगर आपका executor direct argument vector स्वीकार करता है, तो उसे उसी रूप में रखें। Executable और हर argument को अलग field के रूप में दिखाएं, फिर resolved working directory, host, remote user और credential label जोड़ें। Shell चलाना जरूरी हो, तो यह बात साफ बताएं और exact shell program तथा script bytes दिखाएं। sh -c content को सुंदर बनाकर दिखाना लेकिन sh -c छिपा देना सबसे महत्वपूर्ण हिस्से को छोड़ देना है।

ये commands संबंधित दिखते हैं, लेकिन इनसे मिलने वाला व्यवहार काफी अलग है:

ssh [email protected] 'systemctl status web'
ssh [email protected] 'systemctl restart web'

इस छोटे pair में verb का अंतर साफ दिखता है। वास्तविक failures इसे अधिक प्रभावी ढंग से छिपाते हैं: कोई variable दूसरे host तक expand हो जाता है, remote path environment value से आती है या command substitution ऐसी file से instructions लेती है जिसे agent ने पहले बदला था। जहां संभव हो, expansion के बाद की values capture करें। जहां expansion remote side पर होती है या सुरक्षित रूप से resolve नहीं हो सकती, वहां यह सीमा स्पष्ट करें और अधिक सोच-समझकर approval लेने को मजबूर करें।

Command text से read और write का अंतर हमेशा निकाला जा सकता है, ऐसा न मानें। cat side effects वाले device read को trigger कर सकती है। दिखने में harmless client remote hook चला सकता है। जब संभव हो, स्पष्ट semantics वाली command families को प्राथमिकता दें और अस्पष्ट shell execution के लिए human approval मांगें। हर command को सटीक रूप से classify करने का दिखावा false confidence पैदा करता है।

Collision pairs से boundary का परीक्षण करें

Approval testing की शुरुआत ऐसे pairs से होनी चाहिए जिन्हें देखकर कोई व्यक्ति एक ही action समझ सकता है। केवल happy path साबित करने वाले unit tests, जिनमें request approve और send होता है, इस failure class के लिए लगभग बेकार हैं।

Authority से जुड़े dimensions की table बनाएं, फिर हर dimension के लिए एक paired fixture तैयार करें। अधिकांश मामलों में title और destination समान रखें। उद्देश्य यह साबित करना है कि engine गलती से इन सुविधाजनक labels को identity नहीं मानता।

इन cases को तीन layers पर चलाएं। Canonicalization layer पर अलग identities assert करें। Authorization layer पर fixture A के लिए जारी approval से fixture B submit करने का प्रयास करें और rejection की अपेक्षा रखें। Interface layer पर snapshot या structured accessibility capture लें और assert करें कि बदला हुआ field secondary view खोले बिना दिखाई देता है। कई clicks के बाद ही दिखने वाला अंतर अधिकांश reviewers से छूट जाएगा।

फिर mutation tests जोड़ें। Test branch में canonical identity से हर field हटाएं और verify करें कि collision test fail हो जाता है। यह जरूरत से ज्यादा सावधानी जैसा तब तक लगता है जब तक कोई request object refactor करके approval adapter तक header, working directory या credential label पहुंचाना चुपचाप बंद न कर दे। Test को ऐसी omission तुरंत साफ दिखानी चाहिए।

Sallyport का action path secrets को अपने encrypted vault में रखता है और secret material के बजाय results agent को लौटाता है। इससे testing आसान होती है, क्योंकि fixture credential records को label से refer कर सकता है और test यह confirm कर सकता है कि agent को actual credential कभी नहीं मिलता।

एक संभावित failure की शुरुआत harmless call से होती है

मान लीजिए कोई agent release notes संभाल रहा है। वह एक परिचित endpoint के जरिए draft बनाता है और operator body जांचने के बाद पहले card को approve कर देता है। फिर agent उसी draft में कई छोटे updates करता है। Card title "Release request" ही रहता है, host भी वही रहता है और operator सीख जाता है कि हर approval routine है।

बाद में repository instruction agent से "finish the release" कहती है। Agent केवल state को draft से published करता है और live organization चुनने वाला header जोड़ता है। अगर interface केवल title, host और method दिखाता है, तो अंतिम card पहले cards जैसा ही दिखता है। अगर approval cache calls को title और destination के आधार पर समूहित करती है, तो system शायद दोबारा पूछे भी नहीं।

इस कहानी में compromised model या dramatic exploit की जरूरत नहीं है। एक ऐसा agent काफी है जो खराब instruction follow करे, ऐसा reviewer काफी है जो repeated prompts का आदी हो चुका हो और ऐसा interface काफी है जो effect बदलने वाले दो fields छिपा दे। ये स्थितियां सामान्य automation में होती हैं।

सुधार पूरे path को cover करना चाहिए। बदली हुई state और organization को दिखाई देने योग्य बनाएं। Approval को दोनों values और credential record से बांधें। Live request को नया action मानें, भले ही बाकी सब कुछ मेल खाता हो। Proposed action, decision और sent request identity को ऐसे रूप में record करें जिसे operator बाद में देख सके। केवल card या केवल cache ठीक करने से collision का दूसरा रास्ता खुला रह जाता है।

Friction महत्वपूर्ण अंतर पर होनी चाहिए

अगर system routine actions को ईमानदारी से दिखाए और केवल अधिकार बदलने वाली जगह friction बचाए, तो लोग बहुत-सी routine actions approve करेंगे। इसके लिए स्पष्ट rule चाहिए: किसी ज्ञात और सीमित मामले में exact retry के लिए silence स्वीकार्य है; बदली हुई body, header, credential, session, command context या target के लिए नया decision जरूरी है।

अस्पष्ट card की भरपाई अधिक warning colors, लंबी prose या डरावने confirmation button से न करें। ये तरीके routine work को धीमा करते हैं और लोगों को visual noise नजरअंदाज करना सिखाते हैं। Decision से जुड़े values को स्थिर layout में रखें, changes को सरल भाषा में चिह्नित करें और इतना detail बचाकर रखें कि व्यक्ति current request की तुलना आखिरी approved request से कर सके।

जब आपको actions का ऐसा समूह मिले जो सचमुच एक approval साझा कर सकता है, तो equivalence claim को code और tests में document करें। उदाहरण के लिए, idempotent retry के साथ immutable operation identifier हो सकता है जिसे remote service एक बार चलाने की guarantee देती है। यह evidence वाला सीमित दावा है। "ये UI में एक जैसे दिखते हैं" evidence नहीं है।

एक ही title और destination वाले हाल के दस approvals से शुरुआत करें। उनके canonical request fields, credential labels और session IDs की तुलना करें। अगर आपको ऐसे differences मिलें जिन्हें reviewer main card पर नहीं देख सकता था, तो आपने authorization defect खोज लिया है, भले ही अभी किसी ने उसका फायदा न उठाया हो।