# Developer Mac बदलते समय agent credentials rotate करना

Developer Mac बदलना file transfer नहीं, access change है। आपके editor settings, repositories, shell history और local build cache सामान्य migration tools से move हो सकते हैं। लेकिन production APIs call करने या SSH sessions खोलने वाले AI agent credentials के लिए अलग योजना चाहिए।

सबसे आम गलती यह है कि लोग पुराने Mac को suitcase समझ लेते हैं। Developer नया कंप्यूटर तैयार करता है, Migration Assistant चलाता है, परिचित desktop देखता है और मान लेता है कि काम पूरा हो गया। वास्तव में वर्षों की permissions, cached tokens, भूली हुई SSH identities और agent tooling बिना यह जांचे trust boundary पार कर सकते हैं कि उनमें से क्या बचा है।

## Data को authority से अलग move करें

Files की copies बनती हैं। Authority का अर्थ है Mac के बाहर कोई काम करने की लगातार क्षमता। पुराना laptop घर से बाहर चले जाने के बाद भी API token deployment बना सकता है। Private half कॉपी, backup या erase हो जाने के बाद भी SSH public key किसी server पर स्वीकार की जा सकती है। Cloud session तब तक खुद refresh हो सकता है, जब तक उसका issuer उसे revoke न कर दे।

यह फर्क replacement plan बदल देता है। Source code, notes और nonsecret configuration जल्दी कॉपी की जा सकती हैं, क्योंकि बाद में उनकी तुलना की जा सकती है। Authority को तब तक रोकें, जब तक यह तय न हो जाए कि नए Mac को वही credential चाहिए, नया credential चाहिए या किसी credential की जरूरत ही नहीं है।

Agent tooling इस फर्क को और महत्वपूर्ण बना देता है। सामान्य developer expired token आने पर command दर्ज कर सकता है। Autonomous coding agent तेजी से calls कर सकता है, उन्हें दोहरा सकता है और तब भी काम कर सकता है जब आपका ध्यान कहीं और हो। Risk पैदा करने के लिए agent को plaintext secret की जरूरत नहीं होती। उसे केवल ऐसे action तक पहुंच चाहिए जो पुराने device की authority को अब भी स्वीकार करता हो।

एक समझदार migration में दो ledgers होने चाहिए:

- Data ledger में repositories, documents, configuration files, local databases, backup locations और license material दर्ज होते हैं।
- Authority ledger में हर वह remote system दर्ज होता है जो पुराने Mac पर stored, उसे जारी या उससे approved किसी चीज के कारण कोई action स्वीकार करेगा।

इन सूचियों को मिलाएं नहीं। Repository को दो बार restore करने से आम तौर पर परेशानी नहीं होती। Bearer token की दो copies का अर्थ है बचाव के लिए दो स्थान। इसी कारण credentials के मामले में «पहले migrate करें, बाद में सफाई» वाली सामान्य सलाह गलत है।

Apple Migration Assistant को documents, apps, user accounts और settings transfer करने वाले tool के रूप में बताता है। यह पुराने Mac की जानकारी delete नहीं करता। सामान्य migration के लिए Apple का विवरण सही है, लेकिन इसी वजह से यह credential retirement procedure नहीं है। पुरानी machine तब तक live copy रहती है, जब तक आप जानबूझकर उसकी authority नहीं हटाते।

## Fresh enrollment को default choice रखें

Fresh enrollment आमतौर पर अधिक सुरक्षित है, क्योंकि इससे आपको तय करना पड़ता है कि replacement Mac क्या कर सकता है। आप फिर से sign in करते हैं, जहां service इसकी सुविधा देती है वहां नया token या SSH identity बनाते हैं, नए device को न्यूनतम जरूरी role देते हैं और cutover के सफल होने के बाद पुराने device का access हटाते हैं।

यह तरीका धीमा लगता है, क्योंकि account migration जिन समस्याओं को छिपा देता है, वे सामने आ जाती हैं। आपको किसी ऐसे पुराने deploy token का पता चल सकता है जिसका owner team छोड़ चुका है, जरूरत से कहीं अधिक scope वाला personal access token मिल सकता है या कई machines में कॉपी की गई SSH key दिख सकती है, क्योंकि कोई release रोकना नहीं चाहता था। ये खोजें उपयोगी हैं। Replacement उन कुछ मौकों में से एक है जब working setup को बाधित किए बिना इन्हें ठीक किया जा सकता है।

इनमें से कोई भी स्थिति हो तो fresh enrollment चुनें:

- पुराने Mac का इस्तेमाल personal work, administration और production support जैसे एक से अधिक roles के लिए हुआ है।
- आप पुराने Mac से इस्तेमाल किए जा सकने वाले हर credential या remote account का नाम नहीं बता सकते।
- पुरानी machine की repair हुई थी, वह shared थी, कुछ समय के लिए खो गई थी या किसी अन्य तरीके से आपके नियंत्रण से बाहर रही थी।
- Credential issuer device-specific token, certificate, application password या SSH key बना सकता है।
- आप employers, teams, managed device profiles या Apple accounts बदल रहे हैं।

Fresh enrollment rollback को भी साफ रखता है। अगर नए Mac में पहले working day के दौरान समस्या आती है, तो access ठीक करते समय पुराना Mac थोड़े समय के लिए online रह सकता है। इस overlap की कीमत है, इसलिए छोटी deadline तय करें और उसे दर्ज करें। Overlap का उद्देश्य यह साबित करना होना चाहिए कि नई machine काम करती है, revoke करने का निर्णय टालना नहीं।

यह कहना सही नहीं है कि हर credential rotate करने से manage करने के लिए credentials की संख्या बढ़ जाती है। थोड़े समय के लिए दो नामित और inventory में दर्ज credentials संभाले जा सकते हैं। लेकिन password manager item, local keychain record, backup या agent vault में पुरानी authority अब भी है या नहीं, यह किसी को पता न हो और ऐसी स्थिति अनिश्चित समय तक चलती रहे, तो यह स्वीकार्य नहीं है।

## Encrypted migration का काम सीमित है

Encrypted migration तब उचित हो सकती है जब re-enrollment से अस्वीकार्य operational risk पैदा हो, credential issuer साफ replacement का समर्थन न करता हो या vault product में इसी move के लिए documented export और import process हो। केवल credentials दोबारा type करने में परेशानी होती है, इसलिए encrypted migration उचित नहीं हो जाती।

Operating system से encrypted disk और portable encrypted credential package को एक न समझें। Full-disk encryption device की storage को उसके सामान्य protection model के भीतर सुरक्षित रखती है। Migration export एक नया object बन जाता है। आपको पता होना चाहिए कि उसमें अपनी encryption है या नहीं, उसे decrypt करने वाली सामग्री अलग रहती है या नहीं, file कितने समय तक मौजूद रहेगी और क्या कोई दूसरा व्यक्ति बिना किसी को पता चले उसे दूसरी machine पर restore कर सकता है।

Encrypted vault export की अनुमति देने से पहले यह जांच करें:

1. Export format और उसे पढ़ सकने वाले app version का नाम लिखें।
2. केवल उस disk की नहीं, export की अपनी encryption boundary पहचानें जिसमें file रखी है।
3. तय करें कि cutover के दौरान export कहां रहेगा और deletion deadline निर्धारित करें।
4. पुष्टि करें कि नया vault secret values उजागर किए बिना import की सफलता कैसे साबित करेगा।
5. तय करें कि import के बाद कौन से credential records retire या rotate किए जाएंगे।

अगर किसी एक सवाल का जवाब अस्पष्ट है, तो fresh enrollment करें। Security migrations happy-path wizard में नहीं, अस्पष्ट हिस्सों में fail होती हैं।

एक और असुविधाजनक बात है: Encrypted export छिपा हुआ backup हो सकता है। Team उसे नए Mac में import करके जीत की घोषणा कर सकती है और फिर archive को Time Machine, shared file service या external drive में छोड़ सकती है। वह export अब भी credential container है। उसके लिए भी पुराने Mac जैसा retention decision चाहिए।

Encrypted migration और fresh enrollment एक-दूसरे के विरोधी नहीं हैं। व्यावहारिक तरीका दोनों को मिला सकता है। जरूरत हो तो low-impact service credentials को documented encrypted path से move करें। Production tokens, privileged SSH keys, signing material और customer data तक पहुंचने वाली हर चीज फिर से जारी करें। Classification consequence के आधार पर करें, इस आधार पर नहीं कि secret कॉपी करना आसान है या नहीं।

## नए Mac को छूने से पहले authority ledger बनाएं

पुराने Mac पर, जब वह अभी काम कर रहा हो, inventory बनाएं। Transfer के बाद memory पर भरोसा न करें, क्योंकि migrated settings नई machine को पूरी दिखा सकती हैं, जबकि जरूरी access गायब हो। Ledger में secrets के references दर्ज होने चाहिए, secret values नहीं।

एक साधारण file पर्याप्त है। उसे private work location में रखें, जो public repository का हिस्सा न बन जाए।

```text
Service: production deployment API
Purpose: release automation
Credential form: bearer token
Old-device location: agent vault record deploy-prod
Issuer: deployment service administrator
Replacement method: create new device token
Cutover test: read release status only
Old-access action: revoke old token
Owner: platform team
Status: pending

Service: build host
Purpose: remote build troubleshooting
Credential form: SSH identity
Old-device location: agent vault record build-ssh
Issuer: build host authorized_keys
Replacement method: create a new SSH key pair
Cutover test: ssh hostname
Old-access action: remove old public key
Owner: build infrastructure
Status: pending
```

लोग जिस field को सबसे अधिक छोड़ते हैं, वह old-access action है। इसके बिना inventory नए Mac के लिए shopping list बन जाती है। इसे पुराने Mac की removal plan भी होना चाहिए।

इन जगहों के credentials भी inventory में दर्ज करें, जिन्हें developers अक्सर भूल जाते हैं:

- Agent vaults और agent configuration files।
- SSH configuration, SSH agent state, hardware-backed identities और remote authorized key lists।
- Cloud consoles और identity providers के browser sessions।
- Package registries, code-hosting tools, deployment systems और CI administration accounts।
- Local environment files, shell startup files, password managers, backup archives और encrypted removable drives।

Actual bearer tokens, private keys, recovery codes या passwords ledger में न रखें। Ledger इसलिए उपयोगी है, क्योंकि वह आपको access replace और revoke करने के लिए पर्याप्त जानकारी देता है, लेकिन खुद कोई high-value secret store नहीं बनता।

हर item के लिए सबसे कम destructive test लिखें। Deployment credential से शुरुआत status पढ़ने से होनी चाहिए, release बनाने से नहीं। SSH identity का पहला परीक्षण constrained command या ऐसी host पर होना चाहिए जिसके पास production authority न हो। अगर उपलब्ध एकमात्र test production बदल सकता है, तो उस service के access design में समस्या है और अगली hardware replacement से पहले उसे ठीक करना चाहिए।

## नए vault को सफल login से अधिक साबित करना होगा

नया vault तब तैयार माना जा सकता है जब आप expected records का हिसाब दे सकें, नए device के controls के तहत उसे unlock कर सकें, उसके माध्यम से सीमित action कर सकें और उस action का स्वतंत्र trail देख सकें। App में परिचित label दिखाई देना काफी नहीं है। कॉपी किया गया label expired record, गलत account या कभी मौजूद न रहे credential की ओर इशारा कर सकता है।

Agents के credentials रखने वाले vault के लिए स्पष्ट क्रम वाला test sequence अपनाएं:

1. Vault lock करें और harmless action करने की कोशिश करें। Vault locked होने पर request deny होनी चाहिए।
2. सामान्य local control से उसे unlock करें और वही harmless action दोबारा चलाएं।
3. Fresh agent process शुरू करें और पुष्टि करें कि authorization behavior आपके intended session setting से मेल खाता है।
4. Call का individual activity record और agent run का session record देखें।
5. पुराने Mac से कोई source material हटाने से पहले audit trail सत्यापित करें।

Sallyport अपने secrets encrypted local vault में रखता है और plaintext credentials agent को दिए बिना HTTP और SSH actions करता है। Locked अवस्था में उसकी vault gate actions deny करती है, इसलिए ऊपर का पहला test केवल दिखावटी नहीं, वास्तविक है।

Acceptance record में audit command शामिल करें:

```text
sp audit verify
```

Test call के बाद इसे नए Mac पर चलाएं और migration ticket या change log में तारीख, operator, test target और result दर्ज करें। इसका उद्देश्य paperwork बढ़ाना नहीं है। उद्देश्य यह सबूत सुरक्षित रखना है कि source device नष्ट करने से पहले नई machine ने valid trail बनाया था। Hash-chained audit record log में बदलाव पकड़ सकता है, लेकिन यह नहीं बता सकता कि कोई credential enroll करना भूल गए। उस अलग समस्या को authority ledger संभालता है।

Test छोटा रखें। अगर कोई credential read-only request सुरक्षित रूप से नहीं कर सकता, तो migration के लिए dedicated test endpoint या constrained account बनाएं। लोग अक्सर प्रमाण के लिए वास्तविक production change करते हैं, क्योंकि वह निर्णायक लगता है। वह सबसे खराब तरीके से निर्णायक होता है: गलत account पर पहुंचने पर migration test incident बन जाता है।

## Migration Assistant उपयोगी है, लेकिन vault protocol नहीं

जब आपको पुराने Mac से applications, user accounts, files और settings चाहिए हों, तब Migration Assistant कई घंटे बचा सकता है। यह Time Machine backup से पूरा user environment भी transfer कर सकता है। Apple दोनों उपयोगों का documentation देता है। Workstation restore करने में यह व्यापकता उपयोगी है, लेकिन इससे यह सीमित प्रमाण नहीं मिलता कि credential वाली कौन-कौन सी files, sessions, caches और app records साथ आए।

इसे data ledger के लिए इस्तेमाल करें। हर authority item को तब तक absent मानें, जब तक आप उसे नई machine के intended controls के तहत सत्यापित न कर लें। इस सोच से दो खराब परिणामों से बचा जा सकता है: sensitive state के accidental migration पर भरोसा करना और ऐसे credential की तलाश में समय गंवाना जिसे transfer न होने के लिए सही तरीके से design किया गया था।

एक आम failure कुछ ऐसा होता है। Developer अपना account migrate करता है, agent project खोलता है और agent को सफल HTTP call करते देखता है। वह मान लेता है कि नया vault काम कर रहा है। वास्तव में call browser-derived cloud session या copied configuration file में मौजूद token से हुई थी। एक सप्ताह बाद वह session expire हो जाती है। Developer जल्दबाजी में replacement credential जोड़ता है, copied credential को वहीं छोड़ देता है और अब पुराने Mac, एक backup और नए vault, तीनों के पास उसी service तक पहुंच के रास्ते होते हैं।

इसका समाधान Migration Assistant पर रोक लगाना नहीं है। समाधान यह है कि proof को अलग रखा जाए। Agent testing से पहले unrelated browser sessions बंद करें, test में copied environment files का इस्तेमाल न करें और ऐसा vault record इस्तेमाल करें जिसे आपने जानबूझकर enroll या import किया हो। फिर resulting activity record देखें। आपको पता होना चाहिए कि action किस रास्ते से हुआ।

Apple यह भी कहता है कि Migration Assistant पुराने Mac की information delete नहीं करता। Cutover इसी तथ्य को ध्यान में रखकर बनाएं। Migration completion screen का अर्थ है कि copy पूरी हो गई। इसका अर्थ यह नहीं है कि पुराना device किसी और को सौंपने के लिए सुरक्षित हो गया।

## Erase करने से पहले पुराने Mac का access revoke करें

Revocation की कई layers होती हैं और उन्हें एक ही action मानने से झूठा भरोसा पैदा होता है। Agent run समाप्त करने से process रुकता है। Identity provider से device हटाने पर कुछ sessions समाप्त हो सकते हैं। Bearer token revoke करने से भविष्य में API use रुकता है। SSH public key हटाने से उस identity के जरिए remote login रुकता है। Password बदलने से कुछ sessions invalid हो सकते हैं, लेकिन service के अनुसार कुछ अन्य sessions सक्रिय रह सकते हैं।

शुरू करने से पहले हर ledger entry के सामने revocation action लिखें। «Disable old device» जैसी अस्पष्ट note पर निर्भर न रहें। Remote systems में device access की कोई एक सार्वभौमिक परिभाषा नहीं होती।

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

1. पुराने Mac पर active agent sessions revoke करें और local agent processes रोकें।
2. Upstream API tokens, application passwords, cloud sessions और service account credentials को rotate या revoke करें, जो पुराने device से अब भी valid हैं।
3. हर server, bastion और code-hosting account से पुरानी SSH public keys हटाएं जो उन्हें स्वीकार करता है।
4. जहां service यह control देती हो, identity systems से device trust या browser sessions हटाएं।
5. Ledger दोबारा चलाएं और हर item के साथ revocation का evidence दर्ज करें।

Sallyport का Sessions journal agent run को तुरंत revoke कर सकता है, जबकि Activity journal आपको अलग-अलग calls देखने देता है। Live-process layer के लिए इसका इस्तेमाल करें, फिर upstream credential का काम पूरा करें। Local session revoke होने से वह token revoke नहीं होता जिसे external service अब भी स्वीकार कर सकती है।

पहले erase न करें, क्योंकि पुराने Mac में किसी obscure service account, hardware token pairing या उस host alias का एकमात्र record हो सकता है जिसे आपको हटाना है। नए Mac को verify करते समय पुराने Mac को बंद और अपने भौतिक नियंत्रण में रखें। Testing के दौरान उसे online रखना जरूरी हो तो उस पर agents न चलाएं, उसमें credentials न जोड़ें और स्पष्ट cutover deadline तय करें।

Revocation की पुष्टि होते ही पुराने Mac की भूमिका बदल जाती है। वह fallback workstation नहीं रहता। वह थोड़े समय के लिए रखा गया evidence होता है, ताकि service unexpected access report करे तो जांच की जा सके। इसके बाद वह erasure के लिए तैयार device है।

## Disposal अलग security control है

Mac erase करना revocation का विकल्प नहीं है और revocation erase करने का विकल्प नहीं है। दोनों जरूरी हैं। Remote revocation copied credential के प्रभाव को सीमित करता है। Erasure local data, local application state, downloaded source, browser history और device पर बचे vault material को हटाता है।

Apple silicon वाले Mac या supported macOS version पर चलने वाले T2 Security Chip वाले Intel Mac के लिए System Settings, General, Transfer or Reset, फिर Erase All Content and Settings चुनें। Apple के अनुसार Erase Assistant user accounts, user data, installed apps, Apple service sign-ins, Find My और Activation Lock हटाता है। यह केवल current user account नहीं, volumes भी erase करता है।

अगर यह विकल्प उपलब्ध नहीं है, तो file deletion या quick disk format से काम न चलाएं। Apple पुराने unsupported hardware के लिए उचित Recovery और Disk Utility erase procedure अपनाने को कहता है। Method अलग है, क्योंकि supported hardware और security model अलग हैं।

Erase पूरा होने के बाद initial setup screen पर रुकें, अगर Mac को बेचने, trade-in करने, देने या recycle करने वाले हैं। Apple खास तौर पर ऐसी स्थिति में setup जारी न रखने की सलाह देता है। Setup पूरा करने से उस कंप्यूटर पर एक और local account बन जाएगा, जबकि computer आपके नियंत्रण से बाहर जाने वाला है।

अगर पुराना Mac गायब है या आपको लगता है कि उसमें बदलाव किया गया है, तो उसका user account नए कंप्यूटर पर restore न करें। Apple चेतावनी देता है कि suspected tampering के कारण reset करते समय backup से restore नहीं करना चाहिए, क्योंकि backup unwanted software को भी वापस ला सकता है। ऐसी स्थिति में remote credential revocation और replacement Mac के clean setup को प्राथमिकता दें।

## Replacement procedure को इतना साधारण रखें कि दोहराया जा सके

सबसे अच्छी hardware replacement process इस बात पर निर्भर नहीं करती कि secrets कहां रखे हैं, यह किसी को असाधारण रूप से याद हो। हर बार वही records बनने चाहिए: data ledger, authority ledger, नए Mac पर सीमित tests, पुराने Mac के revocation evidence और erase confirmation।

हर developer से credential forensics specialist बनने की अपेक्षा न करें। जहां संभव हो, services से device-specific credentials जारी करवाएं। Privileged access के लिए names और owners अनिवार्य करें। Engineers को read-only test route दें। हर service में revocation स्पष्ट बनाएं। ये आदतें Mac replacement का काम घटाती हैं और हर दूसरे incident को सीमित करना आसान बनाती हैं।

Replacement Mac को पहले दिन केवल उतनी authority मिलनी चाहिए जिसे वह उचित ठहरा सके। अगर यह असुविधाजनक लगता है, तो एक और verification pass के लिए पुराने device को बंद रखें। यह देरी उस स्थिति से सस्ती है जिसमें महीनों बाद पता चले कि discarded laptop के पास अब भी production तक पहुंचने का रास्ता था।