# Autonomous agent onboarding की शुरुआत locked vault से होनी चाहिए

Autonomous agents को चरणों में access हासिल करना चाहिए। अगर आप शुरुआत में किसी एजेंट को production token देकर कहते हैं, «सावधानी से काम करना», तो आपने setup के उस एकमात्र हिस्से को छोड़ दिया है जो दबाव में controls के व्यवहार को समझाता है।

पहले दिन का रास्ता ऐसे vault से शुरू होना चाहिए जो हर चीज़ को deny करता हो। फिर एक low-risk HTTP action जोड़ें, उसके बाद SSH, और फिर उन credentials के हर उपयोग पर approval लगाएँ जिनके लिए इसकी जरूरत है। अंत में audit record को तब verify करें जब run अभी आपके दिमाग में ताज़ा हो। यह क्रम इसलिए महत्वपूर्ण है क्योंकि हर चरण एक अलग failure को अलग करके दिखाता है।

लक्ष्य यह नहीं है कि एजेंट जितनी जल्दी हो सके उपयोगी बन जाए। लक्ष्य यह ठीक-ठीक जानना है कि वह क्या कर सकता है, आपको किस चीज़ को approve करना होगा, वह क्या रिकॉर्ड करता है और उसे ऐसे काम से जोड़ने से पहले कैसे रोकना है जिसके परिणाम गंभीर हो सकते हैं।

## ऐसे vault से शुरुआत करें जो हर कार्रवाई ठुकरा दे

आपका पहला सफल test असल में एक denial होना चाहिए। Locked vault को agent action रोकना चाहिए, भले ही agent का अनुरोध पूरी तरह उचित हो और credential पहले से configured हो।

जब तक आपने agent को failed action दोहराते नहीं देखा हो, यह उलटा लग सकता है। Agents झिझकते नहीं हैं। अगर कोई tool बताए कि access उपलब्ध नहीं है, तो agent दूसरा endpoint आज़मा सकता है, argument बदल सकता है, संबंधित tool चला सकता है या approval मांग सकता है। आप चाहते हैं कि कोई credential protected store से बाहर जाने से पहले security boundary जवाब दे।

Mac पर app चलती रहे, लेकिन vault locked रखें। अपने सामान्य development workflow से agent शुरू करें और उसे जानबूझकर harmless request दें, जैसे किसी ऐसे API से test resource लाने को कहें जिसे आपने अभी authorize नहीं किया है।

अपेक्षित परिणाम सीधा है: request नहीं चलनी चाहिए। Token को environment variable, shell profile, prompt, project file या agent configuration file में paste करके denial को bypass न करें। ऐसा workaround गलत सबक सिखाता है, क्योंकि इससे आपका पहला test सामान्य secret-handling समस्या बन जाता है।

Agent ने क्या report किया, उसे लिख लें। आपको तीन बातें जाँचनी हैं:

- Agent अपने MCP connection के जरिए action gateway तक पहुँच सकता है।
- Vault gate locked रहते हुए action रोक देता है।
- Agent transcript, terminal output या tool arguments में कोई secret दिखाई नहीं देता।

Unavailable credential और locked vault में अंतर महत्वपूर्ण है। Unavailable credential आम तौर पर setup problem बताता है। Locked vault बताता है कि setup काम कर रहा है और access जानबूझकर बंद है। अगर आप दोनों failures को «token काम नहीं किया» मानेंगे, तो अंत में उसी control को disable कर देंगे जो आपकी सुरक्षा कर रहा था।

Sallyport इसे अपनी decision ladder का पहला control बनाता है: vault locked होने पर हर action deny होता है। Supported Mac hardware पर vault gate agent से अपनी पहचान साबित करने को कहने के बजाय Secure Enclave और Touch ID का इस्तेमाल करता है।

## Agent को secret दिए बिना connect करें

Agent को credential की copy नहीं, action path चाहिए। यही नियम उपयोगी automation run को uncontrolled secret distribution event बनने से रोकता है।

MCP-capable agent को bundled stdio shim इस्तेमाल करने के लिए configure करें:

```sh
sp mcp
```

यह shim एक सामान्य MCP server है। Agent उससे बात करता है, HTTP या SSH action करने को कहता है और परिणाम पाता है। Credential app के भीतर encrypted vault में रहता है। Agent को plaintext token, substitute token या ऐसा secret-shaped placeholder नहीं मिलता जिसका बाद में गलत इस्तेमाल किया जा सके।

यह boundary कई teams की बनाई हुई सीमा से अधिक स्पष्ट है। वे अक्सर कहते हैं, «agent को limited access है», जबकि वास्तव में उनका मतलब होता है कि agent के environment में सीमित permissions वाला token रखा है। ये दो अलग systems हैं।

Environment variable के साथ ऐसा हर process secret को copy कर सकता है जो environment पढ़ सकता हो। Shell history entry, debug log, crash report, child process, prompt export या pasted terminal transcript secret की lifetime बढ़ा सकते हैं। Action gateway के साथ agent किसी specific action का अनुरोध कर सकता है, लेकिन उसे authorize करने वाली credential material को देख नहीं सकता।

कुछ भी unlock करने से पहले agent configuration में आम leaks देखें:

- `.env` files, shell startup files, agent instructions और project documentation से tokens हटाएँ।
- केवल इसलिए credential को tool argument में न जोड़ें कि tool `token` field support करता है।
- Agent को उसी password manager, secret file या cloud credential directory को पढ़ने की permission न दें जिसे आप सुरक्षित रखना चाहते हैं।
- पहला agent run ऐसे terminal session से अलग रखें जिसमें privileged environment variables loaded हों।

यहीं developers एक लोकप्रिय लेकिन खराब सलाह भी देते हैं: «पहले temporary token इस्तेमाल करो, बाद में उसे harden कर लेना।» Agent context में पहुँचते ही temporary token भी secret बन जाता है। सीमित प्रभाव के लिए temporary credential जरूर इस्तेमाल करें। इसे agent और secret के बीच की boundary छोड़ने का बहाना न बनाएँ।

## सबसे पहले एक साधारण HTTP request करें

पहली allowed action ऐसी credential के साथ एक HTTP request होनी चाहिए जिसका उद्देश्य सीमित हो। Read-only बेहतर है। Test account और भी अच्छा है। ऐसा endpoint सबसे अच्छा है जो कोई ज्ञात, गैर-संवेदनशील object लौटाता हो।

ऐसी request चुनें जिसे आप independently verify कर सकें। अच्छे उदाहरण हैं test repository का metadata पढ़ना, अपने बनाए sandbox profile को लाना या non-production account से जुड़े status endpoint को call करना। ऐसे endpoints से बचें जो वास्तविक customers, source code, billing data या broad account settings दिखाते हों। सफल read भी आपकी अपेक्षा से अधिक जानकारी उजागर कर सकता है।

Service जिस authentication form की अपेक्षा करती है, उसी के अनुसार HTTP credential को vault में configure करें: bearer authentication, basic authentication या custom header। Credential label इतना स्पष्ट रखें कि बाद में approval card में उसे पहचान सकें। «Test API read», «token 2» से बेहतर है। आपके future self को यह जानने के लिए password manager नहीं खोलना चाहिए कि एक click सुरक्षित है या नहीं।

अब vault unlock करें और agent का fresh process शुरू करें। Per-session authorization default रूप से on है, इसलिए उस नए process की पहली action पर approval card दिखना चाहिए। Approve करने से पहले उसमें दिखाई गई code-signing authority पढ़ें।

इस जाँच को «मैं agent का नाम पहचानता हूँ» तक सीमित न करें। किसी परिचित command name को unexpected wrapper, copied binary या किसी अलग development tool से launch किया जा सकता है। Approval card में process की code-signing authority सबसे पहले दिखाई जाती है, क्योंकि access का अनुरोध करने वाला process उस natural-language task से अधिक महत्वपूर्ण है जिसे वह करने का दावा करता है।

Run को तभी approve करें जब ये सभी बातें सही हों:

1. आपने agent process खुद शुरू किया है।
2. Signing identity वही है जिसकी आपको उम्मीद थी।
3. Requested credential का scope वही सीमित scope है जो आपने तय किया था।
4. Request वही है जो आपने agent से करने को कहा था।

इसके बाद agent से ठीक एक call कराएँ। लौटे हुए result की तुलना agent workflow के बाहर की गई manual request से करें। आप यह साबित नहीं कर रहे कि HTTP काम करता है। आप यह साबित कर रहे हैं कि agent action का अनुरोध कर सकता है, gateway stored credential जोड़ सकता है और credential को उजागर किए बिना result लौट सकता है।

पहले दिन का उपयोगी record छोटा होना चाहिए:

```text
Credential: Test API read
Agent task: Retrieve one known test object
Expected result: Object identifier and status only
Manual comparison: Same identifier and status
Unexpected data returned: None
```

अगर response में आपकी अपेक्षा से अधिक fields हों, तो वहीं रुक जाएँ। Agent से extra data summarize करने को कहकर आगे न बढ़ें। API scope घटाएँ, छोटा test object इस्तेमाल करें या अधिक सीमित endpoint चुनें। पहली HTTP call को प्रभावशाली result से नहीं, containment से confidence बनाना चाहिए।

## Session approval किसी run की permission है, blank check नहीं

Per-session authorization एक specific सवाल का जवाब देता है: क्या आप इस agent process को इस run के पूरे समय के लिए approve करते हैं? यह तय नहीं करता कि हर credential या हर requested action के साथ एक जैसा व्यवहार किया जाना चाहिए।

एक run approve करने के बाद agent उसके exit होने तक एक से अधिक calls कर सकता है। यह तब उपयोगी है जब आप किसी coherent task की निगरानी कर रहे हों, जैसे test metadata पढ़ना और local report बनाना। लेकिन open-ended prompt वाले run में, related work spawn कर सकने वाले run में या अलग-अलग consequences वाली credentials के access के साथ यह जोखिम भरा है।

Session को सीमित work unit मानें। उसे एक task के लिए शुरू करें। शुरुआती कुछ actions देखें। Task पूरा होते ही उसे समाप्त करें। अगले अलग task के लिए नया process शुरू करें ताकि आपको फिर से authorization decision मिले।

Sessions journal इस आदत में मदद करनी चाहिए। यह agent runs रिकॉर्ड करता है और आप किसी run को तुरंत revoke कर सकते हैं। जब agent भटकने लगे, जब आपको पता चले कि आपने गलत process approve किया था या जब task बीच में अपना रूप बदल ले, तब revoke करें।

यह failure pattern पहचानने लायक है। आप agent से कहते हैं, «test API check करो और जो obvious issues हों उन्हें ठीक कर दो।» वह harmless GET request से शुरू करता है। आप session approve कर देते हैं। उसे configuration mismatch मिलता है, उपलब्ध actions में write endpoint दिखता है और वह तय करता है कि obvious fix setting update करना है। Credential इसकी अनुमति दे सकती है और original approval अब भी उसी run पर लागू हो सकता है।

इस कहानी में malicious agent या broken tool की जरूरत नहीं है। गलती task boundary की है। आपने एक ही session में discovery phase और remediation phase रख दिए और उम्मीद की कि original approval दोनों के दौरान एक ही अर्थ रखेगा।

काम को अलग करें। पहले read-only discovery session approve करें। उसके findings की समीक्षा करें। फिर proposed change के लिए अलग run शुरू करें, बेहतर होगा कि write permission वाली narrower, अलग credential इस्तेमाल करें। Approval तब meaningful बनता है जब वह ऐसी work unit से जुड़ा हो जिसे आप एक वाक्य में बता सकें।

## HTTP boundary सामान्य लगने के बाद ही SSH जोड़ें

SSH «servers के लिए HTTP» नहीं है। इसके परिणामों का दायरा बड़ा है, क्योंकि सफल connection arbitrary commands चला सकता है, files देख सकता है, permissions बदल सकता है और ऐसे channels से data भेज सकता है जिन्हें narrow API expose नहीं करती।

Disposable host या isolated development machine से शुरुआत करें। ऐसा remote account बनाएँ जिसके पास production access, shared credentials या home directory और cloud configuration को छूने की कोई वजह न हो। उस host पर ज्ञात text वाली harmless file रखें। Agent का पहला SSH task उस line को और कुछ नहीं, केवल retrieve करना होना चाहिए।

Sallyport SSH actions को अपने bundled stateless Go helper, `sp-ssh`, के जरिए route करता है। Agent उसी gateway model से action का अनुरोध करता है, जबकि stored SSH credential vault में रहता है और ऐसी private key file नहीं बनता जिसे agent पढ़ सके।

पहला SSH exercise जानबूझकर सीमित होना चाहिए:

```text
Host: isolated development host
Remote account: restricted test account
Allowed task: Read one known text file
Expected response: The exact line placed in that file
Stop condition: Any attempt to inspect other paths or run a second command
```

«Run diagnostics» से शुरुआत न करें। यह phrase बहुत broad है। Diagnostics में अक्सर process listings, network configuration, package inventories, log files, home directories और application configuration शामिल हो जाते हैं। सक्षम agent request को व्यापक अर्थ देगा, क्योंकि task पूरा करने के लिए broad interpretation अक्सर उसका तरीका होता है।

एक आम operational mistake पर ध्यान दें: developers SSH test के लिए safe account के बजाय convenient account चुन लेते हैं। उस account को किसी परिचित host तक access होता है, शायद किसी existing personal key के जरिए, इसलिए test जल्दी हो जाता है। फिर agent का पहला SSH experience repositories, deployment credentials, shell history, configuration files और उस account द्वारा पढ़ी जा सकने वाली बाकी चीज़ों तक पहुँच के साथ शुरू होता है। आपने सीखा कि tunnel काम करता है, लेकिन containment के बारे में कुछ उपयोगी नहीं सीखा।

Restricted test account failure को स्पष्ट बनाता है। अगर agent unexpected path मांगता है, तो आप journal में attempted action देख सकते हैं और बिना यह सोचे deny या revoke कर सकते हैं कि शायद वह पहले ही अधिक sensitive file खोज चुका है।

## महत्वपूर्ण credentials पर per-use approval लगाएँ

Per-use approval में हर बार एक credential इस्तेमाल होने पर आपसे पुष्टि मांगी जाती है। ऐसी credential आज़माने से पहले यह flag लगाएँ जो system बदल सकती है, sensitive material तक पहुँच सकती है या ऐसे host तक जा सकती है जहाँ एक shell command का असर बहुत व्यापक हो।

Developers अक्सर इसका विरोध करते हैं क्योंकि बार-बार prompts inefficient लगते हैं। इस cost के बारे में वे सही हैं। हर low-risk read पर prompt आपको बिना पढ़े prompts click करने की आदत डाल देगा। इसे approval fatigue कहते हैं और यह control को अनुपस्थित होने से भी बदतर बना सकता है, क्योंकि इससे झूठा confidence पैदा होता है।

Per-use setting वहाँ लगाएँ जहाँ हर action पर fresh human decision चाहिए। अच्छे candidates में वे credentials शामिल हैं जो:

- remote resources create, modify या delete कर सकते हैं;
- personal, customer, financial या security-sensitive records पढ़ सकते हैं;
- administrative API methods चला सकते हैं;
- shared development, staging या production-adjacent machine तक SSH access खोल सकते हैं;
- deployment, job, workflow या external notification शुरू कर सकते हैं।

Workflow सीखते समय low-risk test reads को session approval के अंतर्गत रखें। अगली ऐसी credential पर per-use gate लगाएँ जिसका वास्तविक परिणाम हो। फिर agent को ऐसा task दें जिसमें दो अलग calls की जरूरत हो, जैसे test setting पढ़ना और change propose करना, लेकिन उसे apply न करना। Confirm करें कि credential flag होने पर हर use के लिए approval जरूरी है।

यह अंतर महत्वपूर्ण है। Per-session approval पूछता है कि कोई specific process इस run के दौरान कार्रवाई कर सकता है या नहीं। Per-use approval पूछता है कि यह specific credential अभी इस्तेमाल की जा सकती है या नहीं। एक process identity और run lifetime से जुड़ा है। दूसरा एक stored secret से जुड़े consequence से। दोनों को interchangeable मानने पर teams या तो बहुत व्यापक approval देती हैं या इतनी बार prompt दिखाती हैं कि कोई card पढ़ता ही नहीं।

Prompt आने पर केवल credential label न देखें। Action, destination और यह भी जाँचें कि agent का current task अब भी उसे उचित ठहराता है या नहीं। अगर नहीं, तो use deny करें और कुछ और approve करने से पहले agent से अपनी योजना plain language में समझाने को कहें।

## Activity journal में surprises evidence बनते हैं

Session record बताता है कि किस agent run को approval मिला। Activity record बताता है कि उस run के भीतर क्या हुआ। दोनों जरूरी हैं, क्योंकि साफ दिखने वाला process भी गलत call कर सकता है और suspicious call का अर्थ अधूरा रहता है अगर आप उसे पैदा करने वाले run से जोड़ न सकें।

HTTP test के बाद Activity journal खोलें और हर individual call पढ़ें। SSH test के बाद भी यही करें। Record की तुलना अपने लिखे हुए exercise से करें: expected endpoint या host, expected action और expected result। आप खुद को mismatch तब पहचानने की आदत सिखा रहे हैं जब उसे समझाना अभी आसान हो।

उन calls पर खास ध्यान दें जो अकेले देखने पर harmless लगती हैं लेकिन task से मेल नहीं खातीं। Metadata endpoint account structure दिखा सकता है। Host probe व्यापक command की ओर ले जा सकता है। Retry harmless हो सकती है या यह संकेत दे सकती है कि पहली response fail होने के बाद agent ने parameters बदल दिए। Context session और sequence से मिलता है, अकेली line से नहीं।

Agent की narration को अपना record न मानें। Agents सही summary दे सकते हैं, कोई detail छोड़ सकते हैं, tool response को गलत समझ सकते हैं या ऐसी action के लिए polished explanation दे सकते हैं जिसे आप approve नहीं करते। Journal इस बात की जाँच के लिए है कि क्या हुआ, उसके आसपास की prose को grade करने के लिए नहीं।

यहीं instant revoke उपयोगी साबित होता है। अगर agent agreed task से exploration की ओर जाता दिखे, तो पहले session revoke करें। Further actions रोकने के बाद तय करें कि call benign थी या नहीं। Credentials वाले active process को पूरी explanation मिलने तक चलने देना meeting में sensible हो सकता है, लेकिन यहाँ यह खराब प्रतिक्रिया है।

## जरूरत पड़ने से पहले audit chain verify करें

Audit record तभी उपयोगी है जब आप record में हुए tampering का पता लगा सकें। Events की list पढ़ने से पता चलता है कि interface अभी क्या दिखा रहा है। Verification बताती है कि encrypted audit log की hash chain अब भी सही है या नहीं।

पहले दो exercises के बाद यह चलाएँ:

```sh
sp audit verify
```

Sallyport ciphertext पर hash chain को offline verify कर सकता है, इसलिए इस check के लिए vault secret तक access जरूरी नहीं है। Investigation के दौरान यह सुविधा व्यावहारिक है। Agent actions नियंत्रित करने वाले उसी store को पहले unlock किए बिना भी आप record की integrity जाँच सकते हैं।

सब कुछ शांत रहने पर command एक बार चलाएँ। किसी change, test या incident के लिए result कहाँ रखेंगे, यह तय करें। फिर इसे एक deliberately denied action, एक approved HTTP call और एक approved SSH call के बाद दोहराएँ। आप ज्ञात events वाली sequence जाँच रहे हैं, इसलिए बाद में unexpected verification result को पहचानना आसान होगा।

किसी गंभीर production सवाल तक इंतजार न करें ताकि आपको पहली बार पता चले कि command कौन चला सकता है, logs कहाँ हैं या आपकी team session record और individual call में अंतर समझती भी है या नहीं। यही आम failure है। Teams logging install करती हैं, मान लेती हैं कि वह मौजूद है और कोई पूछे, «इसे approve किसने किया?» तभी उसे खोलती हैं। तब उन्हें tool सीखने और event reconstruct करने का काम एक साथ करना पड़ता है।

Audit log को एक ही write-blind encrypted, hash-chained record से Sessions और Activity journals में project किया जाता है। इससे operations के लिए दो views मिलते हैं, लेकिन वे views ही एकमात्र evidence नहीं बनते जिसे आप inspect कर सकें।

## पहले demo से पहले सप्ताह को कठिन बनाएँ

Polished demo HTTP request सफल होते ही खत्म हो जाता है। उपयोगी onboarding path तब तक चलता है जब तक आपने कोई action deny न किया हो, bounded run approve न किया हो, जानबूझकर किसी run को revoke न किया हो, individual calls inspect न की हों, isolated host पर SSH आज़माया न हो, per-use approval इस्तेमाल न किया हो और audit chain verify न की हो।

पहले सप्ताह को इतना छोटा रखें कि आप हर action समझा सकें। एक समय में केवल एक नया credential या capability जोड़ें। अगर किसी नए setup को कई exceptions, broad scopes और ऐसा prompt चाहिए जिसे आप जल्दी समझ नहीं पाते, तो वह autonomous agent के लिए तैयार नहीं है।

व्यावहारिक test सीधा है: जब agent action करने को कहे, तो क्या आप बता सकते हैं कि कौन पूछ रहा है, कौन-सी stored credential इस्तेमाल होगी, कौन-सा external system action पाएगा और बाद में कहाँ देखेंगे? अगर कोई जवाब अस्पष्ट है, तो पहले वाले stage पर लौटें और test को सीमित करें।

Token को configuration file में copy करने से यह धीमा है। लेकिन इसी तरह आप रात के दो बजे यह पता लगाने से बचते हैं कि आपका पहला वास्तविक agent run वह क्षण था जब आपके credential controls ने control की तरह काम करना ही बंद कर दिया।