Agent process authorization: forked access रद्द करें

Autonomous agents अक्सर अपने task logs में दिखने वाली साफ-सुथरी समाप्ति पर नहीं रुकते। Agent coding request पूरी कर सकता है, खुशी-खुशी completion message दिखा सकता है और पीछे formatter, test runner, tunnel, shell या helper process छोड़ सकता है जो चलती रहती है। अगर वह बची हुई process अब भी production APIs कॉल कर सकती है या SSH session खोल सकती है, तो task वास्तव में वहां खत्म नहीं हुआ जहां आपका interface कहता है कि वह खत्म हुआ।

समाधान यह नहीं है कि हर process को बंद करने का जुनून पाल लिया जाए। Process cleanup जरूरी है, लेकिन यह authorization system नहीं है। Authority की lifetime को Unix processes की lifetime से अलग तय करें, boundary को दिखाई देने योग्य बनाएं और descendants का पीछा शुरू करने से पहले access रद्द करें। मैंने teams को parent PID को containment का प्रमाण मानते देखा है। जैसे ही agent shell चला सकता है, यह लगभग किसी बात का प्रमाण नहीं रह जाता।

Process tree authorization boundary तय नहीं करती

Parent-child संबंध यह बताता है कि process किसने बनाई। यह नहीं बताता कि parent के खत्म होने के बाद उस process के पास authority रहनी चाहिए या नहीं। ये अलग सवाल हैं। इन्हें मिलाने पर वही परिचित समस्या आती है: कोई agent task रद्द करता है, parent गायब होता देखता है और पांच मिनट बाद किसी child को requests करते हुए पाता है।

Unix processes को आपकी अपेक्षित संरचना से बाहर निकलने के कई रास्ते देता है। Child फिर fork कर सकता है। setsid से नया session बना सकता है। किसी service manager से supervision मांग सकता है। ऐसा shell pipeline छोड़ सकता है जिसमें signal केवल एक सदस्य तक पहुंचता है। या वह इसलिए जीवित रह सकता है क्योंकि parent ने कोई signal भेजा ही नहीं।

Process अपने command line से कहीं अधिक चीजें साथ रखती है। उसे environment variables, current working directory, खुले files, pipes, sockets और file descriptors मिल सकते हैं। अगर parent environment variable में bearer token रखता है, तो वह environment विरासत में पाने वाली हर child के पास token होगा। बाद में child को बंद करने से वह secret vault में वापस नहीं जाता और पहले भेजी गई requests भी वापस नहीं होतीं।

इसीलिए authorization boundary को एक सीमित सवाल का जवाब देना चाहिए: कौन सा live process run privileged actions मांग सकता है, कब तक, और हम उसे तुरंत कैसे रोकेंगे? इसका जवाब यह नहीं होना चाहिए कि "जिस terminal ने task शुरू किया, उससे निकली हर process।" यह process layout का संयोग है, security decision नहीं।

HTTP या SSH access चाहने वाले agent के लिए credentials को agent process से बाहर रखें। Credential-owning component action तभी करे जब वह approved caller को पहचान ले। इससे cleanup leaked authority मिटाने की हताश कोशिश नहीं रहता, बल्कि सामान्य operational hygiene बन जाता है।

Task शुरू करने से पहले lifetime तय करें

हर agent run के लिए start condition, end condition और revocation condition लिखी होनी चाहिए। UI में click, process group या shell wrapper में से किसे control माना जाएगा, यह तय करने से पहले इन्हें लिखें।

Interactive work में सामान्य default एक root agent process के लिए एक authorization होना चाहिए। Authorization उस खास run को approve करने पर शुरू हो और root process के बाहर निकलने या आपके द्वारा उसे रद्द करने पर खत्म हो। नया agent invocation नया decision पाए, भले ही वह उसी directory से वही binary चलाए।

Unattended work में लोगों को बार-बार prompt पसंद नहीं आने के कारण approval को चुपचाप पूरे दिन न खींचें। Job को named owner, सीमित अवधि, destinations की सीमा और ऐसा cancellation path दें जिसे job चलने के दौरान कोई उपयोग कर सके। अगर job को parent task खत्म होने के बाद भी चलना है, तो उसे अलग job मानें और उससे अलग authority का अनुरोध कराएं।

तीन सवाल अस्पष्ट design को जल्दी सामने ला देते हैं:

• User ने किस executable और process instance को approve किया?
• अगर process साफ-सुथरा completion signal कभी न भेजे, तो कौन सा event उसकी authority खत्म करेगा?
• उस event के बाद क्या कोई descendant नई privileged action पा सकता है?

अगर आखिरी जवाब हां है क्योंकि descendant को token विरासत में मिला, तो आपने delegation दर्ज किए बिना authority delegate कर दी। अगर जवाब हां है क्योंकि gateway अब भी हर descendant को trusted मानता है, तो आपने process ancestry को अपनी policy language बना दिया। Incident के दौरान दोनों विकल्पों को समझाना कठिन होगा।

सुविधा को boundary न समझें। Terminal tab, project directory, agent account और code-signing identity सभी उपयोगी context हैं। अकेले इनमें से कोई भी एक run की पहचान नहीं करता। Code-signing identity बताती है कि executable पर किसने हस्ताक्षर किए। यह नहीं बताती कि executable ने expected helper शुरू किया, helper की पुरानी copy शुरू की या cancellation के बाद अलग हो चुके child को शुरू किया।

कुछ बंद करने से पहले live tree की जांच करें

macOS पर task label से अनुमान लगाने के बजाय kernel द्वारा उपलब्ध कराए गए process facts से शुरुआत करें। ps manual pid, ppid, pgid और sid को अलग-अलग fields के रूप में दर्ज करता है। ये process ancestry, process-group membership और session membership दिखाते हैं। जब agent को shells और tools चलाने की अनुमति मिली हो, तो आपको इन सभी की जरूरत होती है।

Run की जांच करते समय यह command चलाकर output सुरक्षित रखें:

ps -axo pid,ppid,pgid,sid,stat,etime,command

उपयोगी output कुछ ऐसा दिख सकता है:

  PID  PPID  PGID   SID STAT ELAPSED COMMAND
48102 47790 48102 48102 S    00:18:04 agent-cli run build
48131 48102 48102 48102 S    00:17:59 /bin/sh -c make test
48144 48131 48102 48102 S    00:17:56 test-runner --watch
48209     1 48209 48209 S    00:16:02 helper --upload-results

पहली तीन processes एक ही group और session में हैं। आखिरी process का PPID 1 है और उसका group और session अलग है। वह अलग हो चुकी हो सकती है या अब किसी launcher के अधीन हो सकती है। किसी भी स्थिति में केवल PID 48102 को signal भेजने से वह नहीं रुकेगी।

किसी ज्ञात root PID की direct children के लिए चलाएं:

pgrep -P 48102 -alf

यह command केवल एक generation खोजती है। अगर तुरंत manual walk चाहिए, तो हर child के लिए इसे दोहराएं। Incident record के लिए revocation से पहले और बाद का ps output सुरक्षित रखें। Exact root PID, start time, command, process group और session भी दर्ज करें। केवल process name कमजोर evidence है, क्योंकि names दोहराए जाते हैं और command lines बदलती रहती हैं।

जब risk external calls से जुड़ा हो, तो खुले network connections जांचें। macOS पर lsof किसी process की network files दिखा सकता है:

lsof -nP -p 48209 -i

Listening socket, established outbound connection या लंबे समय तक चलने वाला SSH transport urgency बदल देता है। यह malicious behavior साबित नहीं करता। यह साबित करता है कि जिस process को आप खत्म समझ रहे थे, उसके पास अब भी ऐसा channel है जिसे समझना जरूरी है।

Production में human-readable ps output को parse करने पर निर्भर security control न बनाएं। इसका इस्तेमाल investigation और testing के लिए करें। वास्तविक launcher को launch के समय identifiers दर्ज करने चाहिए और authorization gateway पर direct revocation handle रखना चाहिए।

Process groups मदद करती हैं, लेकिन detached children उनसे बच निकलती हैं

Dedicated process group launcher को सामान्य task tree रद्द करने का व्यावहारिक तरीका देती है। Agent शुरू होने से पहले group बनाएं, root को group leader रखें और केवल root process के बजाय group को signal भेजें। इससे shells, compilers, test runners और pipelines का वह सामान्य मामला संभल जाता है जो उसी group में रह जाते हैं।

सामान्य signal syntax वाले systems पर negative group ID process group को target करती है:

kill -TERM -48102
sleep 3
kill -KILL -48102 2>/dev/null || true

TERM signal सामान्य tools को files बंद करने और cancellation report करने का अवसर देता है। बाद का KILL उन processes को संभालता है जो बाहर निकलने से इनकार करती हैं या बाहर नहीं निकल पातीं। Automation में इसे डालने से पहले जांच लें कि 48102 सही process group है। गलत group ID आपकी shell या असंबंधित work को बंद कर सकती है।

इस तरीके की सीमाएं हैं। Child setsid चला सकती है, जिससे नया session और आम तौर पर नया process group बनता है। Task local service, remote build system या queue को work भेज सकता है। Shell group के बाहर background process शुरू कर सकती है। ऐसा होने के बाद group termination containment नहीं, केवल cleanup रह जाता है।

Linux पर service manager task को dedicated cgroup में रखकर पूरी cgroup को एक unit की तरह बंद कर सकता है। यह आम तौर पर process-group cleanup से मजबूत है, क्योंकि kernel सामान्य parentage से आगे membership track करता है। यह न कहें कि macOS का menu-bar application भी यही control देता है। macOS और Linux के process supervision models अलग हैं, और portable agent design को यह अंतर छिपाना नहीं चाहिए।

"बस process tree को kill कर दो" वाली सलाह लोकप्रिय है क्योंकि demos में काम करती है। Agent access को जोखिमपूर्ण बनाने वाली स्थितियों में यह विफल होती है: लंबे jobs, background helpers, wrappers और अधूरा cancellation। Debris कम करने के लिए process groups का इस्तेमाल करें। उन्हें अपना एकमात्र revocation mechanism न बनाएं।

Secrets को पूरी tree से बाहर रखें

सबसे सुरक्षित child process भी वही है जो credential पढ़ ही नहीं सकती। Environment variable के जरिए token देने पर वह token environment विरासत में पाने वाले हर descendant के लिए उपलब्ध हो जाता है। यह diagnostics, crash reports या लापरवाह logging में भी दिखाई दे सकता है। Temporary file देना थोड़ा ही बेहतर है, अगर child उसे हटाने से पहले copy कर सकती है।

Agent द्वारा शुरू की गई commands के लिए इन patterns से बचें:

export DEPLOY_TOKEN='token-value'
agent-cli run deploy

agent-cli run deploy --token "$(cat ~/.config/deploy-token)"

दोनों में raw authority agent के execution environment में पहुंच जाती है। दूसरे तरीके में process arguments, shell history या logs में भी token जाने का जोखिम है। समस्या के बाद token rotate करना जरूरी हो सकता है, लेकिन rotation recovery action है, सामान्य cancellation path नहीं।

इसके बजाय local action gateway इस्तेमाल करें। Agent को credential material पाए बिना operation का अनुरोध करना चाहिए, जैसे approved endpoint पर HTTP request या SSH command। Gateway relevant credential inject करे, action चलाए और result लौटाए। इससे आपको ऐसी जगह मिलती है जहां stray child के चलते रहने पर भी अगली call रोकी जा सकती है।

Sallyport HTTP APIs और SSH के लिए यही तरीका अपनाता है: उसका encrypted vault app में रहता है, जबकि agent sp mcp shim के जरिए connect करता है और secrets के बजाय action results पाता है। यह किसी भी चालाक process-killing script से अधिक महत्वपूर्ण है, क्योंकि जिस token को child ने कभी पाया ही नहीं, उसे वह विरासत में नहीं पा सकती।

इस लाभ को बढ़ा-चढ़ाकर न बताएं। Approved gateway session वाली process उस session के खत्म होने या आपके द्वारा उसे रद्द करने तक actions मांग सकती है। Secrets को process tree से बाहर रखने से credential theft सीमित होती है, लेकिन approved agent harmless नहीं बनता।

Approval को family name से नहीं, run से जोड़ें

केवल executable name पर आधारित authorization कमजोर है। कोई binary को दूसरी path पर copy कर सकता है, उसे shell script में wrap कर सकता है या बाद में दूसरा instance चला सकता है। केवल signer पर आधारित authorization attribution के लिए बेहतर है, लेकिन अगर वह उसी party द्वारा signed हर future run को चुपचाप approve करती है, तो यह अब भी बहुत व्यापक है।

उपयोगी approval card में requesting process की ऐसी पहचान होनी चाहिए जिसे व्यक्ति जांच सके: उसकी code-signing authority, executable path, root PID और start time। Decision केवल उस एक process run पर लागू होना चाहिए। किसी child को केवल इसलिए अंतहीन action का अधिकार नहीं मिलना चाहिए कि उसके इतिहास में कहीं approved ancestor मौजूद है।

Descendants के लिए दो उचित models हैं। Stricter model हर अलग requester से approval मांगता है। Practical model एक approved root run के दौरान होने वाली calls की अनुमति देता है, फिर run खत्म होते ही सभी नई calls अस्वीकार करता है। दूसरा model उन agents के लिए अच्छा है जो सच में short-lived tools शुरू करते हैं, बशर्ते gateway यह पहचान सके कि root run खत्म हो गया है और authorization को उसी नाम वाली बाद की process से फिर नहीं जोड़ा जा सके।

Sallyport default रूप से per-session authorization इस्तेमाल करता है: नए agent process की पहली call पर process की code-signing authority को प्रमुखता देने वाला approval card दिखता है और approval उस run के बाहर निकलने तक रहती है। उसका vault gate lock होने पर हर action को रोकता है। Per-call setting किसी खास credential के हर उपयोग पर approval मांग सकती है। ये जानबूझकर छोटे controls हैं। बहुत सारे policy rules केवल इस सवाल को छिपा देंगे कि किसने क्या approve किया।

Per-call approval उन credentials के लिए उपयुक्त है जहां हर action की सावधानी से समीक्षा होनी चाहिए, जैसे production deployment account या destructive administrative API। हर read-only request के लिए यह ठीक नहीं है। जब हर harmless action पर ध्यान देना पड़े, तो लोग हर चीज को approve करना सीख लेते हैं। जहां परिणाम गंभीर हो, वहां friction रखें और बाकी जगह session boundary छोटी और स्पष्ट बनाएं।

Process का पीछा करने से पहले authorization रद्द करें

जब parent task अचानक खत्म हो, तो सबसे पहले उसकी नई privileged calls करने की क्षमता रद्द करें। फिर root group को बंद करें, बचे हुए processes की जांच करें और जो बाहर निकल गई हों उन्हें साफ करें। क्रम उलटने पर gap बनता है: जिस child को आपने अभी खोजा नहीं है, वह process tables देखते समय भी बाहर calls कर सकती है।

एक सही response sequence ऐसा दिखता है:

1. Action gateway पर session रद्द करें या vault lock करें।
2. Root PID, process information, हाल के action records और cancellation time सुरक्षित रखें।
3. ज्ञात process group को TERM भेजें और बची हुई processes की जांच करें।
4. केवल उन processes के लिए KILL इस्तेमाल करें जो task से जुड़ी हैं और बाहर निकलने से इनकार कर रही हैं।
5. जांचें कि detached local processes या remote jobs के लिए अलग cancellation की जरूरत है या नहीं।

पहला action तब भी काम करना चाहिए जब root PID पहले ही गायब हो चुका हो। यह तब भी काम करना चाहिए जब agent जानबूझकर helper को जीवित रखने की कोशिश करे। Revocation के लिए caller का मौजूद होना जरूरी करने वाला gateway उलटी दिशा में बना है।

Instant revocation future requests को रोकना चाहिए, history को फिर से नहीं लिखना चाहिए। Prior authorization और calls दिखाने वाले records सुरक्षित रखें। अगर gateway केवल successful actions log करता है, तो investigation के दौरान उपयोगी evidence छिप जाता है। Revocation के बाद की denied calls बताती हैं कि कोई अब भी action करने की कोशिश कर रहा था।

हर active session के लिए vault locking emergency brake है। जब compromised run को जल्दी पहचानना संभव न हो, तब यह उचित है। पहचान होने पर session revocation अधिक सीमित response है। दोनों operations अलग रखें, ताकि operator को कुछ न करने और हर engineer का work रोकने के बीच ही चुनाव न करना पड़े।

Audit trail को process evidence से जोड़ना जरूरी है

Process context के बिना activity record केवल आधे सवाल का जवाब देता है। वह बता सकता है कि HTTP request हुई, लेकिन यह नहीं कि उसे किस approved run ने शुरू किया। Session record में individual calls न हों, तो समस्या उलटी हो जाती है। आपको दोनों views और यह जांचने का तरीका चाहिए कि incident के बाद किसी ने उन्हें चुपचाप बदला तो नहीं।

कम से कम authorization event, requesting process identity, session start और end, हर privileged action, revocation और revocation के बाद की हर denial दर्ज करें। Timestamps और stable correlation identifiers शामिल करें। Raw secrets रिकॉर्ड न करें। Command line को भी सुरक्षित मानकर न चलें, क्योंकि उसमें अक्सर ऐसी values होती हैं जिन्हें वहां कभी नहीं भेजना चाहिए था।

Sallyport अपने Sessions और Activity journals को एक encrypted, hash-chained audit log से project करता है। उसका sp audit verify command ciphertext पर offline chain की जांच करता है और इसके लिए vault key की जरूरत नहीं होती। जब किसी ऐसे व्यक्ति को exported record देना हो जिसे integrity की पुष्टि करनी है, लेकिन stored credentials पढ़ने की अनुमति नहीं है, तब यह verification उपयोगी है।

Hash chain अधूरे log को पूरा नहीं बनाती। अगर launcher ने root PID कभी record ही नहीं किया, तो audit record बाद में उसे बना नहीं सकता। अगर remote job ने API request पाकर दूसरी machine पर काम जारी रखा, तो local process evidence remote process नहीं दिखाएगा। Remote work शुरू करने वाली request का audit रखें और फिर remote system से उसका अपना cancellation और event record उपलब्ध कराने को कहें।

एक परिचित failure के दो अलग fixes हैं

मान लें coding agent को integration tests चलाने और report publish करने को कहा गया। वह shell शुरू करता है, shell test runner शुरू करती है और test runner results upload करने के लिए helper शुरू करता है। User test failure देखता है और agent को cancel कर देता है। Parent agent बाहर निकल जाता है। Shell चली जाती है। Helper पहले ही अलग हो चुकी है, outbound connection बनाए रखती है और cancellation के बाद report भेजती है।

अगर upload credential environment variable में था, तो local approval रद्द करने के बाद भी helper के पास credential हो सकता है। अब आपको credential rotation, log review और संभवतः incident response की जरूरत है। Process cleanup देर से आया, क्योंकि authority पहले ही child तक पहुंच चुकी थी।

अगर helper ने upload के लिए gateway से अनुरोध किया था, तो parent session रद्द करने से नई upload request रुक जाती है। Upload शुरू हो चुकी थी तो gateway audit यह तथ्य दिखाता है। Helper को फिर भी बंद करें, लेकिन अब नियंत्रण के एकमात्र साधन के रूप में termination पर निर्भर नहीं रहना पड़ता।

कठिन मामला वह helper है जिसे design के अनुसार agent से अधिक समय तक चलना है, जैसे local preview server या queued release job। उसे child कहकर authority हमेशा के लिए विरासत में न दें। उसे स्पष्ट owner, अलग authorization record, तय expiry और दिखाई देने वाला stop control दें। जब work शुरू करने वाले task से अधिक समय तक चलता है, तो वह अपना अलग operational object बन चुका होता है।

अड़ियल descendant के साथ cancellation का परीक्षण करें

जिस control का आप कभी test नहीं करते, वह सबसे असुविधाजनक समय पर विफल होगा। एक harmless test agent बनाएं जो ऐसा child शुरू करे जो sleep करे, harmless local connection खोले और parent के बाहर निकलने के बाद gateway action की कोशिश करे। फिर parent को कई बिंदुओं पर cancel करें: child शुरू होने से पहले, उसके चलते समय, उसके detach होने के बाद और action के in flight होने के दौरान।

आपका expected result स्पष्ट होना चाहिए। सामान्य child process group के साथ बाहर निकल जाए। Detached child दिखाई देती रह सकती है, जिससे साबित होता है कि उसकी जांच अब भी जरूरी है। Revocation के बाद हर नई privileged request को denial मिले। Session record approval और revocation दिखाए, जबकि activity record boundary से पहले और बाद की calls दिखाए।

Passing test का अर्थ केवल UI state बदलना न मानें। Operating system process state, gateway decision और audit record तीनों verify करें। ये तीन अलग observations हैं। ऐसा cancellation button जो केवल task card छिपाता है, दिखावा है।

पहला व्यावहारिक बदलाव सरल है: जब भी agent को authorize करें, root process identity दर्ज करें और authorization को उस run के खत्म होने पर स्वतंत्र रूप से expire कराएं। फिर production बदल सकने वाले credentials के साथ cancellation feature पर भरोसा करने से पहले अड़ियल child वाला test चलाएं।