Agent identity बनाम credential identity: actors को छिपाना बंद करें

Production credential रखने वाला AI agent एक साथ identity की दो समस्याएं पैदा करता है। Agent account की तरह काम कर सकता है, और बाद में team को यह मानने का दिखावा करना पड़ता है कि account का नाम बताता है कि action किसने किया। ऐसा नहीं है। deploy-bot के रूप में authenticated API request यह बताती है कि किसी के पास deploy-bot का credential था। यह नहीं बताती कि caller मंज़ूर किया गया coding agent था, copy की गई shell script, कोई malicious dependency या test के बाद चलती रह गई process।

Teams को उस process की पहचान अलग से करनी होगी जिसने action का अनुरोध किया, और उस account की पहचान भी रखनी होगी जिसे उसे करने की अनुमति थी। यह केवल audit log को बेहतर दिखाने का मामला नहीं है। इससे तय होता है कि आप किसी specific agent run को मंज़ूर कर सकते हैं या नहीं, बाकी काम को बाधित किए बिना उसे रोक सकते हैं या नहीं, खराब deployment की जाँच कर सकते हैं या नहीं और leaked credential को अनुमान लगाए बिना contain कर सकते हैं या नहीं।

Credential authority की पहचान करता है, caller की नहीं

Credential उस authority की पहचान करता है जिसे service देने वाली है, जबकि agent identity उस process की पहचान करती है जिसने उस authority का अनुरोध किया। दोनों को मिलाने पर बाद के हर security decision का दायरा बहुत मोटा हो जाता है।

मान लें कि cloud storage में कोई object delete करने की request आती है। Receiving API bearer token देख सकती है और उसे release-publisher नाम के service account से जोड़ सकती है। यह account authorization का सवाल हल करता है: क्या यह account object delete कर सकता है? लेकिन attribution का सवाल नहीं: token किस local process ने इस्तेमाल किया, उसे किसने शुरू किया, उसने कौन सा code चलाया और क्या किसी ने उस run को मंज़ूरी दी?

शांत समय में ये सवाल एक जैसे लग सकते हैं, क्योंकि अपेक्षित process और account का owner अक्सर एक ही होता है। दबाव में दोनों अलग हो जाते हैं। Developer token को local environment में copy करता है। Code agent उस environment को विरासत में लेता है। Agent द्वारा शुरू किया गया plugin उसे पढ़ लेता है। हर request अब भी release-publisher जैसी दिखती है। Authorization layer अपनी configuration के अनुसार ठीक काम करती है, लेकिन investigation actor खो देती है।

Credential identity आम तौर पर लंबे समय तक रहती है और उसका उद्देश्य व्यापक होता है। यह API token, SSH private credential, cloud service account या client certificate subject हो सकती है। Process identity को कहीं अधिक सीमित चीज़ बतानी चाहिए: यह executable, इस signer या image से, इस context में, इस run के दौरान शुरू हुआ।

इस अंतर का व्यावहारिक असर है:

• जब किसी एक agent run पर भरोसा न रहे, तो उसका process session revoke करें।
• जब secret बाहर निकलने की आशंका हो, तो credential disable या rotate करें।
• जब authority खुद बहुत व्यापक हो, तो account permissions बदलें।
• जब जानना हो कि वास्तव में क्या हुआ, तो process record की जाँच करें।

यदि एक ही field को ये चारों काम करने होंगे, तो वह कोई भी काम ठीक से नहीं करेगी। Credential का नाम agent-prod-42 रखने से समस्या हल नहीं होती। बेहतर label bearer token को bearer का प्रमाण नहीं बना देता।

एक agent request में चार identities होती हैं

Production action में सामान्यतः कम से कम चार identities होती हैं। Audit record को account name में समेटने के बजाय इन सभी को सुरक्षित रखना चाहिए।

पहली identity उस human या system owner की होती है जिसने काम शुरू किया। यह terminal पर काम कर रहा developer, CI job trigger या scheduled task हो सकता है। Ownership बताती है कि agent run का अनुरोध किसने किया और alerts किसे मिलने चाहिए।

दूसरी identity agent process की होती है। Local coding agent के लिए उपयोगी evidence में executable path, signing authority, process identifier, parent process, launch time और launch के समय दिया गया random session identifier शामिल हो सकते हैं। Container environment में इसके बराबर image digest, workload identity document, orchestrator workload name और pod या task instance हो सकते हैं। यह identity बताती है कि कौन सा running program action करने का अनुरोध कर रहा था।

तीसरी identity credential की होती है। यह service account, SSH principal, OAuth client या API token record हो सकता है जिसे destination स्वीकार करता है। यह बताता है कि destination किस चीज़ की अनुमति देगा।

चौथी identity target की होती है: request से प्रभावित hostname, repository, cloud project, database या API audience। Teams अक्सर generic endpoint log करती हैं और बाद में पता चलता है कि action ऐसे environment boundary को पार कर गया जिसे देने का उनका इरादा कभी नहीं था।

एक साफ record इस तरह दिख सकता है:

{
  "event": "http.request",
  "session_id": "ses_7zQ2...",
  "process": {
    "pid": 8421,
    "signing_authority": "Example Developer ID",
    "parent_pid": 8190,
    "launch": "interactive-terminal"
  },
  "credential_ref": "cred_release_publisher",
  "credential_subject": "release-publisher",
  "target": "api.example.internal",
  "operation": "POST /releases",
  "decision": "approved",
  "result": 201
}

credential_ref vault record की ओर संकेत करता है। यह secret नहीं है। Process block वह evidence देता है जो credential subject नहीं दे सकता। अब reviewer देख सकता है कि एक approved session ने एक target पर release-publisher का इस्तेमाल किया और बाद में उसी account का इस्तेमाल करने वाले किसी दूसरे process से उस run को अलग कर सकता है।

Human owner field को भी जरूरत से अधिक काम न दें। Documentation update करने के लिए agent से कहने वाला व्यक्ति अपने आप उस production deployment को मंज़ूरी देने वाला व्यक्ति नहीं बन जाता जिसे agent ने बाद में करने की कोशिश की। Initiation, process, credential और destination को अलग रखें। असुविधाजनक gaps दिखाई देने लगेंगे, और यही उद्देश्य है।

Bearer tokens सबसे ज़रूरी evidence मिटा देते हैं

Bearer token इसलिए स्वीकार किया जाता है क्योंकि caller के पास वह token है। इसलिए वह यह स्थापित नहीं कर सकता कि उसे कौन सा process प्रस्तुत कर रहा है। यह mechanism की विशेषता है, आपके API provider की logging कमी नहीं।

RFC 6750 bearer token के इस्तेमाल को सीधे परिभाषित करता है: token रखने वाला कोई भी पक्ष उसका इस्तेमाल कर सकता है। इसी portability ने bearer tokens को deploy करना आसान बनाया, लेकिन इसका अर्थ यह भी है कि कोई API approved agent और copied process में अंतर नहीं कर सकती, जब तक आप अलग control न जोड़ें। आम जवाब होता है, «हमने token को secret manager में रखा है।» इससे at-rest storage का सवाल हल होता है। Process को value मिलने के बाद क्या होता है, यह हल नहीं होता।

OAuth 2.0 Security Best Current Practice, RFC 9700, जहाँ उचित हो वहाँ sender-constrained access tokens, short lifetimes और audience restriction की सलाह देकर सही दिशा दिखाता है। Sender constraint token replay को कम कर सकता है, क्योंकि resource server intended client से proof जाँचता है। फिर भी उस process की पहचान ज़रूरी रहती है जो client proof को नियंत्रित करता है। यदि कोई agent process private proof material का इस्तेमाल कर सकता है, तो उस process को नियंत्रित करने वाला attacker अभी भी client की तरह काम कर सकता है।

यह अंतर AI agents के लिए खास तौर पर महत्वपूर्ण है, क्योंकि उनका operating environment असामान्य रूप से खुला होता है। वे repositories पढ़ते हैं, commands चलाते हैं, tools call करते हैं, environment variables देखते हैं और कभी-कभी files या issue comments में दिए निर्देशों पर काम करते हैं। Agent को दिया गया token किसी साफ trust boundary में नहीं रहता, केवल इसलिए कि team ने उसे एक tool call के लिए इस्तेमाल करने का इरादा किया था।

हर agent को एक dedicated long-lived token देने और समस्या हल मान लेने वाली लोकप्रिय सलाह से बचें। यह इसलिए लोकप्रिय है क्योंकि इससे साफ account names और आसान dashboards मिलते हैं। यह तब विफल होती है जब agent token पढ़ सकता है, कोई दूसरा process उसी environment को पढ़ सकता है या agent run समाप्त होने के बाद account बना रहता है। Dedicated credentials blast-radius accounting बेहतर बनाते हैं, लेकिन process provenance साबित नहीं करते।

आपको दो controls चाहिए: agent को reusable secret material मिलने से रोकना और हर action का अनुरोध करने वाले agent process का अलग record रखना। पहला चोरी की संभावना घटाता है। दूसरा approval, revocation और investigation को इतना specific बनाता है कि वे उपयोगी हो सकें।

Process identity को ऐसा evidence चाहिए जो prompt से न बदले

Process identity उन facts से आनी चाहिए जिन्हें operating system या execution environment report कर सकता है, न कि उस string से जिसे agent tool request में खुद भेजता है। Agent का name: trusted-release-agent घोषित करना claim है, identity evidence नहीं।

Managed Mac पर code signing authority एक उपयोगी शुरुआत देती है। Operating system supervising app को बता सकता है कि कौन सा signed executable शुरू हुआ और उसे किस authority ने sign किया। इसका अर्थ यह नहीं कि हर signed program approval का हकदार है। इसका अर्थ है कि approval screen ऐसा fact दिखा सकती है जिसे process द्वारा भेजे गए label की तुलना में forge करना कठिन है।

Server पर इसके बराबर evidence देखें। Runtime द्वारा जारी workload identity, verified image digest, mutually authenticated channel या process supervisor का attestation किसी action को workload instance से जोड़ सकता है। SPIFFE इस model को SPIFFE Verifiable Identity Document और X.509 SVIDs के साथ document करता है: workload अपने environment से identity प्राप्त करता है और फिर उसे दूसरे workload के सामने प्रस्तुत करता है। यह shared environment variable से मजबूत model है, क्योंकि identity workload तक सीमित होती है।

Static image digest को complete process identity न समझें। यह code content की पहचान करता है, लेकिन उपयोगी action decision के लिए running instance और launch context भी चाहिए। वही image intended production job, developer के experimental environment या attacker-controlled task में चल सकती है। Destination और session भी decision का हिस्सा हैं।

Local agent work के लिए session creation पर evidence capture करें और बाद के actions को उसी session से bind करें। Minimal session record में ये बातें हो सकती हैं:

session_id: ses_7zQ2...
executable: /Applications/Agent.app/Contents/MacOS/agent
signing_authority: Example Developer ID
parent_process: /Applications/Terminal.app
started_at: 2025-03-08T14:03:19Z
owner: [email protected]

Exact fields operating system के अनुसार बदलेंगे। Discipline नहीं बदलनी चाहिए: action authorize करने वाले component को process facts खुद collect करने चाहिए। Agent से यह अपेक्षा नहीं करनी चाहिए कि untrusted input मिलने के बाद वह अपना विवरण सही बताएगा।

Process identity की सीमाएँ भी हैं। Code signing यह साबित नहीं करती कि signed agent ने सुरक्षित निर्देशों का पालन किया। Image digest यह साबित नहीं करता कि उसका configuration सुरक्षित है। Identity बताती है कि आपने किस actor को मंज़ूरी दी और revocation के लिए handle देती है। यह अकेले किसी जोखिम भरे action को सुरक्षित नहीं बना सकती।

Approval को account name से नहीं, run से जोड़ें

Human approval को किसी specific process session के लिए सीमित अवधि तक action authorize करना चाहिए। बाद में account इस्तेमाल करने वाले किसी भी process को स्थायी रूप से मंज़ूरी नहीं देनी चाहिए। वरना approval छिपे हुए standing access grant में बदल जाता है।

Approval fatigue अक्सर approval की गलत unit से शुरू होती है। Teams या तो हर harmless request पर किसी व्यक्ति से approval मांगती हैं, जिससे वह बिना पढ़े click करना सीख जाता है, या service account को एक बार मंज़ूर करके फिर कोई meaningful prompt नहीं दिखातीं। दोनों ही विकल्प active process की पहचान नहीं करते।

Agent run शुरू होने पर session approval इस्तेमाल करें। वह process evidence दिखाएं जिसका operator मूल्यांकन कर सके: executable या workload name, signing authority या image digest, parent या launcher, intended channels और session identifier। Approval के बाद process के समाप्त होने या operator द्वारा उसे revoke करने तक उसी session के ज़रिए actions की अनुमति दें। नए process को नया session मांगना चाहिए, भले ही वह वही credential इस्तेमाल करने वाला हो।

ऐसे credentials के लिए per-action approval रखें जिनका प्रभाव interruption को उचित ठहराता है। Production database administrator credential, fleet hosts तक पहुँच रखने वाली SSH identity या public artifacts publish करने वाला account हर बार human decision मांग सकता है। सामान्य read access को इसकी जरूरत नहीं। Approval mechanism को यह अंतर स्पष्ट करना चाहिए, न कि उसे ऐसी बड़ी policy file में छिपाना चाहिए जिसकी कोई समीक्षा नहीं करता।

यह व्यवस्था shared access की तुलना में बेहतर containment options देती है। यदि agent खराब व्यवहार करने लगे, तो उसका session revoke करें। Credential अलग approved release process के लिए उपलब्ध रह सकता है। यदि secret exposure का संदेह हो, तो credential भी disable करें और उससे जुड़े सभी sessions की जाँच करें।

Sallyport इसी विभाजन का इस्तेमाल करता है: नया agent process default रूप से per-session authorization प्राप्त करता है, जबकि credentials उसके encrypted vault में रहते हैं और actions agent process के बाहर चलते हैं। उसका session prompt process की code-signing authority को सबसे पहले दिखाता है, यही वह evidence है जिसकी approver को run की अनुमति देने से पहले जरूरत होती है।

Approval record में process session और बाद में इस्तेमाल किए गए credential reference दोनों होने चाहिए। Prompt में credential value न दिखाएं और action result में उसे वापस न दें। यदि system UI में token छिपाकर agent tool response में दे देता है, तो उसने agent को token फिर भी सौंप दिया।

Credential injection secrets को agent की पहुँच से दूर रखता है

Agent को credential reference और target का नाम देकर action का अनुरोध करना चाहिए। Trusted executor HTTP या SSH call करते समय, केवल उसी क्षण secret inject करे। Agent को reusable credential नहीं, केवल result मिले।

यह token को shell environment में रखकर agent से उसे print न करने को कहने की तुलना में कहीं मजबूत boundary है। Environment variables child processes, debug output, crash reports, command history wrappers और tool calls में leak हो सकते हैं। Redaction बाद में accidental display में मदद करती है, लेकिन जिस process ने secret पढ़ लिया हो उससे secret वापस नहीं ले सकती।

Safe action request में credential के बिना call को authorize और execute करने के लिए पर्याप्त विवरण होना चाहिए:

{
  "session_id": "ses_7zQ2...",
  "credential_ref": "cred_release_publisher",
  "channel": "http",
  "request": {
    "method": "POST",
    "url": "https://api.example.internal/releases",
    "headers": {"Content-Type": "application/json"},
    "body": {"version": "1.4.2"}
  }
}

Executor जाँचता है कि session अभी approved है, vault उपलब्ध है, cred_release_publisher प्राप्त करता है, उसे आवश्यक authorization header में inject करता है, request करता है और decision तथा result record करता है। उसे agent के task के लिए ज़रूरी response data लौटाना चाहिए, sensitive response content के लिए सामान्य handling लागू करने के बाद।

यही principle SSH पर भी लागू होता है। Agent git fetch या remote command का अनुरोध SSH channel के ज़रिए कर सकता है, लेकिन उसे private credential PEM block के रूप में या ऐसा agent socket नहीं मिलना चाहिए जिसे कोई भी child process बिना supervision इस्तेमाल कर सके। Executor connection के लिए private credential का इस्तेमाल कर सकता है और event को agent session से जोड़ सकता है।

Sallyport फिलहाल HTTP credential injection और अपने bundled helper के ज़रिए SSH actions support करता है, इसलिए MCP-capable agent API या SSH secret अपने पास रखे बिना काम का अनुरोध कर सकता है। यह design हर action को सुरक्षित नहीं बनाता। यह वह separation बनाए रखता है जिसके आधार पर तय किया जा सकता है कि process को action का अनुरोध करने देना चाहिए या नहीं।

Shared deployment token failure को तब तक छिपाता है, जब तक वह मायने न रखने लगे

Shared credential incident को सीधी जाँच के बजाय reconstruction exercise बना देता है, क्योंकि हर संबंधित log line में वही account name दिखाई देता है। Failure अक्सर एक समझदार shortcut से शुरू होती है।

मान लें कि team PUBLISH_TOKEN को CI secret store में रखती है। Deployment job उसे पढ़ती है, जैसा अपेक्षित है। Release समस्या को दोहराने के लिए developer उसे local environment में भी export करता है। बाद में deployment scripts देखने के लिए वह उसी shell में coding agent शुरू करता है। अब agent अपने environment के ज़रिए release API call कर सकता है।

Repository file में छिपा instruction agent को draft release upload करने वाली command चलाने को कहता है। Command सफल होती है। API audit record कहता है release-publisher created release 1.4.2। CI log में कोई matching job नहीं है। Developer कहता है कि उसने agent से केवल files देखने को कहा था। इन facts पर सभी सहमत हो सकते हैं, फिर भी कोई यह नहीं बताता कि call करने वाला process कौन था।

Team अक्सर PUBLISH_TOKEN rotate करती है। यदि token leak हुआ हो तो इससे replay रुकता है, लेकिन legitimate CI job भी टूट जाती है और जल्दबाज़ी में repair करना पड़ता है। फिर team बिना evidence के developer, agent या repository instruction में से किसी को दोष दे सकती है। Account name CI invocation और local agent action में अंतर करने का कोई तरीका नहीं देता।

अब design बदलें। Release credential action executor द्वारा नियंत्रित vault में रहती है। Agent ऐसा session शुरू करता है जो उसकी signing authority और parent terminal record करता है। वह उसी session के ज़रिए upload action का अनुरोध करता है। Executor approval decision, credential reference, target API, request path और response status record करता है।

Suspicious upload होने पर incident record तुरंत शुरुआती उपयोगी सवालों का जवाब देता है: यह local agent session से आया, session किसी particular terminal से शुरू हुआ, उसे किसी specific समय authorization मिली और उसने release credential का इस्तेमाल एक POST request के लिए किया। Operator उस session को revoke करता है। CI जारी रहती है, क्योंकि उसकी अलग पहचान वाला process revoke नहीं हुआ। यदि repository instruction ने व्यापक secrets expose किए हों, तो team credential rotate कर सकती है, लेकिन अब यह evidence के आधार पर होगा, किसी दूसरे control के अभाव में नहीं।

अंतर perfect prevention का नहीं है। Approved agent फिर भी ऐसा action मांग सकता है जिसे मंज़ूर करने पर human को बाद में पछतावा हो। अंतर यह है कि system actor, authorization decision और targeted stop mechanism सुरक्षित रखता है। इससे incident बहस बनने के बजाय जल्दी छोटा किया जा सकता है।

Audit records को secrets रखे बिना identities जोड़नी चाहिए

Audit trail से process session, credential reference और external action को जोड़ा जा सके, जबकि secret material record से बाहर रहे। यदि ये data common event identifier के बिना अलग products में रहते हैं, तो incident response दबाव के समय manual correlation बन जाता है।

Session decision के लिए एक event और हर action के लिए एक event लिखें। दोनों में वही session_id रखें और हर action को अपना event identifier दें। यदि subject को रखना सुरक्षित हो, तो credential reference और credential subject store करें, लेकिन bearer token, private credential या raw authorization header कभी न रखें।

उपयोगी action record में normalized target, method या remote command, sensitive bodies की स्थिति में request digest, decision, response status और timestamps होने चाहिए। SSH के लिए host, remote user, requested command और exit result record करें। HTTP के लिए method, host, path और status record करें। Raw body तभी रखें जब retention और data handling rules इसकी अनुमति दें।

Tamper evidence महत्वपूर्ण है, क्योंकि action करने वाले process पर बाद में उसे छिपाने का आरोप लग सकता है। Hash chain investigator के पास पूरी sequence होने पर removal या rearrangement को detectable बनाती है। यह event को truthful नहीं बनाती। यदि collector agent द्वारा भेजा गया process name स्वीकार करता है, तो perfectly chained log उस false claim को हमेशा के लिए सुरक्षित रखती है। पहले supervising boundary पर identity evidence collect करें, फिर record को सुरक्षित करें।

Simple verification process को vault contents से स्वतंत्र रूप से काम करना चाहिए। Verifier हर encrypted event blob पढ़े, stored previous hash का मिलान पिछले event hash से करे, current hash दोबारा निकाले और पहली टूटी हुई position बताए। Output secrets उजागर किए बिना sequence position बताए:

$ audit verify events.log
verified: 184 events
chain: valid
first_event: evt_01J...
last_event: evt_01K...

Verification विफल हो तो repair की कोशिश से पहले original files सुरक्षित रखें। Missing record corruption, interrupted write, गलत export handling या जानबूझकर किए गए बदलाव का संकेत हो सकता है। Chain inconsistency दिखाती है, जबकि आसपास के logs और storage controls उसका कारण समझाने में मदद करते हैं।

अधिक automation जोड़ने से पहले identities अलग करें

Teams हर API integration को फिर से बनाए बिना यह model अपना सकती हैं। शुरुआत उन credentials से करें जो production state बदल सकते हैं, artifacts publish कर सकते हैं, customer data तक पहुँच सकते हैं या SSH से connect कर सकते हैं। Agent process के इन्हें विरासत में लेने पर सबसे कठिन incidents पैदा होते हैं।

पहला चरण ठोस रखें:

1. हर credential subject, उन services की सूची बनाएं जिन तक वह पहुँच सकता है और उन सभी processes की भी जो अभी उसका secret प्राप्त करते हैं।
2. Reusable secret values को agent prompts, agent configuration और agent process environments से हटाएं।
3. तय करें कि actions authorize होने के स्थान पर कौन सा process evidence collect किया जा सकता है।
4. हर agent run के लिए session identifier जारी करें और हर action के credential reference के साथ उसे log करें।
5. Containment test करें: एक session revoke करें, जबकि दूसरा approved workload उसी account का इस्तेमाल करता रहे।

आखिरी test आम गलती तुरंत दिखा देता है। यदि agent को रोकने का एकमात्र तरीका shared account disable करना है, तो आपने agent identity को credential identity से अलग नहीं किया है। आपने shared risk को केवल एक friendly name दिया है।

किसी विशाल rules engine से शुरुआत न करें। अधिकांश teams को कुछ स्पष्ट decisions चाहिए: क्या vault उपलब्ध है, क्या यह process session approved है और क्या इस action के लिए इस credential को approval चाहिए? कठिन हिस्सा operational discipline है: secrets को agent processes में भेजना बंद करें, भरोसेमंद process evidence collect करें और service account name को व्यक्ति या program मानने से इनकार करें।

जब अगला संदिग्ध action सामने आए, तो दो अलग सवालों के जवाब मांगें: इसका अनुरोध किस process ने किया और इसे execute किस authority ने किया? यदि आपके records दोनों का जवाब नहीं दे सकते, तो किसी और agent को production access देने से पहले इसे ठीक करें।