सिंगल-प्रोसेस बनाम डेमन-आधारित एजेंट सिक्योरिटी टूल

एक प्रोसेस डायग्राम किसी सिक्योरिटी प्रोडक्ट को या तो भरोसा जगाने वाली सरल चीज़ या बहुत गंभीर व्यवस्था जैसा दिखा सकता है। इनमें से कोई प्रतिक्रिया यह नहीं बताती कि कोई स्वायत्त कोडिंग एजेंट क्रेडेंशियल का गलत इस्तेमाल कर सकता है या नहीं, किसी अनचाही लोकल सर्विस से बात कर सकता है या नहीं, या क्रैश के बाद कोई कार्रवाई बिना रिकॉर्ड के छोड़ सकता है या नहीं।

उपयोगी तुलना ठोस होती है: भरोसे की सीमाएं गिनें, देखें कि उनके बीच कौन से इंटरफेस जा रहे हैं, और किसी सीक्रेट को स्टोरेज से बाहर जाने वाले अनुरोध तक ट्रैक करें। एक सिंगल एप्लिकेशन प्रोसेस लोकल हिस्सों की संख्या घटा सकता है। डेमन प्रिविलेज अलग कर सकता है या कई क्लाइंट के बीच सर्विस को चालू रख सकता है। दोनों डिज़ाइन तब विफल होते हैं जब उनके लेखक प्रोसेस अलगाव को authorization समझ लेते हैं।

प्रोसेस की संख्या सिक्योरिटी सीमा तय नहीं करती

सिंगल-प्रोसेस डिज़ाइन में यूज़र इंटरफेस, क्रेडेंशियल वॉल्ट, मंजूरी की स्थिति, अनुरोध की जांच, नेटवर्क कार्रवाई और लॉगिंग एक ही address space में रहते हैं। इसके अपने हिस्सों के बीच कोई लोकल क्लाइंट सॉकेट नहीं होता, अलग सर्विस रजिस्ट्रेशन संभालने की जरूरत नहीं होती और ऐसा प्रोटोकॉल भी नहीं होता जिससे एक लोकल प्रोसेस दूसरे को कमांड दे। इससे attack surface सचमुच कम हो सकता है।

लेकिन इससे एक बड़ा trust domain बनता है। अगर हमलावर उस प्रोसेस के भीतर code execution हासिल कर ले, तो वह वहां से उपलब्ध हर घटक तक पहुंच सकता है। Memory corruption, दुर्भावनापूर्ण plugin loading, असुरक्षित अपडेट व्यवहार या बहुत खुला scripting interface खास तौर पर गंभीर हो जाते हैं, क्योंकि वॉल्ट और executor सामान्य एप्लिकेशन कोड के ठीक बगल में होते हैं।

डेमन-आधारित डिज़ाइन इन कामों को बांटता है। डेस्कटॉप ऐप या command line client किसी बैकग्राउंड सर्विस को अनुरोध भेजता है। सर्विस सीक्रेट रख सकती है और नेटवर्क कॉल कर सकती है, जबकि क्लाइंट मंजूरियां दिखाता है और परिणाम लेता है। इससे compromised client की क्षमता सीमित हो सकती है, लेकिन तभी जब डेमन उन अनुरोधों को ठुकराए जिन्हें क्लाइंट करने का अधिकार नहीं रखता।

आर्किटेक्चर की चर्चाओं में यह शर्त अक्सर छूट जाती है। एक यूज़र अकाउंट तक सीमित Unix domain socket केवल transport access है। इससे यह साबित नहीं होता कि कॉल करने वाला सही एजेंट या मंजूर किया गया एप्लिकेशन है। उस यूज़र के नाम से चलने वाला हर प्रोसेस socket खोल सकता है। अगर डेमन किसी भी लोकल peer से «credential X को URL Y पर इस्तेमाल करो» जैसा अनुरोध स्वीकार करता है, तो दुर्भावनापूर्ण editor extension, shell script या compromised agent भी वही कार्रवाई मांग सकता है।

इन तीन विचारों को अलग रखें:

• Process boundary memory को अलग करती है।
• Privilege boundary compromise के बाद कोड की क्षमता सीमित करती है।
• Authorization boundary तय करती है कि कौन सा caller कौन सी कार्रवाई मांग सकता है।

टीमें अक्सर पहले को बाकी दो का प्रमाण मान लेती हैं। ऐसा नहीं है। एक ही यूज़र के रूप में चल रहे दो प्रोसेस और बिना authentication वाला IPC channel अलग heaps तो रखते हैं, लेकिन authorization domain फिर भी एक हो सकता है।

सिंगल प्रोसेस को IPC authorization की समस्या नहीं आती, क्योंकि उसके internal calls लोकल सर्विस सीमा पार नहीं करते। फिर भी किसी कार्रवाई को मंजूर करने से पहले बाहरी agent session की पहचान करनी जरूरी है। डेमन यह पहचान समस्या दो बार जोड़ता है: एक बार client endpoint पर और अक्सर फिर किसी administrative endpoint पर।

लोकल socket ऐसा API है जिसे hostile code call कर सकता है

डेमन के समर्थक अक्सर सही तौर पर कहते हैं कि सर्विस केवल localhost या Unix socket पर सुनती है। जो बात छूट जाती है, वह यह है कि अधिकांश agent integrations लोकल कोड के रूप में चलती हैं। Coding agent, terminal, editor, build scripts, package hooks और browser helpers एक ही मशीन साझा करते हैं।

लोकल IPC endpoint को छोटे network API की तरह संभालें। Message formats को कड़ा रखें। जहां protocol इसकी अनुमति देता हो, अज्ञात fields अस्वीकार करें। हर अनुरोध को caller identity और short-lived session से जोड़ें। Request size, concurrency और destination choices पर सीमाएं लगाएं। सफल अनुरोधों के साथ अस्वीकार किए गए अनुरोध भी लॉग करें, क्योंकि बार-बार होने वाली denials यह बता सकती हैं कि कोई integration तय रास्ते को पार करने की कोशिश कर रहा है।

macOS पर किसी टूल के «केवल लोकल» होने के दावे पर भरोसा करने से पहले उसे जांचें:

ps -axo pid,ppid,user,command | grep -i '[a]gent\|[d]aemon'
lsof -nP -iTCP -sTCP:LISTEN
launchctl print gui/$(id -u) 2>/dev/null | grep -i -C 2 'agent\|vault\|security'

जब कोई प्रोसेस TCP पर सुन रहा हो, तो दूसरा कमांड आम तौर पर इस तरह के columns दिखाता है:

COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
service  4128 sam     9u  IPv4 0x...            0t0  TCP 127.0.0.1:48120 (LISTEN)

lsof से कोई output न मिलना यह साबित नहीं करता कि टूल में IPC नहीं है। Unix sockets उस TCP query में दिखाई नहीं देते। Application support directories, temporary directories और socket paths के लिए service documentation देखें। फिर ls -l से permissions जांचें और पूछें कि क्या आपके account के नाम से चल रहा कोई दूसरा प्रोसेस connect कर सकता है।

Apple का launchd.plist manual KeepAlive को उन conditions के समूह के रूप में बताता है जिनमें launchd किसी job को restart करता है। संचालन के लिहाज से यह उपयोगी है, लेकिन इससे सिक्योरिटी की जिम्मेदारी भी आती है। Restart होने वाली सर्विस को locked state, session state और audit state सही तरीके से वापस लानी होगी। «यह अपने आप वापस आ जाती है» इस सवाल का जवाब नहीं है कि restart के बाद पहले सेकंड में वह क्या स्वीकार करती है।

अच्छा डेमन caller identity को client की धारणा पर छोड़ने के बजाय protocol का हिस्सा बनाता है। सही तरीका operating system पर निर्भर करता है। जिन platforms पर लोकल socket के peer credentials मिल सकते हैं, उनका उपयोग करें। जहां code-signing information उपलब्ध हो, session देने से पहले उसे जांचें। Process name, JSON में भेजा गया PID या caller द्वारा दिया गया path identity के रूप में स्वीकार न करें। तीनों को आसानी से नकली बनाया जा सकता है या जांच के समय तक वे पुराने हो सकते हैं।

Startup behavior तय करता है कि जरूरत के समय सुरक्षा मौजूद होगी या नहीं

सिंगल एप्लिकेशन प्रोसेस आम तौर पर यूज़र के app खोलने पर शुरू होता है। उसकी संवेदनशील स्थिति का जीवनचक्र सीधा होता है: app शुरू होता है, यूज़र unlock करता है, मंजूर sessions चलते हैं और app बंद या crash होने पर access खत्म हो जाता है। इसे समझाना और जांचना आसान है।

इसकी कीमत availability है। जब app बंद हो, अभी शुरू हो रहा हो, locked हो या system permission prompt पर अटका हो, तब command line agent gateway इस्तेमाल नहीं कर सकता। मानव-नियंत्रित credential gateway के लिए यह बिल्कुल सही व्यवहार हो सकता है। लेकिन अगर काम reboot के बाद unattended चलना है और product के पास authority वापस पाने का सुरक्षित तरीका नहीं है, तो यह खराब मेल है।

डेमन आम तौर पर login, मांग या boot पर शुरू होता है। हर विकल्प threat model बदलता है। Login पर चलने वाली service यूज़र के key store और desktop session का इंतजार कर सकती है। Boot service तब चल सकती है जब यूज़र किसी चीज़ को मंजूर न कर सके। On-demand service idle exposure घटा सकती है, लेकिन उसकी पहली request initialization के साथ race नहीं करनी चाहिए।

मैंने इस failure का खराब रूप देखा है: UI धीरे शुरू होता है, background service पहले ही requests स्वीकार कर रही होती है और service «approval state लोड नहीं हुई» को «approval की जरूरत नहीं» के बराबर मान लेती है। Developers startup error से बचने के लिए यह branch लिखते हैं। Attackers और flaky automation को इससे कोई फर्क नहीं पड़ता कि यह branch क्यों मौजूद है।

State machine लिखकर रखें। उसे बिना अस्पष्टता के इन सवालों का जवाब देना चाहिए:

1. क्या vault के locked या unlocked होने की सूचना आने से पहले executor request स्वीकार कर सकता है?
2. जब client process बंद हो जाए, तो उस process से जुड़ी approval का क्या होता है?
3. Request चल रही हो और service restart हो जाए, तो service क्या करती है?
4. क्या pending user prompt restart के बाद किसी दूसरे caller से जुड़ सकता है?
5. क्या logout service की usable credential state रद्द कर देता है?

High-risk actions के लिए हर अस्पष्ट transition के दौरान fail closed करें। Service initialize हो रही हो और request आ जाए, तो साफ denial या retryable unavailable response दें। उसे पुरानी approval, cached decrypted credential या default allow decision नहीं मिलना चाहिए।

Startup user behavior को भी प्रभावित करता है। अगर agent workflow इसलिए टूटता है कि यूज़र को छिपी हुई service खुद फिर से शुरू करनी पड़ती है, तो लोग gate बंद कर देंगे या token को environment variable में रख देंगे। जो security controls सामान्य sleep, logout और restart से नहीं बचते, वे यूज़र को उन्हें bypass करना सिखाते हैं।

क्रेडेंशियल एजेंट से गुजरे बिना executor तक पहुंचने चाहिए

मुख्य credential सवाल यह नहीं है कि कोई टूल vault को encrypt करता है या नहीं। सवाल यह है कि क्या agent को कभी secret ऐसी form में मिलता है जिसे वह copy, print, file में रख या किसी दूसरे endpoint पर भेज सके।

सबसे सुरक्षित व्यवस्था में credential gateway के नियंत्रण वाले vault में रहता है। Agent action request भेजता है। Gateway authorization state जांचता है, outgoing HTTP request या SSH operation में credential खुद जोड़ता है, कार्रवाई करता है और परिणाम लौटाता है। Agent को remote system से बना data मिलता है, bearer token या private key नहीं।

यह अंतर महत्वपूर्ण है, क्योंकि agents text में काम करते हैं। अगर token tool output में आ जाए, तो model उसे shell command, source file, issue description, build log या chat transcript में दोहरा सकता है। बाद में display field को redact करने से exposure ठीक नहीं होता। Secret सीमा पहले ही पार कर चुका है।

OWASP की Secrets Management Cheat Sheet secrets को hardcode न करने और exposure का शक होने पर उन्हें rotate करने की सलाह देती है। यह सलाह सही है, लेकिन agent workflows के लिए अधूरी है। Secret source control से बाहर रहकर भी tool response से leak हो सकता है। Gateway को कार्रवाई करते समय ही disclosure रोकना होगा।

डेमन इस सीमा की अच्छी सुरक्षा कर सकता है, जब decryption और outbound networking उसी के पास हो। Client केवल operation description भेजता है, raw secret material का अनुरोध नहीं। डेमन को बहुत व्यापक diagnostics लौटाने से भी बचना चाहिए। Failed authentication response caller को इतना बता सकता है कि अनुरोध विफल हुआ। उसे injected authorization header, serialized SSH configuration या credential provider का memory dump लौटाने की जरूरत नहीं।

सिंगल प्रोसेस भी यही नियम अपना सकता है। उसका internal executor vault पढ़कर call करता है और agent constrained integration point से बात करता है। लाभ यह है कि decrypted material तक किसी दूसरे प्रोसेस की पहुंच नहीं होती। जोखिम यह है कि app के सामान्य features भी secret के साथ उसी memory domain में रह सकते हैं।

इन आकर्षक लेकिन असुरक्षित व्यवस्थाओं से बचें:

• Agent process के लिए API tokens को environment variables में रखना।
• ऐसा ephemeral credential file लिखना जिसे subprocess पढ़े।
• ऐसा placeholder लौटाना जिसे client बाद में असली token में बदले।
• सुविधा के लिए local daemon को «get secret» method देना।
• SSH private key bytes को standard input से भेजना।

Placeholder pattern पर खास शक करें। Placeholder तभी सुरक्षित है जब वह gateway के बाहर credential access न दे और कोई दूसरा process उसे replay न कर सके। व्यवहार में टीमें अक्सर इसे undocumented bearer token बना देती हैं। तब उन्होंने कमजोर lifecycle controls वाला दूसरा credential तैयार कर लिया होता है।

SSH के लिए भी यही अनुशासन रखें। Connection बनाने के लिए helper को key की जरूरत हो सकती है, लेकिन agent को उससे specific remote command या कड़ी सीमा वाली connection operation चलाने को कहना चाहिए। Agent को private key देना, क्योंकि उसे «बस थोड़ी देर के लिए» चाहिए, फिर भी private key देना ही है।

ज्यादा प्रोसेस ज्यादा रखरखाव लाते हैं, ज्यादा परिपक्वता नहीं

डेमन में वह operational work होता है जिससे one-process desktop app बच जाता है। किसी को उसे सही user या system context में install और start करना होगा, update करना होगा, binary verify करनी होगी, crashes संभालने होंगे, पुराने registrations हटाने होंगे और upgrades के बाद socket तथा log files का ownership सही रखना होगा।

यह डेमन के खिलाफ तर्क नहीं है। यह इस भ्रम के खिलाफ है कि ये काम operating system में अपने आप गायब हो जाते हैं। launchd किसी job को restart कर सकता है। वह यह तय नहीं कर सकता कि नई binary में अपेक्षित caller checks हैं या नहीं, upgrade के बाद पुराना socket बचा है या नहीं, या service अब अलग entitlement set के साथ शुरू हो रही है।

डेमन version matching को भी जटिल बनाता है। Command line shim protocol version A बोल सकता है, जबकि installed service version B चाहती हो। अगर लेखक mismatch को गलत संभालते हैं, तो client unauthenticated compatibility route पर जा सकता है या smooth experience बचाने के लिए checks बंद कर सकता है। Compatibility code ने कई टीमों को उम्मीद से ज्यादा परेशानी दी है, क्योंकि वह ठीक तब चलता है जब system सबसे कम समझ में आ रहा होता है।

Incompatible versions को साफ तौर पर reject करें। Error में यूज़र को एक side update करने को कहें, कमजोर mode में चुपचाप negotiation न करें। Protocol को इतना छोटा रखें कि पुराने clients, service restarts, malformed messages और concurrent requests जांचे जा सकें, बिना उसके चारों ओर पूरा test lab बनाए।

Single-process apps को भी update discipline चाहिए। Signed application अपना implementation और vault schema बदल सकती है। फर्क इतना है कि जांचने के लिए एक ही executable lifecycle होता है और approval दिखाने वाला process वही होता है जो protected action करता है। Update फिर भी flaw ला सकता है, लेकिन वह अपने आप local RPC protocol और service manager state नहीं जोड़ता।

टीमों के लिए tradeoff और स्पष्ट हो जाता है। Central daemon कई tools को stable local endpoint दे सकता है, जिससे duplicate integrations कम हों। लेकिन वह shared point of failure भी बन सकता है। एक अटकी हुई service मशीन के हर developer workflow को रोक सकती है। बहुत व्यापक permission वाली एक service हर local client को हर configured credential तक पहुंच दे सकती है।

Background menu bar icon को डेमन के स्वस्थ होने का प्रमाण न मानें। कठिन स्थितियां जांचें: UI को force quit करें, service को kill करें, active session के दौरान reboot करें, पहले client upgrade करें, पहले service upgrade करें और approval का इंतजार कर रही request के दौरान credential हटाएं। अगर किसी case का जवाब «शायद recover हो जाएगा» है, तो आपको अभी operational behavior का पता नहीं है।

Approval याद रखी हुई मशीन की नहीं, पहचाने गए run की होनी चाहिए

Approval system तब विफल होते हैं जब वे «यह कंप्यूटर» या «वर्तमान यूज़र» जैसी अस्पष्ट चीज़ को authorize करते हैं। Autonomous agents child processes शुरू कर सकते हैं, edits के बाद restart हो सकते हैं और shells के जरिए tools call कर सकते हैं। इन सभी कार्रवाइयों के साथ चलने वाली permission इतनी व्यापक होती है कि उसका अर्थ कम रह जाता है।

Approval को किसी specific process run या ऐसी identity से जोड़ें जिसे असंबंधित local code copy न कर सके। Approval screen में इतना provenance दिखना चाहिए कि इंसान किसी surprise को पहचान सके: executable की signing authority, command path और request class, केवल friendly client name से बेहतर प्रमाण हैं। Process name कोई भी चुन सकता है।

Duration भी स्पष्ट रखें। कम जोखिम वाली repeated calls के लिए short agent session की एक approval उचित हो सकती है। Sensitive credentials के लिए हर बार consent जरूरी हो सकता है। Revocation को identified run तुरंत रोकना चाहिए, केवल dashboard से छिपाना नहीं जबकि उसका local connection खुला रहे।

यहां डेमन पर अतिरिक्त जिम्मेदारी आती है। उसे IPC connection को उस identity से जोड़ना होगा जिसे व्यक्ति ने मंजूर किया है और client के exit या reconnect पर यह mapping हटानी होगी। केवल cached identifier दिखाकर client को पुराना session फिर से शुरू न करने दें। अगर identifier file या command argument के जरिए भेजा जा सकता है, तो वह fancy नाम वाला bearer credential है।

One-process design active integration के पास approval state रख सकता है, जिससे mapping का काम कम हो जाता है। फिर भी उसे एक agent launch को दूसरे से अलग पहचानना होगा। अगर app यह नहीं बता सकती कि request मंजूर किए गए run से आई है या बाद में आए replacement process से, तो उसे फिर से prompt करना चाहिए।

उपयोगी policy आम तौर पर टीमों की अपेक्षा से सरल होती है: vault locked हो तो deny करें, नए पहचाने गए run के लिए एक बार पूछें और ऐसे credentials के लिए individual confirmation मांगें जिन्हें अतिरिक्त सावधानी चाहिए। बहुत जटिल local policy languages ऐसे rules बना देती हैं जिन्हें दबाव में कोई audit नहीं कर सकता। छोटा और अनुमान योग्य decision path जांचना आसान और गलती से bypass करना कठिन होता है।

Restart failure कमजोर जोड़ को उजागर करता है

एक developer की कल्पना करें जिसने एक active terminal run के लिए coding agent को सामान्य HTTP calls की मंजूरी दी है। Gateway approval को memory में रखता है। Agent request भेजता है और gateway outbound call तैयार करना शुरू करता है। उसी समय UI crash हो जाता है या update के बाद background executor restart होता है।

लापरवाह daemon implementation इसे कई तरह से खराब कर सकती है। Vault lock state लोड होने से पहले executor लौट आता है। Client socket उसी path पर फिर दिखाई देता है। Agent reconnect करता है। Daemon request में cached session identifier देखकर मान लेता है कि पुरानी approval अभी भी valid है। इस बीच audit writer ने log फिर से नहीं खोला, इसलिए सफल retry का durable record नहीं बनता।

हर फैसला अलग से सुविधाजनक लगता है: session बचाए रखना, prompts घटाना, जल्दी restart करना, logs buffer करना। साथ मिलकर ये उस समय unapproved action बनाते हैं जब system की state सबसे कम भरोसेमंद होती है।

सुरक्षित व्यवहार सरल है। Restart पर volatile approvals हटा दें। Protection state ज्ञात होने तक vault unavailable रखें। Audit writer record commit करने के लिए तैयार होने तक नई actions रोक दें। Agent को denial या temporary unavailable response दें और session न मिलने पर fresh approval मांगें।

इसे किसी खास test hardware के बिना जांच सकते हैं:

1. नया agent session खोलें और कम प्रभाव वाली allowed request को मंजूरी दें।
2. दूसरी request शुरू करें जो approval point या test endpoint पर इंतजार करे।
3. Request के इंतजार के दौरान security process या service को terminate करें।
4. उसे restart करें और original agent process से request फिर चलाएं।
5. जांचें कि fresh authorization जरूरी है और final outcome audit record में केवल एक बार दिखाई देता है।

यही exercise client reconnect, device lock, removed credential और upgrade के साथ भी करें। आप stale authority, duplicate execution या missing records खोज रहे हैं। जो tool इन परिणामों को स्पष्ट नहीं कर सकता, उस पर incident के समय भरोसा करना कठिन है।

Audit records को ऐसे writer की जरूरत है जिसे bypass न किया जा सके

Security logs अक्सर यह दर्ज करते हैं कि user interface ने क्या देखा, न कि credential executor ने क्या किया। जब daemon local requests सीधे स्वीकार करता है, तो यह अंतर गंभीर हो जाता है। Compromised client UI को bypass कर सकता है या executor के action के बाद UI crash हो सकता है।

Audit write को action path में रखें। HTTP request भेजने या SSH helper चलाने वाला घटक caller identity, credential reference, destination, request class, decision और outcome दर्ज करे। Raw secrets या bodies को default रूप से log न करें। Bearer tokens वाले logs खराब access control वाला दूसरा vault बन जाते हैं।

Single process में ordering सीधी हो सकती है: validate करें, decision record करें, execute करें और outcome record करें। Daemon को यह सुनिश्चित करना होगा कि उसका अपना executor logging component से बचने वाले side channel से request न कर सके। Execution से अलग IPC logging तभी रखें जब failure mode स्वीकार्य हो और ordering साबित की जा सके।

Compromise के बाद tamper evidence जरूरी है, केवल routine troubleshooting के समय नहीं। अगर attacker local SQLite file बदल सकता है या text log से कुछ lines मिटा सकता है, तो record debugging में मदद कर सकता है, लेकिन भरोसेमंद history साबित नहीं करता। Append-oriented record में cryptographic chaining जांचकर्ताओं को alteration पकड़ने का तरीका देती है, बशर्ते जरूरी files सुरक्षित रखी जाएं और verify की जाएं।

Sallyport session और call views को एक encrypted, hash-chained audit log से दिखाता है। उसका sp audit verify command vault key के बिना offline chain जांचता है। इससे उस समस्या का समाधान होता है जो अलग UI और daemon logs अक्सर पैदा करते हैं: दो records इस बात पर असहमत होते हैं कि action हुआ था या नहीं।

Audit की क्षमता को बढ़ा-चढ़ाकर न बताएं। Chain उस event को वापस नहीं ला सकती जिसे attacker ने program को लिखने ही नहीं दिया। वह केवल मिले हुए record set में बदलाव पकड़ सकती है। फिर भी यह उपयोगी है, खासकर तब जब crash, upgrade या अनपेक्षित local client के बाद आपको sequence फिर से बनानी हो।

अपनी जरूरत के लिए सबसे छोटा उपयुक्त डिज़ाइन चुनें

सिंगल प्रोसेस चुनें जब protected work में इंसान मौजूद हो, agents के चलने के दौरान application खुली रह सकती हो और UI से स्वतंत्र रहने की तुलना में local endpoints घटाना ज्यादा उपयोगी हो। यह layout उस credential gateway के लिए उपयुक्त है जिसका मुख्य वादा है कि व्यक्ति हर agent run को देख और नियंत्रित कर सकता है।

Daemon तब चुनें जब job को सचमुच service continuity, कम भरोसेमंद client से अलगाव या अलग operating system privilege चाहिए। उसके जोड़े गए हर interface के बारे में जवाब मांगें: कौन connect करता है, service उनकी पहचान कैसे करती है, वे कौन सा request कर सकते हैं, state कब expire होती है और किसी भी side के restart होने पर क्या होता है।

Sallyport जैसा desktop tool single app process का रास्ता अपनाता है और agent requests के लिए नियमित MCP shim इस्तेमाल करता है। उसका vault HTTP या SSH action खुद करता है, इसलिए agent को configured API या SSH credential कभी नहीं मिलता।

इनमें से कोई model अपनाने से पहले एक सीधी जांच करें। Agent के काम करते समय authority रखने वाले component को kill करें, उसे restart करें और देखें कि अगली request deny, reapprove और log होती है या नहीं। यह test किसी polished architecture diagram से कहीं ज्यादा बताता है।