AI agents के लिए HTTP या SSH: blast radius सीमित करें

AI एजेंट को HTTP का इस्तेमाल तब करना चाहिए जब कोई service अपेक्षित कार्रवाई को एक संकीर्ण, authenticated operation के रूप में व्यक्त कर सके। SSH का इस्तेमाल तभी करें जब काम के लिए ऐसी machine-level capability चाहिए जिसे API उपलब्ध नहीं करा सकता। तब भी ऐसा account और command surface इस्तेमाल करें जो उसी एक काम के लिए बनाया गया हो।

आम गलती यह है कि दोनों transports की तुलना इस तरह की जाती है जैसे एक आधुनिक हो और दूसरा पुराना। असली फैसला इससे अलग है। HTTP और SSH केवल delivery mechanisms हैं। उनसे जुड़ा authority स्तर, स्वीकार किए जाने वाले inputs और सुरक्षित रखे गए evidence यह तय करते हैं कि एजेंट सीमित बदलाव कर सकता है या administrator के privileges के साथ production host में कहीं भी घूम सकता है।

मैंने टीमों को एक operational fact के लिए तथाकथित temporary SSH key जारी करते देखा है। एक महीने बाद वही key deployment secrets पढ़ सकती थी, internal services तक पहुंच सकती थी और interactive shell चला सकती थी। किसी ने कोई बड़ा security decision नहीं लिया था। सबने बस सुविधाजनक default स्वीकार कर लिया था। इसी तरह छोटा काम बड़ा blast radius बना लेता है।

Interface तय करता है कि एजेंट को कितना authority मिलेगा

AI एजेंट के लिए HTTP या SSH का सवाल protocol की पसंद से ज्यादा capability के आकार का सवाल है। HTTP call भी व्यापक और खतरनाक हो सकती है, जबकि SSH connection को कड़ाई से सीमित किया जा सकता है। व्यवहार में APIs authority सीमित करने की बेहतर जगह देती हैं, क्योंकि endpoint, method, request schema और token permission मिलकर एक operation का वर्णन कर सकते हैं।

मान लीजिए निर्देश है: failed worker को restart करना। POST /workers/worker-17/restart जैसा HTTP endpoint target और अनुमत verb साफ बताता है। Service unknown worker को अस्वीकार कर सकती है, restart की अनुमति वाली role मांग सकती है और token से जुड़ा record लिख सकती है। ssh host sudo systemctl restart worker जैसी shell instruction के पीछे authority कहीं व्यापक होती है। यह account, sudo configuration, unit naming rules, shell parsing और host state के सही होने पर निर्भर करती है।

इसका मतलब API अपने-आप सुरक्षित नहीं है। ऐसा token जो हर endpoint call कर सकता है, दूसरे tokens बना सकता है या हर record export कर सकता है, साफ-सुथरे URL के पीछे बड़ा blast radius रखता है। इसी तरह allowlist से fixed worker identifier लेने वाला forced SSH command किसी खराब administrative API से छोटा हो सकता है।

किसी भी tool को जोड़ने से पहले यह जांच करें: एक वाक्य में सबसे छोटी सफल कार्रवाई लिखें, फिर बताएं कि एजेंट unexpected input दे तो वही credential और क्या-क्या कर सकता है। दूसरे हिस्से को समझा नहीं सकते तो आपने अभी authority मापी ही नहीं है।

संकीर्ण interface की चार विशेषताएं होती हैं:

• यह पूरे environment के बजाय targets के छोटे set का नाम लेता है।
• यह ऐसे structured input स्वीकार करता है जिसकी grammar validate की जा सके।
• यह ऐसी adjacent actions को अस्वीकार करता है जिनकी मौजूदा task को जरूरत नहीं है।
• यह ऐसा record बनाता है जिससे बाद में कोई दूसरा व्यक्ति परिणाम समझा सके।

Credential कितने समय तक जीवित रहेगी, यह भी task से तय होना चाहिए। एक run के लिए इस्तेमाल की गई credential चुपचाप permanent access में नहीं बदलनी चाहिए, सिर्फ इसलिए कि उसे हटाना याद नहीं रहा। Calendar reminder से बेहतर सीमा process lifetime है।

HTTP उपयोगी सीमाएं तभी देता है जब API उन्हें लागू करे

HTTP एजेंट का blast radius तभी छोटा करता है जब service resource और operation स्तर पर authorization जांचती है। Bearer token केवल carrier है। उसकी सुरक्षा इस बात पर निर्भर करती है कि token मिलने के बाद server क्या verify करता है।

RFC 9110 HTTP methods को उनके semantics के आधार पर समझाता है, जिसमें safe methods और idempotent methods का अंतर भी शामिल है। यह भाषा retries और intent समझने में मदद करती है, permission नहीं देती। GET sensitive material उजागर कर सकता है। PUT idempotent होते हुए भी production setting overwrite कर सकता है। Method names को client behavior के संकेत मानें, permission model नहीं।

एजेंट को token देने से पहले service owner से पूछें:

• यह token किन exact paths और methods को call कर सकता है?
• क्या service हर resource पर access जांचती है या केवल broad collection पर?
• क्या token credentials बना, permissions बदल या exports शुरू कर सकता है?
• क्या किसी identifier के जरिए request दूसरे tenant, project या environment में जा सकती है?
• क्या service credential identity और request outcome रिकॉर्ड करती है?

यह असहज सवाल भी पूछें कि क्या read permission task की जरूरत से अधिक जानकारी लीक करती है। Repository API read token से source, pull request comments, build logs और configuration मिल सकती है। गलत जगह रखा गया एक configuration value read access को secret access के बराबर बना सकता है। यदि एजेंट को केवल एक deployment की state चाहिए, तो वही state लौटाने वाला endpoint दें। General repository token देकर इसे least privilege न कहें।

Request schema scope जितना ही महत्वपूर्ण है। इन दो requests की तुलना करें:

POST /v1/releases/release-42/promote HTTP/1.1
Authorization: Bearer token-value
Content-Type: application/json

{\"environment\":\"staging\"}

POST /v1/admin/execute HTTP/1.1
Authorization: Bearer token-value
Content-Type: application/json

{\"operation\":\"promote\",\"arguments\":{\"environment\":\"staging\"}}

दोनों release promote कर सकती हैं। पहली request server के लिए operation समझने की गुंजाइश कम छोड़ती है। दूसरी एक administrative dispatcher बना देती है। Dispatchers में exceptions जुड़ते हैं, फिर arbitrary operation names और अंत में ऐसा token आता है जिसकी असली authority बताना मुश्किल होता है। Agent use के लिए मैं इनसे बचता हूं, जब तक server strict operation allowlist और हर operation के argument schema को अलग-अलग validate न करे।

जहां service अनुमति दे, अलग verbs के लिए अलग credentials इस्तेमाल करें। Observation को mutation से अलग रखें और routine mutation को identity या billing changes से अलग करें। Setup का काम बढ़ता है, लेकिन authorization failures का अर्थ साफ हो जाता है। Denial बताती है कि task definition और credential मेल नहीं खाते। Broad token हर गलती को सफल request बना देता है, जिसकी जांच बाद में करनी पड़ती है।

Long-lived API secret को agent prompt, environment file, repository setting या tool configuration में न रखें। समस्या केवल output में accidental disclosure नहीं है। Agents अपना environment जांचते हैं, tools diagnostics जमा करते हैं और plaintext access वाला process उस secret को किसी दूसरी destination पर भेज सकता है। Secret को agent process से बाहर रखें और इसके बजाय परिणामी action को authorize करें।

SSH host को खुला छोड़ देता है, जब तक आप shell को जानबूझकर न हटाएं

SSH का default blast radius बड़ा होता है, क्योंकि interactive account files देख सकता है, programs चला सकता है, configuration बदल सकता है, tunnels खोल सकता है और account को उपलब्ध हर network path का इस्तेमाल कर सकता है। आपका इरादा केवल एक command चलाने का हो, फिर भी normal shell पाने वाले account पर कोई सीमा नहीं लगती।

RFC 4251 SSH को secure remote login और अन्य secure network services के protocol के रूप में बताता है। इसमें sessions, channels, port forwarding और कई authentication methods जानबूझकर शामिल हैं। Administrators के लिए ये capabilities उपयोगी हैं। ऐसे autonomous actor के लिए ये खराब शुरुआती बिंदु हैं जिसे एक सीमित maintenance operation करना है।

Command खुद भी महत्वपूर्ण है। systemctl restart service-name सीमित दिखती है, लेकिन उसके आसपास की authority देखें: account किन units को restart कर सकता है, क्या unit files privileged hooks चला सकती हैं, क्या account उन्हें edit कर सकता है और क्या service names validated input से आती हैं। Operational दिखने वाली command उस service के जरिए deployment credentials, mounted volumes या internal control plane तक पहुंच सकती है जिसे वह restart करती है।

यदि SSH जरूरी है, तो बंद input grammar वाला छोटा remote program बनाएं। Program को known request fields को known operations से map करना चाहिए। Request को shell command में concatenate न करें। File paths, hostnames, regular expressions, shell snippets या environment assignments तभी स्वीकार करें जब program हर value को tight allowlist से validate करे।

Restricted authorized_keys entry इस सीमा को साफ कर सकती है। यह pattern एक receiver program को force करता है और कई ऐसी SSH सुविधाएं हटाता है जिनकी agents को सामान्यतः जरूरत नहीं होती:

command=\"/usr/local/libexec/agent-maintenance\",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexample agent-runner

यह line अपने-आप authorization हल नहीं करती। agent-maintenance program को unknown subcommands अस्वीकार करने और arguments validate करने होंगे। Operating account के पास केवल वही file, service और network permissions होनी चाहिए जिनकी program को जरूरत है। यदि program sudo चलाता है, तो sudo rule में fixed executable का नाम हो और editor, interpreter, wildcard या shell escape की अनुमति न हो।

OpenSSH का authorized_keys manual command=, no-pty और forwarding restrictions का विवरण देता है। इन options को seatbelt समझें, vehicle नहीं। ये आसान escape routes हटाते हैं, लेकिन overprivileged account के रूप में चलने वाला forced command फिर भी overprivileged access रखता है।

Remote input protocol साधारण JSON हो सकता है:

{\"action\":\"restart_worker\",\"worker\":\"worker-17\",\"request_id\":\"8b4f3c2a\"}

Receiver को केवल restart_worker और अपनी inventory में मौजूद worker names स्वीकार करने चाहिए। उसे execute करने से पहले event लिखना चाहिए, बिना shell के fixed program चलाना चाहिए, exit status capture करना चाहिए और completion event लिखना चाहिए। यदि agent worker-17; cat /etc/shadow भेजता है, तो validation को पूरा value अस्वीकार करनी चाहिए, इससे पहले कि operating system की कोई command चले।

सिर्फ इसलिए एजेंट को SSH access न दें कि कोई व्यक्ति वही काम SSH से करता है। इंसान unusual prompt पहचान सकता है, hostname mismatch देख सकता है और अजीब परिणाम पर रुक सकता है। Agents के लिए restriction interface में पहले से मौजूद होनी चाहिए।

Logging को attempted action और resulting state दोनों समझाने चाहिए

request failed कहने वाली log line audit record नहीं है। Client library debug करने में यह पर्याप्त हो सकती है, लेकिन यह नहीं बता सकती कि agent ने कुछ बदला, किसी व्यक्ति ने उसे approve किया या incident के बाद क्या जांचना है।

HTTP के लिए agent run identity, credential identity या label, destination host, method, normalized path, request body का सुरक्षित रूप, response status, request correlation value, start time और completion result capture करें। Event action boundary से बाहर जाने से पहले secrets और sensitive fields redact करें। Evidence बचाने के लिए Authorization header log करना खुद breach पैदा करना है।

SSH के लिए host identity, remote account, forced command name, validated arguments, source process identity, exit status, standard error classification और remote operation identifier रिकॉर्ड करें। केवल raw command string कमजोर evidence है, क्योंकि उसमें quoting behavior छिप सकता है और यह नहीं पता चलता कि receiver ने कौन-से arguments स्वीकार किए।

Event sequence में intent और effect अलग-अलग दिखने चाहिए। यह shape दोनों transports के लिए काम करती है:

{\"event\":\"authorization_granted\",\"run\":\"r-204\",\"action\":\"restart_worker\",\"target\":\"worker-17\"}
{\"event\":\"action_started\",\"run\":\"r-204\",\"transport\":\"ssh\",\"operation\":\"restart_worker\",\"request_id\":\"8b4f3c2a\"}
{\"event\":\"action_finished\",\"run\":\"r-204\",\"outcome\":\"success\",\"remote_status\":0,\"request_id\":\"8b4f3c2a\"}

यदि action_started के बाद connection टूट जाए, तो failure गढ़ने के बजाय outcome:\"unknown\" लिखें। यह सही अगला कदम मजबूर करता है: retry करने से पहले remote state पूछें। बाद की जांच भी ईमानदार रहती है।

सामान्य logs में custody की समस्या होती है। Host administrator या पर्याप्त access पाने वाला process उन्हें truncate, rewrite या remove कर सकता है। Central collection मदद करती है, लेकिन collector या network path विफल होने पर gaps फिर भी रह सकते हैं। यदि log को agent की कार्रवाई पर विवाद सुलझाना है, तो integrity checks वाले append-oriented records रखें और action path के बाहर उनकी जांच करें।

Hash chain में हर event पिछले event के digest को शामिल करता है, जिससे edits का पता चल सकता है। यह साबित नहीं करता कि recorder ने हर event देखा था और न ही अविश्वसनीय clock को भरोसेमंद बनाता है। इसकी सीमा महत्वपूर्ण है। Chain एक संकीर्ण लेकिन उपयोगी सवाल का जवाब देती है: क्या बाद में किसी ने सुरक्षित रखे गए sequence में बदलाव किया?

Sallyport agent runs के लिए Sessions journal और individual calls के लिए Activity journal रखता है। दोनों encrypted hash-chained audit log से बनाए जाते हैं। इसका sp audit verify command ciphertext पर offline chain जांचता है। जब evidence देखना हो और उससे पहले secrets उजागर न करने हों, तो यही सही गुण है।

Timeouts unknown outcomes बनाते हैं, failed actions नहीं

Network failures में सावधान टीमें भी duplicate changes कर बैठती हैं। Client request भेजता है, remote side काम कर देती है और response गायब हो जाता है। Agent timeout देखता है और action फिर चला देता है। SSH में भी ऐसा हो सकता है, जब remote command शुरू हो चुकी हो लेकिन client को exit status मिलने से पहले connection टूट जाए।

Agent को transport error को mutation retry करने की अनुमति न दें। पहले operation को classify करें।

Operation तभी idempotent है जब वही request दोहराने पर अतिरिक्त effect के बिना वही intended state मिले। Named worker की desired state को running करना इस परिभाषा में आ सकता है। Payment बनाना, record append करना, secret rotate करना या process restart करना अक्सर ऐसा नहीं होता। पहला attempt recovery sequence शुरू कर चुका हो तो दोबारा restart उसे बाधित कर सकता है।

API support करे तो idempotency identifier इस्तेमाल करें। Service को completed effect के साथ identifier रखना चाहिए और duplicate पर पिछला result लौटाना चाहिए। Server केवल log में client-supplied request identifier लिखे, तो duplication नहीं रुकती।

Remote commands के लिए status operation जोड़ें जो सटीक सवाल का जवाब दे सके। restart_worker के बाद response न मिले तो worker की current generation, last restart request identifier और health state पूछें। यदि receiver execution से पहले request identifier रखता है और status के साथ उसे लौटाता है, तो retry करने वाला agent जान सकता है कि request पहले ही चल चुकी है।

यह failure sequence इसकी अहमियत दिखाता है:

1. Agent request identifier 8b4f3c2a के साथ worker-17 को restart करने की request भेजता है।
2. Receiver identifier दर्ज करता है और worker restart करता है।
3. Worker रुकते समय SSH connection टूट जाता है।
4. Agent दोबारा restart करने के बजाय status पूछता है।
5. Status बताता है कि वही identifier अभी progress में है, इसलिए agent इंतजार करता है और health जांचता है।

Retry budget अस्पष्ट outcomes ठीक नहीं करता। गलत retry decision के बाद यह केवल damage सीमित करता है। State observation खुद decision को सही बनाती है।

HTTP में एक और खतरा है: service asynchronous work पूरा होने से पहले success status लौटा सकती है। 202 Accepted का अर्थ है कि server ने काम बाद में करने के लिए स्वीकार किया है, यह नहीं कि मांगी गई state मौजूद है। Operation resource या status endpoint रखें और agent को task के लिए जरूरी terminal result तक इंतजार कराएं।

SSH में इसका समान trap तब होता है जब command work को background में भेजकर zero exit के साथ समाप्त हो जाती है। Launcher का zero exit code completed maintenance action का प्रमाण नहीं है। Receiver को completion तक इंतजार कराएं या ऐसा durable operation identifier लौटाएं जिसे agent बाद में query कर सके।

Shell command अपने text से अधिक authority छिपाती है

सबसे छोटी remote command में अक्सर सबसे अधिक छिपी authority होती है। Shell expansion, inherited environment, current directories, configuration files और executable search paths, सब यह तय करते हैं कि क्या चलेगा। Host context के कारण agent ऐसा text बना सकता है जो देखने में harmless हो, लेकिन unexpected result दे।

इस pattern से बचें:

ssh ops@host \"deploy $branch $environment\"

भले ही caller आज variables को सही तरह quote करता हो, remote shell command language parse करती है। Deployment script अपनी expansions कर सकती है। Branch name source location चुन सकता है। Environment name credentials या target cluster चुन सकता है। Input bounded है, यह कहने से पहले हर layer की जांच करें।

Structured input पढ़ने वाला receiver इस्तेमाल करें और fixed executable को सीधे invoke करें। अधिकांश languages में इसका अर्थ argument array है, sh -c को string देने का नहीं। Receiver को user-facing target name और host-specific identifier के बीच mapping अपने पास रखनी चाहिए। Agent को filesystem paths या service unit names discover न करने दें।

यही चिंता HTTP parameters पर भी लागू होती है। /files?path=... structured दिख सकता है, जबकि server value को filesystem operation में भेज रहा हो। API तभी risk घटाती है जब server meaning validate करे, केवल command parsing को URL के पीछे स्थानांतरित करने से नहीं।

Credential कहां रखी जाती है, इससे compromised agent process का परिणाम बदलता है। यदि agent SSH private key या API token local रूप से रखता है, तो उस material को पढ़ सकने वाला कोई भी process बाद में कार्रवाई कर सकता है। अलग action boundary secret अपने पास रख सकती है और remote service को केवल request तथा authorization decision दे सकती है। अंतर स्पष्ट है: secret को model output से छिपाना और secret को agent process से बाहर रखना एक ही बात नहीं है।

Sallyport HTTP credentials और SSH keys के लिए यही तरीका अपनाता है। App उन्हें encrypted vault में रखती है और credential material agent को देने के बजाय requested action चलाती है। इससे खतरनाक request सुरक्षित नहीं हो जाती, इसलिए targets सीमित करना और approvals की जांच करना फिर भी जरूरी है।

लिखित capability comparison के आधार पर transport चुनें

लंबी risk workshop के बिना भी उचित फैसला किया जा सकता है। Proposed HTTP call की एक row और proposed SSH command की एक row लिखें, फिर दोनों में वही facts भरें। read access या maintenance access जैसे अस्पष्ट labels पर्याप्त नहीं हैं।

यह पांच हिस्सों वाली तुलना करें:

1. Exact result लिखें, जैसे «service A की deployment state प्राप्त करना» या «failed health check के बाद worker-17 को restart करना»।
2. हर reachable target का नाम दें: API collections, projects, hosts, services, files और network destinations।
3. बताएं कि intended result के बाहर वही credential या account कौन-सी mutations कर सकता है।
4. Timeout, rejection या apparent success के बाद उपलब्ध evidence का वर्णन करें।
5. Approval boundary तय करें: one run, one call या fixed identity वाली preapproved routine।

HTTP चुनें यदि उसकी row छोटा target set, संकीर्ण operation और अधिक स्पष्ट record दिखाती है। SSH चुनें यदि remote receiver यह काम API से बेहतर कर सकता है या जरूरी host operation के लिए API मौजूद नहीं है। दोनों में से कोई भी पर्याप्त संकीर्ण न हो तो agent को अभी न जोड़ें। पहले missing endpoint या receiver बनाएं।

यह तुलना एक आम खराब सलाह भी पकड़ लेती है: «reads के लिए SSH और writes के लिए APIs इस्तेमाल करें।» यह समझदारी भरी लगती है, क्योंकि shell access operational और API calls transactional महसूस होती हैं। लेकिन host पढ़ने से credentials, source, customer data और topology उजागर हो सकते हैं, जबकि carefully scoped API mutation ठीक एक desired state बदल सकती है। Read और write पर्याप्त risk categories नहीं हैं। Reachable data और reachable side effects असली categories हैं।

Build failures diagnose करने वाला agent job status के लिए HTTP endpoint, bounded log window पाने के लिए API call और केवल उस एक host पर remote receiver इस्तेमाल कर सकता है जहां किसी खास repair की जरूरत हो। Jobs को अलग करने से interfaces बढ़ते हैं, लेकिन routine diagnostic task में standing shell credential रखने की जरूरत नहीं रहती, सिर्फ इसलिए कि किसी दुर्लभ repair के लिए वह कभी-कभार चाहिए।

Approval गलत कार्रवाई की लागत के अनुसार होनी चाहिए

Approval तब सबसे उपयोगी होती है जब वह ऐसी boundary पर दिखे जिसे व्यक्ति समझ सके। हर harmless status read के लिए prompt दिखाने से लोग बिना पढ़े click करना सीख जाते हैं। हर future executable को cover करने वाली broad approval meaningful review हटा देती है।

Per-run approval तब लें जब नया agent process पहली बार action मांगता है और उसकी identity साफ दिखाई जा सकती है। व्यक्ति requesting executable की तुलना उस काम से कर सकता है जिसे उसने शुरू करने की उम्मीद की थी। Agent के unexpected व्यवहार पर run revoke करें और action record से उसकी पिछली calls जांचें।

Irreversible या महंगे side effects के लिए per-call approval लें: credential rotation, deletion, production promotion, account changes और वे सभी actions जिनका target agent dynamically चुन सकता है। Approval prompt में destination और operation को सामान्य भाषा में लिखें। «Execute tool request» reviewer को लगभग कुछ नहीं बताता।

हर exception के लिए विशाल rule language बनाकर इस judgment को बदलने की कोशिश न करें। फिर टीमों को दूसरा programming environment maintain करना पड़ता है, जिसकी edge cases उसी चीज को authorize कर देती हैं जिसे रोकना था। Fixed controls का छोटा set inspect करना आसान है: vault lock state, run authorization और जरूरत हो तो sensitive credential के हर use की approval।

Approval unlimited authority वाली credential की भरपाई नहीं करती। यह action machine से बाहर जाने से पहले इंसान को उसे रोकने का अवसर देती है। Underlying service को अपनी authorization खुद लागू करनी होगी और audit record को approval के बाद वास्तव में क्या हुआ, यह सुरक्षित रखना होगा।

पहले incident से पहले remote action boundary बनाएं

आमतौर पर पहला सुधार अधिक जटिल agent prompt नहीं होता। Broad credential को ऐसी action boundary से बदलें जिसमें स्पष्ट input grammar, सीमित target set, timeout plan और दूसरे operator द्वारा verify किया जा सकने वाला evidence हो।

HTTP task के लिए service owner से ऐसी endpoint और credential मांगें जिसकी permissions उसी एक action से मेल खाती हों। Rejected paths और methods को successful calls जितनी ही गंभीरता से test करें। SSH task के लिए dedicated account बनाएं, interactive features बंद करें, receiver program force करें और malformed input को उसके विरुद्ध test करें। Tests उसी route से चलाएं जिसका agent इस्तेमाल करेगा, क्योंकि network access और identity checks administrator के laptop से अलग हो सकते हैं।

फिर उस failure को test करें जिसे कोई simulate नहीं करना चाहता: remote work पूरा करें और caller तक response पहुंचने से पहले connection काट दें। यदि retained record और remote state देखकर agent तय नहीं कर सकता कि wait, query या retry करना है, तो दबाव में design duplicate work करेगा।

इन properties पर जोर देने के बाद protocol choice सीधी हो जाती है। वही interface चुनें जो आपके नाम दिए जा सकने वाले सबसे छोटे capability set की अनुमति दे, failure के बाद भरोसेमंद जवाब दे और कार्रवाई का ऐसा record छोड़े जो किसी की terminal session की याददाश्त पर निर्भर न हो।