AI agent reviews के लिए macOS पर approval prompt spoofing

Approval prompts इसलिए निशाना बनते हैं क्योंकि वे जटिल technical attack को इंसानी reflex में बदल देते हैं। अगर attacker reviewer से ऐसी request approve करवा सके जो सामान्य, जरूरी और जानी-पहचानी लगे, तो उसे credential चुराने की जरूरत नहीं पड़ती।

यह समस्या तब और गंभीर हो जाती है जब autonomous coding agents APIs call कर सकते हों या SSH commands चला सकते हों। Reviewer एक साथ pull request, terminal, chat window और notifications की लंबी सूची देख रहा हो सकता है। अगर approval surface अपना origin और scope साफ नहीं दिखाता, तो reviewer thumbnail देखकर security का काम कर रहा होता है।

समाधान लोगों को हर macOS dialog याद करवाना नहीं है। जिस व्यक्ति ने उन्हीं screenshots का अध्ययन किया हो, उसके बनाए lookalike window के सामने visual memory हार जाती है। Reviewers को approval को तीन बातों से जोड़ने का दोहराया जा सकने वाला तरीका चाहिए: request करने वाला process, होने वाली action और वह trusted जगह जहाँ approval लिया जा रहा है।

जानी-पहचानी window यह साबित नहीं करती कि वह किसकी है

System prompt जैसी दिखने वाली window तब तक केवल pixels है, जब तक आप उसे चल रहे process और किसी specific request से जोड़ न दें। Rounded corners, familiar button order, menu bar icon, Touch ID का उल्लेख और Apple जैसी भाषा origin साबित नहीं करते। वे केवल यह दिखाते हैं कि किसी को macOS का रूप पता है।

बात सीधे कहें तो यह अंतर स्पष्ट लगता है, फिर भी review की आदतें अक्सर इसे मिटा देती हैं। लोग पूछते हैं, «क्या यह उस prompt जैसी दिखती है जो मैंने पिछले हफ्ते देखा था?» बेहतर सवाल है, «इस request को किस process ने शुरू किया और इस window पर भरोसा किए बिना मैं उस process की जाँच कहाँ कर सकता हूँ?»

macOS users को software provenance की उपयोगी सुविधाएँ देता है। Apple अपने macOS documentation के App code signing process में बताता है कि Developer ID signature से users यह जाँच सकते हैं कि developer के sign करने के बाद software में बदलाव नहीं हुआ है। Apple इस दावे को notarization से अलग रखता है, जो जमा किए गए software में ज्ञात malicious content की जाँच करता है। ये controls महत्वपूर्ण हैं, लेकिन signed app द्वारा दिखाया गया हर sentence trusted authorization request नहीं बन जाता।

Malicious program unsigned हो सकता है, लेकिन signed भी हो सकता है। Legitimate program compromise हो सकता है। Legitimate program ऐसी action भी माँग सकता है जिसका मौजूदा task से कोई संबंध न हो। Dialog का visual design इन सवालों का जवाब नहीं दे सकता।

जब तक कुछ और साबित न हो, किसी भी approval display को इन चार चीजों में से एक मानें:

• macOS का अपना consent या authentication surface।
• उस app की window जिसे आप इस्तेमाल करना चाहते थे।
• ऐसी notification जो बताती है कि कोई app आपका ध्यान चाहता है।
• पहले तीन में से किसी जैसी दिखने वाली web page या overlay।

पहली category system controls का उपयोग कर सकती है, लेकिन केवल appearance देखकर approval का निर्णय न लें। बाकी categories application content हैं। वे उपयोगी हो सकती हैं, पर उनकी जाँच «मैं उस button का आकार पहचानता हूँ» से मजबूत तरीके से करनी होगी।

हर approval को actor, action और channel से जोड़ें

Reviewer तभी सही निर्णय ले सकता है जब approval actor, action और channel को एक साथ जोड़े। अधिकांश कमजोर prompts इनमें से केवल एक की पहचान करते हैं और बाकी का अनुमान लगाने की जिम्मेदारी इंसान पर डाल देते हैं।

Actor वह local process है जो request कर रहा है। Agent workflow में यह केवल «coding assistant» नहीं है। यह इस run के लिए शुरू किया गया concrete process है, जिसकी identifiable signing authority workflow दे सके तो वह भी स्पष्ट होनी चाहिए। अगर request सिर्फ «AI assistant को approval चाहिए» कहती है, तो उसने reviewer से सबसे उपयोगी तथ्य छिपा दिया है।

Action असली operation है। जब operation किसी named API endpoint पर production user बनाने की request हो, तब «Allow network access» action का विवरण नहीं है। «Approve SSH» भी पर्याप्त नहीं है, क्योंकि command read-only status check या destructive remote deployment, दोनों हो सकती है। Reviewer को verb, destination और tool द्वारा ईमानदारी से बताए जा सकने वाले परिणाम चाहिए।

Channel वह जगह है जहाँ decision पहुँचता है। Desktop notification delivery mechanism है। Browser page application interface हो सकती है। Native app window सही control plane हो सकती है। इनमें से कोई label अपने-आप safety की गारंटी नहीं देता। Reviewer को ऐसा expected channel चाहिए जिसे वह independently फिर से खोल सके।

व्यवहार में अंतर इस तरह दिखता है।

कमजोर request:

Deployment helper को permission चाहिए। Allow करें?

जाँच योग्य request:

Process: Terminal से चल रहा signed local agent run

Action: api.example.internal पर POST /v1/releases

Authority: production deployment credential

Scope: केवल यह request

Decision channel: चल रहा approval app

दूसरी request को भी reject किया जा सकता है। यह ठीक है। उसका काम approval को सुरक्षित महसूस कराना नहीं है। उसका काम requested authority को इतना स्पष्ट बनाना है कि इंसान निर्णय ले सके।

यह «trusted agents» के साथ होने वाली एक सामान्य गलती भी दिखाता है। किसी actor पर भरोसा करना उसकी हर action की permission नहीं है। Process जाना-पहचाना हो सकता है, जबकि उसका destination गलत हो। Destination अपेक्षित हो सकता है, लेकिन credential scope जरूरत से ज्यादा हो सकता है। Secure review flow इन तथ्यों को साथ रखता है, approval को सामान्य endorsement में नहीं बदलता।

Notifications को review बुलाना चाहिए, consent लेना नहीं

Notification interruption mechanism है, भरोसेमंद authorization surface नहीं। उसकी जगह सीमित होती है, वह desktop की हर दूसरी alert से प्रतिस्पर्धा करती है और उसमें quick click के लिए बनाया गया text हो सकता है। अगर notification कहती है, «तुरंत approve करें, deployment की अवधि खत्म होने वाली है», तो आपको यह जानने से पहले ही दबाव बनाया जा चुका है कि message किसने बनाया और deployment सच में मौजूद है या नहीं।

Apple की Notifications settings में users previews नियंत्रित कर सकते हैं, तय कर सकते हैं कि notifications lock screen पर दिखें या नहीं और display share या mirror होने पर वे दिखाई दें या नहीं। Apple users को app के अनुसार permissions और presentation settings manage करने देता है। ये controls unwanted exposure घटाते हैं, लेकिन notification text को trusted transaction record में नहीं बदलते।

Reviewers को notification का उपयोग केवल pointer की तरह करना चाहिए। App name पढ़ें, समय नोट करें और फिर known location से expected application खोलें। Request असली है तो application को वही pending action पर्याप्त context के साथ दिखानी चाहिए, ताकि उसका मूल्यांकन किया जा सके। अगर notification browser page, किसी दूसरे helper app या ऐसी window खोलती है जिसमें matching pending request नहीं है, तो रुक जाएँ।

Reviewers को यह approve करना न सिखाएँ कि notification icon सही दिख रहा है। Icons छोटे होते हैं, अपरिचित हो सकते हैं और मिलते-जुलते नामों से भ्रमित हो सकते हैं। महत्वपूर्ण सवाल यह है कि notification आपको उस control surface तक वापस ले जाती है या नहीं जिसे आप उस workflow के लिए पहले से अपेक्षित मानते हैं।

ऐसे tools के previews बंद करें जो locked screen पर sensitive destinations, account names या request details दिखा सकते हैं। Screen sharing के दौरान notifications बंद करें, जब meeting audience को उन्हें नहीं देखना चाहिए। ये confidentiality settings हैं, anti-spoofing controls नहीं, लेकिन वे pressure और leakage के एक उपयोगी स्रोत को हटा देती हैं।

High impact actions के लिए notification खास तौर पर खराब होती है, क्योंकि context मिलने से पहले ही reviewer को निर्णय लेना पड़ता है। सही व्यवहार जानबूझकर धीमा है: notification, expected app खोलना, request देखना, फिर approve या deny करना। यह extra motion केवल friction नहीं है। इससे attacker का message और click path, दोनों नियंत्रित करने का प्रयास टूटता है।

Overlays macOS की कमी नहीं, ध्यान का फायदा उठाते हैं

Lookalike approval window को खतरनाक बनने के लिए macOS के security controls तोड़ने की जरूरत नहीं होती। सामान्य application regular window बना सकती है, उसे दूसरी app के ऊपर रख सकती है, मिलता-जुलता title इस्तेमाल कर सकती है और किसी believable trigger के बाद उसे दिखा सकती है। Attack इसलिए काम करता है क्योंकि reviewer attribution की कमी खुद पूरी कर देता है।

आम धारणा बहुत सरल है: «Fake prompt जरूर special screen powers वाले malware ने बनाया होगा।» कभी-कभी malware broad permissions चाहता है, लेकिन convincing overlay के लिए हमेशा उनकी जरूरत नहीं होती। कोई भी app अपना content दिखा सकता है। Browser tab ऐसी web page दिखा सकता है जो consent screen जैसी लगे। Remote support session में operator narrative नियंत्रित करते हुए user से किसी step को approve करने के लिए कह सकता है।

Screen देखने की क्षमता को window बनाने की क्षमता न समझें। Apple Screen & System Audio Recording को Privacy & Security permission मानता है, जिसे users individual apps और websites के लिए allow या deny कर सकते हैं। यह screen और audio content capture को नियंत्रित करती है। यह किसी prompt को प्रमाणित नहीं करती और यह permission मिलने से आपके सामने मौजूद window के मालिक की पहचान नहीं होती।

Accessibility permissions के साथ भी यही सावधानी रखें। Legitimate software को interface elements के साथ interact करने के लिए इनकी जरूरत हो सकती है, लेकिन reviewer को यह नहीं मानना चाहिए कि Accessibility access वाले app की हर window system की है। Permission history investigation में मदद कर सकती है। Approval के समय वह proof नहीं बन सकती।

Overlay की उपयोगी जाँच decoration के बजाय behavior से शुरू होती है:

• क्या request आपके द्वारा शुरू की गई action के तुरंत बाद दिखाई दी?
• क्या expected application पर वापस जाकर उसे फिर खोलने पर वही request दिखाई देती है?
• क्या request destination और scope को आपके काम से मेल खाते शब्दों में बताती है?
• क्या वह password, recovery phrase या ऐसा secret माँगती है जिसकी इस workflow को कभी जरूरत नहीं होनी चाहिए?
• क्या वह आपको request की कहीं और जाँच करने से रोकने की कोशिश करती है?

आखिरी बात जितने खराब prompts पकड़ती है, लोग अक्सर उससे कम की उम्मीद करते हैं। असली control flow कुछ seconds की verification सहन कर सकता है। भ्रामक prompt अक्सर countdown बनाता है, कहता है कि window छोड़ते ही request fail हो जाएगी या reviewer को महसूस कराता है कि थोड़ी भी देरी नुकसान कर देगी।

भरोसेमंद spoof की sequence पहचानी जा सकती है

मान लें कि एक engineer agent से staging environment update करने को कहता है। Agent का terminal output कहता है कि API call के लिए approval चाहिए। लगभग उसी समय एक notification आती है: «Deployment authorization required. Open Security Center.»

Engineer उस पर click करता है। एक window खुलती है जिसका title familiar macOS security panel जैसा है। इसमें छोटा description, expected company domain से शुरू होने वाला destination और «Cancel» तथा «Allow» नाम वाले buttons हैं। इसमें Touch ID का भी उल्लेख है, हालांकि window कभी वास्तविक biometric check शुरू नहीं करती।

Engineer visual story स्वीकार कर ले तो deception सफल हो जाता है। एक साथ कई चीजें गलत हो सकती हैं:

1. Notification approval app के बजाय किसी दूसरे app से आई हो सकती है।
2. Click की गई notification ने actual approval control के बजाय browser page या helper tool खोला हो सकता है।
3. दिखाया गया destination lookalike domain, redirect या उस deployment request के बजाय broad account permission हो सकता है।
4. Agent शुरू करने वाला process approval माँगने वाले process से अलग हो सकता है।
5. Click के बाद action का कोई durable record न बचा हो, जिससे reviewer यह पता न लगा सके कि उसने क्या अनुमति दी।

इसीलिए review protocol को visually perfect imitation के सामने भी काम करना चाहिए। Engineer को दोनों buttons दबाए बिना window खुली छोड़नी चाहिए, menu bar या Applications folder से expected approval application सामने लानी चाहिए और मौजूदा agent run द्वारा बनाई गई pending request ढूँढनी चाहिए। Matching request न मिले तो popup polished होने से ज्यादा trustworthy नहीं हो जाती।

Matching request मिले तो दोनों descriptions की तुलना करें। Legitimate request में वही action, endpoint और authority होने चाहिए। अगर expected application SSH command दिखाती है, जबकि popup generic deployment approval बताता है, तो mismatch समझ आने तक दोनों को reject करें। Attackers को लाभ तब मिलता है जब reviewers partial match को confirmation मान लेते हैं।

मुश्किल यह है कि spoof अक्सर असली details का उपयोग करता है। उसे project name, environment name और real deployment का समय पता हो सकता है। ये details साबित करती हैं कि attacker के पास context है। वे यह साबित नहीं करतीं कि requested action expected process से संबंधित है।

Approval की जरूरत पड़ने से पहले installed app सत्यापित करें

जब कोई window कह रही हो कि action दस seconds में expire हो जाएगी, तब identity की सावधानी से जाँच करना मुश्किल है। Setup के दौरान expected application identity तय करें, उसे team documentation में दर्ज करें और सामान्य workday में verification path का परीक्षण करें।

Known path पर installed app के लिए यह command macOS को दिखाई देने वाली signing information दिखाती है:

codesign -dvvv "/Applications/Expected Approval App.app" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='

Output का सामान्य रूप यह होता है:

Identifier=com.example.approvals
TeamIdentifier=ABCDE12345
Authority=Developer ID Application: Example Software, Inc. (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

इन sample values को checklist में copy न करें। आपकी team ने जिस software को सामान्य software process से प्राप्त करके approve किया है, उसका identifier और team identifier दर्ज करें। Display name कमजोर evidence है, क्योंकि कई apps एक ही नाम इस्तेमाल कर सकते हैं। Bundle identifier और signing team आपको वे facts देते हैं जो window title नहीं दे सकता।

Installed bundle की assessment status के लिए दूसरी जाँच करें:

spctl -a -vv "/Applications/Expected Approval App.app"

Typical output में accepted जैसा assessment, साथ में source और origin शामिल होते हैं। macOS releases और distribution methods के बीच wording बदल सकती है, इसलिए ऐसा script न बनाएँ जो एक exact sentence की उम्मीद पर fail हो जाए। इसे investigation aid की तरह इस्तेमाल करें: unexpected rejection, origin, path या signing identity रुककर जाँच करने का कारण है।

Apple का Gatekeeper documentation बताता है कि macOS default settings में downloaded software के identified developer, notarization और alteration की जाँच करता है। यह launch path की सुरक्षा करता है, जो जरूरी है। लेकिन इससे यह जाँचना अनावश्यक नहीं हो जाता कि app इस समय सही action माँग रहा है या नहीं।

Teams को application name, सामान्य install location, bundle identifier, signing team और updates की जिम्मेदारी रखने वाले व्यक्ति का compact record रखना चाहिए। इसे उसी internal जगह पर रखें जहाँ लोग environment names और incident contacts ढूँढते हैं। Update से इनमें कोई तथ्य बदलता है तो approval event के दौरान फिर से खोजने के बजाय update process के हिस्से के रूप में बदलाव की समीक्षा करें।

आसान लेकिन गलत विकल्प से बचें: «यह Applications में है, इसलिए सही ही होगा।» Applications एक location है, identity assertion नहीं। Copied या मिलते-जुलते नाम वाला bundle भी वहाँ हो सकता है। Path आपको inspect करने के लिए stable object देता है। Signature identity claim देती है। आपकी team process तय करती है कि वह identity अपेक्षित है या नहीं।

Independent path से request की समीक्षा करें

जब approval दिखाई दे, हर बार वही छोटा routine अपनाएँ। सामान्य requests में इसमें एक minute से कम लगना चाहिए और यह तब भी काम करना चाहिए जब पहली window पूरी तरह fake हो।

1. पहले prompt पर रुकें। यह जाने बिना allow, dismiss या embedded link follow न करें कि उसे किसने खोला।
2. Expected action को सरल शब्दों में कहें। उदाहरण: «मैंने staging agent से deployment status पढ़ने को कहा था।» अगर request production write, SSH session या broad account access बताती है, तो discrepancy पहले ही मौजूद है।
3. Expected menu bar item, Applications location या known launcher से approval application independently खोलें। Suspicious window को navigation control के रूप में इस्तेमाल न करें।
4. Pending request ढूँढें और initiating process, action, destination, authority तथा scope की तुलना करें। केवल matching process name पर्याप्त नहीं है।
5. Current task पूरा करने वाली सबसे छोटी request ही approve करें। जो request अस्पष्ट, जरूरत से व्यापक या आपके शुरू किए काम से inconsistent हो, उसे deny करें।

यह routine एक लोकप्रिय लेकिन खराब recommendation को अस्वीकार करता है: «किसी familiar agent को एक बार approve कर दें, फिर वह परेशान नहीं करेगा।» यह इसलिए लोकप्रिय है क्योंकि बार-बार आने वाले prompts परेशान करते हैं और agents को अक्सर कई संबंधित calls की जरूरत होती है। यह गलत है क्योंकि prompt की संख्या design problem है, review boundary हटाने का कारण नहीं।

बेहतर design मौजूदा run के दौरान किसी single known process को authorize कर सकता है, जबकि sensitive authorities के लिए अलग confirmation बनी रहे। Reviewer को कम repetitive decisions लेने पड़ते हैं, लेकिन vague category of work को permanent permission नहीं मिलती।

Sallyport इस विभाजन का सीधे उपयोग करता है: नए agent process को session authorization request मिलती है, जिसमें process की code-signing authority पहचानी जाती है, जबकि credential को हर उपयोग पर approval की जरूरत के लिए mark किया जा सकता है। Agent को secret कभी नहीं मिलता, इसलिए approval यह तय करता है कि app action करे या नहीं, credentials agent को सौंपे नहीं जाते।

असली incident में यह अंतर महत्वपूर्ण है। अगर agent run अजीब व्यवहार करने लगे तो उसका session revoke करें। Agent के अगले approval point तक पहुँचने का इंतजार न करें। Session boundary reviewer को उस process की future action रोकने का तरीका देती है, बिना यह मानने के कि पहले approve की गई हर capability अभी भी उचित है।

Approval wording में urgency से पहले scope स्पष्ट होना चाहिए

Teams warning language को polish करने में बहुत समय लगाती हैं और approval में शामिल किए जाने वाले facts तय करने में बहुत कम। कमजोर prompt में बेहतर sentence भी कमजोर ही रहता है। जरूरी facts वाला थोड़ा साधारण sentence ज्यादा सुरक्षित है।

Action पहले रखें। «Production में release बनाएँ» reviewer को बताता है कि क्या होने वाला है। «Deployment workflow authorize करें» operation को internal label के पीछे छिपा देता है।

फिर destination रखें। Hostname, repository, account या remote host reviewer को बताता है कि authority कहाँ जाएगी। अगर system destination का नाम नहीं दे सकता क्योंकि उसे वह पता ही नहीं है, तो उसे ऐसा कहना चाहिए। Missing context की जगह «trusted service» जैसी reassuring phrase नहीं रखनी चाहिए।

Scope को इंसानी भाषा में बताएँ। Known endpoint पर एक GET request की अनुमति session की हर call के लिए उपलब्ध credential से materially अलग है। One-command SSH approval unrestricted shell से अलग है। Prompt को actual boundary बतानी चाहिए, aspirational boundary नहीं।

Reviewer जो नहीं देख सकता, उसके बारे में ईमानदार रहें। अगर tool केवल इतना जानता है कि agent SSH connection शुरू करेगा, तो उसे यही कहना चाहिए, यह नहीं जताना चाहिए कि उसने हर remote command देख ली है। False precision लोगों को ऐसे labels पर भरोसा करना सिखाती है जो enforcement से मेल नहीं खाते।

इन vague action names से खास तौर पर बचें:

• «Continue»
• «Grant access»
• «Complete setup»
• «Verify identity»
• «Allow agent operation»

हर phrase reviewer से कहती है कि वह context से अर्थ निकाले। अगर वह context attacker-controlled terminal message, chat message, notification या popup से आया है, तो reviewer spoof का हिस्सा बन गया है।

अच्छा approval flow refusal को सामान्य परिणाम भी बनाता है। «Deny» किसी खतरनाक exception जैसा नहीं दिखना चाहिए। उसे action रोकना चाहिए, reviewer को बाद में जाँचने के लिए पर्याप्त information बचानी चाहिए और request ठीक करने के बाद user को retry करने देना चाहिए। जब denial catastrophic लगता है, users अटकने से बचने के लिए approve कर देते हैं।

Logs suspicion को investigation में बदलते हैं

संदिग्ध approval के बाद screen को evidence मानना बंद करें। Screens गायब हो जाती हैं, windows झूठ बोल सकती हैं और memory जल्दी बदल जाती है। इस बात का record सुरक्षित रखें कि कौन-सा process चला, उसने कौन-सी action माँगी, reviewer ने क्या निर्णय लिया और action destination तक पहुँची या नहीं।

पहले time range capture करें। फिर agent transcript, run से संबंधित terminal history और approval tool की action history save करें। जिस application ने request दिखाई उसका exact path दर्ज करें। अगर suspicious item notification के जरिए आया था, तो उसका displayed app name और यह भी लिखें कि खोलने पर browser, helper या expected application में से क्या खुला।

संदिग्ध app को delete करके शुरुआत न करें। Internal investigation के लिए evidence बचाना हो तो पहले उसका path और signing details दर्ज करें। Machine compromised हो सकती है तो अपनी team की incident process अपनाएँ और उचित रूप से उसे isolate करें। Prompt spoofing event social attack, local unwanted app, browser compromise या legitimate tool की design flaw हो सकता है। Evidence बताएगा कि समस्या कौन-सी है।

Agent actions के लिए log में दो स्तर होने चाहिए। एक record run का विवरण दे और operator को उसे revoke करने दे। दूसरा individual calls का विवरण दे, जिसमें destination और decision शामिल हों। पहले के बिना live actor को साफ तरीके से रोकना संभव नहीं होगा। दूसरे के बिना यह पता नहीं चलेगा कि approval ने वास्तव में क्या enable किया।

Sallyport encrypted, hash-chained audit log से session और individual activity records दोनों project करता है, और sp audit verify ciphertext पर offline chain सत्यापित कर सकता है। इससे खराब approval harmless नहीं हो जाता, लेकिन reviewer और investigator को popup गायब होने के बाद उस महत्वपूर्ण सवाल का स्थायी जवाब मिलता है: इस process ने वास्तव में कौन-सी action की?

उद्देश्य हर reviewer को macOS security specialist बनाना नहीं है। उद्देश्य safe action को सामान्य बनाना है: suspicious surface से हटें, expected control plane फिर खोलें, facts की तुलना करें और केवल वही request approve करें जो आपके सामने चल रहे काम से मेल खाती हो। जो prompt इस जाँच में टिक नहीं सकता, वह click का हकदार नहीं है।