AI Agents के लिए HTTP Authentication: सुरक्षित Credential Patterns

AI agent को HTTP action का अनुरोध करने में सक्षम होना चाहिए, लेकिन जिस credential से वह action संभव होता है, वह agent के पास कभी नहीं होना चाहिए। यह नियम इस बात से अधिक महत्वपूर्ण है कि request bearer token, Basic authentication या vendor header का उपयोग करती है। अगर secret agent के context में पहुँच गया, तो वह prompt, tool trace, generated shell command, repository file या किसी ऐसे बाद के summary के माध्यम से लीक हो सकता है जिसे सुरक्षित रखने का किसी ने इरादा नहीं किया था।

HTTP authentication patterns फिर भी महत्वपूर्ण हैं, क्योंकि हर pattern यह प्रभावित करता है कि क्या चोरी हो सकता है, क्या दोबारा इस्तेमाल किया जा सकता है, क्या गलती से आगे भेजा जा सकता है और क्या audit किया जा सकता है। सही design API की आवश्यक scheme से शुरू होता है। इसके बाद credential को एक trusted executor तक सीमित रखें, जो agent की ओर से केवल narrowly defined request भेजे।

Agents सामान्य credentials को copied data में बदल देते हैं

Unattended agent किसी सामान्य API credential का risk बदल देता है, क्योंकि वह बहुत से रूपों में मौजूद text पढ़ता और लिखता है। Developer token को local credential store में रखकर एक request में paste कर सकता है। Agent environment variables देख सकता है, debug output लिख सकता है, curl command बना सकता है, configuration files बना सकता है और अपने काम की report किसी human को भेज सकता है। इन सभी operations से reusable secret के लिए एक नई जगह बनती है।

खतरनाक रास्ता अक्सर शुरुआत में harmless दिखता है:

1. Task runner agent process के environment में PAYMENTS_TOKEN रख देता है।
2. Agent ऐसी diagnostic command चलाता है जो environment print करती है या shell script लिखती है।
3. Script repository, CI artifact, terminal scrollback या किसी दूसरे agent tool call तक पहुँच जाती है।
4. बाद में किसी को token मिल जाता है और वह उसके expire होने या operator द्वारा revoke किए जाने तक valid requests भेजता रहता है।

Token को किसी sophisticated attacker की ज़रूरत नहीं थी। उसे केवल ऐसी जगह text बनना था जिसे text copy करने के लिए बनाया गया है।

Agent के access control को credentials की confidentiality न समझें। Sandbox agent को किसी directory के बाहर files खोलने से रोक सकता है। लेकिन अगर secret पहले ही model context, command arguments या tool result में दिखाई दे चुका है, तो sandbox मदद नहीं करेगा। इसी तरह, «क्या agent को curl चलाने की अनुमति है?» पूछने वाला approval prompt बहुत कम उपयोगी है, अगर agent कोई भी host, path, body और inherited authorization header दे सकता है।

इसीलिए AI agents के लिए HTTP authentication में दो अलग boundaries चाहिए। Agent को request propose करने की अनुमति चाहिए। Trusted component के पास credential की custody और request भेजने का अधिकार होना चाहिए। इन boundaries को मिला देने पर agent को आसानी से copy होने वाला secret मिल जाता है और बाद के controls इस धारणा पर निर्भर हो जाते हैं कि agent उसे पूरी तरह सही ढंग से संभालेगा। यह उचित design assumption नहीं है।

एक सरल test है: सोचें कि क्या आप credential revoke किए बिना पूरा agent transcript issue tracker में paste कर सकते हैं। अगर जवाब नहीं है, तो secret गलत boundary पार कर चुका है।

Bearer tokens भेजना आसान और replay करना आसान होता है

Bearer token access उस व्यक्ति को देता है जो उसे प्रस्तुत करता है। इसलिए agent को bearer token कभी न दें, जब तक आप यह स्वीकार न करते हों कि transcript leak API access leak बन सकता है। RFC 6750 Authorization request header में bearer token के उपयोग को परिभाषित करता है:

GET /v1/projects/alpha/releases HTTP/1.1
Host: api.example.test
Authorization: Bearer eyJhbGciOi...
Accept: application/json

Server को यह साबित करने की ज़रूरत नहीं होती कि sender intended agent, original user या original machine है। वह केवल यह जाँचता है कि प्रस्तुत token valid और authorized है या नहीं। यह property HTTP clients को सरल रखती है, लेकिन copied token को उसके पास मौजूद हर व्यक्ति के लिए उपयोगी भी बना देती है।

RFC 6750 कुछ सीमित परिस्थितियों में form body में bearer token भेजने की अनुमति देता है और legacy cases के लिए URI query use का वर्णन करता है। उन्हें query string में न रखें। URLs browser history, proxy logs, analytics systems, referrer headers, support tickets और application logs तक अपेक्षा से कहीं अधिक आसानी से पहुँचते हैं। Standard खुद चेतावनी देता है कि URI transport में disclosure की संभावना अधिक है। Agent का secret URL का हिस्सा बनाने का कोई अच्छा कारण नहीं है।

Bearer tokens agents के लिए तभी उपयुक्त हैं जब आसपास का credential design नुकसान को सीमित करे। ऐसे tokens को प्राथमिकता दें जिनका intended API audience हो, permissions सीमित हों, expiration छोटी हो और action runner की अलग identity हो। ऐसा API token जो हर project को administer कर सके, हर customer record पढ़ सके और कभी expire न हो, production master credential ही है, चाहे उसका नाम कुछ भी हो।

Agent को bearer token देने का सामान्य तर्क speed है: एक environment variable, एक HTTP client और कोई अतिरिक्त component नहीं। Demo में यह इसलिए लोकप्रिय है क्योंकि काम करता है। लेकिन debugging, delegation, long-running work या एक से अधिक service की ज़रूरत आने पर यह design विफल होने लगता है। Context में copy किया गया token selective तरीके से revoke करना कठिन बना देता है, क्योंकि आपको पता नहीं रहता कि वह किन-किन जगहों तक गया है।

एक और trap है: सीमित नाम वाला token भी प्रभावी रूप से बहुत व्यापक authority रख सकता है। Actual scope model के लिए provider documentation पढ़ें। कुछ services endpoint-specific scopes का उपयोग करती हैं। कुछ organization, project, repository या account level पर rights देती हैं। कुछ API tokens उन्हें बनाने वाले user के पूरे privileges चुपचाप inherit कर लेते हैं। Token label उसकी सीमाओं का प्रमाण नहीं है।

Mediator bearer token अपने पास रख सकता है और requested destination validate करने के बाद ही header बना सकता है। Agent को literal Authorization header के बजाय intent और request data भेजना चाहिए, जैसे «इस body के साथ project alpha में release बनाएँ»। Executor validation के बाद secret जोड़ता है और agent को कोई record लौटाने से पहले उसे हटा देता है।

Basic authentication के लिए अलग service identity चाहिए

TLS के ऊपर narrow service account के लिए Basic authentication स्वीकार्य हो सकता है, लेकिन agent को human username और password देने का यह खराब तरीका है। RFC 7617 wire format को user-id:password के base64 encoding के रूप में परिभाषित करता है, जिसे Authorization header में रखा जाता है:

Authorization: Basic YWdlbnQtcmVsZWFzZXI6czNjcjN0LXZhbHVl

जिसे भी यह value पढ़ने का अवसर मिले, वह इसे decode कर सकता है। Base64 केवल representation बदलता है, value को protect नहीं करता। TLS client और server के बीच connection को सुरक्षित करता है, लेकिन agent, local process, debug log या proxy द्वारा header copy किए जाने के बाद credential को protect नहीं करता।

कई API providers Basic authentication में API token को password की तरह और fixed या ignored username के साथ इस्तेमाल करते हैं। इससे scheme bearer authentication का कमजोर रूप नहीं बनती। इसमें लगभग वही replay exposure रहता है, साथ में कुछ practical risks भी जुड़ जाते हैं। Client या logger decoded username, raw header या दोनों record कर सकता है। Developer real account password दोबारा इस्तेमाल कर सकता है, क्योंकि protocol दूसरे field को password कहता है। यही वह credential है जिसे autonomous process को delegate नहीं करना चाहिए।

जब Basic authentication unavoidable हो, executor के लिए dedicated account बनाएँ। उसे केवल आवश्यक request family की permissions दें। Personal account, administrator account या unrelated automations के बीच साझा credentials का इस्तेमाल न करें। Service identity से किसी व्यक्ति को lock out किए बिना या हर job को एक साथ तोड़े बिना revocation और investigation संभव होती है।

Character encoding को सोच-समझकर संभालें। RFC 7617 username और password के character set से जुड़ी compatibility समस्या का वर्णन करता है और servers को UTF-8 advertise करने की अनुमति देता है। अगर provider केवल सामान्य ASCII values support करता है, तो machine credentials को उसी set तक सीमित रखें। Agent prompt में अपनी encoding step न बनाएँ, क्योंकि इससे secret को transform और log करने वाली एक और असंगत जगह बन जाएगी।

Request executor को protected fields से Basic header खुद बनाना चाहिए। Agent approved operation चुन सकता है और non-secret parameters दे सकता है। उसे base64 value नहीं बनानी चाहिए और error message में decoded credential कभी नहीं दिखना चाहिए। सुरक्षित error यह कहता है कि selected credential reference के लिए authentication विफल हुई। वह header echo नहीं करता और agent को यह नहीं बताता कि password का कौन सा हिस्सा match हुआ।

Custom headers में vendor semantics बिल्कुल सही रखें

Custom authentication header उतना ही सुरक्षित है जितने API के documented verification rules और value को संभालने की आपकी प्रक्रिया। सामान्य उदाहरणों में X-API-Key, Api-Key या provider-specific header आते हैं। कुछ providers static API key चाहते हैं। कुछ timestamp, nonce, canonical path और body digest वाले signed request की अपेक्षा करते हैं। सभी custom headers को interchangeable मानने से authentication टूट सकती है और credential अनजाने में अधिक जगह भेजा जा सकता है।

पहले provider specification का ठीक-ठीक पालन करें। HTTP में header names case-insensitive होते हैं, लेकिन header values और signature inputs ऐसा नहीं भी हो सकते। Signature scheme में canonicalization order, exact body bytes और सीमित timestamp window आवश्यक हो सकते हैं। अगर executor JSON parse करके sign करने से पहले उसे फिर serialize करता है, तो दिखने में valid लेकिन अलग byte sequence बन सकती है। Provider request reject करेगा और लोग अक्सर signature checks बंद करके या broad retry logic जोड़कर प्रतिक्रिया देते हैं। Byte handling ठीक करें।

दूसरे, authentication के लिए उपयोग होने वाले header और client की पहचान बताने वाले header में अंतर करें। User-Agent, request IDs और application identifiers provider को traffic समझने में मदद कर सकते हैं, लेकिन आम तौर पर authority साबित नहीं करते। इसके उलट X-API-Key भी Authorization: Bearer जितना replayable हो सकता है। उसकी sensitivity का अनुमान केवल इस आधार पर न लगाएँ कि नाम में authorization शब्द है या नहीं।

तीसरे, agent को headers की smuggling से रोकें। अगर protected executor credentials inject करता है, तो agent को outbound headers का free-form map न दें। ऐसा map उसे दूसरा Authorization header जोड़ने, expected content type बदलने, unapproved identity header लगाने या downstream proxy को प्रभावित करने की अनुमति दे सकता है, जिसे reviewer ने देखा ही नहीं।

Named और typed fields वाला request contract इस्तेमाल करें। उदाहरण के लिए:

{
  "credential_ref": "release-service",
  "method": "POST",
  "url": "https://api.example.test/v1/projects/alpha/releases",
  "headers": {
    "accept": "application/json"
  },
  "body": {
    "version": "2025.06.0",
    "notes": "Fix parser crash on empty input"
  }
}

credential_ref को vendor के custom header या signing procedure से map करने का काम agent नहीं, executor करे। उसे authorization, cookie, provider के credential header, host या इनके duplicate forms देने की कोशिश reject करनी चाहिए। Content-Length का नियंत्रण भी उसी के पास होना चाहिए, क्योंकि HTTP client को इसे final bytes से calculate करना होता है।

Agent को दिखाया जाने वाला response भी इसी अनुशासन का पालन करे। HTTP response में Set-Cookie, diagnostics या echoed request details हो सकते हैं। Task के लिए आवश्यक status, चुने हुए safe response headers और body ही लौटाएँ। Raw headers और traces operators के लिए आवश्यक हों तो उन्हें protected audit storage में रखें।

Provider की scheme चुनें, फिर blast radius सीमित करें

Third-party API के लिए authentication scheme आप शायद ही चुनते हैं। Provider पहले ही उसे चुन चुका होता है। आप यह तय कर सकते हैं कि credential व्यापक होगा या सीमित, कहाँ रहेगा, किन requests में इस्तेमाल होगा और agent के असामान्य व्यवहार पर क्या होगा।

Boundary design करते समय यह तुलना उपयोगी है:

Signed requests के बारे में एक महत्वपूर्ण बात है। Timestamp और nonce API boundary पर सीधे replay को कम कर सकते हैं, लेकिन signing secret को agent context के लिए सुरक्षित नहीं बनाते। जिस agent को secret मिल सकता है, वह fresh malicious request sign कर सकता है। अगर signing implementation agent से मनमाना method, host, path और body स्वीकार करती है, तो वह उन actions को भी faithfully sign कर देगी जिन्हें आपने authorize करने का इरादा नहीं किया था।

Scope को action के अनुरूप रखें, किसी काल्पनिक future use के अनुरूप नहीं। Release publishing agent को एक project में release बनाने की permission चाहिए हो सकती है। उसे projects delete करने, billing बदलने, हर artifact पढ़ने या users invite करने की permission नहीं चाहिए। अगर provider उचित रूप से सीमित credential जारी नहीं कर सकता, तो provider API के सामने अपने नियंत्रण में narrower service रखें या dangerous calls के लिए human approval बनाए रखें।

खराब scopes को natural language की लंबी allowlist से हल न करें। «Token का उपयोग केवल releases के लिए करें» सलाह है, enforcement point नहीं। Restriction वहीं रखें जहाँ request assemble होती है: expected origin, allowed method, path pattern, header set, body schema और maximum response size। ये constraints credential को उसके intended job के बाहर कम उपयोगी बनाते हैं।

Mediation secrets को agent context से बाहर रखती है

Mediated HTTP calls तब काम करती हैं जब secret holder request execute करता है, न कि secret agent को देकर उससे execute करवाया जाता है। दोनों designs में tool का नाम http_request हो सकता है, इसलिए अंतर आसानी से छिप जाता है। आपने कौन सा design बनाया है, यह data flow से पता चलता है।

Unsafe design में tool token प्राप्त करके agent को दे देता है, शायद environment variable, placeholder expansion या «temporary» credential के रूप में। Agent की अगली action request भेजती है। Token पहले ही ऐसी system में जा चुका है जिसे text पर reasoning, transformation और repetition के लिए बनाया गया है।

Mediated design में agent executor को structured request भेजता है। Executor request को permitted shape से मिलाता है, protected storage से selected credential प्राप्त करता है, सही authentication material inject करता है, request भेजता है, action record करता है और bounded result लौटाता है। Agent को secret value, उसका encoded form या उसे रखने वाली shell command कभी नहीं मिलती।

यह अंतर incident response भी बदल देता है। अगर आपको लगता है कि agent session गलत व्यवहार कर रहा है, तो आप हर credential को तुरंत rotate किए बिना उसके actions request करने की क्षमता रोक सकते हैं। अगर credential खुद बाहर निकल गया हो, तो उसे फिर भी rotate करें। Session revocation और credential rotation अलग समस्याएँ हल करते हैं। Teams का समय तब नष्ट होता है जब वे इन्हें एक ही button समझ लेते हैं।

एक practical executor को default रूप से कई request forms reject करनी चाहिए:

• Unapproved origin की ओर जाने वाले absolute URLs, जिनमें lookalike subdomains भी शामिल हैं।
• Agent द्वारा दिए गए Authorization, Cookie, proxy या credential-specific headers।
• ऐसे redirects जो authenticated request को किसी दूसरे origin तक ले जा सकते हैं।
• Credential के intended use से बाहर के methods, खासकर destructive methods।
• Expected size से बड़े या endpoint के expected format से मेल न खाने वाले bodies।

Sallyport macOS पर इसी custody model को अपनाता है: उसका encrypted vault API और SSH credentials रखता है, जबकि MCP agent credential values प्राप्त करने के बजाय app से HTTP calls करने का अनुरोध करता है।

Mediation को general-purpose policy engine न समझें। यह तय नहीं कर सकती कि «stale test resources delete करें» किसी खास production account में सही है या नहीं। यह सुनिश्चित कर सकती है कि request defined technical boundary में रहे और credential agent context से बाहर रहे। Human review, scoped accounts और application-specific safeguards ही तय करते हैं कि action को approval मिलना चाहिए या नहीं।

Request boundary में redirects, DNS और responses भी शामिल होने चाहिए

केवल https://api.example.test approve करना बहुत व्यापक है, क्योंकि credentialed request में hostname से अधिक चीजें होती हैं। Executor को agent द्वारा effective destination या request के अर्थ को बदलने वाली हर जगह नियंत्रित करनी चाहिए।

Exact origin से शुरू करें: scheme, hostname और port। सामान्य internet API credentials के लिए HTTPS अनिवार्य करें। RFC 9110 HTTP request target और authority rules परिभाषित करता है, लेकिन application code को अपने destination rules फिर भी enforce करने होंगे। केवल suffix के आधार पर hosts approve न करें। «hostname ends with example.test» जैसी जाँच notexample.test को स्वीकार कर सकती है। Loose substring check इससे भी खराब है। Parsed hostnames की तुलना exact allowlist या जानबूझकर बनाए गए subdomain rule से करें।

फिर methods और paths सीमित करें। अगर agent को releases बनानी हैं, तो आवश्यक precise POST path family ही allow करें। Cleanup में उपयोगी हो सकता है, इसलिए DELETE न जोड़ें। यह तय किए बिना arbitrary versioned paths allow न करें कि बाद का API version अलग behavior तो नहीं लाता। Path normalization भी महत्वपूर्ण है। तुलना से पहले URL parse करें और यदि matching code उन्हें predictable ढंग से handle नहीं करता, तो surprising encodings, dot segments या duplicate separators reject करें।

Redirect behavior को स्पष्ट रूप से तय करें। HTTP libraries अलग-अलग व्यवहार करती हैं और library upgrade defaults बदल सकता है। Credentialed calls के लिए सबसे सुरक्षित default redirects reject करना और location agent को report करना है। अगर provider को सचमुच redirect चाहिए, तो केवल specific expected target origin allow करें और उसी restrictions के तहत request फिर से बनाएँ। यह मानकर न चलें कि कोई client credentials को consistently strip कर देगा और open redirect harmless रहेगा।

DNS दूसरा destination check बनाता है। Trusted hostname बदलते addresses पर resolve हो सकता है और internal systems के names sensitive networks की ओर point कर सकते हैं। अगर executor developer laptop पर चलता है, तो arbitrary outbound HTTP local administration services या cloud metadata endpoints तक रास्ता बन सकता है। Connection से पहले approved origins सीमित करें, agent-controlled proxy settings स्वीकार न करें और agent को network interface या resolver चुनने न दें।

अंत में response को cap और filter करें। Release creation सफल हुई, यह जानने के लिए agent को multi-megabyte download की ज़रूरत नहीं है। बड़े bodies context waste करते हैं और किसी untrusted service से copied instructions agent की reasoning में ला सकते हैं। जहाँ संभव हो, अगली action के लिए आवश्यक fields ही लौटाएँ। Tool contract में remote text को data के रूप में चिह्नित करें और response content को executor के authorization rules बदलने न दें।

Approval में calling process और concrete action का नाम होना चाहिए

Human approval click तभी उपयोगी है जब वह decision लेने के लिए पर्याप्त जानकारी दे। «Allow agent access to API» एक blanket permission है जिसे prompt का रूप दिया गया है। इससे approval fatigue बढ़ती है, क्योंकि व्यक्ति नहीं जान पाता कि किस local process ने request की, कौन सा credential इस्तेमाल होगा या क्या भेजा जाएगा।

Calling process की पहचान ऐसे करें कि operator उसे पहचान सके। macOS पर code-signing authority अक्सर mutable process name से अधिक उपयोगी होती है। agent नाम की process legitimate developer tool भी हो सकती है और उसी नाम का unrelated binary भी। Process lineage, executable path और signing information बेहतर evidence देते हैं, लेकिन इनमें से कोई भी bounded action request का विकल्प नहीं है।

Session approval और request approval अलग tradeoffs हल करते हैं। Session approval known agent run के लिए repeated interruptions कम करती है। यह low-risk, repetitive operations में ठीक है, जब credential और request boundary narrow रहें। Request approval irreversible या sensitive operations के लिए उपयुक्त है, जैसे externally publish करना, access settings बदलना या ऐसा data लिखना जिससे कोई दूसरा system trigger हो।

ऐसा approval design न बनाएँ जिसमें हर call के लिए human को dense raw HTTP dump पढ़ना पड़े। तीसरी interruption के बाद लोग पढ़े बिना approve कर देंगे। Concise action summary दिखाएँ: service identity, method, destination, path, meaningful body fields और API द्वारा documented side effect। Investigation के लिए raw request details audit record में रखें।

Session शुरू करने की permission और उसे जीवित रखने की permission में भी अंतर करें। अगर agent process exit हो जाए, तो replacement process को केवल same name के कारण approval inherit नहीं करना चाहिए। User session revoke करे तो executor को तुरंत उसकी calls स्वीकार करना बंद करना होगा। UI में «revoked» दिखे लेकिन already-authorized client requests भेजता रहे, तो यह revocation feature न होने से भी खराब है, क्योंकि false confidence पैदा होता है।

Audit records को agent के exit होने के बाद भी पूरी कहानी बतानी चाहिए

एक उपयोगी audit trail से operator यह जान सके कि call किसने request की, executor ने कौन सा credential reference इस्तेमाल किया, request कहाँ गई, executor ने क्या allow किया और remote service ने क्या लौटाया। इन सवालों के जवाब के लिए raw secret record करने की ज़रूरत नहीं है। वास्तव में ऐसा करना observability के रूप में दूसरा secret store बना देगा।

हर call के लिए session या process identity, timestamp, selected credential reference, HTTP method, approved origin, path, relevant request data का protected representation, response status और allow या deny करने वाला decision रखें। किसी permitted redirect के बाद actual final destination भी दर्ज करें। Failures भी record करें। असामान्य path पर बार-बार denied attempts broken agent instruction या boundary escape की कोशिश दिखा सकते हैं।

Tamper evidence यह बदलता है कि record पर कितना भरोसा किया जा सकता है। Hash-chained log हर entry को पिछली entries से जोड़ता है, इसलिए बाद में modification या deletion verification के दौरान पकड़ी जा सकती है। यह साबित नहीं करता कि original executor ने wise authorization choice की थी और compromised host को trustworthy नहीं बनाता। लेकिन history को चुपचाप बदलना कठिन बनाता है, और incident review में यही गुण चाहिए।

Audit record को agent के ordinary working context से अलग रखें। Agent को 201 Created, release id r-4821 जैसा summary मिल सकता है। Operator को path और decision metadata वाला अधिक विस्तृत record चाहिए हो सकता है। Logging मौजूद है, इसलिए किसी भी पक्ष को raw authorization header न दें।

Sallyport में Sessions और Activity journals encrypted hash-chained audit log से project होते हैं, और sp audit verify vault unlock किए बिना offline उस chain को verify कर सकता है। Review के लिए यह sensible design है, क्योंकि verification के लिए calls authorize करने वाले credentials उजागर नहीं करने पड़ते।

Production access देने से पहले failure paths test करें

जो credential boundary केवल happy path पर सफल होती है, उसने production access का अधिकार अर्जित नहीं किया है। छोटा test API या non-production account इस्तेमाल करें और executor से साबित कराएँ कि वह उन परिस्थितियों को रोकता है जिनसे credentials leak या misuse हो सकते हैं।

ऐसा test sequence इस्तेमाल करें:

1. Approved GET endpoint request करें और जाँचें कि agent को expected body मिले, लेकिन credential-bearing header न मिले।
2. Agent की ओर से Authorization header दें और जाँचें कि executor उसे silently merge या replace करने के बजाय reject करे।
3. URL को unapproved host और deceptive near-match में बदलें। पुष्टि करें कि दोनों network request से पहले fail हों।
4. Test API से cross-origin 302 response लौटाएँ और जाँचें कि executor authentication forward करने के बजाय रुक जाए।
5. Run के दौरान agent session revoke करें और पुष्टि करें कि बाद की calls fail हों, जबकि audit verification सफल रहे।

Run के बाद process environments, temporary directories, shell history, generated files, crash reports और test logs inspect करें। Known test credential string खोजें। यह exercise wrapper scripts और debug modes में होने वाले कई leaks पकड़ती है जिन्हें request-level tests कभी नहीं देख पाते।

Provider errors भी test करें। API ऐसा body लौटा सकती है जिसमें invalid header content echo हो, trace identifier हो या किसी दूसरे endpoint के साथ retry करने की सलाह हो। Confirm करें कि result filter credential-जैसा material agent को वापस न दे और retry logic एक denied request को attempts की बाढ़ में न बदल दे। Retry केवल उन errors तक सीमित रखें जिनके लिए API documentation retry को उचित बताती है, और method तथा destination को unchanged रखें।

पहला production credential इतना narrow होना चाहिए कि test विफल होने पर परेशानी हो, catastrophe नहीं। अगर आपकी team ठीक-ठीक नहीं बता सकती कि कौन से request shapes authorize हैं और active agent run को कैसे revoke करना है, तो credential autonomous use के लिए अभी भी बहुत व्यापक है।