AI agents के लिए credential aliases: सुरक्षित local actions

एजेंट को connection चलाने वाला credential देने के बजाय नाम से connection मांगना चाहिए। यह API design का एक छोटा निर्णय लगता है। असल में यही अंतर है एक ऐसे एजेंट के बीच जो तय सीमा के भीतर काम कर सकता है और ऐसे agent process के बीच जिसके पास दोबारा इस्तेमाल किए जा सकने वाले कई secrets मौजूद हैं।

मैंने teams को GITHUB_TOKEN नाम का secret बनाकर agent के environment में रखते और फिर खुद को यह कहकर संतुष्ट होते देखा है कि tool interface साफ-सुथरा दिख रहा है। Token फिर भी process memory, shell history, debug output, child processes और कभी-कभी agent के अपने working notes तक पहुंच जाता है। Exposure का नाम बदलने से exposure कम नहीं होता।

AI agents के लिए credential aliases तब काम करते हैं जब कोई trusted local executor छोटे, इंसान के लिए समझने योग्य connection name को resolve करके authenticated request खुद चलाता है। Agent repo-release-prod के लिए अनुरोध करता है, executor उपयोग के समय credential डालता है, और agent को status code, secrets से साफ किया गया response body या command output मिलता है। Secret कभी agent loop का input या output नहीं बनता।

इस boundary को पहली versions की तुलना में कहीं अधिक सावधानी से design करना पड़ता है। Alias साफ operational handle, आसान rotation और उपयोगी audit records दे सकता है। लेकिन अगर आप यह तय नहीं करते कि नाम किन कार्रवाइयों की अनुमति देता है, कौन उसे चला सकता है और उसे कैसे रोका जा सकता है, तो वह व्यापक और स्थायी authority पर लगा सजावटी label भी बन सकता है।

Alias किसी छिपे string का नहीं, authority का नाम है

एक उपयोगी credential alias किसी खास उद्देश्य वाली service connection का नाम बताता है। वह secrets के ऐसे database का नाम नहीं होता जिसे agent browse कर सके। यह भी नहीं मानना चाहिए कि alias वाले हर request को स्वीकार करना ही होगा।

मान लीजिए payments-prod। Autonomous agent के लिए यह नाम बहुत अस्पष्ट है। क्या इससे invoices पढ़े जा सकते हैं, refunds जारी किए जा सकते हैं, account data बदला जा सकता है या reports download की जा सकती हैं? एक bearer token तकनीकी रूप से ये सब कर सकता है, लेकिन alias को इन भेदों को मिटाना नहीं चाहिए। बेहतर नाम operational intent साफ करते हैं: payments-invoice-read-prod और payments-refund-review-prod operator को बताते हैं कि वह किस authority को approve करने वाला है और छह महीने बाद audit record को भी समझने योग्य रखते हैं।

लोग अक्सर तीन अलग चीजों को मिला देते हैं:

• Secret reference stored material, जैसे vault path या secret ID, की पहचान करता है।
• Credential alias इस्तेमाल की जा सकने वाली authenticated connection की पहचान करता है।
• Capability name allowed operation की पहचान करता है, जैसे release publish करना या build log पढ़ना।

छोटे setup में ये एक-से-एक map हो सकते हैं, लेकिन इन्हें गलती से एक ही concept न बनने दें। Secret reference ऐसे token की ओर इशारा कर सकता है जो कई endpoints को call कर सकता है। Connection के लिए token के साथ client certificate भी जरूरी हो सकता है। अलग environments में एक capability के लिए अलग connections की जरूरत पड़ सकती है। इन्हें मिला देने पर rotation, review और incident response कठिन हो जाते हैं, क्योंकि कोई यह नहीं बता पाता कि बदला क्या है।

मैं ऐसे aliases पसंद करता हूं जिनमें target service, environment और job शामिल हो, लेकिन credential type नहीं। artifact-publish-prod, artifact-api-token-2 से बेहतर है। पहला नाम static token से short-lived exchange पर migration के बाद भी काम आएगा। दूसरा implementation detail को हर agent prompt, tool call, test और runbook में स्थायी बना देता है।

Agents को default रूप से सभी aliases की सूची न दें। Connection names की सूची internal services, environments और privileged workflows के नाम उजागर कर सकती है। इससे भी महत्वपूर्ण बात यह है कि enumeration सीमित agent को जिज्ञासु agent बना देती है। किसी task को केवल उतने नाम दें जितने उसे चाहिए, या ऐसा operation-oriented tool दें जो connection को अंदर ही चुन ले।

Context से बाहर रखा secret हर रास्ते से बाहर रहना चाहिए

Token को मुख्य model prompt से बाहर रखना जरूरी है, लेकिन यह पर्याप्त नहीं है। Credential तब बाहर निकल जाता है जब agent के reachable process tree का कोई component उसे पढ़ सकता है या किसी दूसरे component से उसे print करवा सकता है।

एक आम असफल design पर विचार करें। Coding agent connection=deploy-prod के साथ local helper को call करता है। Helper API token ढूंढता है और फिर उस token को environment variable में रखकर command-line client शुरू करता है। Command fail हो जाती है। Diagnostic wrapper अपना environment log file में print कर देता है। Agent को workspace log directory तक filesystem access है और वह failure समझाने के लिए token पढ़ लेता है।

Secret उजागर करने का इरादा किसी का नहीं था। Architecture ने ऐसा इसलिए किया क्योंकि helper ने environment variable को private channel समझ लिया। यह child processes, crash reports, diagnostics या अपने environment को inspect करने वाली commands से private नहीं होता। Credentials को command arguments में रखना और भी खराब है, क्योंकि process inspection और shell history उन्हें उजागर कर सकते हैं।

Local executor को credential अपने protected storage में रखना चाहिए, authenticated request memory में बनानी चाहिए और जानबूझकर सीमित result लौटाना चाहिए। HTTP में आमतौर पर वह authorization header खुद जोड़ता है। SSH में वह private key चुनता है या ऐसा helper चलाता है जो key file का path और contents agent को दिए बिना key का उपयोग कर सके।

Response path पर भी उतना ही ध्यान दें। कुछ APIs token creation के दौरान credentials लौटाती हैं, webhooks authorization data दोहरा सकते हैं और error reports में request headers शामिल हो सकते हैं। Executor को ऐसी response policy चाहिए जो ज्ञात secret-bearing headers हटाए और अपनी request construction को वापस response में न आने दे। इसका मतलब business data को चुपचाप बदलना नहीं है। इसका मतलब यह तय करना है कि request और response का कौन-सा हिस्सा agent को देखने का अधिकार है।

Design diagram से अधिक उपयोगी एक साफ test है। Agent से alias value हासिल करने, tool settings dump करने, authentication error पैदा करने, उपलब्ध होने पर running child processes देखने और हर accessible log location पढ़ने को कहें। अपेक्षित परिणाम उबाऊ होना चाहिए: उसे केवल नाम और action outcomes मिलें, कोई token, password, private key या दोबारा इस्तेमाल की जा सकने वाली signed request नहीं।

Connection scope action surface के अनुरूप होना चाहिए

Alias उतना ही सीमित है जितनी उसके पीछे की authority। पूरी तरह छिपा हुआ administrator token फिर भी administrator token ही रहता है।

HTTP services के लिए scope service account या token permissions से शुरू होता है। Release agent को release बनाने और जरूरी artifact upload करने की अनुमति दें। Repository administration, organization membership, billing access या user impersonation केवल इसलिए न जोड़ें कि वे बाद में उपयोगी हो सकते हैं। ऐसी जरूरत अलग review और आमतौर पर अलग connection मांगती है।

जहां service का अपना authorization model endpoint restrictions व्यक्त नहीं कर सकता, वहां उन्हें executor में रखें। यहीं teams अक्सर बड़ी policy language चुन लेती हैं। Demo में वह flexible लगती है, लेकिन तब maintenance problem बन जाती है जब operator को यह अनुमान लगाना पड़े कि कोई अनजान request पास होगी या नहीं। Endpoint restrictions चाहिए तो उन्हें साफ और छोटा रखें: allowed method, host, path family और expected credential। Unusual request bodies और redirects को incidental exceptions नहीं, बल्कि सोच-समझकर design किए जाने वाले cases मानें।

SSH में भी यही अनुशासन चाहिए, भले controls अलग दिखें। Interactive shell खोलने वाली key agent को बहुत बड़ा action surface देती है। ऐसे account को प्राथमिकता दें जो सीमित directory में जरूरी काम कर सके, या forced command का उपयोग करें जो वही सटीक operation स्वीकार करे जिसकी आपको जरूरत है। यह न मानें कि ~/.ssh/config में host alias समस्या हल कर देता है। वह alias client के लिए destination चुनता है, authentication के बाद क्या होगा इसे सीमित नहीं करता।

OpenSSH का authorized_keys manual command=, no-pty, no-port-forwarding और restrict जैसे options का दस्तावेज देता है। Machine connections के लिए ये व्यावहारिक tools हैं। इनके जोखिम भी हैं: forced command को arguments validate करने चाहिए और port forwarding रोकने वाला restriction broad shell account को सुरक्षित नहीं बनाता। पहले effective account permissions समझें। फिर उन paths को कम करने के लिए SSH options लगाएं जिनकी जरूरत नहीं है।

Staging और production के लिए एक alias का उपयोग न करें, केवल इसलिए कि endpoint URL parameter में अलग है। Agent भी दबाव में इंसान की तरह गलती करता है। अलग नामों से अलग credentials, approval treatment और audit expectations तय किए जा सकते हैं। इससे string substitution bug के जरिए staging task को production authority मिलने से भी रोका जा सकता है।

Alias स्वीकार करने से पहले executor को caller authenticate करना चाहिए

अगर कोई भी local process उसे invoke कर सकता है, तो credential alias किसी चीज की रक्षा नहीं करता। Executor को एक सीधे सवाल का स्पष्ट उत्तर चाहिए: यह action किस process ने मांगा?

Process IDs अकेले identity नहीं हैं। वे थोड़े समय के लिए रहते हैं और दोबारा इस्तेमाल हो सकते हैं। Process name इससे भी कमजोर है, क्योंकि कोई दूसरा program वही नाम अपना सकता है। macOS पर code-signing authority approver को request के पीछे मौजूद executable के बारे में बेहतर जानकारी देती है, लेकिन इससे requested action अपने-आप सुरक्षित नहीं हो जाता। Operator को फिर भी तय करना होगा कि इस signed process को इस session में यह connection मिलना चाहिए या नहीं।

कई संबंधित calls करने वाले agents के लिए per-session authorization अच्छी तरह काम करता है। नए agent process की पहली request calling identity और requested run दिखाती है। Approval उस process के exit होने तक लागू रहती है। इससे इंसान को छोटे routine calls की लंबी श्रृंखला approve नहीं करनी पड़ती और अलग-अलग runs के बीच boundary बनी रहती है।

कुछ aliases हर उपयोग पर निर्णय मांगते हैं। Production deployment, destructive API operations और customer data तक access इसके उचित उदाहरण हैं। Approval screen में alias, destination, operation और caller identity सरल भाषा में दिखनी चाहिए। Opaque event approve करने को कहना लोगों को बिना पढ़े click करना सिखाता है।

RFC 6749 एक उपयोगी separation बताता है जिसे agent tool builders को बनाए रखना चाहिए: authorization server access tokens जारी करता है और resource server उन्हें स्वीकार करता है। Agent का इनमें से कोई होना जरूरी नहीं है। Local executor design में executor credential रखने या हासिल करने वाला component बन सकता है और authenticated request भेज सकता है। Agent सीमित रूप से वर्णित action का requester बना रह सकता है। Agent HTTP calls कर सकता है, केवल इस कारण उसे general OAuth client मानने से यह separation कहीं साफ है।

इसका मतलब यह नहीं कि हर agent को interactive approval चाहिए। Controlled build worker के पास narrow, preapproved connection हो सकता है। सवाल यह है कि क्या आप caller की पहचान कर सकते हैं और क्या उसकी authority assigned job से मेल खाती है। अगर दोनों में से किसी का उत्तर स्पष्ट नहीं है, तो alias ने केवल local privilege escalation को बेहतर नाम दे दिया है।

Rotation में नाम बदले बिना material बदलना चाहिए

Aliases का operational लाभ rotation के समय दिखता है। artifact-publish-prod के पीछे token या SSH key बदलें, agent वही connection name मांगता रहे, और किसी prompt, source file या agent configuration में नया secret डालने की जरूरत न पड़े।

इसका अर्थ यह नहीं कि alias हमेशा जीवित रहे। नाम को तभी स्थिर रखें जब उसका अर्थ स्थिर रहे। अगर token read-only access से write access में बदलता है, तो पुराना नाम अब गलत जानकारी देता है। Ownership एक team से दूसरी team में जाए, तो पुरानी approval expectation शायद सही न रहे। Credential test tenant से production tenant में जाए, तो API समान होने पर भी नया alias बनाएं।

Rotation sequence को बदलाव के दोनों पक्ष साबित करने चाहिए:

1. मौजूदा alias के पीछे replacement credential जोड़ें और executor के जरिए एक सीमित health call चलाएं।
2. Service provider पर पुराने material को revoke या disable करें, फिर अपेक्षित agent action दोहराएं।
3. Audit record में failed retries या अनजान callers देखें, क्योंकि stale processes rotation के बाद अक्सर सामने आते हैं।
4. Copied credential files, पुराने environment settings और executor को bypass करने वाली emergency scripts हटाएं।

व्यवहार में rotations अक्सर आखिरी item पर विफल होती हैं। कोई release जारी रखने के लिए temporary token बनाता है, उसे CI variable या local script में छोड़ देता है और भूल जाता है। सुव्यवस्थित alias path तो ठीक से rotate हो जाता है, लेकिन छोड़ा हुआ bypass काम करता रहता है। Alternate path खोजकर बंद किए बिना rotation पूरी नहीं हुई है।

OWASP Secrets Management Cheat Sheet teams को secrets rotate करने और least privilege लागू करने की सलाह देती है। दोनों बातें सही हैं, लेकिन उन्हें अक्सर केवल storage hygiene की तरह पेश किया जाता है। Agents के लिए rotation instruction layer की भी रक्षा करती है। Stable alias का मतलब है कि model context में बदलता हुआ secret नहीं रहता और secret update task की जरूरत नहीं पड़ती, जो transcripts, commit messages या tool output में दिखाई दे सकता है।

Audit records को secrets दर्ज किए बिना decisions का वर्णन करना चाहिए

Logs से आपको यह पता चलना चाहिए कि action किसने मांगा, कौन-सा connection मांगा गया, executor ने क्या किया और उसे approval मिली या नहीं। Logs को credential vault की सुविधाजनक copy नहीं बनना चाहिए।

एक व्यावहारिक event record में timestamp, session identifier, caller identity, alias, channel, destination, method या command class, authorization decision और result class शामिल होते हैं। HTTP call के लिए POST /releases दर्ज करना आमतौर पर action समझाने को पर्याप्त है। पूरा Authorization header दर्ज करना कभी उपयोगी नहीं है और cleanup की गंभीर समस्या पैदा करता है। SSH के लिए host alias, remote account या command class और exit status दर्ज करें, private key fingerprint नहीं, अगर वह fingerprint sensitive inventory detail उजागर कर सकता हो।

Session record और individual action record को अलग रखें। Session बताता है कि agent run कब शुरू हुआ, कौन-सा local process उसका owner था और क्या आपने उसे revoke किया। Individual records बताते हैं कि run के भीतर क्या हुआ। दोनों को एक अस्पष्ट activity feed में मिला देने पर suspicious run revoke करना और उसकी कार्रवाइयां ढूंढना जरूरत से अधिक समय लेता है।

Tamper evidence audit trail की गुणवत्ता बदल देता है। जिसे कोई भी edit कर सकता है, ऐसी append-only file को बदलना आसान है। Hash chain बाद में किए गए बदलाव का पता लगाने योग्य बनाती है, क्योंकि हर entry में पिछली entry का digest शामिल होता है। यह deletion नहीं रोकती और न यह साबित करती है कि malicious executor ने सच लिखा। लेकिन इससे इतिहास को चुपचाप बदलना और उसे असली दिखाना काफी कठिन हो जाता है।

एक उपयोगी verification command का contract जानबूझकर सरल होना चाहिए:

$ sp audit verify
verified 184 records
chain: valid
first record: 2025-04-03T09:14:22Z
last record:  2025-04-03T16:48:01Z

सटीक count और timestamps अलग होंगे। महत्वपूर्ण यह है कि verification stored encrypted record stream पढ़े, chain जांचे और किसी record में बदलाव होने पर invalid position बताए। Ciphertext पर offline verification खास तौर पर उपयोगी है, क्योंकि investigator vault खोले या stored action details उजागर किए बिना continuity जांच सकता है।

Tamper evidence को monitoring न समझें। Suspicious activity देखना, incident शुरू होने पर copies सुरक्षित रखना और sessions revoke करने का अधिकार किसके पास है यह तय करना फिर भी जरूरी है। Cryptography बता सकती है कि record sequence बदली है। वह यह नहीं बता सकती कि delete-production-data समझदारी भरी request थी या नहीं।

Approval fatigue खराब alias design का संकेत है

अगर किसी व्यक्ति को हर harmless action approve करना पड़े, तो वह बिना पढ़े approval देने लगेगा। यह लोगों की समस्या नहीं है। यह ऐसा system है जो routine authority और consequential authority में फर्क नहीं करता।

ऐसे bounded agent run के लिए session approval इस्तेमाल करें जिसकी allowed connections में सामान्य operational risk हो। Approval में process की code-signing authority दिखनी चाहिए, क्योंकि agent जैसा label बहुत कम जानकारी देता है। Process exit होने पर अगले process के लिए नई approval मांगें। इससे copied tool invocation को उस one-time approval की तुलना में बेहतर सीमित किया जा सकता है जो हमेशा valid रहती है।

ऐसे aliases के लिए per-call approval रखें जिनके हर invocation की समीक्षा जरूरी है। Executor को decision event इतना स्पष्ट बनाना चाहिए कि इंसान उसे जल्दी reject कर सके। Use payments-refund-review-prod to submit refund request for order 4821 actionable है। Tool call requires approval आलसी design है।

Sallyport इसी वजह से fixed decision ladder इस्तेमाल करता है: locked vault हर action को deny करता है, नया agent process default रूप से session authorization मांगता है और individual credentials को हर उपयोग पर approval की जरूरत हो सकती है। यह policy language से बचता है, इसलिए local operators को agent रोकने से पहले authorization interpreter debug नहीं करना पड़ता।

हर confirmation को agent के साथ बहस में न बदलें। Approval control point है, conversational prompt नहीं। Action reject करें, run रास्ते से हट गया हो तो session revoke करें और पिछली records जांचें। यदि किसी task को बार-बार exceptional approvals चाहिए, तो task boundary बदलें या ऐसी narrow connection बनाएं जिसकी authority नियमित काम से मेल खाती हो।

Aliases prompt injection या खराब task design का इलाज नहीं हैं

Credential isolation secret theft से होने वाले नुकसान को सीमित करती है। यह तय नहीं करती कि agent को API call करनी चाहिए, file upload करनी चाहिए या remote command चलानी चाहिए।

Repository issue में छिपा prompt injection agent से release publish करने, allowed endpoint के जरिए report बाहर भेजने या broad account की authority के भीतर आने वाली SSH command चलाने को कह सकता है। अगर attacker को token नहीं मिला, तो alias ने अपना काम किया। फिर भी agent ने हानिकारक allowed action किया हो सकता है।

इसीलिए wide alias secret leak न होने पर भी खतरनाक है। cloud-admin-prod injected instruction को बहुत अधिक गुंजाइश देता है। Restricted service account और expected destination के साथ artifact-publish-prod उसे कम गुंजाइश देता है। फिर भी आपको agent के पढ़ सकने वाली files सीमित करनी होंगी, untrusted content को action instructions से अलग रखना होगा और task से अधिक गंभीर परिणाम वाली कार्रवाइयों पर approval मांगनी होगी।

एक और कमजोर design generic http_request tool और alias parameter expose करता है। तब agent powerful credential को arbitrary paths, redirects के बाद hosts या ऐसे endpoints पर भेज सकता है जिनके बारे में operator ने सोचा ही नहीं। create_release जैसा purpose-built tool कम flexible है, लेकिन agent के untrusted text follow करने पर यह security benefit हो सकता है।

हर alias को ऐसे वाक्य के उत्तर की तरह देखें जिसे आप लिख सकें: «यह पहचाना गया process इस destination पर इस approval treatment के साथ इस class की action कर सकता है।» अगर यह वाक्य “anything” या “as needed” जैसे शब्दों के बिना नहीं लिखा जा सकता, तो agent को connection देने से पहले उसे और design की जरूरत है।

Local executor को साधारण और inspectable रहना चाहिए

Executor के पास agent से अधिक privilege है, इसलिए उसे agent से कम काम करना चाहिए। उसे encrypted credential storage, कुछ action channels, caller identification, decision handling और audit recording चाहिए। उसे remote access gateway, all-purpose proxy या सैकड़ों exceptions वाली custom rules language बनने की जरूरत नहीं है।

Local development setup में menu-bar application vault state और pending approvals को visible बना सकती है, बिना किसी ऐसे अलग background service के जिसे operators भूल जाएं। इससे careful engineering की जरूरत खत्म नहीं होती। लेकिन sensitive operation एक ऐसी जगह केंद्रित हो जाती है जो lock कर सकती है, requests deny कर सकती है और अपने records रख सकती है।

Sallyport API keys और SSH keys को encrypted local vault में रखता है और credentials को agent context में भेजने के बजाय MCP-capable agents की ओर से HTTP और SSH actions चलाता है। इसका sp mcp shim agent को सामान्य stdio connection देता है, जबकि app executor बनी रहती है।

Inspectability का मतलब है कि incident के दौरान operator source code पढ़े बिना बुनियादी सवालों के जवाब दे सके: क्या vault locked है? कौन-सा run active है? उसने कौन-सा connection मांगा? क्या मैं उस run को revoke कर सकता हूं? क्या recorded sequence बदली है? अगर जवाब पाने के लिए पांच अलग components के logs जोड़ने पड़ें, तो system clever हो सकता है, लेकिन रात के दो बजे manageable नहीं है।

Tool protocol को narrow रखें। Structured success और error results लौटाएं। ऐसे error messages से बचें जिनमें internal request objects या secret storage paths शामिल हों। Cancellation को explicit बनाएं, ताकि user unrelated work को मारे बिना लंबी action रोक सके। ये choices साधारण लगती हैं। यही उस boundary का अंतर हैं जिसे आप चला सकते हैं और उस boundary का जिसे केवल मौजूद होने की उम्मीद है।

Boundary को ऐसे test करें जैसे attacker prompts लिख सकता हो

Happy-path demo केवल यह साबित करता है कि alias resolve होता है। Design पर भरोसा करने से पहले उन तरीकों की जांच करें जिनसे agent या compromised plugin connection name को broader access में बदलने की कोशिश कर सकता है।

Nonproduction service account की ओर इशारा करने वाले alias से शुरुआत करें। Agent task से intended call कराएं, फिर उसे adversarial instructions दें कि tool schemas inspect करे, configuration dumps मांगे, malformed requests चलाए, redirects follow करे, child commands शुरू करे और accessible logs पढ़े। Visible transcript और executor records दोनों की समीक्षा करें। आप secret material, unexpected destinations और intended action boundary को bypass करने वाली calls खोज रहे हैं।

फिर failures को जानबूझकर test करें। Request के दौरान vault lock करें। Second call से पहले session revoke करें। Underlying credential rotate करें। Copy में stored audit record बदलकर verification चलाएं। हर expected failure operator के लिए स्पष्ट और attacker के लिए अनुपयोगी होनी चाहिए। «Access denied because the vault is locked» ठीक है। Vault record या header value वाली stack trace ठीक नहीं है।

अंत में awkward operational case test करें: agent run legitimate work कर रहा हो और उसका व्यवहार suspicious हो जाए। क्या operator run पहचान सकता है, उसे तुरंत revoke कर सकता है, जान सकता है कि कौन-सी calls पहले सफल हुईं और verify कर सकता है कि record sequence edit नहीं हुई? अगर इन actions के लिए terminals और cloud dashboards में खोजबीन करनी पड़े, तो और aliases जोड़ने से पहले इसे ठीक करें।

Named connection एक छोटा interface है, लेकिन उसके परिणाम बड़े हो सकते हैं। उसका नाम ईमानदार रखें, authority सीमित रखें, caller की पहचान संभव बनाएं और records को उपयोगी रखें। फिर agent को secret दिए बिना actions request करने दें।