AI एजेंटों के लिए HTTP connection pool credential isolation

दोबारा इस्तेमाल किया गया HTTP connection अपने आप credential leak नहीं होता। उसे हानिरहित मान लेने से टीमें असली विफलता नहीं देख पातीं: client object cookies, challenge responses, redirect headers, proxy identity या TLS identity जमा करता है, फिर बाद का अनुरोध अलग credential के साथ वह state उधार ले लेता है।

HTTP connection pool credential isolation का मतलब तय करना है कि कौन सी state requests के बीच जा सकती है और बाकी को साझा करना असंभव बनाना है। केवल destination host आम तौर पर action runner या कई अकाउंट के लिए काम कर सकने वाले agent के लिए बहुत व्यापक सीमा है। कभी-कभी गलत अकाउंट की cookie भेजने वाला तेज client, धीमे client से बदतर है, क्योंकि गलती सामान्य सफल request जैसी दिखती है।

Socket transport है, account ownership नहीं

TCP connection किसी origin के लिए bytes ले जाता है। वह application को भरोसेमंद account boundary नहीं देता। HTTP/1.1 कनेक्शन को क्रम से फिर इस्तेमाल करता है और HTTP/2 एक साथ कई streams चला सकता है, पर कोई भी protocol यह नहीं कहता कि कनेक्शन पर हर request एक ही user या service account की है।

यह अंतर अहम है क्योंकि client libraries अक्सर असंबंधित चिंताओं को session, agent, client या transport नाम के एक सुविधाजनक interface के पीछे रखती हैं। फिर developers हर host के लिए ऐसा एक object बनाते हैं और हर call से पहले bearer token जोड़ते हैं। bearer header हर बार सही हो सकता है, जबकि cookie jar, digest challenge cache या proxy context चुपचाप उस आखिरी account का हो सकता है जिसने object इस्तेमाल किया था।

RFC 9110 authentication को request और protection-space behavior मानता है। client किसी खास origin, scheme और realm की challenge का जवाब देता है। यह नहीं कहता कि खुला connection किसी व्यक्ति या service account का मालिक है। अगर आपका client ऐसा ownership मानता है, तो वह मान्यता HTTP से नहीं, आपके code या उसकी library से आती है।

Connection reuse फिर भी उपयोगी है। इससे बार-बार handshake नहीं होता, port churn कम होता है और load में remote service को मदद मिलती है। सही नियम अधिक सीमित है: connection केवल उन requests में फिर इस्तेमाल करें जिनकी connection-level और client-managed state जानबूझकर संगत हो।

अलग रखने योग्य state दो समूहों में आती है:

• Request state में Authorization, Cookie, account headers, request bodies और idempotency values शामिल हैं। कॉलर को हर कार्रवाई के लिए इन्हें नया बनाना चाहिए।
• Connection और client state में pool entry, proxy session, client certificate selection, redirect behavior, cookies, challenge caches और protocol settings शामिल हैं। client को इन्हें जानबूझकर scope करना या बंद करना चाहिए।

केवल Authorization header में इस्तेमाल होने वाला bearer credential किसी दूसरे bearer credential के साथ TCP connection साझा कर सकता है, यदि library हर request के लिए headers भेजती है और कोई account state नहीं रखती। यह सीमित दावा है, सामान्य अनुमति नहीं। जैसे ही service session cookie भी set करती है, दूसरे host पर redirect करती है या client certificate मांगती है, उसी pool design को फिर से जांचना चाहिए।

Cookies, नाम साधारण लगने पर भी account state हैं

Accidental account crossover का सबसे आम कारण cookie jar है। टीमें bearer token API देखकर मान लेती हैं कि cookies का कोई महत्व नहीं, फिर load balancer, interactive login endpoint या legacy service response में Set-Cookie जोड़ देती है। सामान्य HTTP client उसे आम तौर पर store कर लेता है, जब तक आप उसे रोकें नहीं।

RFC 6265 बताता है कि user agent domain, path, security attributes और संबंधित नियमों के आधार पर cookies कैसे चुनता है। उसके storage model में "जिस credential record को यह cookie मिली" जैसा कोई field नहीं है। इसलिए एक ही host और path को call करने वाले दो bearer credentials एक ही stored cookie के योग्य हो सकते हैं। Protocol अपने नियम बिल्कुल सही ढंग से निभाता है, जबकि आपका application accounts को पार कर जाता है।

Test service की इस trace पर विचार करें। Account alpha bearer token इस्तेमाल करता है और उसे affinity cookie मिलती है:

GET /v1/whoami HTTP/1.1
Host: api.example.test
Authorization: Bearer alpha-token

HTTP/1.1 200 OK
Set-Cookie: route=alpha-node; Path=/; Secure; HttpOnly
Content-Type: application/json

{"account":"alpha"}

अगली कार्रवाई beta को चुनती है। अगर shared jar stored cookie भेजता है, तो request में ownership के दो संकेत होते हैं:

GET /v1/whoami HTTP/1.1
Host: api.example.test
Authorization: Bearer beta-token
Cookie: route=alpha-node

सबसे अच्छा नतीजा वह service है जो mismatch अस्वीकार कर दे। कम सावधान services beta की request को alpha के sticky session से route कर सकती हैं, उसे गलत server-side context से जोड़ सकती हैं या जो header प्रभावी हो उसे स्वीकार सकती हैं। Client यह भरोसा नहीं कर सकता कि remote service mixed request को बचा लेगी।

Machine-to-machine APIs के लिए मेरा सीधा default है: ambient cookie storage बंद करें। अगर API को सचमुच cookies चाहिए, तो एक credential record और एक तय service context के लिए cookie jar बनाएं। केवल host string मेल खाने के कारण उसे साझा न करें।

Credential injection से पहले request inputs भी जांचें। Agent, plugin या caller अपना Cookie header credentialed call तक पहुंचने योग्य नहीं होना चाहिए। Ambient authentication headers और cookies हटाएं, फिर केवल वे headers जोड़ें जिनकी action definition अनुमति देती है। वरना आपने isolation उस दरवाजे के चारों ओर बनाया है जिसे callers पार कर सकते हैं।

Authentication challenges को मौजूदा caller चाहिए

401 response केवल error code नहीं है। यह client को credentials चुनकर retry करने के लिए कह सकता है, और यह selection logic अक्सर उस code के बाहर रहती है जिसने मूल request बनाई थी। Basic और Digest authentication handlers खास तौर पर इस pattern के प्रति संवेदनशील हैं, लेकिन custom middleware bearer tokens के साथ भी यही गलती कर सकता है।

खराब implementation shared client पर mutable currentCredential रखता है। Request A को challenge मिलती है, handler alpha का secret लोड करता है और client retry करता है। Retry पूरी होने से पहले Request B शुरू होती है और currentCredential को beta में बदल देती है। अब challenge handler में race है, जिसे test suites नहीं पकड़ते क्योंकि वे requests एक-एक करके चलाते हैं।

Global credential field पर lock लगाकर इसे ठीक न करें। Lock काम को serialise कर देता है और identity की जिम्मेदारी फिर भी गलत object पर छोड़ता है। Credential record को request context से बांधें, उसे हर retry तक ले जाएं और context न होने पर retry अस्वीकार करें।

Digest authentication पर विशेष संदेह करें। इसमें nonces, realms, counters और calculated response होते हैं। ये values challenged protection space से जुड़ी होती हैं, किसी सामान्य shared client से नहीं। Basic authentication wire पर सरल है, लेकिन बाद की requests में उसे अपने आप जोड़ने वाले cache को भी वही credential scope चाहिए।

ऐसा test endpoint इस्तेमाल करें जो हर account के लिए अलग realm या challenge लौटाए। फिर concurrent requests चलाएं और assert करें कि हर retry अपनी कार्रवाई से जुड़े credential record का इस्तेमाल करती है। केवल अंतिम 200 status जांचने वाला test कमजोर है। Server पर request identity capture करें और alpha की challenge से beta authorization attempt बने तो test fail करें।

403 को challenge न समझें। Servers कई authorization decisions के लिए 403 इस्तेमाल करते हैं और clients को दूसरा credential ढूंढने की अनुमति नहीं माननी चाहिए। Credentials के बीच automatic fallback access failure को account probing में बदल देता है, जो असुरक्षित है और audit करना मुश्किल है।

HTTP/2 में ownership की गलतियां छिपाना आसान है

HTTP/2 कई streams को एक TLS connection साझा करने देता है। यह कुशल है, लेकिन एक request के दूसरी के पीछे इंतजार करने का पुराना दृश्य संकेत हटा देता है। Client alpha और beta के actions एक ही समय भेज सकता है और उनके headers तभी अलग रहते हैं जब library उन्हें अंत तक अलग requests की तरह model करे।

RFC 9113 HTTP/2 requests में HTTP/1.1 के connection-specific header fields, जैसे Connection, पर रोक लगाता है। यह नियम cookies या authentication को account scoped नहीं बनाता। यह केवल hop behavior के एक वर्ग को सामान्य request headers की तरह व्यक्त होने से रोकता है। Cookie selection, retry selection, redirects और shared middleware की जिम्मेदारी फिर भी आपके client की है।

HTTP/2 connection coalescing एक और पेच जोड़ता है। कुछ clients certificate और name checks की अनुमति होने पर एक secure connection को एक से अधिक origins के लिए इस्तेमाल कर सकते हैं। Coalescing अपने आप Authorization header replay नहीं करता। इसका मतलब इतना है कि साधारण host comparison पर आधारित pool identity शायद उस connection को न बताए जिसे client ने वास्तव में चुना। Origin authorization decisions को transport optimization से अलग रखें और जिस library behavior को deploy करते हैं उसका परीक्षण करें।

Header compression को लेकर भी लोग गलत कारण से चिंतित होते हैं। HPACK एक HTTP/2 connection में headers compress करता है और QPACK HTTP/3 के लिए इससे मिलता-जुलता काम करता है। Compliant client पिछले request की Authorization value को बाद की request में decode नहीं करता। खतरा आपके client code में direct state reuse का है, साथ ही असामान्य threat models में metadata concerns का भी। यदि आपकी library नियंत्रण देती है, तो sensitive headers को कभी index न करने के लिए mark करें, लेकिन इसे request isolation का विकल्प न कहें।

HTTP/3 transport को TCP से QUIC में बदलता है। Ownership का नियम नहीं बदलता। ऐसा pool जो cookie jar या credential cache को actions के बीच खुलकर घूमने देता है, QUIC पर भी गलत है।

Client certificates अलग हैं। TLS client certificate connection स्थापित करते समय चुना जाता है, इसलिए वह वास्तव में connection-bound है। अलग client certificate identities को एक connection या pool entry से कभी multiplex न करें। Certificate record को pool identity में रखें या हर certificate के लिए अलग client instance दें। यही सावधानी उस proxy पर भी लागू होती है जो requests forward करने से पहले connection को authenticate करती है।

Code में pool identity साफ रखें

Pool identity में हर वह value शामिल होनी चाहिए जो नए connection के सुरक्षित अर्थ को बदलती है। Cookies बंद और proxy identity रहित bearer-only API के लिए यह origin के साथ credential record identifier हो सकता है। Client certificate, proxy-authenticated path या विशेष TLS profile हो, तो उनके identifiers भी शामिल करें।

Map identifier के रूप में secret text इस्तेमाल न करें। इससे memory और logs में secret की अनावश्यक copies बनती हैं, rotation जटिल होती है और debugging के दौरान कोई map print करने के लिए ललचा सकता है। Opaque credential record ID इस्तेमाल करें, जिसकी lifetime आपका vault या action registry नियंत्रित करे।

यह TypeScript sketch इसका स्वरूप दिखाता है। इसमें Undici का Pool इस्तेमाल हुआ है, लेकिन सीमा किसी भी client library पर लागू होती है। credentialId एक identifier है, bearer value नहीं।

import { Pool } from "undici";

type Boundary = {
  origin: string;
  credentialId: string;
  proxyId?: string;
  clientCertificateId?: string;
};

const pools = new Map<string, Pool>();

function poolId(boundary: Boundary): string {
  return [
    boundary.origin,
    boundary.credentialId,
    boundary.proxyId ?? "direct",
    boundary.clientCertificateId ?? "none"
  ].join("\u001f");
}

function poolFor(boundary: Boundary): Pool {
  const id = poolId(boundary);
  let pool = pools.get(id);
  if (!pool) {
    pool = new Pool(boundary.origin);
    pools.set(id, pool);
  }
  return pool;
}

function headersFor(token: string, input: HeadersInit = {}): Headers {
  const headers = new Headers(input);
  headers.delete("authorization");
  headers.delete("cookie");
  headers.delete("proxy-authorization");
  headers.set("authorization", `Bearer ${token}`);
  return headers;
}

यह sketch caller द्वारा दिया गया Authorization या Cookie header injected credential के साथ जाने से रोकता है। यह cookie jar, redirects, proxy dispatch या certificate configuration लागू नहीं करता। यह कमी जानबूझकर है: इनमें से हर एक को accidental default की जगह सोच-समझकर फैसला चाहिए।

यदि हर credential एक ही anonymous public endpoint से बात करता है, तो अलग pools अनावश्यक हो सकते हैं। यदि endpoint अलग accounts देखता है, तो अलग pool entries इस्तेमाल करें, जब तक साझा करने का कोई खास कारण और सबूत न हो। Account mixup की तुलना में pool सस्ता है।

Rotation का अपना नियम होना चाहिए। Credential record बदलने पर नई actions को उसके पुराने pool में देना बंद करें। अगर आपकी action semantics अनुमति देती हैं तो पहले से भेजी requests को उनके मूल record के तहत पूरी होने दें, फिर वह pool बंद कर दें। In-flight retry को replacement record की ओर न मोड़ें। Rotation authority बदलती है, पहले से शुरू हुए काम का अर्थ ठीक नहीं करती।

एक लोकप्रिय सलाह है कि हर जगह keep-alive बंद कर दें। इससे shared transport objects की संख्या घटती है, इसलिए incident के बाद यह सुरक्षित लगता है। लेकिन इससे cookies, redirect code और challenge caches सही scope में हैं या नहीं, यह छिप जाता है और हर request पर नया handshake load बनता है। Pooling रखें, उसका ownership स्पष्ट करें और कठिन paths का परीक्षण करें।

Redirects साफ request को गलत जगह भेज सकते हैं

Redirect handling पहले client के भीतर छिपा दूसरा client है। Library को 301, 302, 303, 307 या 308 response मिलता है, वह दूसरी request बनाती है और तय करती है कि कौन से headers बचेंगे। अगर यह निर्णय आपकी credential boundary code के बाद होता है, तो account header या cookie अनचाहे destination तक जा सकता है।

Injected credentials वाली actions के लिए redirects को शुरू में बंद या manual रखें। किसी redirect को follow करने से पहले target origin जांचें। Redirect तभी स्वीकारें जब action definition उसे अपेक्षित मानती हो, destination उसके approved origin set में हो, और client पुराने header bag को copy करने की जगह मूल credential context से headers फिर बनाए।

Status code महत्वपूर्ण है। सामान्य browser behavior में 303 request को GET में बदल सकता है, जबकि 307 और 308 method और body बनाए रखते हैं। सभी को एक जैसा मानने वाला retrying client credentialed write को दूसरे endpoint पर दोहरा सकता है। Secret किसी origin के बाहर न जाने पर भी यह action integrity की समस्या है।

हर cross-origin redirect पर Authorization और Cookie headers हटाएं। कई clients में यह पहले से default है, लेकिन default परीक्षण का परिणाम नहीं होता। अपनी version और configuration की पुष्टि करें। Same-origin redirects में भी path allowlist चाहिए, जब credential मूल endpoint से अधिक authority दे सकता हो।

Proxy authentication को भी इसी तरह संभालना चाहिए। Proxy-Authorization चुने गए proxy path का है, origin service का नहीं। उसे कभी generic default-header map में न रखें। यदि दो actions अलग authenticated proxies के जरिए उसी API तक पहुंचती हैं, तो उनकी pool entries अलग रखें और action record में proxy selection स्पष्ट दिखाएं।

असफल isolation test का एक पहचाने जाने वाला रूप होता है

अधिकतर टीमें जांचती हैं कि alpha API को call कर सकता है और beta API को call कर सकता है। इससे साबित होता है कि credentials काम करते हैं। इससे यह साबित नहीं होता कि वही long-lived client alpha से beta पर बिना सामान साथ लाए बदल सकता है।

दो accounts वाला छोटा test server बनाएं और उसे बताने दें कि उसे क्या मिला। उसे Authorization से निकला account लौटाना चाहिए, आने वाला Cookie header echo करना चाहिए, account-specific cookie set करनी चाहिए और redirect endpoint देना चाहिए। Cookie का account label bearer account label से अलग हो तो service को request अस्वीकार करनी चाहिए। यह rejection गलती को स्पष्ट करता है, affinity layer को उसे छिपाने नहीं देता।

Production में इस्तेमाल होने वाली ठीक उसी client configuration के साथ यह sequence चलाएं:

1. Fresh pool से alpha request भेजें। पुष्टि करें कि response route=alpha set करता है।
2. Production वाले pool lookup से beta request भेजें। Assert करें कि server beta authorization और खाली Cookie header देखता है, जब तक beta के पास अलग jar न हो जिसमें केवल beta cookies हों।
3. HTTP/2 पर alpha और beta requests साथ शुरू करें। हर endpoint को reply से पहले रुकवाएं ताकि उनकी streams overlap हों, फिर identities और cookies को अलग-अलग assert करें।
4. हर account को 401 challenge लौटाएं और पुष्टि करें कि retry अपने मूल credential record का इस्तेमाल करती है।
5. दूसरे origin पर redirect लौटाएं और पुष्टि करें कि follow-up request में authorization या cookie header नहीं है।

Assertions को status codes से अधिक दर्ज करना चाहिए। Selected credential record ID, pool ID, origin, protocol version, redirect target, Cookie की मौजूदगी और response account capture करें। Credential को log न करें। Test fail हो तो ये fields बताते हैं कि leak pool lookup, ambient headers, jar या retry middleware से आया था।

Credential rotation भी जांचें। Server पर प्रतीक्षा करती request शुरू करें, credential record बदलें, फिर नई request भेजें। नई action को नई pool identity इस्तेमाल करनी चाहिए। तय करें और दस्तावेज करें कि प्रतीक्षा करती action अपने मूल authority से पूरी होती है या cancel होती है। दोनों उचित हो सकते हैं, लेकिन बीच में चुपचाप authority बदलना उचित नहीं।

जिस भी proxy configuration को आप support करते हैं, उसके जरिए test चलाएं। Proxy state और origin state अक्सर library की अलग layers में रहती हैं, इसलिए यहां आश्वस्त करने वाला unit test उपयोगी integration test बनता है।

Agent actions को कम authority surface चाहिए

Autonomous coding agent को "इस approved API को credential record billing-read से call करो" जैसी action मांगनी चाहिए। उसे token लेकर ऐसा व्यापक, long-lived client नहीं बनाना चाहिए जो task बदलने के बाद भी session state रख सके। Action executor bytes भेजने से पहले approved destination, method, credential record और client boundary bind कर सकता है।

Sallyport इसी अलगाव का पालन करता है: API और SSH credentials अपने encrypted vault में रखता है और खुद action करता है, इसलिए agent को credential के बजाय result मिलता है। यह containment तभी उपयोगी है जब HTTP path भी हर credential record को अपने authority context की तरह मानता हो।

Approval, client isolation की जगह नहीं लेता। Operator वैध beta action मंजूर कर सकता है, जबकि लापरवाह shared cookie jar उसे mixed alpha और beta request बना दे। Approval record फिर ऐसी action दर्ज करता है जो operator की अनुमति वाली request से अलग है। Boundary को approval screen के नीचे रखें, जहां headers, retries और transport selection वास्तव में होते हैं।

Action gateway के लिए audit event में credential record ID और pool identity दर्ज करें, secret कभी नहीं। कोई caller account discrepancy बताए तो आपको पता लगाना होगा कि executor ने सही credential चुना या नहीं और उसने केवल उसी record की state लगाई या नहीं। Tamper-evident activity trail इस जांच में मदद करता है, लेकिन ambiguous client design को सुरक्षित नहीं बनाता।

पहला व्यावहारिक बदलाव सरल है: हर shared HTTP client खोजें और लिखें कि खुला connection छोड़कर वह क्या याद रखता है। अगर जवाब में cookies, challenge responses, redirects, client certificates या proxy identity हों, तो अगली token rotation या concurrent agent run के bug को महंगा बनाने से पहले हर item का स्पष्ट owner तय करें।