# MCP stdio या Unix सॉकेट का फैसला ट्रस्ट सीमा करती है

डेस्कटॉप सीक्रेट ब्रोकर को stdio तब इस्तेमाल करना चाहिए जब अधिकार किसी एक एजेंट प्रोसेस का हो, और Unix डोमेन सॉकेट तब जब अधिकार किसी साझा लोकल सेवा का हो। यह ट्रांसपोर्ट का चुनाव लगता है, लेकिन बाइट भेजना आसान हिस्सा है। मुश्किल यह तय करना है कि कौन कार्रवाई करा सकता है, वह अनुमति कितनी देर रहती है, और किसी भी तरफ की प्रक्रिया क्रैश होने के बाद कौन सा प्रमाण बचता है।

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

यह तुलना ऐसे macOS डेस्कटॉप ब्रोकर को मानती है जो API या SSH क्रेडेंशियल रखता है और लोकल AI एजेंटों के लिए कार्रवाई करता है। एजेंट को सीक्रेट कभी नहीं मिलना चाहिए। इसलिए ब्रोकर किसी लोकल कैश से अधिक महत्वपूर्ण चीज की रक्षा करता है: वह तय करता है कि कौन सी प्रोसेस सुरक्षित रखे अधिकार को बाहरी असर में बदल सकती है।

## ट्रांसपोर्ट से पहले ट्रस्ट सीमा चुनें

सही ट्रांसपोर्ट ऑथराइजेशन की इकाई से निकलता है। अगर उपयोगकर्ता एक एजेंट रन को मंजूरी देता है, तो चाइल्ड stdio सर्वर उस मंजूरी को स्वाभाविक सीमा देता है: पाइप उसी प्रोसेस संबंध तक मौजूद रहता है और किसी एक सिरे के बाहर निकलते ही बंद हो जाता है। अगर कई टूल एक अनलॉक ब्रोकर साझा करेंगे, तो Unix सॉकेट उन्हें स्थिर मिलने की जगह देता है, पर ब्रोकर को सॉकेट के ऊपर अपनी सेशन सीमा बनानी होगी।

थ्रेट मॉडल को पक्षों और कार्रवाइयों के रूप में लिखें, केवल सुरक्षित IPC की सामान्य इच्छा के रूप में नहीं। उन लोकल प्रोसेसों, ब्रोकर के क्रेडेंशियल, उन क्रेडेंशियल से संभव कार्रवाइयों और एक्सेस खत्म करने वाली घटनाओं को नाम दें। उसी लॉगिन उपयोगकर्ता के रूप में चलने वाले मैलवेयर को शामिल करें। फाइल अनुमति अक्सर दूसरे उपयोगकर्ताओं को रोकती है, पर उसी खाते की दूसरी प्रोसेस के खिलाफ बहुत कम करती है। कॉपी किया हुआ एजेंट बाइनरी, बदला हुआ प्लगइन, एजेंट से शुरू हुआ shell और दिखाई देने वाला काम समाप्त होने के बाद बची पुरानी प्रोसेस भी शामिल करें।

फिर तय करें कि मंजूरी का अर्थ क्या है। वह किसी साइन किए executable, एक operating system प्रोसेस, एक प्रोसेस ट्री, एक terminal job या लॉगिन उपयोगकर्ता की हर client प्रोसेस को अधिकार दे सकती है। ये अलग वादे हैं। ट्रांसपोर्ट आपके लिए इनमें से चुनाव नहीं कर सकता। वह केवल कुछ वादों को लागू करना आसान बनाता है।

रद्द करना एक उपयोगी डिजाइन जांच है। पूछें कि पूरा vault लॉक किए बिना ब्रोकर किस चीज का अधिकार तुरंत वापस ले सकता है। stdio में पाइप बंद करना या चाइल्ड प्रोसेस खत्म करना उस चैनल को समाप्त करता है, हालांकि लॉन्चर की लापरवाही से descendant प्रोसेस file descriptor अपने पास रख सकती हैं। सॉकेट में एक स्वीकार किया कनेक्शन बंद करने से वही client खत्म होता है और listening socket उपलब्ध रहता है। अगर authorization record कनेक्शन से अधिक समय तक रहता है, तो दोनों में केवल बंद करना काफी नहीं है।

जब तक ब्रोकर नेटवर्क listener भी न खोलता हो, इस लोकल फैसले के केंद्र में नेटवर्क हमलावरों को न रखें। अधिक सीधे जोखिम हैं: गलत पहचान, login session से मिला ambient अधिकार, descriptor inheritance, filesystem socket का बदल दिया जाना और उपयोगकर्ता के मंजूर काम से ज्यादा समय तक टिकने वाला authorization।

## Stdio चैनल को प्रोसेस के जीवनकाल से बांधता है

MCP over stdio सबसे अच्छा तब है जब broker shim को agent प्रोसेस के साथ जीना और मरना चाहिए। client एक server command शुरू करता है, JSON-RPC संदेश उसके standard input पर लिखता है और standard output से उत्तर पढ़ता है। EOF operating system से मिला lifecycle signal है, application heartbeat में छिपा समझौता नहीं।

Model Context Protocol transport specification एक काम की operational मांग भी रखता है: stdio server को stdout पर protocol से बाहर का data नहीं लिखना चाहिए। logs stderr पर जाते हैं। इसे केवल framing की सफाई मानना आसान है, पर यह नियम diagnostic line को security boundary के अंदर invalid message बनने से रोकता है। stdout को protocol memory मानें। पहले उत्तर से पहले libraries और crash reporters को configure करें ताकि वे इसे दूषित न करें।

Stdio को filesystem नाम, socket directory, permission mode, discovery file या resident listener नहीं चाहिए। agent configuration executable और arguments की ओर इशारा करता है। desktop product के लिए यह असली deployment लाभ है क्योंकि खोजने को endpoint और सुधारने को stale path नहीं है। update के सक्रिय होने की साफ जगह भी मिलती है: अगली बार शुरू हुआ shim नया executable चलाता है। चल रहा session पुराने version पर जारी रह सकता है, इसलिए session के साथ executable identity और version दर्ज करें; install होते ही हर active client बदल गया, यह न मानें।

प्रोसेस संबंध उपयोगी प्रमाण है, पर पूरी पहचान नहीं। ब्रोकर अपने private backend से जुड़े shim को जांच सकता है और shim अपने parent process को। parent के exit के बाद process identifier दोबारा इस्तेमाल हो सकता है, और दिखाई देने वाले agent और shim के बीच launcher बैठ सकता है। process के जीवित रहते audit token या code signing information लें। केवल PID बचाकर बाद में उसे resolve न करें।

Pipes में inheritance की दिक्कत भी है। launcher descriptor को inheritable रखे तो grandchild, agent के exit के बाद भी write end खुला रख सकता है। फिर ब्रोकर ऐसे EOF की प्रतीक्षा करता है जो कभी नहीं आता। जहां platform अपने आप न करे वहां close on exec सेट करें, spawn के तुरंत बाद अनुपयोगी सिरे बंद करें, और session से pipe व expected client process दोनों की निगरानी कराएं। EOF access रद्द करे, और process exit भी उसे स्वतंत्र रूप से रद्द करे।

Concurrency जानबूझकर सीमित है। stdio server का एक instance सामान्यतः एक client process को सेवा देता है। इससे isolation साफ मिलता है और हर agent पर एक अतिरिक्त process का खर्च आता है। अगर असली vault desktop app में है, तो stdio executable आम तौर पर छोटा shim होता है जो typed requests app को भेजता है। अंदर की इस hop को भी authentication और session binding चाहिए। MCP edge पर stdio किसी unauthenticated shared backend को सुरक्षित नहीं बनाता।

## Unix सॉकेट सेवा का जीवनकाल बनाता है

Unix domain socket उस ब्रोकर के लिए ठीक है जो पहले से resident service है और समय के साथ अलग clients को स्वीकार करता है। listening endpoint client के exit के बाद रहता है, इसलिए menu bar app हर agent को broker process का मालिक बनाए बिना calls स्वीकार कर सकता है। कई clients, backpressure और central upgrades सीधे हैं। लागत यह है कि service को उन सभी सीमाओं को खुद तय करना होगा जो single client process पहले implicit रूप से देती थी।

Socket pathname discovery है, authentication नहीं। उसे खोज सकने वाले client को connect करने की अनुमति फिर भी चाहिए, और connect कर सकने वाले client पर authorization decision फिर भी चाहिए। socket को user या application के control वाली directory में रखें, directory को mode 0700 से बनाएं और socket को 0600 रखें। साझा writable directory में अनुमान लगने वाला path न रखें। temporary directory का sticky bit कुछ deletion attacks रोकता है, मगर directory को trusted namespace नहीं बनाता।

Permissions केवल अंतिम mode पर निर्भर नहीं होतीं। process umask creation को प्रभावित करता है। मौजूदा parent directories तय करती हैं कि दूसरा account नाम तक पहुंच या उसे बदल सकता है या नहीं। चुने path पर symlink या stale node पहले से हो सकता है। service trusted parent directory खोले, links follow किए बिना entry जांचे और उसे तभी हटाए जब साबित हो कि वह मरे instance का socket है या current installation का path है। ज्ञात नाम को बिना जांच unlink करने से replacement race बनती है।

macOS पर accepted local socket से `getpeereid` जैसे system calls के जरिए peer credentials मिल सकते हैं, और lower level APIs audit token दे सकते हैं। user और group IDs बताते हैं कि peer process किस account की है। वे यह नहीं बताते कि user किस application को मंजूर करना चाहता था। उसके लिए audit token को live process से resolve करें और product की घोषित policy के अनुसार code signing identity, executable path और launch context देखें।

Socket multiplexing आसान करता है, पर इससे sessions धुंधले हो सकते हैं। एक सफल connection को arbitrary session identifier वाली हर request की मंजूरी न मानें। server connection identity बनाए, authorization उससे bind करे और client के identity बदलने के प्रयास को reject करे। service restart के बाद helper फिर connect करे तो नया authorization decision लें, जब तक threat model उस घटना के पार approval बचाए रखने की साफ अनुमति न देता हो।

Performance शायद ही इस चुनाव का फैसला करती है। local pipes और Unix sockets दोनों छोटे JSON-RPC requests को HTTP API या SSH operation से बहुत तेजी से ले जाते हैं। broker बड़े response bodies भेजे तो मापें, मगर local IPC की अनुमानित बचत के बदले समझ आने वाला authority model न छोड़ें।

## सॉकेट अनुमति उपयोगकर्ता की मंशा साबित नहीं करती

Mode 0600 का अर्थ है कि दूसरे user IDs से चलने वाली processes सामान्य discretionary access checks से socket नहीं खोल सकतीं। इसका अर्थ यह नहीं कि उसी user ID की हर process stored credentials की हकदार है। desktop malware, untrusted package script, editor extension और approved agent अक्सर वही user ID साझा करते हैं।

यह फर्क इसलिए धुंधला होता है क्योंकि Unix permissions ठोस और जांचने में आसान हैं। team private socket देखकर endpoint को authenticated कह देती है। वह केवल account boundary तक authenticated है। threat model अगर दूसरे login users पर रुकता है तो यह पर्याप्त हो सकता है। autonomous tools के secrets broker आम तौर पर एक login session के अंदर control का दावा करते हैं, इसलिए उन्हें ज्यादा संकरी identity चाहिए।

macOS पर code signing information identity को संकरा कर सकती है। live peer को validate करें, request में आई path string को नहीं। path बदली हुई file की ओर इशारा कर सकता है और process update के बाद पुरानी mapped image चलाती रह सकती है। operating system जिस signing authority और designated requirement की रिपोर्ट करता है, उसे दर्ज करें। ad hoc signed development builds का व्यवहार तय करें; उन्हें चुपचाप production application मान लेना developer सुविधा को bypass बना देता है।

Caller identity और caller authority भी अलग हैं। identity बताती है किस process ने connection खोला। authority बताती है कि क्या वह process इस समय किसी खास credential से कोई खास action कर सकती है। valid signed agent unreviewed repository में चल रहा हो सकता है या उसका prompt hostile content से प्रभावित हो सकता है। executable पहचान में आने के कारण हर action मंजूर करना provenance को consent समझना है।

Stdio में launcher shim शुरू करते समय immediate parent की identity दे सकता है, और broker उस evidence को fresh channel nonce से bind कर सकता है। socket में broker accept के समय peer identity निकाल कर accepted file descriptor से bind कर सकता है। दोनों designs में identity का source broker होना चाहिए। `client_name` जैसा field display metadata है, प्रमाण नहीं।

सच्चा approval card operating system से स्थापित तथ्य और user की मंजूरी का दायरा दिखाता है। wrapper script top level agent की भरोसेमंद attribution रोकती हो तो यह बताएं या call deny करें। process tree में ऊपर तब तक अनुमान लगाना जब तक परिचित नाम न मिले, attacker के control वाला search path बनाता है।

## सफाई security model का हिस्सा है

Stdio cleanup descriptors और child processes पर केंद्रित है। सामान्य स्थिति सरल है: client stdin बंद करता है, server EOF देखता है, active work पूरा या cancel करता है और exit करता है। असामान्य स्थितियां अधिक मायने रखती हैं। descendant pipe पकड़े रहे तो client crash कर सकता है। server लटका रह सकता है जबकि client उसे मृत मानता है। cancellation action करने वाले worker तक न पहुंचे तो privileged action revocation के बाद पूरी हो सकती है।

हर request को broker assigned operation ID और queued, executing, completed, denied या indeterminate जैसी state दें। channel बंद होने पर future requests तुरंत revoke करें। remote API को पहले ही भेजे action पर cancellation का दावा तभी करें जब remote operation उसे support करता हो। local process outcome जानने से पहले मरे तो indeterminate result दर्ज करें। यह entry retry loop को action चुपचाप दो बार करने से रोकती है।

Socket cleanup में दो अलग objects हैं: accepted connections और listening pathname। protocol failure, failed authorization, idle expiry या service shutdown पर हर संबंधित client connection बंद करें। pathname तभी हटाएं जब service के पास अब भी वही filesystem object हो। restart पर `EADDRINUSE` जांच का कारण है, जो मौजूद है उसे unlink करने की अनुमति नहीं।

यह shell check development के दौरान उपयोगी है क्योंकि बिना कुछ बदले path type, ownership, mode और listening process दिखाता है:

```sh
sock="$TMPDIR/com.example.broker.sock"
stat -f 'type=%HT owner=%Su mode=%Sp inode=%i' "$sock"
lsof -n -U "$sock"
```

सामान्य macOS result इस आकार का होता है:

```text
type=Socket owner=alice mode=srw------- inode=123456
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
Broker  48102 alice   9u  unix 0x0123456789abcdef      0t0        /.../com.example.broker.sock
```

Sample values को parse न करें। assert करें कि type socket है, owner expected user है, mode group और other access रोकता है, और process installed broker instance है। forced crash, application update, logout और second launch के बाद वही inspection चलाएं। केवल normal quit के बाद काम करने वाले cleanup design की जांच पूरी नहीं हुई है।

launchd service शुरू करे तो ownership लगातार उसी के पास रखें। application managed startup को launch agent के साथ मिलाने पर दो instances एक path के लिए race कर सकते हैं। creation, readiness और removal का मालिक एक component हो, और clients के पास बार बार अधिक brokers spawn करने के बजाय साफ unavailable state हो।

## डिप्लॉयमेंट का काम दूसरी जगह चला जाता है

Stdio installation के समय सस्ता और कई clients के shared resident state पर महंगा है। हर MCP client को command entry चाहिए। shim को signed application या उसका private endpoint खोजना, compatible protocol version negotiate करना और desktop app absent या locked होने पर साफ error देना होगा। packaging को executable permissions और code signatures बचानी होंगी। shell startup files जरूरी न बनाएं; GUI applications अक्सर उस environment के बिना खुलती हैं जिसकी terminal user अपेक्षा करता है।

Unix socket को service installation, startup ownership, endpoint discovery, directory permissions, crash recovery और independent client तथा server upgrades की compatibility चाहिए। बदले में हर client एक stable endpoint इस्तेमाल करता है, और service vault state व audit ordering एक process में रख सकती है। desktop app पहले से लगातार चलती हो तो यह उपयोगी है।

Endpoint discovery का contract होना चाहिए। macOS पर `$TMPDIR` per user है, मगर terminal, editor और GUI launcher में environment inheritance अलग हो सकती है। protected application support directory में fixed path को समझना आसान है, हालांकि sandboxing और installation layout उसे सीमित कर सकते हैं। अगर clients bootstrap command से path लेते हैं, तो bootstrap result को authenticate करें; project configuration से arbitrary path स्वीकार न करें।

दोनों models में version skew होता है। stdio में client चुनता है कि कौन सा shim executable launch हो। resident socket में staged updates के दौरान old client new service तक या इसका उलटा पहुंच सकता है। first exchange में छोटा version negotiation रखें। approval मांगने से पहले unsupported combinations reject करें, क्योंकि client और broker request को अलग समझें तो user उसकी अर्थपूर्ण मंजूरी नहीं दे सकता।

Operations teams कभी sockets पसंद करती हैं क्योंकि जाने पहचाने tools उन्हें list कर सकते हैं। developers कभी stdio पसंद करते हैं क्योंकि command terminal में चलती है। कोई सुविधा debug backdoor न बने। privileged requests भेज सकने वाला diagnostic client agent वाली attribution और approval path से ही गुजरे। authorization छोड़ने वाला debug flag आखिर किसी development machine से बाहर निकलेगा।

Broker resident न हो तो deployment comparison बदलती है। हर stdio connection पर full UI application शुरू करने से धीमा launch और असहज prompts मिलते हैं। छोटे shim से बचने के लिए socket service को जिंदा रखना update और cleanup का काम बढ़ाता है। पहले application lifetime चुनें, फिर external transport को उससे मिलाएं।

## डिजाइन को साफ खतरों से मिलाएं

Platform team को दर्ज करना चाहिए कि कौन सी design property किस threat का जवाब देती है। नीचे की table decision record है, scorecard नहीं। transport किसी row में तभी जीतता है जब आसपास का implementation बताया control देता हो।

| खतरा या जरूरत | Stdio डिजाइन | Unix सॉकेट डिजाइन |
| --- | --- | --- |
| दूसरा login user access की कोशिश करता है | private process descriptors और सही inheritance | protected parent directory और mode 0600 |
| उसी user की दूसरी process connect करती है | केवल launcher के pipe रखने पर कठिन, पर inherited descriptors का खतरा रहता है | default रूप से संभव, इसलिए peer credentials और application identity checks जरूरी हैं |
| approval एक agent run के साथ खत्म हो | EOF और watched process exit स्वाभाविक revocation signals देते हैं | server session बनाए और connection तथा process lifetime से bind करे |
| कई independent agents एक vault साझा करें | हर shim को vault process तक private authenticated hop चाहिए | resident service अलग authenticated connections लेती है |
| broker crash होकर restart हो | client EOF देखता है और नया instance शुरू या failure report करता है | service stale path संभाले और clients से reconnect तथा reauthorize कराए |
| run के दौरान client executable बदलता है | captured identity उसी session से जुड़ी रहती है | captured peer identity connection से जुड़ी रहती है; reconnect पर fresh evaluation होता है |
| आसान first install | command और signed executable, endpoint setup नहीं | startup registration, protected path, discovery और cleanup चाहिए |
| central audit ordering | shared vault core को shims के events क्रम में रखने होंगे | एक resident service में स्वाभाविक, पर durable logging का design फिर भी चाहिए |

इस exercise से आम तौर पर दो निष्कर्ष बचते हैं। पहला, same user attacker filesystem mode bits से मिलने वाले भरोसे का अधिकतर हिस्सा मिटा देता है। दूसरा, approval की अवधि endpoint access जितनी महत्वपूर्ण है। पूरी तरह private socket जिसका approval record पूरे दिन चले, सावधानी से scoped stdio channel से अधिक authority दे सकता है।

जब तक team weights का बचाव न कर सके, numeric weights न दें। गंभीर credential के लिए एक missed identity check सभी deployment advantages पर भारी पड़ सकता है। हर row का acceptance test लिखें। जैसे, उसी user में unapproved process शुरू करके साबित करें कि broker उसे deny करता है; agent को approve करें, उसे kill करें, descendant को alive रखें और साबित करें कि old authorization reuse नहीं हो सकता।

Choice layered भी हो सकती है। agent और छोटे shim के बीच MCP stdio इस्तेमाल करे, जबकि shim resident desktop broker से private Unix socket या किसी दूसरे operating system IPC पर बात करे। यह अक्सर सही desktop shape है, लेकिन दो boundaries बनाता है। दोनों को authenticate करें। shim साबित करे कि वह कौन सा agent run दिखाता है, और app साबित करे कि shim intended broker तक पहुंचा है, project files से बदले endpoint तक नहीं।

## पहचान को सत्यापित सेशन envelope में रखें

छोटा protocol envelope security decision को review करने योग्य बनाता है। वह operating system identity की जगह नहीं लेता। वह broker से पहले सत्यापित facts को उस request से बांधता है जिसे broker चलाने जा रहा है।

Broker live caller को inspect करने के बाद session identifier और nonce बनाए। वह इन्हें authenticated channel पर लौटाए। बाद की हर request उस session identifier, लगातार बढ़ते sequence number, requested capability और action parameters को रखे। broker unknown session, repeated या strict ordering में skipped sequence, approval से बाहर capability या अलग channel पर मिली request को reject करे।

```json
{"session_id":"s_7M4K","sequence":12,"capability":"http:billing.read","action":{"method":"GET","path":"/v1/invoices"}}
```

Response को operation identity और state दोहरानी चाहिए, secrets या injected authorization headers नहीं:

```json
{"operation_id":"op_01J8","sequence":12,"state":"completed","result":{"status":200,"body_ref":"activity:8841"}}
```

इन्हें universal field names नहीं, protocol shapes मानें। काम की property यह है कि server identity assign करता है, ordering enforce करता है और recorded action का durable reference देता है। agent को दी key से envelope sign न करें; इससे agent credential holder बन जाएगा। इसे authenticated local channel से bind करें और secret material broker में रखें।

Stdio में channel binding में fresh pipe से ही मिला random value और captured launcher identity शामिल हो सकती है। Unix socket में accepted connection और peer audit token शामिल हो सकते हैं। requests connections के बीच जा सकती हों तो short lifetime और one time tokens वाला deliberate resumption protocol तय करें। log से copy हुआ ambient session identifier authority resume न करे।

Approval data को display data से अलग रखें। repository path, agent supplied label, tool name और requested rationale व्यक्ति को फैसला लेने में मदद करते हैं, पर attacker उन्हें चुन सकता है। broker record में verified process facts, user assertions, approved capabilities और request content अलग दिखें। incident review में यह फर्क काम आता है, जहां सजा हुआ label वरना evidence जैसा लगता है।

## डेस्कटॉप ब्रोकर दोनों को बिना भ्रम के इस्तेमाल कर सकता है

Signed और हमेशा चलने वाले macOS app के लिए सबसे साफ design अक्सर MCP boundary पर stdio और app तक अलग authenticated local hop है। agent को MCP का expected launch model और process scoped lifetime मिलता है। app एक vault, एक approval surface और एक ordered audit history रखता है। design तभी सफल है जब internal hop outer caller identity बचाए, सभी shims को एक trusted client में न बदल दे।

Sallyport यही आकार इस्तेमाल करता है: MCP capable agents bundled `sp mcp` stdio shim शुरू करते हैं, जबकि app HTTP और SSH actions चलाता है ताकि secrets agent तक न पहुंचें। उसका session approval process की code signing authority से शुरू होता है, जो socket permissions से अनुत्तरित कमजोर बिंदु को संबोधित करता है।

इस choice का अर्थ नहीं कि Unix sockets हमेशा गलत हैं या stdio अकेला काफी है। कई native clients वाला broker बनाने वाली platform team protected socket को primary API बना सकती है। तब team peer inspection, session construction, stale endpoint recovery और upgrade compatibility की मालिक है। वह हर एक का काम समझा नहीं सकती तो socket अभी credentials उठाने के लिए तैयार नहीं है।

वह design चुनें जिसके failure state में deny करना सबसे आसान हो। attribution fail हो तो action deny करें। broker यह साबित न कर सके कि endpoint उसके current instance का है तो connect या unlink न करें। client किसी process restart के बाद reconnect करे तो नया session बनाएं। इन rules में थोड़ी सुविधा जाती है, लेकिन local brokers को खतरनाक बनाने वाली silent continuity हटती है।

Final architecture review एक page में आनी चाहिए: authorization unit, verified caller evidence, session start, session end, endpoint ownership, crash behavior, update behavior और audit record। कोई answer "same user" पर निर्भर हो तो review साफ बताए कि same user malware threat model से बाहर है या नहीं। यह एक sentence दिखा देगा कि stdio और Unix sockets को transports की तरह compare किया जा रहा है या security decision के विकल्प की तरह।