AI agent action gateway बनाम MITM proxy: control points

AI agent action gateway और man-in-the-middle proxy, दोनों agent और external service के बीच बैठ सकते हैं। इसी सतही समानता के कारण architecture के गलत फैसले होते हैं। एक मॉडल credential अपने पास रखते हुए agent की ओर से authenticated action चलाता है। दूसरा उस traffic को आगे भेजता या intercept करता है जिसे agent पहले ही बनाने का फैसला कर चुका है।

यह अंतर तय करता है कि आप कहाँ «नहीं» कह सकते हैं, agent क्या चुरा सकता है, approval का अर्थ क्या है और audit record किसी सोच-समझकर की गई कार्रवाई का वर्णन करता है या फिर packets के flow से घटना दोबारा बनाता है। अगर आवश्यकता है कि «agent के पास production credentials कभी न हों», तो proxy आम तौर पर सही primary boundary नहीं है। उसका अपना उपयोग हो सकता है, लेकिन client process में पहले से मौजूद secret की समस्या वह ठीक नहीं कर सकता।

Gateway named actions चलाता है, proxy connections संभालता है

AI agent action gateway किसी external operation को चलाने का अनुरोध स्वीकार करता है, stored credential चुनता है, operation करता है और परिणाम लौटाता है। Agent काम मांगता है, लेकिन उसे bearer token, password या private key नहीं मिलती, जिनसे वह वही काम कहीं और दोहरा सके।

Forward proxy client से network connection लेता है और उसे destination तक भेजता है। Request पर नियंत्रण client का ही रहता है। Plain HTTP में proxy method, URL, headers और body पढ़ सकता है, क्योंकि client उसे HTTP भेजता है। HTTPS में सामान्य स्थिति CONNECT tunnel होती है: proxy target से TCP connection बनाता है और दोनों दिशाओं में encrypted bytes relay करता है।

MITM proxy HTTPS के साथ अलग तरह से काम करता है। वह client का TLS connection समाप्त करता है, decrypted HTTP message को पढ़ या बदल सकता है, फिर upstream server के लिए अलग TLS connection बनाता है। Client को proxy द्वारा नियंत्रित certificate authority पर भरोसा करना पड़ता है, क्योंकि proxy destination host के नाम का certificate दिखाता है।

ये मॉडल अलग सवालों का जवाब देते हैं:

• Proxy पूछता है कि traffic कहाँ जा सकता है और interception के साथ traffic में क्या लिखा है।
• Action gateway पूछता है कि वह कोई खास authenticated operation करेगा या नहीं।
• Proxy client के request में सामग्री जोड़ या हटा सकता है।
• Gateway credential अपने पास रखकर authenticated request स्वयं बना सकता है।

यह आखिरी बात केवल शब्दों का अंतर नहीं है। इससे तय होता है कि compromised agent credential लेकर किसी दूसरी machine, अलग समय या अलग route से service को call कर सकता है या नहीं।

मान लें agent से deployment बनाने को कहा गया है। Proxy design में agent आम तौर पर POST /deployments तैयार करता है, JSON body चुनता है और request भेजता है। Proxy उसे अनुमति दे सकता है, रोक सकता है, log कर सकता है या Authorization header जोड़ सकता है। Executor design में agent arguments के साथ create_deployment जैसी action call करता है। Gateway configured destination और secret चुनता है, HTTP call करता है और केवल वही status तथा response body लौटाता है जिसे action लौटाने की अनुमति है।

Executor को भी सावधानी से design करना पड़ता है। «arbitrary HTTP request भेजें» जैसी बहुत सामान्य action proxy model का बड़ा हिस्सा फिर बना सकती है। फिर भी credential boundary अलग रहती है: gateway के पास credential है, agent के पास नहीं।

TLS inspection को certificate authority की समस्या बना देता है

सिर्फ proxy से गुजरने के कारण HTTPS traffic सामान्य forward proxy को दिखाई नहीं देता। यह बात अक्सर गलत समझी जाती है और teams ऐसे controls बना देती हैं जो client के CONNECT इस्तेमाल करते ही बेकार हो जाते हैं।

RFC 9110 में CONNECT को target host और port तक tunnel बनाने का अनुरोध बताया गया है। Tunnel बनने के बाद proxy bytes relay करता है। TLS handshake उस tunnel के भीतर client और origin server के बीच होता है। Proxy target host, port, timing, byte counts और connection outcome रिकॉर्ड कर सकता है, लेकिन encrypted header में मौजूद POST /v1/... या API key नहीं पढ़ सकता।

HTTPS inspect करने के लिए intercepting proxy को client का TLS endpoint बनना पड़ता है। RFC 8446 में निर्दिष्ट TLS 1.3 के तहत client को certificate chain और hostname validate करना होता है। Proxy यह validation तभी पूरा कर सकता है जब client ऐसी certificate authority पर भरोसा करे जो intercept किए जा रहे sites के लिए certificates जारी कर सके।

इससे वास्तविक operational काम पैदा होता है:

1. हर उस machine या runtime पर private CA install और सुरक्षित करें जिसे agent इस्तेमाल करता है।
2. Language runtimes, package managers, command line tools, containers और embedded clients को उस पर भरोसा करवाएँ।
3. Public certificates pin करने वाले clients या अपना certificate store इस्तेमाल करने वाले clients संभालें।
4. Proxy को मिलने के बाद decrypted request bodies और credentials सुरक्षित रखें।
5. समझाएँ कि unknown certificate issuers पर अविश्वास करने वाला process अब आपके interception CA पर भरोसा क्यों कर रहा है।

Managed enterprise environment में यह उचित हो सकता है। यह कोई छोटा implementation detail नहीं है। Agent का सारा traffic decrypt करने वाला proxy हर secret, request body और response का high-value holder बन जाता है।

Credential रखने वाले executor को operation देखने के लिए हर destination certificate की नकल करने की ज़रूरत नहीं होती। वह अपने operation के लिए HTTP client की तरह काम करता है। Destination से सामान्य TLS connection बनाता है, public certificate को सही client की तरह validate करता है और execution के समय stored credential जोड़ता है।

इससे TLS संबंधी चिंताएँ समाप्त नहीं होतीं। Gateway को certificates सही तरह validate करने और secret store सुरक्षित रखने होंगे। लेकिन केवल action देखने के लिए agent process में private interception CA बाँटने की ज़रूरत नहीं रहती।

एक उपयोगी test यह है: अगर design document कहता है कि proxy HTTPS requests inspect करेगा, तो पूछें कि client interception CA पर भरोसा कहाँ करता है। अगर कोई साफ जवाब नहीं दे सकता, तो proxy केवल tunnels देखेगा या certificates सही तरह validate करने वाला tool fail होगा।

Credential custody तय करती है कि compromised agent कितना नुकसान कर सकता है

उपयोगी security boundary यह नहीं है कि «agent ने हमारे box के ज़रिए network request की»। असली सवाल है कि क्या agent reusable authority पा सकता है।

Bearer tokens इस बात को स्पष्ट करते हैं। API server आम तौर पर उस हर process से bearer token स्वीकार करता है जो वहाँ तक पहुँच सकता है। अगर agent को string मिल गई, तो वह उसे file में लिख सकता है, tool output में रख सकता है, दूसरे endpoint तक भेज सकता है या approval session खत्म होने के बाद इस्तेमाल कर सकता है। बाद में logs redact करने से मदद नहीं मिलेगी। Credential अपनी intended boundary से बाहर जा चुका है।

Proxy token को स्वयं inject करके exposure घटा सकता है। फिर भी design की जाँच करनी होगी। Proxy तक पहुँचने वाले request पर नियंत्रण agent का है। जब तक proxy API semantics समझकर उन्हें भरोसेमंद ढंग से लागू नहीं करता, agent injected token का इस्तेमाल किसी भी endpoint, method या payload के लिए कर सकता है जिसकी अनुमति token देता है।

उदाहरण के लिए, «api.example.internal के लिए यह token inject करें» जैसा rule requesting process को पूरे host पर token की effective authority देता है। Agent token string नहीं देखता, लेकिन वह proxy से destructive calls करवा सकता है। Narrowly scoped service account के लिए यह स्वीकार्य हो सकता है। यह named deployment action की अनुमति देकर असंबंधित administrative endpoints रोकने जैसा control नहीं है।

Action gateway credential को उस action path से बाँध सकता है जो उसका इस्तेमाल करता है। Agent authorization material नहीं, केवल arguments देता है। Gateway network request बनाने से पहले व्यक्ति को credential identity और intended operation दिखा सकता है। वह ऐसा अनुरोध भी रोक सकता है जो configured channel के अनुरूप न हो।

मुख्य अंतर secret non-disclosure और authority containment के बीच है।

Secret non-disclosure का अर्थ है कि agent को raw credentials कभी न दिखें। Header-injecting proxy यह कर सकता है।

Authority containment का अर्थ है कि agent permitted integration को general-purpose authenticated transport में न बदल सके। इसके लिए action definitions, destination handling, argument validation और side effect से पहले लागू होने वाले controls चाहिए। सामान्य proxy अपने-आप यह सुविधा नहीं देता।

SSH इस मुद्दे को और स्पष्ट कर देता है। SSH public-key authentication में protocol exchange के दौरान client साबित करता है कि उसके पास private key है। अगर agent के पास private key है, तो वह उस key को स्वीकार करने वाली हर जगह authenticate कर सकता है। अगर agent के पास केवल gateway से routed SSH command है, तो gateway या उसका helper key export किए बिना authentication करेगा।

RFC 4253 SSH transport protocol और उससे जुड़ी authentication architecture का वर्णन करता है। व्यावहारिक नतीजा सरल है: client request में «SSH private key header inject» नहीं किया जा सकता। या तो process signing authority रखता है, या कोई दूसरा process उसकी ओर से authenticated connection बनाता है।

Authorization external side effect से पहले होनी चाहिए

किसी control point का मूल्य तभी है जब वह उस चीज़ से पहले काम करे जिसे आप नियंत्रित करना चाहते हैं। Upstream server के request स्वीकार करने के बाद उसे log करने से evidence मिलता है, veto नहीं।

MITM proxies अक्सर host, URL, method, headers, request body, client identity या destination category के आधार पर policy और approval systems देते हैं। Decrypted traffic दिखने और application protocol समझने पर ये मजबूत controls हो सकते हैं। लेकिन तब rules की समस्या भी आती है। किसी को तय करना होगा कि /projects/123/members सुरक्षित है या नहीं, JSON payload harmless update को privilege grant में बदलता है या नहीं और encoded request string match को bypass करती है या नहीं।

मैंने teams को तीन proxy rules से शुरू करके exceptions की एक undocumented language संभालते देखा है। समस्या यह नहीं कि rules हमेशा खराब होते हैं। समस्या यह है कि agent के arbitrary request format को stable और कम-अस्पष्ट policy surface मान लेना।

Action gateway छोटी vocabulary इस्तेमाल कर सकता है। Authorization decision calling process, configured credential, requested action और supplied arguments को देख सकता है। व्यक्ति को opaque curl command देखकर यह अनुमान नहीं लगाना पड़ता कि downstream कौन-सा stored secret जोड़ा जाएगा।

Sallyport policy language के बजाय fixed decision ladder अपनाता है। Locked vault हर action रोकता है। नया agent process default रूप से session authorization मांगता है और approval में process की code-signing authority दिखाई जाती है। Individual credentials को हर उपयोग पर approval की आवश्यकता भी दी जा सकती है। ये जानबूझकर coarse controls हैं, लेकिन app के HTTP या SSH action करने से पहले लागू होते हैं।

इस approach की सीमा स्पष्ट है: fixed approval model हर organization का conditional rule व्यक्त नहीं कर सकता। यदि आपको «किसी maintenance window में, ticket field की खास value होने पर ही writes दें» जैसा rule चाहिए, तो उसे evaluate और maintain करने वाला system चाहिए। Simple action gateway को general-purpose policy engine बताने की कोशिश न करें।

छोटे control set का लाभ यह है कि operator उसके व्यवहार का अनुमान लगा सकता है। Vault locked या unlocked है। Process run approved है या नहीं। Credential हर बार approval मांगता है या नहीं। Security controls तब व्यावहारिक रूप से fail होते हैं जब कोई यह नहीं समझा सकता कि call पास क्यों हुई।

Request visibility और action authority अलग गुण हैं

Teams अक्सर «full visibility» मांगती हैं, जबकि उन्हें दो अलग चीज़ें चाहिए: किस agent ने काम शुरू किया और कौन-सी external action हुई। Packet-level visibility debugging में मदद कर सकती है, लेकिन action record का अच्छा विकल्प नहीं है।

Proxy log में source address, destination, TLS details, interception सफल होने पर HTTP fields और raw bytes हो सकते हैं। यह उपयोगी forensic material है, लेकिन identity की समस्या भी पैदा करता है। Connection तभी बताता है कि कौन-सा process जुड़ा था जब environment उस identity को उपलब्ध कराए और सुरक्षित रखे। Request बताता है कि proxy तक क्या पहुँचा, यह ज़रूरी नहीं कि कौन-से model instruction या agent session से वह शुरू हुआ।

Action gateway operation boundary से शुरू होता है। वह operation मांगने वाले agent run और executor द्वारा की गई individual call दोनों रिकॉर्ड कर सकता है। ये records अलग सवालों का जवाब देते हैं:

• किस authorized agent process का active session था?
• उस session ने कौन-सी external action मांगी?
• Executor ने कौन-सा credential या channel इस्तेमाल किया?
• कौन-सा परिणाम लौटा या call कहाँ fail हुई?

Audit trail को access control system न समझें। Detailed log agent को data delete करने से नहीं रोकता, अगर आपने उसे वह action दी है। वह बाद के बदलावों को detect करने योग्य बना सकता है और incident review को service के अपने database पर कम निर्भर करता है।

Sallyport अपने Sessions और Activity journals को एक encrypted, hash-chained audit log से तैयार करता है। sp audit verify command ciphertext पर offline chain जाँचती है और vault key की आवश्यकता नहीं रखती। इससे verification को secrets decrypt करने की क्षमता से अलग किया जाता है, जो ऐसे investigator के लिए सही विभाजन है जिसे credential access पाए बिना history validate करनी हो।

Concrete verification workflow का output ऐसा होना चाहिए जिसे लोग तुरंत पहचान सकें। उदाहरण के लिए:

$ sp audit verify
Verifying audit chain...
Entries checked: 184
Chain status: valid

Exact संख्या बदल सकती है। उपयोगी बात यह है कि बदला हुआ, गायब या क्रम से बाहर हुआ record verification को fail कराए, न कि चुपचाप छोटी history दिखाए। अगर पूरी deletion से सुरक्षा चाहिए, तो encrypted audit data की copy उस machine से बाहर रखें जिसने उसे बनाया। Hash chain आपके पास मौजूद records से छेड़छाड़ पकड़ती है, लेकिन attacker ने machine के साथ जो files नष्ट कर दीं, उनके अस्तित्व को साबित नहीं कर सकती।

HTTP और SSH की mediation limits अलग हैं

HTTP आसान दिखता है, क्योंकि उसमें headers, URLs और verbs होते हैं। इसी वजह से teams हर integration को header injection problem समझने की गलती करती हैं।

HTTP bearer-token API के लिए executor ऐसा credential record रख सकता है जो बताए कि authentication कैसे करनी है और वह कहाँ लागू होती है। Agent operation मांगता है तो executor स्वयं bearer header जोड़ता है। Custom-header scheme में वह configured header जोड़ता है, उसका value agent को नहीं लौटाता। Basic authentication भी इसी custody rule का पालन करती है, हालांकि executor को username और password को सामान्य configuration text नहीं बल्कि secrets मानना होगा।

Inputs का विभाजन व्यावहारिक रूप से ऐसा हो सकता है। Agent request data दे सकता है:

{
  "method": "POST",
  "path": "/repos/acme/widget/deployments",
  "body": {
    "environment": "staging",
    "revision": "7d3c1a"
  }
}

Agent को यह नहीं देना चाहिए:

{
  "authorization": "Bearer token-value-goes-here"
}

यह विभाजन उस सामान्य failure को रोकता है जिसमें tool schema secret field दिखाता है, model उसमें value रखता है और वह value traces, terminal scrollback, test fixtures या copied conversation text में दिखाई देने लगती है। Token को tool argument मानना design error है, भले ही call के बाद UI उसे छिपा दे।

HTTP mediation में भी boundaries चाहिए। अगर gateway arbitrary URLs स्वीकार करता है, तो agent credentialed path से internal services, cloud metadata endpoints या असंबंधित hosts को target कर सकता है। अगर वह arbitrary headers स्वीकार करता है, तो agent request smuggling का प्रयास कर सकता है या authentication semantics बदल सकता है। अगर arbitrary bodies स्वीकार हैं, तो API स्वयं policy language बन जाती है।

SSH की सीमाएँ अलग हैं। Action को remote command चलानी, file copy करनी या host query करना पड़ सकता है। Gateway को destination और अपने पास रखी private key चाहिए। Stateless helper SSH connection बनाकर standard output, standard error और exit status लौटा सकता है, बिना key को agent environment में रखे।

Command boundary महत्वपूर्ण है। ऐसा request:

host: build-host
command: git rev-parse HEAD

उस agent की तुलना में कम review surface देता है जो ~/.ssh, arbitrary proxy settings और unrestricted command line वाले local shell तक पहुँच रखता हो। फिर भी यह authenticated remote command है। अगर credential remote तौर पर rm -rf चला सकता है, तो transport बदलने से gateway उसे सुरक्षित नहीं बना सकता। Remote account की permissions सीमित करें और वही credentials चुनें जिन jobs के लिए वे वास्तव में चाहिए।

Proxy SSH को TCP tunnel के रूप में भेज सकता है, लेकिन केवल port 22 route करके SSH command inspect नहीं कर सकता। SSH protocol content inspect करने के लिए उसे SSH endpoint बनकर upstream में दूसरा SSH connection स्थापित करना होगा। इससे host trust, authentication, recording और compatibility की सभी जिम्मेदारियाँ आती हैं। इसे proxy कहने से engineering work कम नहीं होता।

Proxy तब उपयोगी रहता है जब वह सही layer संभाले

MITM proxy को agent action gateway के रूप में इस्तेमाल करने के विरुद्ध तर्क proxies के विरुद्ध तर्क नहीं है। सही layer पर काम करने पर proxies कई समस्याएँ अच्छी तरह हल करते हैं।

Forward proxy या egress gateway का उपयोग तब करें जब आपको यह सीमित करना हो कि runtime किन networks या hostnames तक पहुँच सकता है, traffic को ज्ञात route से भेजना हो, सामान्य tools का outbound access नियंत्रित करना हो या connection metadata इकट्ठा करना हो। ये controls agent को unapproved host call करने से रोक सकते हैं, भले agent आपके action model को न समझता हो।

MITM proxy तब इस्तेमाल करें जब clients आपके नियंत्रण में हों, आप trust CA manage कर सकें, कई conventional HTTP clients के behavior को diagnose या enforce करना हो और decrypted traffic संभालने की जिम्मेदारी स्वीकार हो। Security test environments और managed device fleets अक्सर इन शर्तों को पूरा करते हैं।

Action gateway तब चुनें जब requirement autonomous agent की identity और authority से जुड़ी हो: agent external action मांगे, credential अपने पास न रखे और executor द्वारा की गई action का reviewable record बने।

कई गंभीर deployments दोनों को मिलाते हैं। Agent runtime को restricted outbound access मिलता है, इसलिए वह arbitrary direct calls नहीं कर सकता। Action gateway को approved external services तक पहुँचने के लिए आवश्यक सीमित network access मिलता है। Gateway credentials और approvals संभालता है। Network layer escape routes रोकती है।

सारे controls proxy में इसलिए न डालें कि वह पहले से network path में है। इससे अक्सर application-level authorization URL patterns में चली जाती है और secret handling traffic relay करने के लिए बने interception service पर आ जाती है। Deployment diagram साफ दिखता है, लेकिन operational boundary खराब हो जाती है।

Plausible proxy design handoff पर fail हो सकता है

एक development environment में चल रहे coding agent को issue tracker query करना, deployment बनाना और SSH से build host inspect करना है। Team HTTPS proxy install करके ये environment variables configure करती है:

HTTPS_PROXY=http://proxy.internal:8080
HTTP_PROXY=http://proxy.internal:8080

Proxy issue tracker के लिए API token inject करता है। Team token को सुरक्षित मानती है, क्योंकि agent उसे configuration file से नहीं पढ़ता।

अब agent उसी host के administrative endpoint को request भेजता है। Proxy permitted hostname देखता है और वही token inject करता है। अगर rule endpoint semantics नहीं समझता, तो उसने indirect interface के ज़रिए agent को token की पूरी authority दे दी।

Team path allowlists से इसे ठीक करने की कोशिश करती है। जल्द ही pagination, attachment upload endpoints, redirects, alternate API versions और write के बाद read वाले workflow के लिए exceptions चाहिए। अब proxy ऐसी application policy ढो रहा है जो service API बदलते ही बदलती है।

इस बीच एक tool HTTPS_PROXY का सम्मान नहीं करता। दूसरा private certificate store इस्तेमाल करता है और TLS interception fail हो जाती है। तीसरा अलग CA bundle वाला container है। काम जारी रखने के लिए कोई bypass जोड़ देता है। यही bypass बाद में prompt-injected agent या compromised dependency का चुना हुआ रास्ता बन सकता है।

SSH अंत में mismatch दिखाता है। Proxy tunnel में SSH private key inject नहीं कर सकता। Team key को «कुछ समय के लिए» agent environment में mount करती है या ऐसा agent process शुरू करती है जिसे local SSH agent तक पहुँच है। अब system वह property खो चुका है जिसे बचाने के लिए design बनाया गया था।

Action-execution design handoff बदल देता है। Agent local stdio connection के ज़रिए MCP tool invoke करता है। Executor API credential या SSH key अपने पास रखता है, external connection बनाता है और outcome लौटाता है। MCP tool request को transport करता है, agent को secrets का free pass नहीं देता। Model Context Protocol specification tool interaction boundary परिभाषित करती है, लेकिन credential custody implementer की जिम्मेदारी रहती है।

यह design prompt injection समाप्त नहीं करता। Malicious instruction अब भी agent को ऐसी harmful action मांगने के लिए मना सकती है जिसकी उसे अनुमति है। लेकिन failure उस authority तक सीमित रहता है जिसे gateway expose करता है, operator के पास approve या deny करने का point रहता है और हर सफल tool call reusable secret exfiltrate करने का अवसर नहीं बनती।

Architecture उस authority से चुनें जिसे आप सौंपना नहीं चाहते

उस sentence से शुरुआत करें जिसे सच करना है। अगर वह है «process केवल approved destinations तक पहुँच सकता है», तो path में network control रखें। अगर वह है «process के पास यह API key या SSH private key कभी नहीं होनी चाहिए», तो किसी दूसरे process से authenticated action करवाएँ। अगर वह है «हर बार credential के उपयोग पर human approval चाहिए», तो approval executor के remote service call से पहले होना चाहिए।

फिर bypasses के विरुद्ध claim जाँचें। क्या agent token वाला environment variable पढ़ सकता है? क्या वह credential file, local SSH agent, browser session, cloud metadata service या unrestricted outbound network तक पहुँच सकता है? क्या वह generic HTTP tool से उसी injected credential के साथ कोई अलग path call कर सकता है? TLS interception fail होने पर क्या operator certificate validation बंद या direct route चालू कर देगा?

एक छोटी review में चार सवाल होने चाहिए:

1. Memory में हर secret किस process के पास है?
2. Authenticated connection कौन-सा process बनाता है?
3. Remote service को देखने से पहले human call को कहाँ रोक सकता है?
4. कौन-सा record किसी agent run को पूरी हुई operation से जोड़ता है?

अगर पहले दो सवालों का जवाब «agent» है, तो कोई proxy rule basic risk नहीं बदलता। अगर जवाब «proxy» है, तो तय करें कि क्या आप TLS interception और application policy चलाने के लिए तैयार हैं। अगर जवाब «credential-holding executor» है, तो सुनिश्चित करें कि उसका action surface छोटा हो और agent उसे bypass न कर सके।

Sallyport macOS पर इसी आखिरी arrangement के लिए बना है: उसका sp mcp shim MCP-capable agents को HTTP और SSH actions मांगने देता है, जबकि app secrets अपने पास रखकर actions चलाता है। यह MITM proxy नहीं है और इसे ऐसा नहीं बताया जाना चाहिए।

पहला implementation task अक्सर आकर्षक नहीं होता: agent runtime से direct credentials हटाना। जब तक यह सच नहीं होता, approvals और traffic logs ऐसे process के चारों ओर guardrails हैं जिसके पास keys अब भी मौजूद हैं।