AI agent action gateway की जरूरत के पाँच संकेत
AI agent action gateway credentials को coding agents से दूर रखता है, approvals स्पष्ट करता है और हर HTTP या SSH action का record बनाता है।
जब कोई AI coding agent अपने workspace से बाहर ऐसे अधिकार के साथ काम कर सकता है जिसे कोई स्पष्ट रूप से देख, approve या revoke नहीं कर सकता, तब उसे action gateway की जरूरत होती है। चेतावनी यह नहीं है कि agent code लिखता है। असली समस्या यह है कि वह credential खर्च कर सकता है, hosted service बदल सकता है या SSH session खोल सकता है, अक्सर तब जब किसी ने उसके context में secret paste करके इस व्यवस्था को तैयार मान लिया हो।
Teams को अक्सर AI agent action gateway की समस्या तब समझ आती है जब कोई घटना होते-होते बचती है। Token chat transcript में दिखाई देता है। Coding run production deploy account इस्तेमाल करता है, क्योंकि वही उपलब्ध था। कोई पूछता है कि database change किसने approve किया, और जवाब messages की ढीली कड़ी तथा shared terminal session में छिपा होता है। ये केवल paperwork की कमियाँ नहीं हैं। इनसे पता चलता है कि team ने किसी untrusted process को operational authority दे दी है, बिना ऐसी usable boundary के जो उसे सीमित कर सके।
Gateway हर command को नैतिक रूप से सही बताकर agent को सुरक्षित नहीं बनाता। यह उसका उद्देश्य नहीं है। Gateway credentials को agent से बाहर रखता है, सही जगहों पर human decision लगाता है और ऐसा record छोड़ता है जिससे operator memory के सहारे घटना दोबारा बनाए बिना बता सके कि क्या हुआ। अगर नीचे दिए संकेत परिचित लगते हैं, तो direct credential access अपनी सुविधा की सीमा पार कर चुका है।
Copied API keys सामान्य setup बन चुकी हैं
जब developer काम कराने के लिए API keys को prompts, environment files, terminal sessions या agent configuration में paste करने लगे, तब agent के लिए अलग action boundary चाहिए। यह आदत harmless लगती है, क्योंकि पहला run अक्सर वही करता है जो developer ने कहा था। लेकिन इससे production authority की कई copies ऐसी जगहों पर बनती हैं जिन्हें उसे रखने के लिए बनाया ही नहीं गया।
Agent context में मौजूद credential मूल prompt से कहीं अधिक रास्तों से बाहर जा सकता है। Agent उसे command में दोहरा सकता है, configuration file में लिख सकता है, bug report में डाल सकता है, generated documentation में शामिल कर सकता है या failure समझाते समय दिखा सकता है। Terminal scrollback, shell history, process environments, CI logs, backups और support screenshots और copies बनाते हैं। एक visible message को redact करने से बाकी copies नहीं मिटतीं।
Teams जिस फर्क को अक्सर भूल जाती हैं, वह सीधा है: agent का secret इस्तेमाल करना और agent के पास secret होना अलग बातें हैं। Browser payment submit कर सकता है, बिना card number को page पर चलने वाली हर script के सामने रखे। Agent के लिए भी यही separation संभव है। वह बताए गए payload के साथ POST /deployments का अनुरोध कर सकता है, जबकि trusted executor credential inject करके response लौटा दे।
इस separation का नकली रूप स्वीकार न करें, जिसमें system API_KEY=... को ${SECRET_NAME} से बदलकर उस placeholder को agent process के भीतर resolve करता है। Plaintext फिर भी उसी process तक पहुँचता है। Compromised extension, repository में मौजूद malicious instruction या जरूरत से ज्यादा verbose debug dump उसे निकाल सकता है।
एक सुरक्षित request boundary कुछ ऐसी दिखती है:
{
"channel": "http",
"credential": "deploy-service",
"method": "POST",
"url": "https://api.example.internal/deployments",
"headers": {"content-type": "application/json"},
"body": {"service": "catalog", "revision": "a1b2c3d"}
}
Agent endpoint, payload, approval status और response देख सकता है। वह bearer token कभी नहीं देखता, जो request को authorize करता है। इसी अंतर से credentials rotate किए जा सकते हैं, बिना prompts और local worktrees को leaked copies के लिए साफ किए।
अगर key agent context में पहुँच चुकी है, तो उसे exposed मानें। उसे revoke या rotate करें, जाँचें कि run ने output कहाँ-कहाँ log किया और direct-secret pattern हटाएँ। Teams कभी-कभी rotation इसलिए टालती हैं कि वे साबित नहीं कर सकतीं कि token leak हुआ है। आपको यह साबित करने की जरूरत नहीं कि copied credential चुरा लिया गया था। इतना पहचानना पर्याप्त है कि अब आपको पता नहीं कि वह कहाँ-कहाँ मौजूद है।
Shared accounts बदलाव करने वाले actor को छिपाते हैं
जब agent shared deploy user, team-wide cloud token या ऐसा SSH account इस्तेमाल करता है जिसे हर developer और automation job साझा करते हैं, तब action gateway चाहिए। Shared access थोड़े समय के लिए account administration बचाता है, लेकिन कुछ गलत होते ही attribution खत्म कर देता है।
एक आम failure देखें। Agent को build failure ठीक करने को कहा जाता है। उसे infrastructure की पुरानी setting मिलती है और वह ops@production से host पर जुड़ता है। Account काम करता है, क्योंकि उसके पास broad permissions हैं और private key repository की onboarding notes में रखी है। Agent file बदलता है, service restart करता है और success report करता है।
बाद में service errors देने लगती है। Server journal कहता है कि ops ने उसे restart किया। Cloud audit trail कहता है कि team token ने deployment API call की। कोई record यह नहीं बताता कि कौन-सा agent process था, किस work request ने उसे शुरू किया, किस व्यक्ति ने process चलाया या operation से पहले किसी ने उसे देखा भी था या नहीं। अब incident investigation अनुमान पर टिकी है।
हर व्यक्ति के लिए अलग credential shared account से बेहतर है, लेकिन agent use की समस्या पूरी तरह हल नहीं होती। अगर agent को Alice की private key या long-lived token मिलता है, तो audit trail सिर्फ यह बताएगा कि Alice का credential इस्तेमाल हुआ। वह भरोसे से नहीं बता सकता कि request Alice ने, उसके terminal ने, compromised repository instruction ने या उसके agent ने शुरू की।
Identities और records को अलग काम दें:
- Service identity बताती है कि external system क्या अनुमति देता है।
- Agent session उस खास running process की पहचान बताता है जिसने काम माँगा।
- Approval बताता है कि किस व्यक्ति ने action scope स्वीकार किया।
- Action record सटीक request और उसका result बताता है।
इन सबको user नाम के एक field में न समेटें। Outage या access review के समय हर field अलग सवाल का जवाब देता है।
SSH के मामले में broad shared accounts पर खास संदेह करें। SSH private key portable signing authority होती है। अगर key agent के पास है, तो login के बाद लगाने वाले controls की सबसे उपयोगी boundary पहले ही खो चुकी है। Forced commands और account restrictions नुकसान घटा सकते हैं और उनका इस्तेमाल करना चाहिए, लेकिन इससे यह तथ्य नहीं बदलता कि agent key से अनुमत हर connection शुरू कर सकता है।
Key को ऐसे executor में रखें जो SSH operation खुद करे। Agent को ऐसा request interface दें जो host, command, identity, session और outcome दर्ज करे। Request इतना सीमित हो कि reviewer उसे समझ सके। systemctl restart catalog की समीक्षा की जा सकती है। ssh host 'bash -c \"$(curl ... )\"' मनमानी authority के लिए opaque tunnel है।
हर चीज के लिए एक approval, असल में approval नहीं है
जब developer एक बार अस्पष्ट permission approve करता है और बाद की requests में वह permission कहाँ इस्तेमाल हुई, यह नहीं बता सकता, तब action gateway चाहिए। «Allow agent access» नाम का button consent का दिखावा है, अगर वह unknown endpoints, commands, accounts और durations को cover करता है।
Approval तभी काम करता है जब वह दो व्यावहारिक सवालों का जवाब दे: किस process ने request की और यह approval किस चीज को cover करता है? Process identity महत्वपूर्ण है, क्योंकि local machine पर trusted coding agent, repository से copy की गई unsigned script और agent का नाम नकल करने वाला malicious process, तीनों चल सकते हैं। केवल display label trust स्थापित नहीं करता। Code-signing authority reviewer को जाँचने लायक उपयोगी तथ्य देती है।
Scope महत्वपूर्ण है, क्योंकि approval fatigue लोगों को बिना सोचे click करने वाला बना देती है। हर developer से प्रति घंटे पचास routine calls की समीक्षा कराने से human control नहीं बनता। लोग prompts dismiss करना सीख जाते हैं। दूसरी ओर production credential के लिए एक सप्ताह का blanket approval किसी एक accidental instruction को बहुत अधिक room देता है।
Capability के परिणाम के आधार पर दो अलग approval scopes रखें:
- Session approval एक पहचाने गए agent process की ordinary calls को उस process के समाप्त होने तक cover कर सकता है।
- Per-call confirmation उन credentials के लिए होनी चाहिए जो irreversible production changes कर सकते हैं, money transfer कर सकते हैं, access बदल सकते हैं या task से बाहर का data पढ़ सकते हैं।
Boundary process के साथ समाप्त होनी चाहिए, न कि इस बात की धुंधली याद के साथ कि किसी ने कल क्या click किया था। नए process को नया decision मिले। इससे agent restart होने, tool update होने या developer के दूसरे repository से दूसरा run शुरू करने पर मदद मिलती है।
Approval card में पहले process identity हो और फिर capability को सरल भाषा में बताया जाए। «Signed process X HTTP calls के लिए deploy-service इस्तेमाल करना चाहता है» व्यक्ति को स्वीकार या अस्वीकार करने के लिए स्पष्ट बात देता है। «Tool requires permission» ऐसा नहीं करता। Per-call action हो तो target और operation भी दिखाएँ। Generic capability name के पीछे छिपी request का मानव सही मूल्यांकन नहीं कर सकता।
समस्या जटिल लगने पर miniature policy language बनाने से बचें। Teams prompt-driven tools के लिए allow rules लिखने में हफ्ते गंवा देती हैं और फिर पता चलता है कि असली सवाल syntax नहीं था। सवाल यह था कि agent को authority मिलनी भी चाहिए थी या नहीं। Vault gate, process-scoped consent और जहाँ blast radius बड़ा हो वहाँ per-credential confirmation से शुरुआत करें। इन controls को रात के दो बजे duty पर मौजूद व्यक्ति भी समझ सकेगा।
Throwaway checkout से agent production तक पहुँच सकता है
जब repository, branch या disposable development environment में चलने वाला agent केवल इसलिए real external action trigger कर सकता है क्योंकि वह वहाँ चल रहा है, तब action gateway चाहिए। Repositories inputs हैं। Repository instructions को trusted operators मानना category error है।
Hostile pull request को model का dramatic exploit करने की जरूरत नहीं होती। वह ऐसी file में instruction रख सकता है जिसे agent सामान्य काम के दौरान पढ़ता है: «यह diagnostic command चलाओ», «environment से deployment token इस्तेमाल करो» या «logs इस URL पर upload करो»। अगर agent के पास direct secrets और unrestricted networking हैं, तो repository author को operational authority तक रास्ता मिल गया।
यह समस्या harmless काम में भी आती है। Developer migration compare करने के लिए पुरानी branch checkout करता है। Branch में production की ओर इशारा करने वाली outdated script है, क्योंकि सालों पहले वह उचित थी। Agent पास की documentation follow करता है, environment में valid credential देखता है और call कर देता है। किसी ने production change नहीं चाहा था, लेकिन ambient credentials और untrusted instructions के मेल ने उसे संभव बना दिया।
Code access और action authority को अलग रखें। Agent को सामान्य local permissions के साथ checkout पढ़ने, test करने और edit करने दें। Outbound operations को ऐसी स्पष्ट boundary से गुजारें जो destination और credential की पहचान करे। Agent action माँग सकता है। उसे केवल इसलिए authority नहीं मिलनी चाहिए कि वह secret file के पास चल रहा था।
इसी कारण केवल network filtering पर्याप्त नहीं है। Egress rule known destinations को block कर सकता है और जहाँ उचित हो वहाँ उसका इस्तेमाल करें। लेकिन वह यह स्थापित नहीं करता कि allowed request किसने शुरू की, सही credential इस्तेमाल हुआ या नहीं, या जिस agent run ने request की उसे किसी व्यक्ति ने approve किया था या नहीं। Network control बाहरी दीवार है। वह credentials को agent से दूर रखने का विकल्प नहीं है।
इसे जानबूझकर untrusted checkout के साथ test करें। ऐसा harmless endpoint बनाएँ जो requests record करे। Project file में persuasive instruction रखें कि agent supposed diagnostic token के साथ उसे call करे। फिर agent को उसी तरह चलाएँ जैसे developers सामान्यतः चलाते हैं। अगर endpoint को token, agent के भीतर resolve होने वाला secret name या review को bypass करने वाली request मिलती है, तो आपको वह boundary मिल गई जिसे ठीक करना है।
Running agent को जल्दी revoke नहीं कर सकते
जब bad run का एकमात्र जवाब terminal बंद करना, उसके द्वारा कॉपी किए गए हर credential को revoke करना या उसके खत्म होने की उम्मीद करना हो, तब action gateway चाहिए। गंभीर control operator को current authority रोकने देता है, बिना local mistake को बड़े credential emergency में बदलने के।
Process lifetime एक स्वाभाविक revocation unit देता है। अगर approval एक agent process से जुड़ा है, तो session revoke करने पर वह run बाद की actions नहीं कर सकता, भले process खुला रहे। Agent code draft करना जारी रख सकता है, लेकिन gateway द्वारा नियंत्रित external channels तक नहीं पहुँच सकता। यह unrelated developer work बंद करने या incident के दौरान organization-wide token rotate करने से कहीं कम disruptive है।
Teams अक्सर तीन अलग revocations को मिला देती हैं:
- Session revoke करने से एक पहचाना गया agent run आगे approved requests नहीं कर पाता।
- Credential vault lock करने से हर protected action रुक जाता है, जब तक authorized व्यक्ति उसे फिर न खोले।
- External credential rotate या disable करने से उसे जारी करने वाली service पर authority हट जाती है।
Incident को सीमित करने वाली सबसे छोटी कार्रवाई पहले करें और evidence माँगे तो व्यापक कार्रवाई करें। Developer ने गलत task चुन लिया हो तो session revocation काफी हो सकती है। Agent ने external transcript में token छाप दिया हो तो token rotate करें। यह स्पष्ट न हो कि किन agent runs के पास access है, तो पहले vault lock करें और stable position से जाँच करें।
Vault locked होने पर gateway को actions deny करनी चाहिए। यह बात स्पष्ट लगती है, जब तक ऐसे tools न मिलें जो सुविधा के लिए decrypted credentials cache करते हैं। Cached authority उस क्षण lock का उद्देश्य खत्म कर देती है जब operators को इसकी सबसे अधिक जरूरत होती है। Locked state का अर्थ होना चाहिए कि executor stored secrets की जरूरत वाली HTTP calls या SSH connections नहीं कर सकता।
Incident से पहले rehearsal करें। Agent session शुरू करें जो harmless protected action माँगे, session revoke करें और वही request फिर भेजें। Expected response बताए कि authorization अब valid नहीं है। फिर नया process शुरू करके देखें कि उसे अपना approval लेना पड़ता है। अगर पुराना process काम करता रहे, तो आपने control नहीं, notification system बनाया है।
आपके logs output दर्ज करते हैं, actions नहीं
जब आपके पास chat transcripts और terminal output हों, लेकिन reliable action record न बना सकें, तब action gateway चाहिए। Transcript बताता है कि agent ने क्या करने की बात कही। वह यह साबित नहीं करता कि network पर क्या गया या किस credential ने उसे authorize किया।
Action record executor के पास event को capture करे। HTTP call के लिए agent session, request time, target, method, credential reference, authorization decision और result status दर्ज करें। SSH के लिए host, account reference, command request, decision और exit result दर्ज करें। Journal को complete दिखाने के लिए raw passwords, private keys, bearer tokens या पूरे sensitive response bodies log न करें।
OWASP's Logging Cheat Sheet भी यही व्यावहारिक बात कहती है: Logs security investigation में मदद करें, लेकिन applications को access tokens, passwords, session identifiers और दूसरे secrets सीधे record करने से बचना चाहिए। कई teams केवल पहला हिस्सा अपनाती हैं। Agent failure के बाद verbose debugging चालू करती हैं और log store में दूसरा secret leak बना देती हैं।
बेहतर record evidence और secret material को अलग रखता है। Executor deploy-service जैसे credential reference, request digest और action result को रख सकता है। Investigator credential पाए बिना यह स्थापित कर सकता है कि किसी खास authorized session ने उस credential का इस्तेमाल किसी specific operation के लिए किया।
Record में tamper evidence भी चाहिए। अगर actions करने वाला वही process कल का journal चुपचाप बदल सकता है, तो journal वही कहानी बन जाएगा जो process आपको सुनाना चाहता है। Hash chaining व्यावहारिक बचाव है: हर entry में पिछली entry का digest शामिल होता है, इसलिए पुरानी entry बदलने या हटाने पर बाद की verification टूट जाती है।
Verification के लिए हर sensitive event को decrypt करना जरूरी नहीं होना चाहिए। उपयोगी audit tool encrypted records के विरुद्ध chain integrity validate कर सकता है। इससे contents तक व्यापक access दिए बिना operator बदलाव पकड़ सकता है। यह साबित नहीं करता कि हर original action समझदारी भरी थी। यह साबित करता है कि recorded sequence बाद में चुपचाप edit नहीं की गई।
Audit में «क्या agent सफल हुआ?» से आगे का सवाल पूछें: «कल production deployment credential किस agent run ने इस्तेमाल किया, किस process को consent मिला और हर request ने क्या result लौटाया?» अगर आपको shell history, cloud logs, chat export और किसी व्यक्ति की याद को जोड़ना पड़े, तो आपके पास action journal नहीं है।
Proxy traffic देख रहा है, फिर भी power agent के पास है
जब proposed fix ऐसा proxy हो जो traffic देखता है, जबकि API token या SSH key agent के पास ही रहती है, तब action gateway चाहिए। Proxies के वैध काम हैं, लेकिन traffic visibility और credential custody अलग controls हैं।
Reverse proxy application edge पर requests authenticate कर सकता है। Outbound proxy destinations filter कर सकता है या request logs रख सकता है। इनमें से कोई भी व्यवस्था यह जरूरी नहीं बनाती कि local agent token पढ़ न सके, उसे दूसरी request में न रख सके, file में save न कर सके या किसी दूसरे approved path का इस्तेमाल न कर सके। SSH के लिए network proxy agent environment में पड़ी private key की समस्या हल नहीं करता।
Man-in-the-middle design अपना operational burden भी लाता है। उसे TLS trust, certificate deployment, protocol exceptions और ऐसे traffic को संभालना पड़ता है जिसे applications अलग से pin या encrypt करती हैं। Teams कभी-कभी इसे universal control point समझकर बनाती हैं। फिर पता चलता है कि अब भी यह तय करना है कि कौन-सा process कौन-सा credential इस्तेमाल कर सकता है।
Boundary केवल packet पर नहीं, action पर रखें। Agent structured request करे। Executor stored credential चुने, उसे HTTP request में inject करे या SSH के लिए इस्तेमाल करे, decision record करे और result लौटाए। Agent के पास काम माँगने की जानकारी हो, service identity की नकल करने के लिए जरूरी material नहीं।
इस design की उपयोगी सीमा है: यह natural language से intent का अनुमान लगाने वाला general policy engine बनने की कोशिश नहीं करता। यह authority को स्पष्ट बनाता है। Agent known channel के जरिए operation माँगता है। Person या configured credential control तय करता है कि वह channel उस run के लिए उपलब्ध है या नहीं। Record बताता है कि क्या हुआ।
macOS teams के लिए Sallyport इस model को MCP stdio shim के जरिए इस्तेमाल करता है: agent HTTP या SSH actions माँगता है, जबकि app API और SSH secrets को अपने encrypted vault में रखकर action खुद करती है। इससे अच्छे service permissions चुनने की जरूरत खत्म नहीं होती, लेकिन raw credentials agent को देने की आदत खत्म होती है।
Least privilege पर भरोसा है, पर edges test नहीं किए
जब team कहती है कि उसके tokens least privilege हैं, लेकिन उसने यह test नहीं किया कि autonomous process के हाथों में वे permissions क्या कर सकती हैं, तब action gateway चाहिए। Least privilege किसी role पर लगा label नहीं, बल्कि real credential और उसके reachable operations का गुण है।
केवल एक service deploy करने वाला token भी उस service के environment variables बदल सकता है, जिससे traffic redirect या data expose हो सकता है। एक host तक सीमित SSH account deployment configuration पढ़ सकता है, जिसमें दूसरे systems के credentials हैं। Resources delete न कर सकने वाला cloud role अत्यधिक broad identity वाला workload बना सकता है। Permission names हर consequence नहीं दिखातीं।
Review products के आधार पर नहीं, actions के आधार पर करें। लिखें कि agent executor से क्या करा सकता है और हर action के लिए service की authorization rules देखें। Reads को भी शामिल करें। Export endpoints, log retrieval, configuration reads और discovery APIs के जरिए agent बिना कोई resource बदले भी महंगे या sensitive incidents कर सकता है।
Review के दौरान छोटी table इस्तेमाल करें:
| Requested action | External identity | Consequence if misused | Approval scope |
|---|---|---|---|
| Create a preview deployment | preview deploy account | Temporary workload and cost | Session |
| Restart a production service | production operations account | User outage | Per call |
| Read an incident log bundle | support account | Possible sensitive data exposure | Per call |
| Open SSH to build host | build host account | Command execution on host | Session if command scope is narrow |
Table असुविधाजनक, लेकिन उपयोगी बातचीत कराती है। अगर consequence को छोटे वाक्य में नहीं बता सकते, तो permission शायद बहुत broad है या request interface बहुत अस्पष्ट।
Action gateway को service identities की excess permissions छोड़ने का बहाना न बनाएँ। यह secret exposure घटाता है और consent तथा evidence बेहतर करता है। External API या host अब भी तय करता है कि credential क्या कर सकता है। Rights घटाएँ, अलग environments के लिए अलग identities रखें और irreversible operations पर tighter approval rule लगाएँ।
पहली boundary उस action पर लगाएँ जो इस सप्ताह नुकसान कर सकता है
Action gateway तब उपयोगी है जब वह team के मौजूदा direct credential path को बदलता है, न कि six-month access redesign बन जाता है। Agent द्वारा अभी किए जा रहे सबसे high-consequence action को चुनें और पहले वही path बदलें।
कई teams के लिए यह production deployment API होता है। दूसरों के लिए build या operations host तक SSH access। चयन actual authority के आधार पर करें, demo में आसान लगने वाले integration के आधार पर नहीं। Read-only issue tracker token महत्वपूर्ण हो सकता है, लेकिन वह ऐसी private key से ध्यान नहीं हटाना चाहिए जो production services restart कर सकती है।
पहला rollout ठोस रखें:
- Agent को उपलब्ध tokens, SSH keys, shared accounts और environment variables की सूची बनाएँ।
- ऐसा credential चुनें जो real trust boundary पार करता हो और उसका plaintext agent environment से हटाएँ।
- Structured action request तय करें, जिसमें destination और operation शामिल हों।
- उस request path के लिए process-scoped authorization माँगें और action से बड़ा नुकसान हो सकता हो तो per-call confirmation चुनें।
- Benign test चलाएँ, session revoke करें और जाँचें कि journal allowed call तथा denied retry दोनों दिखाता है।
Staging credential से शुरुआत तभी करें जब staging उसी action path को सही तरह exercise करता हो। बिल्कुल अलग tool में staging token production authorization के व्यवहार के बारे में बहुत कम बताता है। Test में actual executor, approval, revocation और audit path शामिल होने चाहिए।
Perfect agent behavior का इंतजार न करें। Prompt injection defenses, repository review, sandboxing, service permissions और network controls सभी risk घटाते हैं। फिर भी जब agent process ऐसे credential के साथ external action माँगता है जिसे उसके पास होना ही नहीं चाहिए, तब इनमें से कोई clean answer नहीं देता। अगली copied token को incident investigation बनने से पहले credential को boundary के पीछे रखें।
सामान्य प्रश्न
AI coding agent के लिए action gateway क्या होता है?
Action gateway credentials को agent process से बाहर रखता है और agent की ओर से approved external actions करता है। Secret manager secrets को store और retrieve करता है। अगर वह API token agent को वापस दे देता है, तो agent के पास token रहता है और वह उसे उजागर या दोबारा इस्तेमाल कर सकता है।
क्या छोटी teams को भी action gateway की जरूरत होती है?
आप एक खतरनाक channel से शुरुआत कर सकते हैं, आमतौर पर production HTTP access या SSH से। पहली उपयोगी सीमा सरल है: agent action का अनुरोध करे, अलग trusted component credential रखे, और कोई व्यक्ति run को देख और रोक सके।
अगर agent ने prompt में API key कॉपी कर ली हो तो क्या करना चाहिए?
Prompt, transcript, shell history, terminal capture या generated file में token पहुँचते ही उसे exposed मानें। उसे revoke करें, नया token जारी करें, पता लगाएँ कि वह कहाँ दिखाई दिया और फिर वह workflow बदलें जिसके कारण agent को token मिला था।
क्या restricted SSH keys agent को सीधे देना सुरक्षित है?
नहीं। SSH key account, source address या command से सीमित हो सकती है, फिर भी agent process उस key को मिली हर permission का इस्तेमाल कर सकता है। Private key को अलग executor में रखें और उसके चलने वाले commands को approve या सीमित करें।
Agent access के लिए shared service accounts समस्या क्यों हैं?
Shared accounts attribution मिटा देते हैं। सफल request से पता चलता है कि कौन-सा account इस्तेमाल हुआ, यह नहीं कि किस agent run या व्यक्ति ने उसे शुरू किया। जहाँ संभव हो, हर workload को अलग identity दें और हर action के साथ agent session दर्ज करें।
Agent action के approval prompt में क्या दिखना चाहिए?
उपयोगी approval में agent process, destination, operation, इस्तेमाल होने वाला credential या capability और approval scope का नाम होना चाहिए। केवल «agent access चाहता है» कहने वाला approval व्यक्ति को महत्वपूर्ण बातों का अनुमान लगाने पर मजबूर करता है।
AI agent action log में क्या दर्ज होना चाहिए?
Action records में agent session, समय, destination, method या command, authorization result और outcome दर्ज होने चाहिए। Raw credentials, tokens और sensitive response bodies को न लिखें, जब तक आपके पास उनके लिए जानबूझकर बनाया गया protected process न हो।
क्या reverse proxy action gateway की जगह ले सकता है?
Proxy traffic को देख या route कर सकता है, लेकिन इससे agent के पास credentials रहने या किसी दूसरे network path का इस्तेमाल करने की समस्या अपने आप हल नहीं होती। Action gateway को credential अपने पास रखना और action खुद करना चाहिए, केवल request के रास्ते में बैठना नहीं।
हर agent call के लिए approval कब माँगना चाहिए?
सीमित scope वाले, ज्ञात agent process के routine काम के लिए per-session approval ठीक है, बशर्ते session सही तरीके से समाप्त हो। Broad production impact वाले credentials, irreversible operations या पहले हो चुकी accidental misuse के लिए हर उपयोग पर confirmation माँगें।
Development रोके बिना agent action controls कैसे शुरू करें?
पहले agent को उपलब्ध हर credential, SSH key, shared account और outbound integration की सूची बनाएँ। फिर सबसे अधिक प्रभाव वाले रास्ते से direct secret delivery हटाएँ और जाँचें कि request से approval और result तक एक test action को पूरा फिर से बनाया जा सकता है।