# Basic authentication usernames sensitive metadata होते हैं Basic authentication usernames sensitive metadata होते हैं। यह बात तब तक जरूरत से ज्यादा सावधान लग सकती है, जब तक आपको किसी ऐसे automation run के बाद सफाई न करनी पड़े जिसने `billing-export@north-division` को shell transcript, CI log, agent prompt और incident ticket में कॉपी कर दिया हो। हो सकता है कि इन चारों जगहों पर password मौजूद न हो। फिर भी attacker को पता चल जाता है कि north-division tenant मौजूद है, उसमें billing export integration है और account शायद किसी खास legacy API तक पहुंचता है। Teams अक्सर data को secrets और बाकी सब कुछ, इन दो हिस्सों में बांटती हैं। Agent-driven API work के लिए यह बंटवारा बहुत मोटा है। Username, tenant ID, hostname, API path और response code अलग-अलग देखने पर harmless लग सकते हैं। इन्हें साथ रखें तो ये ऐसा account structure बताते हैं जिस पर हमला करना worthwhile हो सकता है। इन combinations को sensitive metadata मानें, खासकर तब जब agent किसी व्यक्ति के एक request टाइप करने की तुलना में context को कहीं अधिक दूर और तेजी से कॉपी कर सकता हो। ## Username account system की बनावट बता सकता है Basic username अक्सर अपने field name से कहीं अधिक जानकारी रखता है। Legacy systems इसे login name, customer code, division label, service role, environment marker या compound identifier के रूप में इस्तेमाल करते हैं। कई बार यह identifier उस समय जोड़ दिया गया था, जब identity model के लिए बेहतर विकल्प मौजूद नहीं था। इन values पर ध्यान दें: ```text acme-east:password svc-payroll-prod:password tenant-48291-export:password j.smith@customer.example:password ``` पहली value customer और regional split बताती है। दूसरी internal capability और environment का नाम देती है। तीसरी tenant identifier और function दिखाती है। चौथी किसी व्यक्ति और customer relationship को उजागर करती है। Password rotation से password वाला हिस्सा बदल जाता है। कॉपी किया हुआ account map गायब नहीं होता। यह इसलिए महत्वपूर्ण है क्योंकि attackers हर बार credential से हमला शुरू नहीं करते। वे target list से शुरुआत करते हैं। पहचान में आने वाला username believable reset request बनाने, related accounts का अनुमान लगाने, breach dumps खोजने, customer-specific route को probe करने या support पर ऐसे details के साथ दबाव डालने में मदद करता है जो internal लगती हैं। यह कहकर इसे theoretical न मानें कि username केवल password के साथ valid है। यह जानना कि `svc-orders-import-prod` मौजूद है, उस account को control करने के बराबर नहीं है, लेकिन यह कुछ भी न जानने से कहीं अधिक उपयोगी है। Security work तब महंगा हो जाता है जब teams किसी field को protect करने से पहले उसके complete credential बनने का इंतजार करती हैं। सही classification context पर निर्भर करती है। हर sandbox account में इस्तेमाल होने वाले generic public username को शायद कम protection चाहिए। Internal endpoint के साथ जुड़ी tenant-scoped service identity को कहीं अधिक सावधानी से संभालना चाहिए। हर integration के लिए यह अंतर लिखकर तय करें, leak के बाद blanket label न लगाएं। ## Basic authentication हर call के साथ account name जोड़ता है Basic authentication HTTP `Authorization` header में `user-id:password` value को Base64 में encoded रूप में भेजता है। Base64 representation बदलता है। Header पढ़ सकने वाले व्यक्ति से original bytes छिपाता नहीं है। एक सामान्य request ऐसी दिखती है: ```http GET /v1/exports/monthly HTTP/1.1 Host: api.legacy.example Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ= Accept: application/json ``` Client के API call करने पर encoded text दोनों हिस्से हर बार साथ ले जाता है। Teams अक्सर इसी repetition को भूल जाती हैं। Bearer token भी account context उजागर कर सकता है, लेकिन कई Basic integrations human-readable usernames इस्तेमाल करती हैं, जिन्हें decode करने के बाद account context साफ दिखाई देता है। RFC 7617 इस scheme को define करता है और यहां दो details महत्वपूर्ण हैं। पहली colon user-id और password को अलग करती है, इसलिए username में colon मान्य नहीं है। Control characters भी forbidden हैं। इसका अर्थ है कि कोई legacy vendor देखने में सुविधाजनक account convention स्वीकार कर सकता है, लेकिन वह standards-compliant Basic header में टिक ही न पाए। अपनी escaping rule न बनाएं और यह उम्मीद न करें कि हर library उससे सहमत होगी। दूसरी detail character handling है। RFC 7617 server challenge में UTF-8 advertise करने की अनुमति देता है, लेकिन यह signal advisory है और कई पुराने systems non-ASCII identities को एक जैसा handle नहीं करते। अगर account name में accented characters, case rules या transformed Unicode है, तो production से पहले exact client और server pair को test करें। Mismatch से authentication failure हो सकती है और कोई व्यक्ति उसे ठीक करने के लिए पूरा credential debug output में डाल सकता है। Basic authentication के लिए HTTPS भी जरूरी है। OWASP Basic credentials को encrypted नहीं, encoded बताता है और Basic के इस्तेमाल पर TLS की सलाह देता है। TLS transit में connection को सुरक्षित रखता है। लेकिन client library, reverse proxy, tracing agent, error handler या debugging tool header record कर ले, तो वह उसे सुरक्षित नहीं करता। ## Tenant IDs और endpoints की जोड़ी खतरनाक बन जाती है Tenant ID अकेले कोई opaque number हो सकता है। Endpoint अकेले generic route हो सकता है। साथ मिलकर ये customer के business function और उसे चलाने वाले system की पहचान कर सकते हैं। मान लें agent को यह instruction मिलती है: ```text For tenant 48291, call https://ledger.internal.example/v2/reconciliation/import with username tenant-48291-ledger-import. ``` भले ही कोई दूसरा component password डालता हो, instruction agent को tenant, host, operation और service identity दे देती है। Agent इस instruction को अपने working notes में quote कर सकता है। Tool wrapper इसे record कर सकता है। Model transcript इसे बचाकर रख सकता है। Developer error को chat channel में paste कर सकता है। Password दिखाई नहीं दिया, लेकिन account structure छिपा नहीं रहा। जब names किसी predictable grammar का पालन करते हैं, exposure और बढ़ता है। अगर एक username `tenant-48291-ledger-import` है, तो `tenant-48291-ledger-export`, `tenant-48291-reporting` या दूसरे tenants के लिए वही roles होने का अनुमान लगाना आसान है। Predictability operators के लिए सुविधाजनक और enumerators के लिए उपयोगी है। आपको सभी naming conventions छोड़ने की जरूरत नहीं है, लेकिन यह समझें कि convention कब एक leaked name को directory query में बदल देती है। Endpoint pairs अपना signal भी लेकर चलते हैं। Neutral hostname होने पर भी `/admin/users`, `/payroll/export`, `/claims/submit` और `/archive/retention` अलग-अलग तरह के काम बताते हैं। Host, path और tenant मिलकर phishing message या support impersonation attempt को विश्वसनीय बनाने के लिए पर्याप्त जानकारी दे सकते हैं। सिर्फ fields नहीं, पूरी tuple को classify करें: - service identity plus tenant ID - service identity plus hostname - tenant ID plus endpoint path - endpoint path plus response body या error text - timestamp plus successful action record यह rule "password redact करें" से अधिक स्पष्ट है। इससे reviewers समझ सकते हैं कि literal secret न रखने वाली log line भी broad observability system में भेजने के लिए unsafe क्यों हो सकती है। ## Agents context वहां कॉपी करते हैं जहां ordinary clients नहीं करते Ordinary API client आमतौर पर URL, account name और password को narrow configuration path से पाता है। AI agent instructions को text की तरह handle करता है। वह repository देख सकता है, ticket पढ़ सकता है, command चला सकता है, error समझ सकता है और summary लिख सकता है। हर handoff उन identifiers को बचा सकता है जिन्हें traditional client को कभी display करने की जरूरत नहीं पड़ती। जोखिम यह नहीं है कि agents अपने आप में असावधान होते हैं। जोखिम यह है कि agent workflows design के स्तर पर context को portable बनाते हैं। जिस feature से agent deployment note और API response के बीच reasoning कर पाता है, वही feature उसे tenant names और endpoint patterns को tool inputs, transcripts या generated patches में ले जाने देता है। एक आम failure ऐसा दिखता है: 1. Developer local `.env` file में Basic username और tenant code रख देता है, क्योंकि password secret store से आता है। 2. Failing integration समझने के लिए agent file पढ़ता है। 3. API verbose 401 response लौटाती है, जिसमें username और tenant दोहराए जाते हैं। 4. Agent config excerpt और error वाली troubleshooting report लिखता है। 5. Developer report को ऐसे issue में paste कर देता है जिसे बड़ा group देख सकता है। किसी ने credentials publish करने का इरादा नहीं रखा था। फिर भी issue में valid naming pattern, tenant, host, route, service role और वह time window दर्ज हो जाती है जब integration active थी। यह context आगे के जोखिम के लिए काफी है। हर nonsecret string को agents से छिपाना समाधान नहीं है। इससे उपयोगी काम रुकता है और व्यवहार में यह अक्सर विफल होता है। इसके बजाय तय करें कि किस action को कौन सी facts चाहिए। Monthly export request करने वाले agent को abstract action name और month की जरूरत हो सकती है। उसे Basic username, password, tenant routing rule या raw target URL की जरूरत नहीं है। इससे design question बदल जाता है। सवाल यह नहीं रहता कि "क्या agent authenticate कर सकता है?" सवाल यह बनता है कि "Intended request बनाने के लिए agent को action description का सबसे छोटा कौन सा रूप चाहिए?" यही सवाल account structure को agent के context window से बाहर रखता है। ## Identity material को prompts और repositories से बाहर रखें Prompt configuration store के लिए खराब जगह है। Source files, sample curl commands, issue templates, shell aliases और test fixtures भी ऐसे ही हैं। ये सभी अपने author की अपेक्षा से कहीं ज्यादा दूर तक पहुंचते हैं। सबसे पहले उन तीन चीजों को अलग करें जिन्हें teams अक्सर मिला देती हैं: 1. **Credential material** authentication के लिए इस्तेमाल होने वाला username और password है। 2. **Routing metadata** बताता है कि request कहां जाएगी, जैसे host, tenant partition या endpoint family। 3. **Action intent** business operation है, जैसे "March reconciliation file डाउनलोड करें।" Human या agent अक्सर बाकी दो categories देखे बिना action intent बता सकता है। यही preferred boundary है। अगर legacy API tenant-specific host या tenant-specific username के जरिए routing मजबूर करती है, तो mapping उस component में रखें जो request execute करता है, उस prompt में नहीं जो request मांगता है। Repository में ऐसे raw `.env` examples न रखें: ```bash LEGACY_API_URL=https://tenant-48291.api.legacy.example/v2/payroll/export LEGACY_API_USER=tenant-48291-payroll-export LEGACY_API_PASSWORD=replace-me ``` `replace-me` placeholder example को safe नहीं बनाता। URL और username अब भी customer-specific integration pattern document करते हैं। कॉपी किया हुआ example बाद में production configuration में बदल सकता है, अक्सर deadline के दबाव में। इसके बजाय abstract local contract इस्तेमाल करें: ```yaml actions: export_monthly_payroll: account_ref: payroll-export-production target_ref: payroll-export-api inputs: - tenant_alias - month ``` `account_ref` और `target_ref` labels इतने opaque होने चाहिए कि repository reader customer, hostname या service role का अनुमान न लगा सके। Executor इन्हें locally resolve करे। Agent को `tenant_alias` तभी दें जब action को सच में इसकी जरूरत हो, और जब local mapping काम कर सकती हो तब यह alias production tenant identifier नहीं होना चाहिए। यह तरीका एक आम migration mistake भी रोकता है: password को secret manager में ले जाना, लेकिन username, target URL और customer code को application में hard-code छोड़ देना। Password commit करने से यह बेहतर है, लेकिन इससे structure हर developer, build log और code-scanning export के सामने खुला रहता है। ## ऐसे aliases इस्तेमाल करें जो एक leak को directory में न बदलें Opaque names कोई जादुई समाधान नहीं हैं, लेकिन accidental disclosure से मिलने वाली जानकारी घटाते हैं। Account name का purpose उस छोटे group को समझ आना चाहिए जो इसे administer करता है, हर उस system को नहीं जो इसे देखता है। इन service aliases की तुलना करें: ```text bad: acme-east-payroll-export-prod better: svc-47f2-export-p1 ``` दूसरे alias में readable service prefix और environment marker अब भी है। यह अक्सर practical होता है। उपयोगी details वहीं तक रुक जाती हैं। एक अलग protected registry `svc-47f2-export-p1` को customer, owner, endpoint, permissions और rotation record से map कर सकती है। Random-looking aliases को authorization का विकल्प न समझें। Password रखने वाला attacker अब भी authenticate कर सकता है और registry access वाला employee mapping देख सकता है। Aliases अनावश्यक disclosure घटाते हैं। Least privilege और access reviews account की capabilities को नियंत्रित करते हैं। ऐसे मामले भी हैं जहां vendor username format तय करता है। कुछ पुराने APIs customer number, email address या region वाला compound value अनिवार्य करते हैं। ऐसा हो तो मानें कि field sensitive है और उसके आसपास का handling बदलें। Value का नाम नहीं बदल सकते, इसलिए उसे public मानने का दिखावा न करें। Vendor-required identifiers को credential boundary में रखें और downstream outputs को साधारण बनाएं। Request executor `export accepted` और job identifier लौटा सकता है। Calling agent को submitted username, पूरा target URL या tenant routing value दोहराने की जरूरत नहीं है। ## Logs को account directory बनाए बिना audit trail रखें Security logging में इतना detail होना चाहिए कि पता चल सके action किसने शुरू किया, क्या हुआ, कब हुआ और सफल हुआ या नहीं। Client ने भेजे हर byte को बचाकर रखने की जरूरत नहीं है। OWASP की logging guidance passwords, session identifiers और अनावश्यक system details जैसी sensitive information को log न करने की स्पष्ट चेतावनी देती है, साथ ही authentication और access-control events record करने को कहती है। यह tension वास्तविक है। सब कुछ हटा दें तो operators incident की जांच नहीं कर पाएंगे। Raw headers और full URLs हमेशा रखते रहें तो logs searchable account directory बन जाएंगे। Operational correlation को sensitive metadata से अलग रखने वाला record shape इस्तेमाल करें: ```json { "event": "legacy_api_call", "action": "export_monthly_payroll", "request_id": "req_01J...", "actor_run": "run_01J...", "credential_ref": "cred_4c91", "target_ref": "target_a77e", "result": "denied", "http_status": 401, "reason": "authentication_failed", "occurred_at": "2026-07-22T14:03:21Z" } ``` References authorized operators को protected inventory के साथ events correlate करने देती हैं। Username, tenant ID, raw endpoint या Authorization header हर event में नहीं आते। Inventory access को ordinary log access से अधिक सीमित रखें। Username का hash करके समस्या हल हुई मान लेना गलत है। छोटे और patterned username space का deterministic hash अक्सर guess किया जा सकता है, और stable hash records के बीच account tracking की अनुमति देता है। Correlation चाहिए तो अपने system द्वारा दिया गया random credential reference इस्तेमाल करें। Credential rotate करने पर reference को भी rotate या retire करें। Failure diagnostics के साथ सावधान रहें। यह response आगे भेजना गलत है: ```text 401 for tenant-48291-payroll-export at /v2/payroll/export: user exists but password rejected ``` यह account, tenant, route और validation result की पुष्टि कर देता है। बेहतर internal handling में vendor का exact diagnostic restricted support record में रखा जा सकता है, अगर सच में जरूरत हो। General activity trail में केवल `authentication_failed` record करें। Agent को छोटा failure दें, जो उसे रुककर help मांगने के लिए कहे, न कि variations आजमाने का एक और संकेत दे। ## Redaction और minimization अलग समस्याएं हल करते हैं Redaction किसी known dangerous value को तब हटाता है जब वह पहले ही किसी system ने handle कर ली हो। Minimization उस value को ऐसी जगह पहुंचने से रोकता है जहां उसका होना जरूरी नहीं है। आपको दोनों चाहिए और इन्हें मिलाने से खराब designs बनते हैं। Header scrubber इसे: ```http Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ= ``` ऐसा बना सकता है: ```http Authorization: [REDACTED] ``` यह जरूरी है। लेकिन इससे path, hostname, tenant query parameter, verbose 401 body, request label या header के साथ record हुए trace attributes का कुछ नहीं होता। Password redact करने पर गर्व करने वाला system, अगर `tenant-48291.api.legacy.example/payroll/export` बचाए रखता है, तो एक risk घटाता है और उपयोगी account map छोड़ देता है। Minimization request चलने से पहले कठिन सवाल पूछता है: - क्या agent को actual target host चाहिए या केवल action name? - क्या activity log को tenant identifier चाहिए या protected reference? - क्या support को ordinary log stream में raw vendor response चाहिए? - क्या executor locally resolve कर सकता है, फिर भी URL में tenant डालना जरूरी है? - क्या approval देखने वाले व्यक्ति को पूरी identity चाहिए या human-friendly, लेकिन nonrevealing label? यहीं teams अक्सर एक popular लेकिन गलत recommendation देती हैं: "पूरी request एक बार log कर लें, filters बाद में सुधार लेंगे।" ऐसा इसलिए कहा जाता है क्योंकि legacy APIs debug करना कठिन होता है और full captures सवालों के जल्दी जवाब देते हैं। लेकिन captured data backups, analytics stores, test environments और copied incident notes में स्थायी evidence बन जाता है। इसके बजाय short-lived investigation के लिए restricted diagnostic path बनाएं। Broad raw capture को normal operating mode न बनाएं। ## Legacy APIs को blind trust नहीं, containment boundary चाहिए हो सकता है कि इस quarter में Basic authentication को replace करना संभव न हो। Supplier केवल एक integration style support कर सकता है। Warehouse appliance की API कई साल पहले freeze हो चुकी हो सकती है। Practical response containment है, यह मान लेना नहीं कि legacy API acceptable है। Basic credential और identifier mapping को ऐसे component के पीछे रखें जो खुद HTTP request करता हो। Agent को structured inputs वाला named action मांगना चाहिए। Request component target चुनता है, credential प्राप्त करता है, header में उसे डालता है, intended scope जांचता है और limited result लौटाता है। Agent action के लिए useful request contract ऐसा हो सकता है: ```json { "action": "export_monthly_payroll", "tenant_alias": "tenant_ref_91ab", "month": "2026-06" } ``` Action executor month validate कर सकता है, protected local mapping में `tenant_ref_91ab` resolve कर सकता है और vendor call कर सकता है। उसे `url`, `authorization`, `username` और `headers` जैसे extra fields reject करने चाहिए। अगर callers इन fields को override कर सकते हैं, तो वे trusted credential को arbitrary host पर भेज सकते हैं या narrowly defined action को raw HTTP client में बदल सकते हैं। यह restriction credential exposure के साथ SSRF-style mistakes के लिए भी महत्वपूर्ण है। User-provided URL कोई harmless convenience नहीं है, जब executor के पास credentials हों। Target controlled definition से आना चाहिए और redirects को भी उतनी ही सावधानी से handle करना चाहिए। Authorization header रखते हुए किसी नए origin पर redirect follow न करें। यह boundary retries भी संभाले। खराब design वाला agent बदले हुए input के साथ 401 retry कर सकता है या timeout के बाद operation बार-बार चला सकता है। Executor को safe transport retry, authentication failure और unknown write outcome में अंतर करना चाहिए। Non-idempotent legacy endpoint के लिए ऐसा status लौटाएं जो human review मजबूर करे, न कि agent के confidence से उसी request को फिर भेज दे। जब MCP-capable agent को HTTP API call करनी हो और उसे Basic credential नहीं देना हो, तब Sallyport इसी pattern पर काम करता है। इसका HTTP channel app के भीतर Basic credentials डालता है और per-session तथा per-call controls से व्यक्ति तय कर सकता है कि agent run उस account का इस्तेमाल कब करे। Agent को action result मिलता है, plaintext username या password नहीं जिसे वह कहीं और reuse कर सके। ## Approval में गलत action पकड़ने लायक context दिखना चाहिए सिर्फ "Allow API call?" कहने वाला approval dialog मदद नहीं करता। पूरा Basic username, tenant, full URL और raw request body दिखाने वाला dialog बहुत ज्यादा जानकारी साझा करता है। Reviewer को ऐसी compact description चाहिए जो account structure खोले बिना गलत action को स्पष्ट कर दे। Action name, protected target label, reviewer के लिए चुना tenant display label, operation type और high-level consequence दिखाएं। उदाहरण: ```text Allow export_monthly_payroll? Target: Payroll export service Tenant: Finance tenant 7 Operation: Create June 2026 export Agent run: signed local coding process ``` इससे reviewer unexpected month, function या target पहचान सकता है। Approval record में vendor hostname, tenant number या service username उजागर नहीं होता। Display label के लिए governance चाहिए। अगर केवल एक finance customer वाली team में "Finance tenant 7" दिखता है, तो वह customer की पहचान फिर भी बता सकता है। Labels उस group के अनुसार चुनें जो उन्हें देखेगा। Security का अर्थ यह नहीं है कि हर उपयोगी नाम को ऐसे opaque code से बदल दें जिसे reviewers समझ ही न सकें। Sensitive Basic accounts के लिए हर use पर approval मांगें, जब action money move कर सकता हो, regulated records export कर सकता हो, access बदल सकता हो या external party से संपर्क कर सकता हो। कई low-risk reads वाले short run के लिए per-session approval अधिक practical है। Choice account की authority और action के consequence पर निर्भर होनी चाहिए, केवल इस बात पर नहीं कि Basic authentication पुराना है। Approval decision और resulting call का auditable record रखें। Tamper-evident record तभी उपयोगी है जब वह actor, action, result और approval state बताए और credential map की एक और copy न बन जाए। Sallyport के अलग session और activity journals इसी विभाजन के लिए बनाए गए हैं। दोनों views उसके encrypted hash-chained audit log से project होते हैं। ## Account structure को शुरू से collect करना कठिन बनाएं समाधान ऐसा विशाल policy document नहीं है जो कहे, "Metadata को सावधानी से संभालें।" Safer route को वह path बनाएं जिसे developers और agents स्वाभाविक रूप से इस्तेमाल करें। हर Basic integration की inventory बनाएं और हर एक के लिए पूछें: Username क्या उजागर करता है? इसमें person, customer, environment, product या role है? कौन सा host और endpoint pair उस value को अधिक revealing बनाता है? ये values आज कहां दिखाई देती हैं? इन्हें वास्तव में किस caller को देखना जरूरी है? फिर आसान copies हटाएं। Raw curl snippets को action examples से बदलें। Tenant-specific fixture names को neutral test aliases से बदलें। Application logs में Authorization headers और URL userinfo block करें। Full vendor diagnostics को agent-visible output से बाहर रखें। Credential boundary पर user-supplied request targets reject करें। Incident justify करे तो support को details पाने का controlled तरीका दें। RFC 9110 कहता है कि senders को `user:password@host` userinfo वाले HTTP या HTTPS URI references generate नहीं करने चाहिए। यह चेतावनी भी दी गई है कि configuration या command options में उस form का इस्तेमाल करने पर implementations user identifier या password उजागर कर सकती हैं। URLs से आगे भी यह एक उपयोगी warning है: convenient text fields में रखी identity details अक्सर उन जगहों पर कॉपी हो जाती हैं जहां उनका होना कभी intended नहीं था। Basic authentication इसलिए बना रह सकता है क्योंकि vendor आगे नहीं बढ़ा है। आपके अपने handling को उसके साथ अटके रहने की जरूरत नहीं है। जब आप usernames, tenant IDs और endpoint pairs को sensitive metadata मानते हैं, तो agent को task के साथ account directory देना बंद कर देते हैं।