Agent sessions में shared API account attribution कैसे काम करता है

साझा API account रखना कभी-कभी सही संचालन विकल्प होता है। Vendor एक organization token जारी कर सकता है, rate limits उसी account से जुड़ी हो सकती हैं, और उसकी जगह लगभग एक जैसी कई keys रखना नियंत्रण बेहतर किए बिना secrets की संख्या बढ़ा सकता है।

गलती तब होती है जब इस account को actor समझ लिया जाता है। यह external credential principal है, यानी वह identity जिसे vendor पहचानता है। जब कई स्थानीय agents इसका इस्तेमाल करते हैं, तो आपको दूसरा रिकॉर्ड चाहिए जो बताए कि हर अनुरोध किस स्थानीय process ने किया, उसे कौन सा काम करने की अनुमति थी और उस process को credential इस्तेमाल करने का अधिकार कैसे मिला। अगर यह रिकॉर्ड execution के समय नहीं लिया गया, तो बाद में आप केवल अनुमान लगा पाएंगे।

हर agent को नाम और रंगीन dashboard देना आकर्षक लग सकता है, लेकिन यह उससे कम महत्वपूर्ण है। असली कसौटी तब आती है जब दो agents एक साथ काम करें, एक retry करे, कोई इंसान बीच में run रद्द कर दे और vendor के audit page पर केवल automation-service दिखाई दे।

Vendor account और actor अलग identities हैं

Shared vendor account इस सवाल का जवाब देता है, «Provider ने कौन सा credential स्वीकार किया?» Actor attribution पूछता है, «इस खास operation को किस स्थानीय principal ने शुरू किया?» ये जवाब अक्सर अलग होते हैं। उन्हें एक ही field में भरने से खराब audit trail बनता है।

कम से कम इन चार identities को अलग रखें:

• External account: vendor tenant, service user, OAuth client या API key identity, जो remote API को दिखाई देती है।
• Execution session: शुरू किया गया एक agent process, जिसे नया, अनुमान लगाना कठिन session ID मिले।
• Initiating principal: वह व्यक्ति, CI job या parent service जिसने session शुरू किया।
• Work reference: issue, change request, deployment, repository या स्पष्ट task, जो बताता है कि कॉल क्यों की गई।

External account महीनों तक स्थिर रह सकता है। Execution session ऐसा नहीं होना चाहिए। एक task reference कई sessions में दोहराया जा सकता है। Initiator एक दिन keyboard पर बैठा व्यक्ति हो सकता है और अगले दिन automated build। हर field की अवधि अलग है और उसके पीछे अलग सवाल है।

यह केवल शब्दों का फर्क नहीं है। मान लें vendor-prod किसी remote deployment को delete करता है। Provider सच कह सकता है कि deletion vendor-prod ने की। आपके स्थानीय रिकॉर्ड में दिखना चाहिए कि s_7f3... session Maya द्वारा शुरू किए गए release agent से आया था या नहीं, उसे इस run की approval मिली थी या नहीं और deletion सीधी call थी या timeout के बाद retry। केवल actor=vendor-prod field रखने से incident response के लिए ज़रूरी सभी तथ्य छिप जाते हैं।

RFC 8693 OAuth delegation में इससे जुड़ा फर्क बताता है। यह उस subject को अलग रखता है जिसकी ओर से authority मौजूद है और उस मौजूदा actor को भी, जो JWT के act claim का इस्तेमाल करता है। इसमें यह भी कहा गया है कि resource servers को access decision top-level token claims और current actor के आधार पर लेना चाहिए, पुराने nested actors के आधार पर नहीं। स्थानीय agent systems के लिए भी यह उपयोगी सीमा है: जांच के लिए lineage रखें, लेकिन authorization साफ़ current session identity से करें, पिछली calls की लंबी और अस्पष्ट कहानी से नहीं।

Vendor account को «agent» न कहें। इसका इस्तेमाल agents, scripts, emergency operators और migration jobs सभी कर सकते हैं। इसे external_principal जैसा स्पष्ट नाम दें और अपने audit record में local session को actor बनाएं।

Session identity launcher से आनी चाहिए

Agent शुरू करने वाला process agent के किसी बाहरी action का अनुरोध करने से पहले session identity बनाए। Agent को इसे चुनने न दें। जो agent session_id=release-approved चुन सकता है, वह बाद की समीक्षा को भ्रामक बना सकता है।

एक व्यावहारिक session record में executable की पहचान और काम का संदर्भ समझाने के लिए पर्याप्त जानकारी होनी चाहिए:

{
  "session_id": "ses_01JQ6EXAMPLE3K5A",
  "started_at": "2026-07-22T15:04:18Z",
  "initiator": {
    "kind": "human",
    "id": "[email protected]"
  },
  "agent": {
    "process_id": 48192,
    "binary_authority": "signed-local-agent",
    "launch_path": "/workspace/payments"
  },
  "work": {
    "kind": "change_request",
    "id": "CR-1842"
  },
  "parent_session_id": null
}

सटीक field names से ज्यादा महत्वपूर्ण यह है कि किस field का मालिक कौन है। Launcher session_id, start time, executable identity और parent session का मालिक है। Work reference इंसान या calling system दे सकता है, लेकिन gateway को यह भी दर्ज करना चाहिए कि उसे किसने दिया। Agent अपने task का वर्णन सुझा सकता है, पर वह text launcher से मिली identity की जगह नहीं ले सकता।

केवल process ID कमजोर प्रमाण है। Operating systems इन्हें दोबारा इस्तेमाल करते हैं, logs processes से ज्यादा समय तक रहते हैं और process ID यह कम बताता है कि binary किसने शुरू की। Local developer machine पर code signing authority अधिक उपयोगी है, क्योंकि यह approval decision को signed process family से जोड़ती है। फिर भी, उपलब्ध होने पर executable path और launch context दर्ज करें। परिचित signature यह साबित नहीं करती कि हर invocation का उद्देश्य एक ही था।

हर नए agent process के लिए नया session इस्तेमाल करें। Task number समान होने पर session दोबारा इस्तेमाल करना छोटे experiment की approval को लंबे समय तक चलने वाले permission bucket में बदल देता है। लंबे समय तक चलने वाले agents के लिए स्पष्ट policy तय करें: या तो एक session रखें और उसकी अवधि साफ़ दिखाएं, या नए pull request अथवा resumed terminal run जैसी तय सीमा पर session बदलें। दोनों तरीकों को चुपचाप एक साथ न अपनाएं।

Credential injection से पहले attribution दर्ज होनी चाहिए

Actor को request से जोड़ने की सबसे सुरक्षित जगह वह क्षण है जब trusted component shared credential लगाने और request भेजने से ठीक पहले होता है। इससे पहले की जानकारी agent बदल सकता है। इसके बाद की जानकारी vendor के पास न हो, संक्षेप में बदल जाए या overwrite हो जाए।

ऐसा call envelope बनाएं जिसे agent पूरी तरह खुद न लिख सके। Agent requested action देता है। Gateway session identity, authorization decision, call ID और external credential reference जोड़ता है। Request भेजने से पहले envelope सुरक्षित करें और response आने पर outcome जोड़ें।

{
  "call_id": "call_01JQ6F9K4W7D",
  "session_id": "ses_01JQ6EXAMPLE3K5A",
  "external_principal": "vendor-prod",
  "channel": "http",
  "request": {
    "method": "POST",
    "host": "api.vendor.example",
    "path_template": "/v1/deployments/{id}",
    "operation": "create_deployment"
  },
  "authorization": {
    "vault_unlocked": true,
    "session_authorized": true,
    "per_call_approval": false
  },
  "work_id": "CR-1842",
  "attempt": 1,
  "created_at": "2026-07-22T15:08:34Z"
}

ध्यान दें कि इसमें क्या नहीं है: bearer token, पूरा request body और agent भरोसेमंद है, ऐसा कोई free-form दावा। Attribution साबित करने के लिए secrets store करने वाला log अपने पहले काम में ही असफल हो गया। Body का हर byte दर्ज करने से customer data, source code या regulated records भी उजागर हो सकते हैं। Normalized operation name, route template, चुने हुए nonsecret identifiers और जरूरत होने पर content digest रखें, जब payload की समीक्षा महत्वपूर्ण हो।

यह design intent और effect को भी अलग रखता है। Agent create_deployment का अनुरोध कर सकता है, लेकिन remote service validation error लौटा सकती है। Call journal में दोनों तथ्य होने चाहिए। बाद में आप बता सकेंगे कि agent ने action करने की कोशिश की थी, बिना यह दावा किए कि action सफल हुआ।

Sallyport यही व्यवस्था अपनाता है: agent अपने MCP shim के माध्यम से connect करता है, जबकि app secret अपने पास रखकर HTTP या SSH action चलाता है। इस तरह session और activity records स्थानीय run को shared credential के इस्तेमाल से जोड़ सकते हैं, बिना credential को agent context में रखे।

Agent द्वारा भेजे गए headers प्रमाण हैं, सबूत नहीं

Teams अक्सर X-Agent-Name, X-Task-ID या X-Run-ID जैसे headers जोड़कर मान लेती हैं कि समस्या हल हो गई। ये fields remote logs को जोड़ने में मदद कर सकते हैं, लेकिन request नियंत्रित करने वाला agent इन्हें छोड़, बदल या दोबारा चला भी सकता है। ये labels हैं, authority boundary नहीं।

अगर vendor इन्हें स्वीकार करता है, तो attribution headers आगे भेजे जा सकते हैं। Gateway को तीन नियम मानने होंगे। पहला, reserved headers के agent द्वारा भेजे गए versions हटाएं। दूसरा, final values recorded session और call envelope से बनाएं। तीसरा, vendor ने header प्राप्त किया है, इसे अतिरिक्त प्रमाण मानें, source of truth नहीं।

उदाहरण के लिए, gateway के भीतर यह छोटा header set reserve करें:

X-Execution-Session: ses_01JQ6EXAMPLE3K5A
X-Action-Call: call_01JQ6F9K4W7D
X-Work-Reference: CR-1842

केवल सुविधा के लिए header में email address, prompt, customer data वाला branch name या raw command न डालें। Headers proxies, tracing systems, error reports और vendor support tooling से होकर गुजरते हैं। Opaque IDs इस्तेमाल करें और उन्हें protected local journal से resolve करें।

कुछ providers unknown headers reject करते हैं, उन्हें हटा देते हैं या audit views में दिखाते ही नहीं। यह सामान्य है। Remote API को आपका identity system बनने की जरूरत नहीं। आपका gateway तब भी काम करना चाहिए जब provider केवल अपना सामान्य authorization scheme स्वीकार करे।

एक और जाल है: signed header local logging का विकल्प नहीं है। Request signature यह साबित कर सकती है कि gateway ने कोई request sign की, लेकिन human approval, process identity, task context या result तब तक सुरक्षित नहीं रहते जब तक आप उन्हें स्थानीय रूप से दर्ज न करें। Signatures transport claims की रक्षा करती हैं। वे अपने आप investigation record नहीं बनातीं।

Retries के लिए एक timestamp नहीं, lineage चाहिए

Autonomous agents retry करते हैं। HTTP clients retry करते हैं। Disconnected terminal के बाद SSH commands फिर से चलाई जा सकती हैं। अगर audit trail हर intended action के लिए केवल एक line लिखता है, तो duplicate changes पैदा करने वाली प्रक्रिया छिप जाती है। अगर वह केवल raw requests लिखता है, तो एक intended action कई असंबंधित decisions जैसा दिखता है।

दोनों स्तरों को model करें। Intended operation को operation_id दें और हर network attempt को अलग call_id दें। Retries को पिछली attempt से जोड़ें और retry का कारण दर्ज करें।

{
  "operation_id": "op_01JQ6F8P0Z",
  "call_id": "call_01JQ6F9K4W7D",
  "attempt": 2,
  "retries_call_id": "call_01JQ6F79S2M1",
  "retry_reason": "connection_closed_before_response",
  "idempotency_key": "idem_94c2e1",
  "vendor_request_id": "req_8d71"
}

retry_reason महत्वपूर्ण है। 429 response का मतलब है कि vendor ने पहली request प्राप्त की और rate limiting के कारण उसे अस्वीकार किया। Gateway से bytes निकल जाने के बाद आया timeout यह नहीं बताता कि vendor ने action पूरा किया या नहीं। इन स्थितियों में अलग operational response चाहिए, इसलिए दोनों को केवल failed में न मिलाएं।

जब vendor समर्थन करता हो, तो remote state बनाने या बदलने वाली operations के लिए idempotency keys इस्तेमाल करें। Key trusted gateway में बनाएं या launcher से work record के साथ दिलवाएं। Model को अपनी योजना बदलने पर हर बार नई key बनाने न दें, वरना replay की गई operation पहचानना मुश्किल हो जाएगा।

एक आम failure इस तरह दिखता है। Session A deployment बनाने को कहता है, connection टूट जाता है और उसका client retry करता है। कुछ पल बाद Session B उसी task reference के साथ शुरू होता है, उसे कोई deployment दिखाई नहीं देता और वह फिर अनुरोध करता है। Vendor के पास अब दो deployments हैं। उपयोगी journal में दो sessions, दो intended operations, उनकी अलग attempts और साझा idempotency key दिखाई देगी। कमजोर journal में एक service account के अंतर्गत POST /deployments की चार lines होंगी और टीम को बाकी जानकारी timestamps से जोड़नी पड़ेगी।

Approval को friendly name से नहीं, process से जोड़ें

«क्या release agent को production इस्तेमाल करने दें?» जैसा prompt तब तक ठीक लगता है, जब तक दो release agents न हों, जिनमें से एक trusted repository से और दूसरा copied directory से शुरू हुआ हो। नाम केवल presentation text है। Approval को execution session और उसे बनाने वाली process authority से जोड़ना चाहिए।

कई संबंधित calls करने वाले agents के लिए per-session approval अच्छा default है। Operator देख सकता है कि अनुरोध कौन कर रहा है और छोटे task के दौरान एक जैसे prompts बार-बार नहीं आते। Process समाप्त होते ही approval भी समाप्त होनी चाहिए। नया process, भले ही उसका task text वही हो, फिर से approval मांगे।

High-consequence या असामान्य रूप से व्यापक scope वाली operations के लिए per-call approval इस्तेमाल करें। यह session approval का विकल्प नहीं है। इसका सवाल अधिक सीमित है: क्या इस credential का यह खास इस्तेमाल अभी आगे बढ़ना चाहिए? हर harmless read के लिए per-call approval लेने वाली टीम लोगों को बिना पढ़े approve करना सिखा देगी। यह design की गई approval fatigue है, इंसान की गलती नहीं।

Decision को stable reference वाले event के रूप में दर्ज करें:

{
  "approval_id": "apr_01JQ6G3C",
  "session_id": "ses_01JQ6EXAMPLE3K5A",
  "scope": "session",
  "decision": "approved",
  "decided_at": "2026-07-22T15:06:11Z",
  "process_authority": "signed-local-agent"
}

हर call पर केवल bare boolean लिखकर यह न मानें कि consent साबित हो गया। Boolean बताता है कि approval मौजूद थी। Approval event बताता है कि वह कब हुई, किस scope पर लागू थी और किस session को authorize किया गया। बाद में operator session revoke करे, तो revocation को नए event के रूप में सुरक्षित रखें। पुरानी approval मिटाने से record साफ़ दिख सकता है, लेकिन incident समझना कठिन हो जाता है।

Vendor audit logs को आपके record की पुष्टि करनी चाहिए

Vendor logs उपयोगी हैं, लेकिन आम तौर पर वे आपकी identity model के बजाय vendor की identity model बताते हैं। Shared token service user, OAuth application, token hash, installation या IP address के रूप में दिखाई दे सकता है। इससे बाहरी call होने की पुष्टि हो सकती है, लेकिन आम तौर पर यह नहीं पता चलता कि किस स्थानीय agent session ने action चुना।

GitHub का documentation इस फर्क का स्पष्ट उदाहरण है। GitHub App user to server token से की गई calls में audit actor के रूप में user दिख सकता है और programmatic access type उस token form के रूप में दिखाई दे सकता है। GitHub enterprise audit events कई event types के लिए actor, token information, request ID और user agent जैसे fields भी दिखाते हैं। यह provider-side evidence उपयोगी है, लेकिन इन fields का अर्थ GitHub के authorization model से आता है, आपके local agent session model से नहीं।

जहां संभव हो, stable correlators से remote और local records जोड़ें:

• Response header या body में मिले vendor request ID को सुरक्षित रखें।
• अपना outbound call ID और normalized operation name सुरक्षित रखें।
• Response status, completion time और सुरक्षित resource identifiers दर्ज करें।
• Call में इस्तेमाल external principal को सुरक्षित रखें।
• Local session ID को authoritative execution identity बनाए रखें।

मुख्य रूप से समय के आधार पर records न जोड़ें। Clock skew, asynchronous vendor processing, retries और queues close timestamp को दिखने से कमजोर बना देते हैं। Timestamps search को सीमित करने में उपयोगी हैं, लेकिन request ID या idempotency key मौजूद हो तो attribution का फैसला केवल timestamps से न करें।

कुछ vendors short-lived delegated tokens, user की ओर से OAuth tokens या app installation tokens जारी कर सकते हैं। जब ये provider को meaningful actor visibility दें और आपके privilege model में फिट हों, तो इनका इस्तेमाल करें। उदाहरण के लिए, GitHub app के user की ओर से काम करने और अन्य programmatic access types के बीच फर्क बताता है। यह shared static token से बेहतर provider-side attribution है, लेकिन इससे call शुरू करने वाले स्थानीय process की पहचान की जरूरत खत्म नहीं होती।

Credentials तभी अलग करें जब उनसे वास्तविक boundary मिले

आम सलाह है, «हर agent को अपनी API key दें।» यह लोकप्रिय है क्योंकि समझाना आसान है और vendor audit screen अधिक व्यवस्थित दिखती है। लेकिन यह हमेशा सही control नहीं होता।

Separate credentials की operational cost तब उचित है जब वे meaningful boundary बनाएं। यह read-only discovery agent और deployment agent के लिए अलग scopes, independent vendor revocation, अलग billing या provider audit record में distinct principal हो सकता है। अगर हर key का broad scope, rotation owner और local execution path एक ही है, तो आपने attribution बेहतर करने से ज्यादा secret inventory बढ़ाई है।

नई vendor identity बनाने से पहले यह test करें:

1. क्या नई credential को shared credential से कम privilege दिया जा सकता है?
2. क्या unrelated work में बाधा डाले बिना इसे revoke किया जा सकता है?
3. क्या provider इसे अलग actor के रूप में दर्ज करेगा, जिसका उपयोग responders कर सकें?
4. क्या local tooling में भूली हुई copies छोड़े बिना इसे rotate और retire किया जा सकता है?
5. क्या इससे कोई महत्वपूर्ण authorization decision local gateway से हटता है?

अगर इनमें से अधिकांश सवालों का जवाब नहीं है, तो shared external account रखें और local actor record बेहतर बनाएं। इससे responders को वही जानकारी मिलेगी जिसकी उन्हें जरूरत है: किस agent session ने call की, किसके शुरू करने पर, किस work item के लिए, किस approval के साथ और किस result के साथ।

इस तर्क की सीमा भी है। अगर कोई credential production administration की अनुमति देता है और experimental agent को वह शक्ति नहीं चाहिए, तो केवल अच्छे logs होने के कारण उसे साझा न करें। Attribution बाद में action को समझाता है। Scope यह तय करता है कि action हो भी सकता है या नहीं।

Tamper-evident journal को क्रम और denial दोनों सुरक्षित रखने चाहिए

केवल सफल vendor calls रखने वाला audit record अधूरी कहानी है। Denied calls, locked vault attempts, rejected approvals और revoked sessions अक्सर बताते हैं कि incident और गंभीर क्यों नहीं हुआ। वे यह भी दिखा सकते हैं कि authority खोने के बाद भी agent action मांगता रहा।

Session शुरू होने, authorization decision होने, call तैयार होने, external action समाप्त होने और session revoke या exit होने पर event लिखें। हर line में बड़ा mutable object copy करने के बजाय IDs से records जोड़ें। Chain को sequence स्पष्ट करना चाहिए, ताकि हर consumer को prose से state दोबारा बनाने की जरूरत न पड़े।

Tamper evidence महत्वपूर्ण है क्योंकि shared vendor account इस्तेमाल करने वाले concurrent agents के बीच फर्क बताने वाला एकमात्र source अक्सर local attribution होता है। अगर local access वाला व्यक्ति incident के बाद call record बदल सकता है, तो team ने वही trust problem एक layer नीचे दोहरा दी। Hash-chained logs reviewers को बदलाव पहचानने में मदद करते हैं, लेकिन वे यह तय नहीं करते कि कौन से fields record करने हैं। इसके लिए complete event model फिर भी चाहिए।

Sallyport अपने Sessions और Activity journals को एक encrypted, hash-chained audit log से बनाता है और sp audit verify से उस chain की offline पुष्टि कर सकता है। Operational point command का नाम नहीं है। महत्वपूर्ण यह है कि session approval, individual action और बाद की revocation को उसी क्रमबद्ध record के आधार पर जांचा जा सके।

जब incident reviewer पूछे कि कुछ किसने किया, तो vendor account label को अंतिम जवाब न मानें। Record को external principal से call ID तक, call ID से execution session तक, session से initiator और approval तक, फिर response से vendor के अपने request identifier तक follow करें। इनमें से कोई भी link न हो, तो अगली shared credential रहस्य बनने से पहले उस capture point को ठीक करें।