AI agent API access: direct tokens या mediated actions?

AI coding agent को केवल API call करने की जरूरत है, इसलिए उसे general SaaS token नहीं मिलना चाहिए। Direct token देने पर agent process credential holder बन जाता है। Credential कई सामान्य रास्तों से बाहर आ सकता है: verbose command, child process, uploaded diagnostic bundle, tool result या ऐसा instruction जो agent से configuration print करने को कहे।

इसका अर्थ यह नहीं कि हर API call को जटिल ceremony चाहिए। बात यह है कि action करने का अधिकार और उस अधिकार को प्रमाणित करने वाले credential का possession अलग रखें। Agent को उपयोगी काम माँगने का सीमित तरीका दें, credential उस component के पास रखें जो action execute करता है और जहाँ परिणाम महत्वपूर्ण हो वहाँ human decision लें।

यह फर्क इसलिए धुंधला हो जाता है क्योंकि सफल curl command harmless दिखती है। समस्या तब शुरू होती है जब agent production deployment बना सकता है, customer ticket बंद कर सकता है, issue बदल सकता है या remote command चला सकता है। उस बिंदु पर token setup detail नहीं, बिना judgment वाली operational authority है।

Direct token देने पर agent credential boundary बन जाता है

जब आप SAAS_TOKEN को agent के environment, configuration file, tool definition या prompt-accessible secret store में रखते हैं, agent authenticated requests कर सकता है और कोई दूसरा component हर request की जाँच नहीं करता। Token के scopes उचित हो सकते हैं, लेकिन वह उस process के हर behavior और अक्सर उसके द्वारा शुरू किए गए programs के लिए उपलब्ध हो जाता है।

Developers अक्सर कहते हैं कि agent environment variable को «देख» नहीं सकता। सामान्य tool use में यह दावा टिकता नहीं। Agent shell से environment जाँच सकता है, ऐसा script चला सकता है जिसे variable विरासत में मिले, debug logging वाले test tool को चला सकता है या configuration snapshot repository में लिख सकता है। Exposure का सटीक रास्ता agent और उसके tools पर निर्भर है, इसलिए सुरक्षित धारणा सरल है: अगर process bearer token सीधे इस्तेमाल कर सकता है, तो अक्सर token को ऐसी जगह दिखा भी सकता है जिसकी आपने योजना नहीं बनाई थी।

Bearer token की एक और समस्या है। SaaS service intended agent और उस string की copy रखने वाले व्यक्ति में अंतर नहीं कर सकती। RFC 6750, OAuth 2.0 Bearer Token Usage specification, कहता है कि bearer tokens को storage और transit में disclosure से बचाना जरूरी है, क्योंकि possession ही उनके उपयोग के लिए पर्याप्त है। यह केवल सैद्धांतिक बात नहीं है। Agent के build log में token print होते ही service को valid caller दिखता है, गलती नहीं।

Direct access accountability को भी अस्पष्ट करता है। Service audit logs bot account दिखा सकते हैं, लेकिन आम तौर पर यह नहीं बताते कि कौन-से agent run ने request बनाई, उसे कौन-से instructions मिले, किस user ने उसे शुरू किया या किसी व्यक्ति ने परिणाम approve किया था। आपको बाद की API event मिलती है, निर्णय की पूरी कहानी नहीं।

Disposable local sandbox में direct token कभी-कभी स्वीकार्य हो सकता है, यदि ये सभी बातें सही हों:

• Token जल्दी expire हो और केवल minimum non-production scope रखता हो।
• Target में customer, employee या production data न हो।
• Agent isolated environment में चलता हो जिसे हटाया जा सके।
• Shared work बाधित किए बिना कोई व्यक्ति credential revoke कर सके।

Teams token copy करना तेज होने के कारण इस अपवाद को routine practice बना देती हैं। Speed वास्तविक है, लेकिन token artifact में पहुँचने या agent के issue description में छिपे malicious instruction का पालन करने के बाद की cleanup भी वास्तविक है।

Scopes permissions सीमित करते हैं, intent नहीं

OAuth scopes, API roles और repository permissions यह बताते हैं कि «यह identity क्या कर सकती है?» वे यह नहीं बताते कि «यह request अभी होनी चाहिए या नहीं?» दोनों अलग controls हैं। उन्हें एक समझने पर बड़ा security gap रह जाता है।

मान लीजिए issue tracker token को एक project में issues edit करने की अनुमति है। Bugs triage करने वाले agent के लिए scope सही हो सकता है। Imported issue में prompt injection agent को हर open issue बंद करने, priorities बदलने या misleading comments डालने को कह सकती है। हर request scope के भीतर होगी, फिर भी हर request गलत होगी।

Deployment platform में भी यही समस्या है। एक application तक सीमित token यह नहीं जानता कि agent को current commit deploy करना चाहिए, release rollback करनी चाहिए, environment variable बदलना चाहिए या preview environment हटाना चाहिए। Service को authorized API calls दिखती हैं। वे task और acceptable target से मेल खाती हैं या नहीं, यह आपका workflow तय करेगा।

IETF OAuth 2.0 Security Best Current Practice short-lived access tokens, जहाँ संभव हो sender-constrained tokens और कम privileges की सलाह देता है। ये अच्छी practices हैं। Copied credential की उपयोगी अवधि और पहुँच घटती है। लेकिन properly scoped destructive action के लिए approval नहीं जुड़ता और agent का intent भी स्पष्ट नहीं होता।

हर endpoint और argument का अनुमान लगाने वाली बहुत बड़ी rules catalog न बनाएँ। Teams ऐसी catalogs बनाती हैं और फिर नई service APIs तथा असामान्य release procedures के exceptions सँभालते-सँभालते महीनों लगा देती हैं। छोटा action interface और सही समय पर human approval, ऐसी policy language से अधिक व्यवहारिक होता है जिसे कोई भरोसे से पढ़ नहीं सकता।

Issue trackers में human judgment बचाने वाले write paths चाहिए

Issue trackers कम जोखिम वाले लगते हैं, जब तक agent बड़े पैमाने पर बदलाव शुरू न करे। Issue बंद करने से customer report दब सकती है। Labels बदलने से triage reports टूट सकती हैं। Comment से internal reasoning external collaborators तक जा सकती है। किसी user को ticket में जोड़ने से sensitive context की पहुँच बढ़ सकती है।

Agent का काम observation और mutation में बाँटें। उसे issues retrieve करने, labels खोजने, linked pull requests देखने और proposed update का draft बनाने दें। Final mutation ऐसे action से कराएँ जिसमें project, issue, बदले गए fields और comment body स्पष्ट हों। Service को भेजने से पहले reviewer को वास्तविक content दिखना चाहिए।

Request contract यह सीमा स्पष्ट कर सकता है। Agent को credential-bearing command line बनाने के बजाय structured intent भेजना चाहिए।

{
  "service": "issue-tracker",
  "action": "update_issue",
  "issue": "APP-184",
  "changes": {
    "labels_add": ["needs-reproduction"],
    "comment": "I reproduced this on the current release and attached the failing test."
  }
}

Executor अपना credential जोड़े और सीमित result लौटाए:

{
  "ok": true,
  "issue": "APP-184",
  "updated_fields": ["labels", "comment"],
  "request_id": "service-request-id"
}

Raw Authorization header, पूरा HTTP trace या secrets वाला debug object न लौटाएँ। कठिन integration के दौरान verbose HTTP diagnostics enable करना आसान है। Diagnostics को human-operated troubleshooting path के पीछे रखें और redaction को मान लेने के बजाय test करें।

Human ने session approve कर दिया हो, तब भी agent गलत judgment कर सकता है। इसलिए destructive issue changes के लिए अलग approval option रखें। Session authorization बताता है कि running program integration इस्तेमाल कर सकता है या नहीं। Per-call approval बताता है कि यह खास mutation होनी चाहिए या नहीं। Tickets, documents या pull request comments से untrusted text पढ़ने वाले agent में यह अंतर खास महत्व रखता है।

Deployment APIs में release button से आगे के परिणाम होते हैं

Deployment API अक्सर केवल «यह version deploy करो» तक सीमित नहीं होती। वह environment variables बदल सकती है, builds trigger कर सकती है, workloads restart कर सकती है, domains बना सकती है, versions rollback कर सकती है, logs ला सकती है या resources हटा सकती है। Broad deploy token ऐसे agent के लिए convenient remote control बन जाता है जिसने गलत plan बनाया हो।

Deployment work के लिए अलग action categories रखें। Build status पढ़ना और deployment का public metadata लाना सामान्य काम हो सकते हैं। Artifact को production में promote करना, release rollback करना, secret reference बदलना और environment हटाना अलग परिणाम रखते हैं। इन्हें «deployment access» नाम वाले एक approval के पीछे न रखें।

सही request में immutable artifact reference और स्पष्ट target होना चाहिए। जहाँ service commit, image digest या build identifier resolve कर सकती है, वहाँ «latest» जैसे अस्पष्ट input को reject करें। Mutable labels approval और execution के बीच समय का अंतर बनाते हैं: reviewer एक चीज approve करता है और action दूसरी चला देता है।

{
  "service": "deployment-platform",
  "action": "promote_release",
  "application": "billing-api",
  "environment": "production",
  "artifact": {
    "git_commit": "8cf4f3a",
    "build_id": "build-4921"
  },
  "reason": "Fixes the confirmed invoice retry failure"
}

Executor जाँच करे कि approved identifiers उसी request से मेल खाते हैं जिसे वह भेज रहा है। Service response identifier और target environment भी record करे। केवल «deploy succeeded» लिखने से रात 2 बजे यह पता लगाना कठिन होगा कि कौन-सा artifact गया और किसने authorize किया था।

API design से बचने के लिए agent को web dashboard scrape न करने दें। Browser automation review से details छिपाती है, बिना warning टूट सकती है और stale page state पर click कर सकती है। Platform API देता हो तो API के ऊपर narrow mediated action इस्तेमाल करें। केवल dashboard उपलब्ध हो तो कुछ operations को human work ही रहने दें, जब तक dependable connector न बन जाए।

Customer support tools में automation से पहले data minimization करें

Customer support systems operational actions को personal data के साथ जोड़ते हैं। Ticket में account details, contact information, attachments, order history, logs और भावनात्मक messages हो सकते हैं। Direct agent access दो सवाल उठाता है: क्या agent ऐसी सामग्री पढ़ सकता है जिसकी उसे जरूरत नहीं, और क्या वह आपकी company के नाम से harmful reply भेज सकता है?

Default के रूप में पूरे ticket transcripts agent को न भेजें। Task के लिए जरूरी fields ही fetch करें। Ticket classify करने के लिए subject, redacted body और product area पर्याप्त हो सकते हैं। हर पुराना internal note, billing record या attachment शायद जरूरी नहीं है।

Write actions को classification से अधिक review चाहिए। एक उपयोगी तरीका है: पहले draft, फिर send। Agent ticket और इस्तेमाल किए गए internal source के references के साथ response proposal बनाए। व्यक्ति tone, factual claims, account-specific details और internal notes के accidental disclosure की जाँच करे। उसके बाद executor message post करे।

Closing, merging और reassigning tickets के लिए भी explicit action semantics रखें। «Resolve ticket» बहुत अस्पष्ट है, अगर वह चुपचाप closure email भेजे, service-level agreement clock बदले या draft हटा दे। Request schema में support service द्वारा किए जाने वाले side effect की पहचान होनी चाहिए।

यहीं broad service account सबसे आकर्षक लगता है। Permissions की friction हटती है और agent किसी भी queue को संभाल सकता है। लेकिन एक flawed instruction account boundaries पार कर सकती है। जहाँ provider अनुमति दे, service identities को queues या teams से जोड़ें और mediated action interface को उन्हीं operations तक सीमित रखें जिनकी उस team को जरूरत है।

SSH अलग syntax वाला API credential नहीं, execution authority है

SSH को अलग तरह से देखें, क्योंकि private key shell, file transfer, port forwarding और अपने credentials वाले tools तक पहुँच दे सकती है। Deployment API सीमित operations देती है। Remote shell मौके पर नए operations जोड़ सकती है।

Coding agent को SSH private key देने से दो जोखिम पैदा होते हैं। Key leak हो सकती है और agent मनमाने remote commands बना सकता है। Restricted account मदद करता है, लेकिन deployment scripts, cloud CLI credentials या production configuration तक पहुँच रखने वाला restricted account भी मूल task से कहीं अधिक कर सकता है।

ऐसा mediator इस्तेमाल करें जो private key रखे और requested host, command तथा arguments प्राप्त करे। Argument handling के बाद resolved host और exact command record करें। ऐसी shell string approve न करें जिसे agent nested quotes, command substitution या untrusted branch से fetched remote script के जरिए बाद में बदल सके।

Sensitive hosts के लिए general shell access के बजाय fixed remote operations बेहतर हैं। release-status --service billing-api जैसी command review करना bash -lc '...' से आसान है। General command जरूरी हो तो execution के exact रूप में दिखाएँ और हर call पर approval लें। sudo, package installation, secret file reads, shell redirection और outbound copy commands को higher-risk cases मानें।

SSH host verification भी जरूरी है। Client को managed known-hosts entry के विरुद्ध server host key verify करनी चाहिए। New host fingerprint को automatically स्वीकार करने से network या DNS mistake credential-use event बन सकती है। इससे private key छिपाने का पूरा उद्देश्य विफल हो जाता है।

Mediated actions credentials छिपाते हैं और decision point बनाते हैं

Mediated action system SaaS token या SSH private key को executor के भीतर रखता है और agent को defined work माँगने का interface देता है। Executor credentials जोड़ता है, request करता है और result लौटाता है। Agent को secret कभी नहीं मिलता, ऐसा placeholder भी नहीं जिसे वह गलती से command में डाल सके।

इससे failure mode बदल जाता है। Direct-access agent malicious instruction मानकर reusable credential के साथ action तय भी कर सकता है और चला भी सकता है। Mediated agent फिर भी गलत action माँग सकता है, क्योंकि कोई security control language-model judgment को perfect नहीं बनाता। लेकिन executor caller पहचान सकता है, व्यक्ति से call approve करा सकता है, credentials agent से दूर रख सकता है और request तथा result record कर सकता है।

Sallyport HTTP API calls और SSH commands के लिए इसी model का उपयोग करता है: MCP-capable agent sp mcp से connect होता है, जबकि macOS app API और SSH credentials को encrypted vault में रखकर actions खुद execute करता है। Vault locked होने पर उसका gate हर action deny करता है। Machine से जिम्मेदार व्यक्ति दूर हो तो यही सही behavior है।

Mediator को man-in-the-middle proxy न समझें। Proxy सामान्य traffic observe या relay करता है। Action gateway specific action request लेता है, authorization controls लागू करता है, अपने पास रखे credential का उपयोग करता है और outcome लौटाता है। यह shape approval point और audit record देती है, बजाय इसके कि agent traffic बना लेने के बाद हर चीज को समझने की कोशिश की जाए।

सबसे अच्छे mediated interfaces जानबूझकर साधारण होते हैं। वे समझने योग्य verbs की छोटी संख्या देते हैं, structured parameters लेते हैं, अस्पष्ट targets reject करते हैं और effect verify करने के लिए पर्याप्त जानकारी लौटाते हैं। Arbitrary URLs, headers और bodies स्वीकार करने वाला clever universal endpoint कुछ अतिरिक्त steps के साथ direct access फिर बना सकता है।

जब लोग request समझ न सकें तो approval design विफल होता है

Approval prompt व्यक्ति को निर्णय लेने में मदद करे, केवल interrupt न करे। «Agent support tool access माँग रहा है» reviewer से अज्ञात भविष्य को approve करने को कहता है। «Support team के रूप में ticket 4821 पर यह reply post करें» concrete action देता है जिसे reviewer जाँच सकता है।

नए agent process की पहली call पर process identity और code-signing authority दिखाएँ। Development machine पर कई terminals, extensions और helper programs एक ही integration माँग सकते हैं। Session grant करने से पहले reviewer को पता होना चाहिए कि कौन-सा signed program request कर रहा है।

Authorization का स्तर सही चुनें:

• Low-impact repeated reads या एक agent run में routine calls के लिए session approval लें।
• External messages, state changes, deployments, remote commands और irreversible effects के लिए per-call approval लें।
• दूर होने पर credential store lock करें, ताकि unattended approval का इंतजार करने के बजाय हर action fail हो।
• Task बदलने, agent अजीब व्यवहार करने या process पहचान में न आने पर current session revoke करें।

Approval fatigue design failure है। हर harmless retrieval approve करनी पड़े तो लोग click-through करना सीखेंगे। एक approval agent को पूरी दोपहर production mutations की अनुमति दे दे तो interface ने सुविधा के पीछे बहुत authority छिपा दी है। Consequence के अनुसार action types अलग करें, फिर सामान्य activity शांत और महत्वपूर्ण activity स्पष्ट रखें।

Approval text में agent का अपना vague description दोहराने से बचें। Action layer में structured fields पहले से हैं। Service, authenticated account या role, target project या host, operation और organization से बाहर जाने वाले human-facing content को दिखाएँ। Reviewer को जिन credentials और private fields की जरूरत नहीं, उन्हें redact करें।

Logs को agent run से हर external effect तक पहुँचना चाहिए

केवल service-provider logs पर्याप्त नहीं हैं, क्योंकि वे API boundary से शुरू होते हैं। केवल agent transcripts भी पर्याप्त नहीं हैं, क्योंकि actual request छूट सकती है या transcript बदला जा सकता है। Run-level और call-level दोनों records चाहिए, और दोनों के बीच reliable connection होना चाहिए।

Run-level journal में agent process, session start और end, उसे अनुमति देने वाला approval और तुरंत revoke करने का तरीका दर्ज हो। Call-level journal में action request, authorization outcome, execution result, target और उपलब्ध होने पर service request identifier record करें। Customer content वाले sensitive request bodies को routine displays से बाहर रखें, लेकिन incident जाँच के लिए protected evidence पर्याप्त मात्रा में बचाएँ।

Logs में tamper evidence भी उपयोगी है। Plain local text file history दिखा सकती है, लेकिन user या compromised process उसे बदल सकता है। Hash chain हर record को पिछले record पर निर्भर बनाती है, इसलिए बाद में किया गया बदलाव verification तोड़ देता है। इससे log infallible नहीं बनती, लेकिन unnoticed rewriting कठिन होती है और investigator के पास जाँचने योग्य integrity property होती है।

Sallyport अपने Sessions और Activity journals को write-blind encrypted, hash-chained audit log से project करता है। Vault key के बिना sp audit verify से ciphertext chain को offline verify किया जा सकता है। Healthy verification कुछ ऐसा दिखना चाहिए:

Audit chain: valid
Records checked: 184
First sequence: 1
Last sequence: 184

Sequence टूटने या hash mismatch की report आए तो files सुरक्षित रखें और journal पर भरोसा करने से पहले जाँच करें। Suspect log की खराब tail हटाकर उसे «repair» न करें। इससे record बदलने का समय और तरीका बताने वाला एकमात्र evidence भी मिट सकता है।

Direct-token migration सबसे जोखिमपूर्ण credential से शुरू करें

एक सप्ताह में हर integration redesign करने की कोशिश न करें। उस credential से शुरू करें जिसके दुरुपयोग से recovery सबसे कठिन होगी: production deployment authority, broad customer support access या shared systems तक पहुँचने वाली SSH key। हर workflow perfect करने से पहले agent से usable secrets हटाना migration का पहला लक्ष्य होना चाहिए।

हर integration के लिए यह क्रम अपनाएँ:

1. आज agent credential कहाँ से पाता है, इसकी inventory बनाएँ। Environment variables, repository files, CI secrets, shell profiles, tool configuration और copied prompts शामिल करें।
2. Agent वास्तव में कौन-से operations करता है, सूची बनाएँ और reads, drafts, mutations तथा remote execution अलग करें। अधिकांश direct tokens इस सूची से कहीं अधिक अनुमति देते हैं।
3. जरूरी operations के लिए structured action requests बनाएँ। हर write को named target और हर deployment को immutable artifact reference से बाँधें।
4. Credential को ऐसे executor में ले जाएँ जिसे agent पढ़ न सके। नया path काम करने के बाद पुराना credential rotate करें।
5. Failure को जानबूझकर test करें: vault lock करें, approval deny करें, session revoke करें, invalid target भेजें और audit verification चलाएँ। केवल happy-path demo लगभग कुछ साबित नहीं करता।

Rotation step teams की एक आम गलती पकड़ता है: mediator जोड़कर original token को «fallback» के लिए agent environment में छोड़ देना। इससे उसी authority तक दो रास्ते रह जाते हैं और कम नियंत्रित रास्ता आखिर इस्तेमाल होगा। Fallback हटाएँ। Mediated path अभी जरूरी operation support न करे तो temporary exception लिखें, उसका scope और lifetime सीमित रखें और removal के लिए किसी व्यक्ति का नाम तय करें।

Direct token देना आसान है, क्योंकि कठिन निर्णय process environment में मौजूद string को सौंप दिया जाता है। Throwaway sandbox में यह trade उचित हो सकता है। लेकिन customers, deployments या shared infrastructure को प्रभावित करने वाली services के लिए credentials agent से बाहर रखें और action होने से पहले उसे स्पष्ट रूप से दिखाएँ।