AI एजेंट के लिए सीक्रेट मैनेजर: स्टोरेज, एक्शन कंट्रोल नहीं

AI एजेंट के लिए सीक्रेट मैनेजर जरूरी है, लेकिन यह सबसे खतरनाक सवाल हल नहीं करता: एजेंट के क्रेडेंशियल मांगने के बाद क्या होता है? अगर मैनेजर प्लेनटेक्स्ट सीक्रेट एजेंट प्रोसेस को लौटा देता है, तो सीक्रेट उस सीमा को पार कर चुका है जिसकी आप सुरक्षा करना चाहते थे।

यह अंतर तब तक मामूली लगता है, जब तक एजेंट किसी दूषित निर्देश का पालन न करे, अनपेक्षित टूल न चलाए, डायग्नोस्टिक फ़ाइल न लिखे या गलत होस्ट से संपर्क न करे। वॉल्ट किसी टोकन को वर्षों तक एन्क्रिप्टेड रख सकता है, फिर एक ही retrieval call में उस सुरक्षा का बड़ा हिस्सा खत्म कर सकता है। एजेंट के लिए सुरक्षित डिजाइन यह है कि क्रेडेंशियल विश्वसनीय executor के पास रहे और एजेंट उससे authenticated action का अनुरोध करे।

वॉल्ट स्टोरेज की सुरक्षा करता है, क्रेडेंशियल के इस्तेमाल की नहीं

पारंपरिक सीक्रेट मैनेजर स्टोरेज का सवाल पूछता है: यह मान कौन प्राप्त कर सकता है? स्वायत्त एजेंट एक अलग सवाल खड़ा करते हैं: क्या यह प्रोसेस इस समय, इस गंतव्य के विरुद्ध, इस खास कार्रवाई के लिए इस मान का इस्तेमाल कर सकती है?

अधिकांश टीमों ने सही आदतों से शुरुआत की। उन्होंने टोकन को रिपॉजिटरी से बाहर रखा, उन्हें rest पर एन्क्रिप्ट किया, गलती से commit होने पर बदला और build environment में inject किया। सामान्य application deployment के लिए ये आदतें अच्छी हैं। Build job में आम तौर पर तय स्क्रिप्ट, सीमित जीवनकाल और ज्ञात endpoints होते हैं। उसका environment फिर भी जरूरत से ज्यादा खुला हो सकता है, लेकिन job शुरू होने से पहले किसी व्यक्ति ने commands लिखी होती हैं।

एजेंट अलग होता है। वह commands बनाता है, tools चुनता है, issue text का पालन करता है, दूसरों की लिखी files पढ़ता है और अपना plan बदल सकता है। DEPLOY_TOKEN को environment variable में देने का मतलब है कि उसके शुरू किए हर subprocess को token पढ़ने का मौका है। Environment प्रिंट करने वाली shell command, debugger, package install hook या ऐसा untrusted tool भी उसे पढ़ सकता है जिसे एजेंट ने किसी दस्तावेज के निर्देश पर चुना हो।

ऐसी स्थिति में secret manager विफल नहीं हुआ। उसने वही किया जिसके लिए उसे configure किया गया था: authorized workload को secret दे दिया। समस्या यह थी कि authorization model ऐसे actor के लिए बहुत मोटा था जो अपनी अगली कार्रवाई खुद चुन सकता है।

इन दो permissions को अलग रखें:

• किसी स्थिर reference से credential की पहचान करने की permission।
• बताए गए outbound action के लिए उस credential का इस्तेमाल करने की permission।

पहली permission एजेंट के लिए सुरक्षित हो सकती है। दूसरी के लिए कार्रवाई के अनुरूप सीमाएं चाहिए। POST https://deploy.example.internal/releases जैसा अनुरोध reviewer जांच सकता है। read production token जैसा अनुरोध ऐसा asset सौंप देता है जिसके भविष्य के इस्तेमाल का retrieval के समय आकलन नहीं किया जा सकता।

इससे एक आम लेकिन अनुपयोगी दावा भी साफ होता है: «एजेंट के पास पहले से code execution है, इसलिए secret छिपाने से कुछ नहीं बदलेगा।» Developer machine पर code execution अपने आप में जोखिम है। उस मशीन से कॉपी किया गया bearer token दूसरी समस्या पैदा करता है: वह मशीन से बाहर जा सकता है, session खत्म होने के बाद भी बचा रह सकता है और पूरी तरह दूसरे computer से काम कर सकता है। Secret को process से बाहर रखने से हर जोखिम खत्म नहीं होता, लेकिन portable और लंबे समय तक चलने वाली access का वह रूप हट जाता है जिसे हमलावर सबसे ज्यादा चाहते हैं।

RFC 6750 OAuth bearer tokens के बारे में यही बात स्पष्ट करता है। इसकी परिभाषा के अनुसार bearer token रखने वाला कोई भी पक्ष उसका इस्तेमाल कर सकता है। Protocol यह नहीं पूछता कि वह आपका approved agent है, malicious plugin है या log file पाने वाला कोई व्यक्ति। Bearer token की इस मूल विशेषता को नजरअंदाज करके उसे सामान्य tool output मानना गलत है।

Read access निर्देश की गलती को credential leak में बदल देता है

प्लेनटेक्स्ट secret access वाला एजेंट बिना जानबूझकर exfiltrate किए भी credential लीक कर सकता है। खतरनाक रास्ता आखिरी कदम तक सामान्य दिखता है।

मान लीजिए किसी एजेंट से पूछा गया कि deployment API ने release क्यों अस्वीकार किया। वह repository document पढ़ता है जिसमें support bundle बनाने को कहा गया है। Bundle script env चलाती है, configuration files कॉपी करती है और output को archive करती है। एजेंट archive बनाकर उसे ticket में attach करता है या chat system पर upload कर देता है। Token terminal में कभी दिखाई नहीं दिया, फिर भी वह environment, archive, ticket और उस ticket से जुड़े हर backup या notification system में पहुंच गया।

यह केवल prompt injection नहीं है। Prompt injection गलत कार्रवाई तक पहुंचने का एक रास्ता है, लेकिन कॉपी किया गया credential मूल निर्देश गायब होने के बाद भी अपना अलग blast radius बनाता है। Ticket पढ़ने वाला कोई व्यक्ति उसे download कर सकता है। Automated scanner उसे index कर सकता है। Recipient एजेंट run खत्म होने के काफी बाद भी उसका इस्तेमाल कर सकता है।

यही विफलता कम दिखाई देने वाले तरीकों से भी होती है:

• Verbose HTTP client retry के दौरान Authorization header प्रिंट कर देता है।
• Shell history file command line में दिया गया token रख लेती है।
• Test fixture request header रिकॉर्ड करके commit हो जाता है।
• Child process को ऐसा environment variable मिल जाता है जिसकी उसे जरूरत नहीं थी।
• Secret tool output में दिखने के कारण model उसे अपनी explanation में शामिल कर देता है।

आम जवाब redaction है। गलती के बाद redaction मदद करता है, लेकिन यह साबित नहीं कर सकता कि हर output path, archive format, trace, subprocess और remote service ने मान को सही संभाला। Unknown secret formats और कई fields में बंटे tokens के साथ यह और कमजोर पड़ता है। जिस credential को एजेंट को पढ़ना ही नहीं चाहिए, उसके चारों ओर मुख्य सुरक्षा दीवार redaction को न बनाएं।

बेहतर व्यवस्था एजेंट के inputs को सीमित करती है। एजेंट बिना credential material वाला intent भेजता है: HTTP method, permitted URL, request body और credential reference। Trusted component request की जांच करता है, authentication material भीतर से जोड़ता है, request भेजता है और sensitive headers हटाकर response लौटाता है।

यह सीमा incident response को बेहतर जवाब देती है। एजेंट गलत व्यवहार करे तो उसका session revoke करें या अगली कार्रवाइयां रोक दें। Run के बाद कोई malicious instruction मिले तो शुरुआत इस धारणा से नहीं करनी पड़ेगी कि हर transcript, temporary file और remote artifact में production token मौजूद है।

Action execution, secret retrieval से अलग interface है

Execution boundary को operation स्वीकार करना चाहिए, न कि agent को कोई opaque value देकर यह उम्मीद करनी चाहिए कि वह सावधानी से इस्तेमाल करेगा। यही वह अंतर है जिसे टीमें सबसे ज्यादा धुंधला करती हैं, और गलती होने पर vault credential vending machine बन जाता है।

HTTP के लिए एजेंट इस तरह का request व्यक्त कर सकता है:

{
  "credential": "release-api",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "version": "2025.03.8",
    "environment": "staging"
  }
}

Executor protected vault में release-api खोजता है, matching authentication scheme जोड़ता है और request भेजता है। एजेंट को इस आकार का result मिल सकता है:

{
  "status": 201,
  "headers": {
    "content-type": "application/json"
  },
  "body": {
    "release_id": "rel_4821",
    "state": "queued"
  }
}

Response में injected Authorization header, कॉपी किया गया credential value या उसे उजागर करने वाले transport diagnostics नहीं होने चाहिए। यह बात स्पष्ट लगती है, लेकिन जब developers request और response logging को harmless plumbing समझते हैं तो boundary design विफल हो जाता है।

SSH के लिए एजेंट को host, account, command और संभव हो तो credential reference भेजना चाहिए। Executor SSH authentication exchange के दौरान private key का इस्तेमाल करे और standard output, standard error तथा exit status लौटाए। एजेंट को PEM block या ऐसा agent socket कभी न मिले जिसे वह कहीं और दोबारा इस्तेमाल कर सके।

इसे general proxy न समझें। Proxy मनमाना traffic forward कर सकता है और उसे inspect या modify कर सकता है। Action executor का काम संकरा है: credentials अपने पास रखना, नामित HTTP और SSH operations करना, decision रिकॉर्ड करना और सीमित result लौटाना। यह संकरापन लाभ है। हर अतिरिक्त protocol या generic bypass agent को authority को unreviewable request में बदलने का एक और रास्ता देता है।

Request interface में भी अनुशासन चाहिए। Credential reference अकेला पर्याप्त नहीं है। अगर release-api कई hosts पर authenticate कर सकता है या arbitrary URL स्वीकार करता है, तो एजेंट valid credential को attacker-controlled endpoint या कम सुरक्षित internal service की ओर भेज सकता है। Credentials को intended authentication scheme और destinations से बांधें। Unexpected userinfo segments, नए host पर redirects या approved host से मिलते-जुलते host जैसे URL tricks अस्वीकार करें।

Executor को यह भी तय करना होगा कि वह क्या लौटाए। Full API response में user data, downstream service से मिले access tokens या ऐसी configuration details हो सकती हैं जिन्हें model context में वापस नहीं जाना चाहिए। अगली कार्रवाई के लिए जरूरी fields ही लौटाने से एजेंट अधिक reliable और सुरक्षित दोनों बन सकता है।

SSH को केवल private-key custody नहीं, command control भी चाहिए

SSH private key छिपाना मदद करता है, लेकिन arbitrary remote commands को सुरक्षित नहीं बनाता। Authentication बताता है कि server से कौन जुड़ा है। Shell शुरू होने के बाद account क्या कर सकता है, यह वह सीमित नहीं करता।

RFC 4252 SSH public-key authentication को exchange data पर signature के रूप में बताता है। Exchange के दौरान private key निजी रहती है, इसलिए लोग SSH को environment variable में रखे API token से अधिक सुरक्षित मानते हैं। एक सीमित अर्थ में यह सही है: client private key भेजने के बजाय उसे रखने का प्रमाण देता है। फिर भी जो process SSH agent से sign करने को कह सकती है, वह उन systems तक पहुंच पा सकती है जो उस key पर भरोसा करते हैं।

SSH agent forwarding पर साफ बात जरूरी है। इससे remote server connection की अवधि तक आपके local authentication agent का इस्तेमाल कर सकता है। Remote server को private key file नहीं मिलती, लेकिन forwarded socket के जरिए वह signatures मांग सकता है। यह तभी स्वीकार्य है जब आप उस remote machine पर इतना भरोसा करते हों कि forwarding channel खुला रहने तक वह व्यवहार में आपकी पहचान से authenticate कर सके। ऐसे autonomous agent के लिए यह साफ सीमा नहीं है जो तय कर सकता है कि कहां connect करना है और कौन-सी setup command चलानी है।

सुरक्षित SSH action interface destination और command को स्पष्ट रूप से नाम देता है। दोनों रिकॉर्ड करें, क्योंकि ssh deploy@host "./deploy staging" और ssh deploy@host "cat /etc/shadow" में authentication event समान है, लेकिन परिणाम बिल्कुल अलग हैं।

Remote-side restrictions फिर भी जरूरी हैं। अलग-अलग कामों के लिए अलग accounts रखें। Deployment account को administrator access देने के बजाय deployment directories तक पहुंच दें। जहां server support करे, automation credentials के लिए forced commands या restricted command wrappers configure करें। केवल इसलिए agent tasks में shared personal administrator key का इस्तेमाल न करें कि वह workstation पर पहले से मौजूद है।

एक व्यावहारिक SSH request इतना छोटा हो सकता है:

{
  "credential": "staging-deployer",
  "host": "staging-runner.internal",
  "user": "deploy",
  "command": "./release apply 2025.03.8",
  "timeout_seconds": 120
}

इस request से reviewer के पास मंजूर करने के लिए कुछ ठोस होता है और बाद में audit करने के लिए भी। अगर एजेंट को interactive shell चाहिए, तो रुककर पूछें कि क्यों। Interactive shells लोगों के लिए system repair में उपयोगी हैं। एजेंट के लिए वे खराब default हैं, क्योंकि bounded action एक open-ended session में बदल जाती है और हर अगली command वही authority विरासत में लेती है।

Host verification भी जरूरी है। Executor को known-host verification का इस्तेमाल करना चाहिए, न कि model के कहने पर कोई भी presented host key स्वीकार करनी चाहिए। अगर एजेंट host verification बंद कर सकता है, तो network attacker commands प्राप्त कर सकता है, output देख सकता है और login के बाद एजेंट द्वारा भेजा गया data पकड़ सकता है।

Approval को process और action scope की पहचान करनी चाहिए

Human approval button कमजोर है अगर वह केवल इतना बताता है कि «एक एजेंट» ने access मांगा। आपको यह जानना चाहिए कि किस local process ने अनुरोध किया, किस signed authority ने उसे शुरू किया और approval इस run पर लागू है या हर भविष्य के run पर।

Per-call prompts सबसे सुरक्षित लगते हैं, इसलिए टीमें अक्सर वहीं से शुरू करती हैं। फिर एजेंट harmless reads, status checks और follow-up calls की लंबी श्रृंखला करता है। देखने वाले व्यक्ति को लगभग एक जैसे dialogs की दीवार मिलती है और वह लय में approve करने लगता है। यह प्रतिक्रिया स्वाभाविक है, लेकिन intended control को निष्प्रभावी कर देती है।

सामान्य काम के लिए session approval बेहतर है, जब वह एक approval को एक agent process lifetime से बांधता है। व्यक्ति उसकी identity देखकर किसी खास run को approve करता है। Agent process खत्म होने तक अपना अपेक्षित sequence पूरा कर सकता है। नया process नया decision पाता है। इससे उसी project directory का इस्तेमाल करने वाले restarted या substituted process का प्रभाव सीमित रहता है।

Per-call approval उन credentials के लिए रखें जिनका इस्तेमाल irreversible या महंगा परिणाम ला सकता है। Production release credentials, account deletion tokens या sensitive systems तक पहुंचने वाली SSH identity इस श्रेणी में आती है। Read-only status calls आम तौर पर नहीं।

Approval scope को सरल भाषा में चार सवालों के जवाब देने चाहिए:

1. यह request किस code-signing authority या executable ने शुरू की?
2. यह किस credential reference का इस्तेमाल करेगी?
3. Action किस destination या host को भेजी जाएगी?
4. Process खत्म होने पर decision समाप्त होगा, या इस call के लिए अलग confirmation चाहिए?

Policy language से बचें, जब तक आपके पास उसे maintain करने वाले लोग और उसके प्रभाव को साबित करने वाले tests न हों। Policy engines engineers को आकर्षित करते हैं क्योंकि वे हर स्थिति का सटीक उत्तर देने का वादा करते हैं। व्यवहार में rules का ढेर undocumented authorization program बन जाता है और काम रुकने पर टीमें broad exception दे देती हैं। छोटा और साफ gates का सेट जांचना आसान और गलती से कमजोर करना कठिन है।

Sallyport एक fixed decision ladder इस्तेमाल करता है: locked vault हर action अस्वीकार करता है, नया agent process डिफ़ॉल्ट रूप से session authorization मांगता है और चुने हुए credentials हर इस्तेमाल पर approval मांग सकते हैं। Model जानबूझकर छोटा रखा गया है, ताकि agent credential boundary approval state को स्पष्ट बनाए, administrators को authorization syntax debug न करनी पड़े।

Audit trail को run के बाद सवाल का जवाब देना चाहिए

Agent activity के दो views चाहिए: एक run के लिए और एक हर credentialed call के लिए। Session record बताता है कि agent किसने चलाया और उसकी authority कब खत्म हुई। Action record बताता है कि कौन-सा destination, method या command, credential reference, decision और result हुआ।

टीमें अक्सर केवल terminal transcript लॉग करती हैं। यह पर्याप्त नहीं है। Transcript वह दिखाता है जो agent ने print किया, जरूरी नहीं कि executor ने जो भेजा हो। Background calls छूट सकती हैं, output बदला हुआ हो सकता है या secret उजागर हो सकता है, अगर agent को वह मिला हो। दूसरी ओर raw packet या request log इतना sensitive data रख सकता है कि उसे सुरक्षित रखना कठिन हो।

हर byte नहीं, decision point लॉग करें। HTTP के लिए normalized method, host, path, credential reference, response status, timestamp, session identity और approval outcome रखें। Customer data बचाए बिना correlation चाहिए तो request-body digest या सीमित summary रिकॉर्ड करें। SSH के लिए verified host, remote user, command, exit status और वही session तथा approval fields रखें।

Record को इस सवाल का जवाब देना चाहिए: «किस authorized process ने deployment credential का इस्तेमाल करके कौन-सा operation किया और क्या किसी मानव ने उसे approve किया?» अगर जवाब नहीं मिलता, तो record debugging में मदद कर सकता है, लेकिन incident के बाद बहुत कम।

Tamper evidence record का मूल्य बढ़ाता है। उसी machine पर रखी plain log file को पर्याप्त local access वाला process बदल सकता है। Hash chain हर event को पिछले event से जोड़ती है, इसलिए पहले record को हटाने या बदलने पर बाद की verification टूट जाती है। Encryption content की सुरक्षा करता है, जबकि chaining यह प्रमाण देती है कि sequence बदला गया।

Sallyport session और action journals को encrypted, hash-chained audit log से project करता है, और sp audit verify ciphertext पर vault key के बिना offline chain जांच सकता है। Investigation के दौरान यह separation महत्वपूर्ण है: reviewer credentials या vault में रखे request contents तक पहुंचे बिना log integrity जांच सकता है।

Chain किसी compromised endpoint को जादुई रूप से trustworthy नहीं बनाती। Running application पर नियंत्रण रखने वाला attacker आपके response से पहले actions करने की कोशिश कर सकता है, और log entry लिखे जाने से पहले नियंत्रण पाने वाला attacker record को प्रभावित कर सकता है। Chain stored history के बारे में मजबूत evidence देती है। इसे prompt revocation, protected local storage और जरूरत पड़ने पर remote-side logs के साथ इस्तेमाल करें।

समस्या तब शुरू होती है जब एजेंट को सुविधाजनक escape hatch मिल जाता है

सबसे खतरनाक designs अक्सर उचित लगने वाले exception से शुरू होते हैं। कोई कहता है कि gateway एक integration के लिए बहुत restrictive है, इसलिए agent को environment में token के साथ generic shell command दे दें। या deployment tool को SSH चाहिए, इसलिए specific SSH action बनाने के बजाय forwarding चालू कर दें। या testing आसान बनाने के लिए engineer headers लौटाने वाला debug endpoint जोड़ देता है।

हर exception स्थानीय समस्या हल करता है और secret retrieval को किसी दूसरे नाम से वापस खोल देता है।

एक परिचित setup देखें। Coding agent के environment में service token है ताकि वह release command चला सके। Agent failed release की जांच मांगने वाली pull request comment पढ़ता है। Repository की helper script diagnostic command चलाती है। वह command environment variables को support archive में export कर देती है। Comment में ticket बनाने को कहा गया था, इसलिए agent archive को third-party issue tracker पर upload कर देता है।

किसी attacker को token value पहले से जानने की जरूरत नहीं थी। उसे केवल उस text को प्रभावित करना था जिसे agent ने instruction माना और उसे ऐसे tool path की ओर ले जाना था जिसने inherited state उजागर कर दी। पता चलने पर agent session revoke करने से archive वापस नहीं आता। Token rotate करना जरूरी हो जाता है और टीम को archive के हर destination की पहचान करनी पड़ती है।

Gated executor इस sequence को बदल देता है। Helper script फिर भी चल सकती है और agent approved API action से release status फिर भी प्राप्त कर सकता है। लेकिन वह environment से token नहीं पढ़ सकता, क्योंकि token वहां रखा ही नहीं गया था। Script नया credentialed call करने की कोशिश करे तो executor उसे रिकॉर्ड करता है और session या per-call decision लागू करता है। Support archive के पास चुराने के लिए कम सामग्री होती है।

केवल इसलिए bypass न दें कि agent कहता है कि task पूरा करने के लिए किसी tool की जरूरत है। पूछें कि tool को सबसे छोटी कौन-सी operation चाहिए। एक API endpoint call करना है तो वही operation expose करें। एक deployment command चाहिए तो वही command expose करें। जरूरत सचमुच व्यापक हो तो उसे broad authority मानें और मानव से अलग, सोच-समझकर चलाए जाने वाले workflow का इस्तेमाल कराएं।

सीमा उन कार्रवाइयों के आसपास बनाएं जो वास्तव में मायने रखती हैं

उन credentials से शुरुआत करें जिनके खोने पर emergency rotation करनी पड़ेगी या meaningful production change संभव होगा। हर development token को पहले दिन migrate करना जरूरी नहीं। सबसे खतरनाक credentials के चारों ओर बनी आधी सीमा उस complete migration से बेहतर है जिसे कोई पूरा नहीं करता।

पहले पता लगाएं कि agents आज authority कैसे प्राप्त करते हैं। Agent launch scripts, shell configuration, CI handoff files, tool configuration, local .env files और command wrappers खोजें। हर उस जगह को चिह्नित करें जो agent को token, password, private key, cloud session या forwarded authentication socket देती है। अक्सर पता चलता है कि inherited developer settings के जरिए agent को किसी की अपेक्षा से अधिक authority मिली हुई है।

फिर plaintext delivery को action requests से बदलें। Credential references को व्यक्ति या अस्पष्ट environment label के बजाय purpose से नाम दें। staging-deployer, shared-key-2 से ज्यादा स्पष्ट है। जब दो uses के approval requirements या destinations अलग हों, तो अलग references बनाएं।

हर reference को automate करने से पहले तय करें:

• इसके काम के लिए कौन-से HTTP hosts, methods और paths, या कौन-से SSH hosts, users और commands उचित हैं?
• क्या नए agent process को इस्तेमाल से पहले स्पष्ट approval चाहिए?
• क्या destructive या कठिनाई से reversible action होने के कारण हर use पर confirmation चाहिए?
• काम जारी रखने के लिए agent को result के कौन-से fields चाहिए?
• Secret material रखे बिना बाद में action समझाने के लिए कौन-से records चाहिए?

Rejection paths को happy path जितनी सावधानी से test करें। बिना approval agent process चलाकर पुष्टि करें कि वह action नहीं कर सकता। मिलते-जुलते host name, दूसरे host पर redirect, expected deployment path से बाहर command और credential reference को value की तरह print करने की कोशिश करें। Confirm करें कि revoked session आगे requests नहीं कर सकता।

Human side भी test करें। अगर approvals इतनी बार आती हैं कि आप पढ़ना बंद कर देते हैं, scopes गलत हैं। अगर dialog यह नहीं बता सकता कि request किस process ने की, तो process identity कमजोर है। अगर agent normal work पूरा करने के लिए बार-बार generic escape hatch मांगता है, तो interface में एक और carefully bounded operation जोड़ें, secret dump नहीं।

सफलता का मानक सरल है: agent approved work पूरा कर सके, लेकिन transcript, subprocess, plugin या poisoned instruction उस काम को reusable credential के स्वामित्व में न बदल सके। अगली urgent deployment में सुविधाजनक exception harmless लगे, उससे पहले इस मानक तक पहुंचने की तैयारी करें।