Production rollout से पहले Agent API access testing

Agent को production API access तब मिलना चाहिए जब वह denied, malformed, slow या dangerous request के समय सही व्यवहार करे। Sandbox में एक सफल response दे देना पर्याप्त नहीं है। Friendly demo उन failures को छिपा देता है जो वास्तव में मायने रखते हैं: गलत process के लिए दी गई approval, agent transcript में कॉपी किया गया token, rate limit पर लगातार दबाव डालता retry loop, या ऐसा journal जो यह नहीं बता सकता कि destructive call को किसने मंज़ूरी दी।

Production capability देने से पहले पूरी action path को nonproduction destination के खिलाफ टेस्ट करें। इसमें agent का request, authorization, credential injection, remote API response, failure की agent द्वारा समझ और हर call का ऐसा record शामिल है जो session के बाद भी बना रहे। इनमें से एक हिस्सा भी गायब हो, तो आपने API client को टेस्ट किया है, autonomous actor को नहीं।

Nonproduction endpoint उन तरीकों से अलग होना चाहिए जिनसे गलती का नुकसान हो सकता है

एक उपयोगी test endpoint के पास अलग credentials, अलग data और ऐसी damage boundary होनी चाहिए जिसे आप एक वाक्य में समझा सकें। Production hostname को ऐसे query parameter के साथ कॉल करना, जो कथित रूप से test mode चुनता है, पर्याप्त नहीं है, अगर वही token customer records पढ़ सकता है या पैसे खर्च कर सकता है।

जब vendor sandbox अलग account और test credentials देता हो, तो उसका इस्तेमाल करें। अगर service में sandbox नहीं है, तो dedicated tenant लें। और अगर इनमें से कुछ भी उपलब्ध नहीं है, तो किसी अलग hostname के पीछे अपने नियंत्रण में छोटी service चलाएं और उसे disposable data से जोड़ें। मुद्दा staging जैसे label का नहीं है। मुद्दा यह है कि गलती से भेजा गया request production users, production balances या production secrets को प्रभावित न कर सके।

Endpoint से साबित करवाएं कि वह nonproduction है। हर सफल response में environment field साफ़ तौर पर लौटाएं और destructive routes को केवल test ledger में लिखने दें। इस तरह का response किसी operator को green test को production change समझने से रोकता है:

{
  "environment": "test",
  "request_id": "req_7f1a",
  "status": "accepted",
  "resource_id": "demo-order-184"
}

Test data इतना वास्तविक रखें कि pagination, missing fields, permissions और conflicts की जांच हो सके। एक perfect record agent को गलत आदतें सिखाता है। कुछ ऐसे records तैयार करें जिन्हें वह पढ़ सके, एक ऐसा जिसे वह update कर सके और एक ऐसा जिसे उसे कभी access नहीं करना चाहिए। बहुत बड़ा fixture set जरूरी नहीं है। इतना variation काफी है कि वह code पकड़ में आ सके जो मानता है कि हर response साफ़ और पूरा होगा।

सुविधा के लिए production bearer token को test environment में दोबारा इस्तेमाल न करें। मैंने टीमों को इसे temporary shortcut कहते देखा है, फिर हर अगला काम ज्यादा जरूरी लगने के कारण वह token वहीं पड़ा रह जाता है। Test identity का नाम, owner, expiry date और खास test cases से मेल खाती permissions होनी चाहिए। अगर कोई यह नहीं बता सकता कि किसी permission की जरूरत किस test को है, तो उसे हटा दें।

पहला run API को नहीं, authorization boundary को टेस्ट करे

Business behavior validate करने से पहले साबित करें कि अनपहचाना agent process चुपचाप काम नहीं कर सकता। नया agent process शुरू करें और उससे test endpoint पर एक harmless read करने को कहें। अपेक्षित परिणाम यह है कि API request भेजे जाने से पहले authorization event हो।

इससे एक ऐसा फर्क सामने आता है जिसे टीमें अक्सर मिला देती हैं: user approval, process approval नहीं है। Operator अपने terminal पर भरोसा कर सकता है, लेकिन plugin, copied script या किसी दूसरी application द्वारा शुरू किए गए agent पर नहीं। Approval surface पर यह स्पष्ट होना चाहिए कि कौन-सी executable authority काम करने की मांग कर रही है। केवल Allow लिखा बटन लोगों से एक अनजान process को मंज़ूरी देने को कहता है।

इस test में चार observations दर्ज करें:

• नया process external call से पहले approval request पाता है।
• Approval में process की ऐसी पहचान होती है जिसे operator पहचान सके।
• Approval केवल इच्छित run तक रहती है, हर future process के लिए नहीं।
• Process समाप्त करने पर session authorization हट जाती है।

Approve करने से पहले एक बार request reject करें। Rejection के बाद agent को usable failure signal मिलना चाहिए, गढ़ी हुई success नहीं। अच्छे agent instructions बताते हैं कि refusal के बाद क्या करना है: operation रोकना, बताना कि approval deny हुई और उसी endpoint तक पहुंचने का दूसरा रास्ता न खोजना।

फिर agent restart करें और harmless read दोहराएं। अगर दूसरा process पहले process की permission ले लेता है, तो कारण पता करें। Cached authorization demo में efficient लगती है, लेकिन update के बाद agent restart होने पर या किसी दूसरे launcher द्वारा वही command चलाए जाने पर यह चुपचाप permission grant बन सकती है।

Sallyport में session approval default रूप से चालू रहती है और नए agent process की पहली call पर process की code-signing authority दिखाती है। Human judgment टेस्ट करने के लिए यही सही समय है, credential वाला request बाहरी service तक पहुंचने से पहले।

Credential injection में साबित होना चाहिए कि agent ने secret कभी अपने पास नहीं रखा

Credential injection तभी सफल माना जाएगा जब agent action मांग सके, लेकिन उस action में इस्तेमाल credential वापस न निकाल सके। Console output में token को mask करना protection नहीं है। जो token environment variable, tool response, prompt, shell history या local file में agent तक पहुंच गया, वह agent के लिए उपलब्ध था, भले ही किसी ने उसे print न किया हो।

ऐसा test credential तैयार करें जिसे remote service उसकी value दिखाए बिना पहचान सके। कई APIs token label, client identifier या audit field देती हैं। अगर आपकी API ऐसा नहीं करती, तो test route बनाएं जो उसे दिखी credential identity लौटाए, credential खुद नहीं। परिणाम से यह साबित होना चाहिए कि call ने किस test identity से authentication किया।

Bearer-token API के लिए wire-level request आमतौर पर ऐसी होती है:

GET /v1/test/projects/demo HTTP/1.1
Host: api.test.example
Authorization: Bearer [injected outside the agent]
Accept: application/json

कोष्ठक में लिखा पाठ documentation है, agent के भरने के लिए value नहीं। Agent को method, destination और अनुमत request arguments देने चाहिए। Approval decision के बाद credential handler authorization header जोड़ता है। Basic authentication और custom header schemes पर भी यही test करें, क्योंकि configuration गलत होने पर वे अलग-अलग जगह fail होते हैं।

Agent transcript, tool request history, agent को दिखने वाला shell environment और run के दौरान बनाई गई files की जांच करें। Literal token material के साथ-साथ ऐसे indirect leaks भी खोजें, जैसे authorization header वाला request object। बाद में redaction करना उस design को ठीक नहीं करता जिसमें secret process को दे दिया गया था।

फिर test credential rotate करके वही request चलाएं। सफल दूसरा run साबित करता है कि action path agent configuration में embedded stale value के बजाय current stored credential पढ़ता है। Failed run भी उपयोगी हो सकता है, अगर error authentication failure बताए और rejected secret को print न करे।

ऐसे token से test न करें जो scenario से ज्यादा काम कर सकता हो। Read-only credentials injection साबित करने के लिए पर्याप्त हैं। Mutation tests के लिए बाद में सीमित और reversible write permission जोड़ें। Test की समीक्षा करने वाले व्यक्ति को यह तय करने के लिए raw token तक access की जरूरत नहीं होनी चाहिए कि test पास हुआ या नहीं।

Approval friction call से होने वाले नुकसान के अनुसार होनी चाहिए

Session approval और हर इस्तेमाल की approval अलग समस्याएं हल करती हैं। Session approval यह तय करती है कि कोई खास agent run bounded capability इस्तेमाल कर सकता है। हर इस्तेमाल की approval sensitive credential से की गई हर request की human review कराती है। इन्हें एक-दूसरे का विकल्प मानने पर या तो बेकार prompt storm बनता है या महंगी गलतियों का unattended रास्ता खुल जाता है।

Session boundary टेस्ट करने के लिए low-risk credential इस्तेमाल करें। Create, delete, transfer, publish या access बदल सकने वाले credential पर per-use approval लगाएं। Agent से उस credential के साथ दो अलग test calls कराएं। आपको दो decisions दिखने चाहिए और दूसरी request को पहली के लिए मिली approval का लाभ नहीं मिलना चाहिए।

Test में rejection भी शामिल होना चाहिए। पहले test action को approve करें और दूसरे को reject। Agent report और action record में इन बातों की पुष्टि करें:

1. पहली action test service तक पहुंची और उसने अपना request identifier लौटाया।
2. Rejected action test service तक कभी नहीं पहुंची।
3. Agent ने यह दावा नहीं किया कि उसने बदलाव कर दिया।
4. Rejected credential की जरूरत न रखने वाले operations के लिए session usable रहा।

चौथा बिंदु एक गंभीर failure mode पकड़ता है। कुछ integrations sensitive request decline होने पर आगे के हर operation को बंद कर देती हैं। दूसरी integrations refusal को अनदेखा करके तब तक retry करती हैं जब तक कोई व्यक्ति गलती से approve न कर दे। दोनों व्यवहार human control को जरूरत से ज्यादा कठिन बनाते हैं।

Approval fatigue design failure है, लेकिन approval हटाना आमतौर पर इसका सही इलाज नहीं है। Short-lived session में काम समेटकर, sensitive calls की संख्या घटाकर या agent को safer bulk operation देकर इसे कम करें। Prompts की अधिकता का समाधान यह नहीं है कि ऐसे process को broad permanent token दे दिया जाए जिसकी योजना task के बीच बदल सकती है।

HTTP status codes को agent का व्यवहार तय करना चाहिए

Agent को failure classes के लिए स्पष्ट व्यवहार चाहिए, क्योंकि HTTP success और task success एक ही बात नहीं हैं। RFC 9110 HTTP response status codes का अर्थ बताता है। इसमें 401 का मतलब missing या invalid authentication credentials और 403 का मतलब है कि server ने request समझी, लेकिन उसे पूरा करने से इनकार किया। इन responses को अलग तरीके से संभालें। आम तौर पर दोनों को उसी request के साथ दोबारा भेजने से progress नहीं होती, केवल noise बढ़ती है।

Rollout से पहले failure table बनाएं और test endpoint के खिलाफ हर row को चलाएं। Required actions इतने स्पष्ट और सीमित रखें कि reviewer समझ सके कि agent ने उनका पालन किया या नहीं।

400 response पर जितना ध्यान मिलना चाहिए, अक्सर उससे कम मिलता है। यह agent के tool schema और remote API के वास्तविक contract के बीच mismatch दिखा सकता है। Test server से field-level validation errors लौटाएं, फिर देखें कि agent गलत argument report करता है या कोई replacement value गढ़ता है। Fields का अनुमान लगाने वाला agent harmless validation error को गलत account के खिलाफ request में बदल सकता है।

Transport failure को HTTP 503 से अलग टेस्ट करें। Test service disconnect करें या controlled test request को unreachable address पर भेजें। Agent को no response और server response में फर्क करना चाहिए। यह फर्क तब महत्वपूर्ण है जब operation service तक पहुंच चुका हो लेकिन response खो गया हो। Ambiguous timeout के बाद create operation retry करने से duplicates बन सकते हैं।

जहां API support करे, idempotency identifiers इस्तेमाल करें। अगर ऐसा support नहीं है, तो potentially mutating call दोहराने से पहले agent से existing result पढ़वाएं। Retry three times कहना recovery plan नहीं है, जब हर retry card charge कर सकती हो, user बना सकती हो या message भेज सकती हो।

असफल rollout अक्सर harmless retry loop से शुरू होता है

एक आम failure तब शुरू होता है जब agent से test resource create करके उसे verify करने को कहा जाता है। Create request service पर सफल हो जाती है, लेकिन network interruption response छिपा देती है। Agent error देखता है, create call दोबारा भेजता है और दूसरी successful result पाता है। फिर वह guessed name से एक resource fetch करके success report कर देता है। Operator के पास duplicate changes होते हैं और यह स्पष्ट record नहीं होता कि कौन-सी request ने कौन-सा बदलाव किया।

इसे production risk के बिना दोहराया जा सकता है। Test route से create request स्वीकार करवाएं, test object store करवाएं और response लौटाने से पहले connection जानबूझकर बंद कर दें। Agent को fixed request identifier के साथ चलाएं। सुरक्षित व्यवहार यह है कि create दोहराने से पहले agent उस identifier के लिए test service से query करे। अगर वह ऐसा नहीं कर सकता, तो उसे रुककर ambiguous outcome report करना चाहिए।

एक minimal test service contract जांच को स्पष्ट बना सकता है:

POST /v1/test/jobs
{
  "request_id": "rollout-042",
  "name": "reconcile-demo"
}

GET /v1/test/jobs?request_id=rollout-042
{
  "items": [
    {"id": "job_128", "request_id": "rollout-042", "state": "queued"}
  ]
}

यहीं ऐसे prompts भी सामने आते हैं जो agent से कहते हैं कि काम होने तक कोशिश करते रहो। किसी human operator को देखते हुए यह instruction समझदारी भरी लग सकती है। लेकिन ऐसा actor जिसे कोई notice करे उससे पहले calls करने की क्षमता हो, उसके लिए यह unsafe है। इसकी जगह bounded retry rule, duplicate check और human review जरूरी करने वाली condition रखें।

OWASP का API Security Top 10 unrestricted resource consumption और broken object level authorization को रेखांकित करता है। Agent rollout में दोनों सामान्य behavior mistakes के रूप में दिखते हैं: limit को अनदेखा करता loop और requested object identifier fail होने पर पास के किसी दूसरे identifier को आजमाता agent। आपके test में forbidden object और rate-limited route दोनों होने चाहिए, क्योंकि happy-path fixture इनमें से किसी आदत को सामने नहीं लाएगा।

Records में decision और external effect दोनों स्पष्ट होने चाहिए

Call record से कोई व्यक्ति agent की पूरी private reasoning दोबारा बनाए बिना समझ सके कि क्या हुआ। Authority और effect साबित करने वाले facts रखें: किस session ने काम किया, किस process ने request की, कौन-सा destination और method इस्तेमाल हुआ, कौन-सा credential reference लागू था, किसी व्यक्ति ने approval दी या नहीं, समय क्या था और क्या result मिला।

हर record में raw request bodies डालने की आदत न बनाएं। कुछ payloads में customer data, third-party tokens या वह content हो सकता है जिसे agent को process करने के लिए दिया गया था। जरूरत पूरी हो तो safe summary या चुने हुए fields store करें। Remote service का request identifier खास तौर पर उपयोगी है, क्योंकि इससे local record को service के अपने audit trail से जोड़ा जा सकता है।

Run record और call record अलग रखें। Run record बताता है कि किसी agent process को काम करने की अनुमति थी या नहीं और क्या किसी व्यक्ति ने बाद में उसे revoke किया। Call record हर external action में क्या हुआ, यह बताता है। दोनों को chat transcript में मिला देने पर वह structure खो जाता है जिसकी जरूरत एक run में कई requests होने पर पड़ती है।

Sallyport session और activity journals को एक encrypted, hash-chained audit log से project करता है। उसका sp audit verify command ciphertext पर vault key के बिना offline chain जांच सकता है। इससे record integrity को secrets तक access से अलग टेस्ट करना व्यावहारिक हो जाता है।

सामान्य test के बाद verification चलाएं। फिर encrypted audit file को test location पर कॉपी करें और copy के bytes बदलें। Altered copy पर command को failure report करना चाहिए, जबकि original verify होनी चाहिए। यह केवल disposable copy के साथ करें। इस अभ्यास से review team production investigation के दौरान जरूरत पड़ने से पहले valid report पहचानना सीखती है।

Tamper evidence का मतलब यह नहीं है कि हर operator हर detail पढ़ सकता है, और यह remote API logs की जगह भी नहीं लेता। इसका सीमित उद्देश्य है: क्या local records का sequence intact रहा? Test endpoint के request IDs और timestamps रखें, ताकि investigator दोनों ओर की तुलना कर सके।

Revocation को अगली call रोकनी चाहिए, केवल window बंद नहीं करनी चाहिए

Agent के चलने के दौरान revocation टेस्ट करें। Session approve करें, एक harmless request भेजें, session revoke करें और उसी process से दूसरी harmless request कराएं। दूसरी request nonproduction endpoint तक पहुंचने से पहले fail होनी चाहिए। अगर existing connection या cached credential बच जाने के कारण वह सफल हो जाती है, तो यह production blocker है।

फिर vault gate को अलग से टेस्ट करें। Credential store lock करें और request दोबारा आजमाएं। Locked vault को हर action deny करना चाहिए, इसमें वह request भी शामिल है जिसे operator ने session के लिए पहले approve किया था। यह एक run revoke करने से मजबूत control है, क्योंकि vault पर निर्भर सभी action paths रुक जाते हैं।

दोनों tests के दौरान endpoint पर नजर रखें। Agent का access denied वाला message proof न मानें। Server-side request log में दिखना चाहिए कि दूसरी request पहुंची ही नहीं। यह सरल cross-check उन integrations को पकड़ता है जो HTTP request dispatch करने के बाद approval failure report करती हैं।

अगर आपका agent HTTP calls के साथ SSH work भी कर सकता है, तो disposable host के खिलाफ यही test दोहराएं। Nonprivileged account और स्पष्ट परिणाम देने वाली command इस्तेमाल करें, जैसे temporary directory में file बनाना। Revocation को fresh SSH command भी रोकनी चाहिए, जैसे वह API request रोकती है। अगर gateway दोनों channels को अलग तरह से संभालता है, तो एक blind spot बनता है जिसमें operator समझता है कि control अभी भी मौजूद है।

Promotion के लिए demo का confidence नहीं, evidence packet चाहिए

Production में तभी जाएं जब reviewer compact test record देखकर बता सके कि agent अपनी intended authority के भीतर रहा या नहीं। Packet में test identity और permissions, endpoint boundary, अपेक्षित approval behavior, representative success और failure results, record verification result और observed revocation result शामिल होने चाहिए।

हर test permission को agent के साथ production में promote न करें। अलग से production credential बनाएं और पहले real task के लिए जरूरी operations के सबसे छोटे set से शुरुआत करें। ऐसा operator तय करें जो runs approve या revoke कर सके और लिखें कि किन response states पर agent को रुकना होगा। अगर team उस व्यक्ति का नाम नहीं बता सकती, तो उसने operational control chance को सौंप दिया है।

पहला production task approvals enabled के साथ चलाएं और तुरंत बाद उसके records की जांच करें। Actual request count, destinations और outcomes की तुलना test run से करें। अगर agent किसी unplanned endpoint से संपर्क करता है, broader credential मांगता है या production data के साथ अलग तरह से retry करता है, तो rollout रोकें और उस behavior को वापस nonproduction endpoint पर लाएं।

सही पहला production rollout जानबूझकर boring होता है। Agent कुछ अपेक्षित calls करता है, कोई व्यक्ति उसे रोक सकता है, credential agent context में कभी नहीं आता और हर external effect का ऐसा record होता है जो service के अपने request ID से मेल खाता है। सावधानी से आगे बढ़ने के लिए इतना proof काफी है। Polished demo नहीं।