क्या आपका Touch ID access review agent approvals को कवर करता है?

फिंगरप्रिंट enrollment में बदलाव access change होता है। इसे नए administrator account, दूसरे व्यक्ति को दिए गए laptop या recovered device जितनी गंभीरता से लें, क्योंकि इससे यह बदल जाता है कि agent के कार्रवाई करने के समय biometric approval prompt कौन पूरा कर सकता है।

यह बात तब तक साफ लगती है जब तक deployment का इंतजार न हो रहा हो, कोई यह न कह दे कि उसने laptop अनलॉक करने के लिए अपने जीवनसाथी की उंगली भी दर्ज कर दी है, और टीम को याद न आए कि यही मशीन production credentials के इस्तेमाल को मंजूरी दे सकती है। मैंने टीमों को agent के लिए सावधानी से नियंत्रण बनाते देखा है, लेकिन physical computer को अपने access process से बाहर छोड़ दिया। कमजोरी आम तौर पर cryptography नहीं होती। अक्सर समस्या एक ऐसे सुविधाजनक shortcut की होती है जिसे किसी ने दर्ज नहीं किया।

यह runbook जोड़े गए और हटाए गए फिंगरप्रिंट, Mac के मालिकाना हक में बदलाव और biometric lockout को कवर करता है। इसमें माना गया है कि AI agent HTTP requests या SSH connections तभी कर सकता है जब कोई व्यक्ति कार्रवाई के रास्ते को मंजूरी दे। अपनी टीम के स्थानीय roles और escalation contacts के नाम बदल लें, लेकिन निर्णय के महत्वपूर्ण बिंदुओं को हल्का न करें। अगर आप यह तय नहीं कर सकते कि Mac को कौन नियंत्रित करता है, तो उस Mac से महत्वपूर्ण कार्रवाइयों को मंजूरी न लेने दें।

फिंगरप्रिंट बदलने से approval boundary बदलती है

जोड़ा गया फिंगरप्रिंट किसी व्यक्ति को पिछले मालिक वाली उसी biometric boundary को पार करने की अनुमति दे सकता है। इसलिए मशीन से किसी दूसरे agent action को मंजूरी लेने से पहले मालिक को इसकी समीक्षा करनी चाहिए। सवाल यह नहीं है कि नया फिंगरप्रिंट किसी भरोसेमंद परिवारजन, teammate या IT technician का है या नहीं। सवाल यह है कि क्या उस व्यक्ति के पास अब ऐसे credentials से जुड़ी गतिविधि को मंजूर करने का व्यावहारिक रास्ता है जिन्हें वह manage नहीं करता।

Apple की Touch ID guidance बताती है कि फिंगरप्रिंट डिवाइस पर दर्ज होते हैं और कुछ घटनाओं के बाद macOS Touch ID स्वीकार करने के बजाय password मांग सकता है। यह fallback उपयोगी है, लेकिन इससे enrollment change कोई मामूली preference नहीं बन जाता। Mac पर अब भी ऐसा password वाला account चाहिए जिसके पास enrollment manage करने का पर्याप्त अधिकार हो, और physical possession अब भी मायने रखती है।

जब भी कोई फिंगरप्रिंट जोड़ता या हटाता है, यह review चलाएं, चाहे बदलाव जानबूझकर हुआ हो या support work के दौरान। Mac के लिए जिम्मेदार व्यक्ति को shared infrastructure तक पहुंच रखने वाले किसी agent का इस्तेमाल करने से पहले इसे पूरा करना चाहिए।

1. मौजूदा device owner और उस local account की पहचान करें जो Touch ID enrollment नियंत्रित करता है। team alias नहीं, मालिक का नाम लिखें।
2. मालिक की मौजूदगी में Mac की Touch ID settings खोलें। दर्ज फिंगरप्रिंट की तुलना अपेक्षित users से करें। हर फिंगरप्रिंट के होने का कारण पूछें।
3. पुष्टि करें कि कौन से local accounts Mac को unlock, administer और device settings बदल सकते हैं। Account review के बिना fingerprint review मंजूरी के रास्ते का आधा हिस्सा छोड़ देता है।
4. बदलाव से पहले चल रहे सभी agent runs समाप्त करें। बदली हुई approval boundary के बाद पिछला authorization decision जारी न रखें।
5. उन credentials की समीक्षा करें जिन्हें agent इस Mac से इस्तेमाल कर सकता है। समीक्षा पूरी होने तक सबसे महत्वपूर्ण credentials के लिए नई human confirmation आवश्यक करें।

असहज मामला support technician का होता है। मशीन की मरम्मत के लिए technician को password और physical access की जरूरत पड़ सकती है, लेकिन इससे उसे अपने आप agent actions मंजूर करने का स्थायी अधिकार नहीं मिल जाता। अगर support enrollment से बचना संभव न हो, तो repair closeout के हिस्से के रूप में वह फिंगरप्रिंट हटा दें और यह दर्ज करें कि ऐसा किया गया। "fixed Touch ID" लिखी ticket इस बात का रिकॉर्ड नहीं है कि repair के दौरान production access को कौन मंजूर कर सकता था।

लोगों से यह वादा करने को न कहें कि वे prompt को छुएंगे नहीं। प्रक्रिया इस तथ्य पर आधारित बनाएं कि shared physical access जोखिम बदलता है। जब confirmation routine लगे, खासकर तब जब agent तेजी से काम कर रहा हो और request रोजमर्रा के काम जैसी दिखे, लोग गलतियां करते हैं।

हर कॉल की मंजूरी के लिए किसी नामित व्यक्ति का निर्णय जरूरी है

Per-call approval तभी सुरक्षित है जब मंजूरी देने वाला व्यक्ति prompt के समय action, credential और उसके परिणाम को पहचान सके। Touch ID यह साबित कर सकता है कि दर्ज व्यक्ति ने Mac से interaction किया। यह साबित नहीं कर सकता कि उस व्यक्ति ने तीस सेकंड पहले agent द्वारा किए गए request को सही तरह समझा था।

यह अंतर लगातार धुंधला किया जाता है। Biometric prompt को अक्सर identity check कहा जाता है और फिर authorization review की तरह इस्तेमाल किया जाता है। दोनों जुड़े हुए हैं, लेकिन अलग सवालों का जवाब देते हैं। Identity पूछती है कि sensor को किसी enrolled user ने छुआ या नहीं। Authorization पूछता है कि उस user को अभी यह call मंजूर करनी चाहिए या नहीं। जो टीम दोनों को मिला देती है, वह destructive request को login screen जैसी निश्चितता के साथ मंजूर कर देगी।

Approval rule साधारण भाषा में लिखें। उदाहरण के लिए: "ऐसी हर call जो production deployment बदल सकती है, लंबे समय तक चलने वाला token बना सकती है, billing बदल सकती है या संगठन के बाहर data भेज सकती है, उसके लिए मौजूदा service owner को उसका निरीक्षण करके approval देना होगा।" यह rule बताता है कि मानवीय निर्णय किसे लेना है। यह दिखावा नहीं करता कि निर्णय केवल fingerprint ने लिया।

Approval prompt में उपयोगी context भी होना चाहिए। स्वीकार करने से पहले reviewer को agent की private reasoning दोबारा बनाए बिना इन सवालों का जवाब मिल जाना चाहिए:

• Call किस agent process ने की?
• Call किस credential का इस्तेमाल करेगी?
• Request या SSH command किस destination को भेजी जाएगी?
• Call सफल होने पर कौन सा operation होगा?
• यह व्यक्ति, इस Mac पर, इसे मंजूर करने के लिए अधिकृत क्यों है?

अगर आपका prompt इन सवालों का जवाब नहीं दे सकता, तो access बढ़ाने से पहले workflow ठीक करें। "Agent को permission चाहिए" जैसा generic request approval theater बनाता है। लोग इसलिए click करते हैं क्योंकि उपयोगी काम करने से पहले वे blocked हैं, इसलिए नहीं कि उन्होंने सोच-समझकर निर्णय लिया है।

Sallyport इस अंतर को स्पष्ट रखता है: locked vault हर action को रोकता है, session authorization एक agent process के exit होने तक उस process को कवर करता है, और किसी credential के हर उपयोग पर approval आवश्यक की जा सकती है। यह तय क्रम exceptions के तात्कालिक संग्रह से अधिक आसानी से review किया जा सकता है, बशर्ते टीम biometric confirmation को human decision माने, किसी जादुई stamp को नहीं।

रोजमर्रा की कम-प्रभाव वाली calls के लिए per-session approval उचित हो सकता है। इससे हर harmless read की पुष्टि कराए बिना व्यक्ति किसी run पर नियंत्रण बनाए रखता है। जहां एक call स्थायी बदलाव कर सकती है या महत्वपूर्ण data उजागर कर सकती है, वहां per-call approval इस्तेमाल करें। केवल सख्त दिखने के लिए हर credential पर इसे न लगाएं। बहुत सारे prompts लोगों को बिना सोचे approval देने की आदत डाल देते हैं। फिर महत्वपूर्ण prompt भी बाकी prompts जैसा ही लगता है।

Ownership transfer में custody break जरूरी है

जब Mac किसी दूसरे व्यक्ति के हाथ में जाता है, तो नया मालिक उसका इस्तेमाल करने से पहले पुराने मालिक की actions approve करने की क्षमता समाप्त होनी चाहिए। Handoff तब पूरा नहीं होता जब laptop दूसरी desk पर पहुंच जाए या device-management inventory बदल जाए। यह तब पूरा होता है जब मशीन का local access, enrolled biometrics, vault access, active sessions और credentials नई custody arrangement से मेल खाने लगें।

सबसे तेज सुरक्षित तरीका clean reprovisioning है। Company-owned Mac को erase करके संगठन की सामान्य management process के जरिए नए मालिक के लिए set up करें। इससे पुराने local accounts, भूले हुए fingerprints, browser sessions, cached tokens और transfer के बाद बच गए development tools के बारे में अनुमान लगाने की जरूरत नहीं रहती। Reprovisioning में समय लगता है, लेकिन खराब transfer के बाद forensic guessing में उससे अधिक समय लगता है।

कभी-कभी clean rebuild संभव नहीं होता क्योंकि मशीन पर local development state होती है जो अभी move नहीं हुई। तब temporary transfer procedure अपनाएं और end date तय करें। "बाद में साफ कर लेंगे" को production-capable Mac की स्थायी स्थिति न बनने दें।

Temporary transfer का क्रम यह होना चाहिए:

1. पुराना owner services से sign out करे, vault lock करे और हर agent run रोक दे। नए owner को जितनी development material चाहिए, उसे approved path से ही export करें।
2. Administrator पुराने owner का local account हटाए या company policy के अनुसार disable करे। Restart के बाद पुराना owner login नहीं कर सकता, इसकी पुष्टि करें।
3. नया owner अपना local account और fingerprint enroll करे। Administrator और नया owner दोनों की मौजूदगी में enrollment list जांचें।
4. Access को सोच-समझकर फिर से बनाएं। पुराने account से credentials, SSH private keys, browser profiles या local secret files copy न करें, क्योंकि copying से ऐसा access भी बच सकता है जिसका आपको पता न चले।
5. नए owner द्वारा पहली approved agent call करने के बाद activity record की समीक्षा करें। पुष्टि करें कि process, destination और credential नए owner के काम से मेल खाते हैं।

Mac ownership और credential ownership अलग बातें हैं। Contractor कुछ समय के लिए मशीन अपने पास रख सकता है, जबकि service owner कोई employee बना रह सकता है। ऐसी स्थिति में contractor को केवल device अपने पास होने के कारण approving party न बनाएं। Credential को उस workflow के लिए unavailable रखें या वास्तविक service owner से approved device पर confirmation करवाएं।

Display name बदलकर और पुरानी profile रखकर transfer हल करने की कोशिश न करें। यह तरीका लोकप्रिय है क्योंकि tools बचे रहते हैं और धीमा setup नहीं करना पड़ता। Agent activity को authorize कर सकने वाली मशीन के लिए यह गलत है, क्योंकि इससे कई अनदेखे रास्ते खुले रहते हैं: saved passwords, SSH configuration, command history, local repositories और recovery methods तक पहुंच। Workstation setup में सुविधा की जगह है। बदले हुए custodian के evidence trail में इसकी जगह नहीं है।

हटाए गए फिंगरप्रिंट के लिए मौखिक आश्वासन नहीं, प्रमाण चाहिए

फिंगरप्रिंट हटाने से approval तक पहुंचने का एक रास्ता कम होता है, लेकिन इससे यह साबित नहीं होता कि पूर्व user ने Mac तक पहुंच खो दी है। Review में यह स्थापित होना चाहिए कि वह व्यक्ति किसी अन्य local account, administrator credential, recovery method या पहले से खुले session के जरिए authenticate नहीं कर सकता।

Departures और role changes के बाद यह खास तौर पर महत्वपूर्ण है। Manager किसी employee के service पर काम बंद करने के बाद उसका fingerprint हटाने को कह सकता है। यह अच्छा पहला कदम है, लेकिन अगर employee को login password अब भी पता हो, administrator account बचा हो या shared desk पर device unlocked रहता हो, तो इससे झूठा भरोसा पैदा हो सकता है।

Mac से fingerprint हटाए जाने पर यह evidence set इस्तेमाल करें:

• मौजूदा owner Touch ID settings खोलकर पुष्टि करे कि fingerprint मौजूद नहीं है।
• Administrator यह सत्यापित करे कि former local accounts लागू retention procedure के अनुसार disabled या removed हैं।
• मौजूदा owner screen lock करे, Mac restart करे और पुष्टि करे कि केवल approved लोग desktop पर लौट सकते हैं।
• Service owner समीक्षा करे कि removal से पहले कौन से credentials उपलब्ध थे और तय करे कि किसी को rotate करना है या नहीं।
• Reviewer access change का समय, शामिल लोगों और checks के नतीजे दर्ज करे।

Restart उपयोगी है क्योंकि इससे पहले से unlocked computer की आरामदेह लेकिन भ्रामक स्थिति समाप्त हो जाती है। यह टीम को उस password path का सामना भी कराता है जिसे Touch ID आम तौर पर छिपा देता है। अगर former user अब भी login screen पार कर सकता है, तो fingerprint वह access boundary नहीं था जो आपने समझी थी।

Credential को तब rotate करें जब former person को उसकी पहुंच थी, वह उसे copy कर सकता था या Mac unlocked होने के दौरान calls approve कर सकता था। केवल इसलिए rotate न करें कि routine change के महीनों बाद किसी ने fingerprint हटाया, अगर आप दिखा सकते हैं कि credential कभी उसके सामने उजागर नहीं हुआ और device controlled custody में रहा। Rotation की लागत होती है, और बिना सोचे हर credential rotate करने से लोग जरूरत पड़ने पर भी इसे टालने लगते हैं। निर्णय को ritual से नहीं, व्यक्ति की वास्तविक क्षमता से जोड़ें।

यह agent sessions revoke करने का भी समय है। Session approval किसी खास access condition में चल रहे किसी खास process के बारे में दिया गया statement है। अधिकृत व्यक्ति या biometric enrollment बदलते ही वह statement समाप्त हो जाता है। Agent restart करना आसान है। Custody change के बाद पुराने process ने access क्यों बनाए रखा, यह समझाना आसान नहीं है।

Biometric lockout में पहले containment करें

Touch ID lockout होने पर approvals रोक दें, जब तक टीम possession की पुष्टि करके intended recovery path से access बहाल न कर दे। Lockout सामान्य कारणों से हो सकता है: बार-बार असफल प्रयास, restart, sensor की समस्या या macOS का account password मांगना। यह ठीक उस समय भी हो सकता है जब किसी पर किसी भी तरह control के आसपास रास्ता खोजने का दबाव हो।

Machine को unlocked छोड़कर, chat में account password साझा करके या credential को agent configuration file में डालकर प्रतिक्रिया न दें। ये कदम तुरंत prompt हल कर सकते हैं, लेकिन लंबी incident पैदा करते हैं। केवल इसलिए कि कोई व्यक्ति biometric confirmation पूरी नहीं कर पा रहा, agent को secret कभी नहीं मिलना चाहिए।

इस containment sequence का उपयोग करें:

1. Agent run रोकें या उसका authorization revoke करें। Agent process और उस action को दर्ज करें जिसे वह करने वाला था।
2. Physical custody स्थापित करें। पूछें कि Mac किसके पास है, वह कहां रहा है और unlocked रहते किसी approved group के बाहर के व्यक्ति ने उसका उपयोग तो नहीं किया।
3. अगर owner मौजूद और authorized है, तो सामान्य macOS path से local account password का उपयोग करें। Restart के बाद password मांगना expected behavior है, यह प्रमाण नहीं कि Touch ID fail हो गया।
4. अगर owner authenticate नहीं कर सकता, तो device को approved support या recovery process में दें। किसी दूसरे व्यक्ति के account या fingerprint से काम चलाने की कोशिश न करें।
5. Recovery के बाद enrollment list, local accounts और किसी भी attempted agent actions की समीक्षा करके ही approval capability बहाल करें।

पांचवें step पर टीमें अक्सर लापरवाह हो जाती हैं। Desktop फिर दिखाई देता है और वे incident खत्म घोषित कर देते हैं। Recovery यह साबित करती है कि किसी ने access वापस पा लिया। यह नहीं बताती कि lockout ने hardware problem, unauthorized attempts, बदली हुई fingerprint list या छोड़े गए agent session को छिपाया था या नहीं। Event ताजा रहते दो मिनट निकालकर इन सवालों के जवाब दें।

Urgent release के दौरान हुआ lockout भी इसी treatment का हकदार है। अगर संगठन के पास कोई दूसरा approved machine है तो release decision वहां ले जाएं। अगर नहीं है, तो consequential action रोक दें। यह जवाब किसी को परेशान करेगा, लेकिन time pressure में credential boundary कमजोर करने और बाद में यह पता चलने से बेहतर है कि exception ही documented process बन गया।

अनिश्चितता के दौरान vault gate पूरी तरह बंद रहना चाहिए

जब Mac की custody या biometric state अनिश्चित हो, तो जिम्मेदार व्यक्ति के इसे सुलझाने तक vault boundary पर access deny करें। ऐसी conditional rule जो investigation के दौरान कुछ agent calls जारी रखने दे, समझना कठिन और दुरुपयोग करना आसान बनाती है।

यहीं simple control model उपयोगी साबित होता है। अगर locked vault सभी actions deny करता है, तो operator को device review के दौरान यह हिसाब नहीं लगाना पड़ता कि कोई HTTP request पर्याप्त harmless है या नहीं। वह vault lock करता है, प्रभावित sessions रोकता है और checks करता है। कीमत एक छोटी interruption है। लाभ यह है कि बाद में पूछे जाने वाले सवाल का साफ जवाब मिलता है: क्या device access पर संदेह रहते agent काम कर सकता था?

Sallyport का vault supported Macs पर Secure Enclave और Touch ID के जरिए hardware-gated है, और उसका lock state actions को deny करता है। इससे custody review की जरूरत खत्म नहीं होती। इससे reviewer को एक साफ containment control मिलता है, जब तक वह यह स्थापित करता है कि computer किसके पास है और उसकी approval requirements कौन पूरी कर सकता है।

इस control को बढ़ाकर यह दावा न करें कि vault locked होने पर Mac हमेशा सुरक्षित है। Mac पर source code, browser sessions, work notes या व्यापक authority वाला local account अब भी हो सकता है। Vault gate केवल उसके जरिए होने वाली actions की रक्षा करता है। Transfer और incident procedures को बाकी workstation की भी सुरक्षा करनी होगी।

यही सीमा किसी भी audit record पर लागू होती है। Record यह दिखा सकता है कि agent ने कोई action attempt या complete किया। यह नहीं बता सकता कि किसी ने former owner को password type करते देखा था या नहीं, unlocked machine unattended पड़ी थी या नहीं, या supervisor prompt को समझ पाया था या नहीं। Logs review में मदद करते हैं, review खुद नहीं करते।

Audit entries में device event को action से जोड़ना चाहिए

Access review तब उपयोगी होती है जब बाद का investigator fingerprint या ownership event को उसके आसपास हुई agent activity से जोड़ सके। एक concise record रखें जिसमें physical change, local account checks, affected sessions और credential decision एक साथ जुड़े हों।

छोटी टीम के लिए controlled ticket या security journal पर्याप्त है। अपनी internal procedure के अनुसार Mac asset identifier या serial number, previous और current custodian, event type, reviewer, time window और result दर्ज करें। फिर agent session record और individual action record के references जोड़ें। Ticket में passwords, fingerprint images, recovery keys या copied secrets न रखें।

Record इस रूप में हो सकता है:

Event: Touch ID enrollment removed
Mac custodian before: Development contractor
Mac custodian after: Platform engineer
Observed by: Device administrator
Local-account result: Former account disabled and restart check passed
Agent result: Active sessions revoked at 14:32 UTC
Credential result: Deployment credential rotated after access review
Follow-up: Clean reprovision scheduled before reassignment

इस artifact का उद्देश्य paperwork नहीं है। यह सबसे नुकसानदेह ambiguity रोकता है: एक व्यक्ति मानता है कि device का मालिक बदल गया, दूसरा मानता है कि agent approval जारी रही, और तीसरा यह समझता है कि meeting में इसका उल्लेख होने के कारण credential rotation हो गई। हर claim के साथ observable result होना चाहिए।

Sallyport session और call records को write-blind encrypted, hash-chained audit log से project करता है। उसका offline sp audit verify check vault material की जरूरत के बिना यह स्थापित कर सकता है कि encrypted chain अब भी verify होती है या नहीं। Integrity के प्रमाण को अपने custody record के साथ रखें। Valid chain अधूरे handoff को पूरा नहीं बनाती।

बाद में records की समीक्षा करके ऐसे patterns देखें जो process की समस्या की ओर इशारा करते हैं: release के आसपास बार-बार lockout, लगातार होने वाले support enrollments, अस्पष्ट owners वाली machines से approvals या per-call review के लिए चिह्नित credentials जिनका लोग इस्तेमाल नहीं करते क्योंकि हर prompt में context नहीं होता। ये design problems हैं। इन्हें report करने वाले व्यक्ति को दंड न दें। उस workflow को बदलें जिसने workaround को आकर्षक बनाया।

Shared Macs व्यक्तिगत biometrics को टीम का जोखिम बना देते हैं

एक से अधिक लोगों द्वारा इस्तेमाल किया जाने वाला Mac sensitive agent actions की approval station नहीं होना चाहिए, जब तक टीम clear custody तय करके उसे लागू न कर सके। Shared workstations labs, build rooms और temporary incident spaces में आम हैं। वे काम जल्दी कराने में सुविधाजनक हैं, लेकिन यह साबित करने में कमजोर हैं कि permission decision किसने लिया।

आम बचाव यह होता है कि हर व्यक्ति का अपना login है। इससे मदद मिलती है, लेकिन तब पर्याप्त नहीं होता जब लोग एक-दूसरे के passwords जानते हों, handoffs के लिए sessions खुले छोड़ते हों या किसी helpful coworker को prompt पार करने के लिए अपना fingerprint इस्तेमाल करने देते हों। Cooperative team का social norm अक्सर technical separation को हरा देता है।

हर approval-capable Mac के लिए एक primary custodian नियुक्त करें। वही व्यक्ति enrollment review, lock state और machine के स्थान या user बदलने पर escalation का जिम्मेदार हो। अगर टीम को shared incident workstation चाहिए, तो उसे credential approval path से बाहर रखें या ऐसी procedure अपनाएं जिसमें authorized service owner अपने controlled device से approval दे।

Physical convenience को credential reach से अलग रखें। Shared Mac documentation, dashboards और read-only agent work host कर सकता है, बिना production credentials तक पहुंच का रास्ता रखे। जैसे ही वह agent को shared systems बदलने की अनुमति देने लगे, उसके स्थान, account setup और biometric enrollment में किसी भी privileged workstation जैसा अनुशासन चाहिए।

Monitor पर "do not use Touch ID" का sign लगाकर भरोसा न करें। Sign केवल intention बताता है। Intended owner अनुपस्थित होने पर system को action deny करना चाहिए और process को उस अनुपस्थिति को स्पष्ट बनाना चाहिए। अगर आपकी टीम यह नहीं बता सकती कि Mac को कौन unlock, approve और recover कर सकता है, तो उसे approval path से हटा दें।

अगली agent run से पहले पहली review हो जानी चाहिए

Enrollment, removal, ownership change या lockout के तुरंत बाद review चलाएं, क्योंकि normal work फिर शुरू होने से पहले evidence सबसे साफ होता है। Quarterly access review तक इंतजार करने पर specific event memory test बन जाता है, और शांत exceptions अक्सर memory में ही गायब हो जाते हैं।

Device अपने हाथ में लेकर शुरुआत करें। Custodian की पहचान करें, enrolled fingerprints और local accounts जांचें, कुछ अस्पष्ट हो तो access lock या revoke करें, फिर पुराने agent sessions समाप्त करें। इसके बाद तय करें कि प्रभावित credentials को rotate करना है या नहीं और relevant action history के साथ result दर्ज करें।

मुश्किल हिस्सा macOS settings खोलना नहीं है। मुश्किल यह मानने से इनकार करना है कि physical-access change केवल व्यक्तिगत सुविधा का मामला है, जबकि वही Mac agent को वास्तविक credentials इस्तेमाल करने की मंजूरी दे सकता है। इस boundary को स्पष्ट रखें और अगला urgent prompt ऐसा निर्णय बनेगा जिसे आप उचित ठहरा सकेंगे।