tmux agent session ownership: approvals और audits

Terminal multiplexers एक वास्तविक operational समस्या हल करते हैं: SSH connection टूटने, laptop के sleep mode में जाने या terminal window गलती से बंद हो जाने पर भी वे काम को जारी रखते हैं। यही persistence इस बात को अस्पष्ट कर सकती है कि AI agent का owner कौन है, उसका approval अब भी लागू है या नहीं, और authenticated request वास्तव में किस process ने भेजी।

गलती यह मानना है कि tmux window एक security session है। ऐसा नहीं है। tmux terminal sessions के लिए process manager है। इसका server terminal client से अधिक समय तक चल सकता है और इसके panes उन्हें बनाने वाले व्यक्ति के बाद भी मौजूद रह सकते हैं। GNU screen में भी यही मूल गुण है। अगर आपका approval model, incident note या audit process «the tmux session» को एक actor और एक agent run की पहचान मानता है, तो आपने investigation को पहले ही जरूरत से ज्यादा कठिन बना दिया है।

यह बात खास तौर पर तब महत्वपूर्ण होती है जब कोई agent human-controlled gateway के जरिए APIs या SSH hosts तक पहुंच सकता हो। कोई व्यक्ति pane में agent शुरू कर सकता है, detach कर सकता है, किसी colleague को session name दे सकता है, दूसरी machine से reattach कर सकता है और बाद में उसी pane में दूसरा agent शुरू कर सकता है। Operator को ये घटनाएं लगातार जुड़ी हुई लग सकती हैं। Process table में ये अलग-अलग तथ्य हैं।

tmux session, agent run नहीं है

tmux session लंबे समय तक चलने वाले tmux server के पास रखे गए windows और panes का नामित समूह है। Agent run एक process और उसके बनाए हुए children का समूह है, जिसकी सीमा process के start और exit से तय होती है। ये अलग objects हैं। इन्हें एक मानने पर approval scope या तो बहुत व्यापक हो जाता है या बाद में समझाना असंभव होता है।

जब आप tmux new-session -s build चलाते हैं, tmux server शुरू करता है या उससे जुड़ता है। Server शुरुआती pane के लिए pseudo-terminal बनाता है और shell शुरू करता है। जब वह shell agent शुरू करता है, तो agent shell का descendant बन जाता है। Detach करने पर tmux से client connection हटता है। सामान्य रूप से server, shell या agent बंद नहीं होते।

एक सामान्य timeline इस तरह दिख सकती है:

1. Maya tmux new -s release शुरू करती है और pane 0 में agent launch करती है।
2. Agent काम करता रहता है और Maya meeting के लिए detach कर देती है।
3. बाद में उसका colleague release से attach करता है, pane का output पढ़ता है और follow-up command चलाता है।
4. उसी शाम Maya pane 0 को किसी दूसरे agent process के लिए reuse करती है।

Session name release ही रहा। Security के लिए महत्वपूर्ण entities वही नहीं रहीं। कम से कम दो agent processes, दो human interactions और संभवतः अलग authorization events हुए। Terminal history इन्हें एक coherent identity में नहीं बदल सकती।

GNU screen भी इसी तरह काम करता है। Detached screen server terminal windows और child processes का owner होता है। Commands अलग हैं, लेकिन security निष्कर्ष वही है: attachment state terminal multiplexer तक access बताती है, उसके अंदर मौजूद हर process का ownership नहीं।

The tmux manual client-server model और sessions, windows तथा panes के management का वर्णन करता है। यह केवल implementation detail नहीं है। इससे पता चलता है कि continuity कहाँ रहती है: server में, उस terminal application में नहीं जिसे कोई व्यक्ति देख रहा है। Authorization उस process के आधार पर बनाएं जो action request करता है, न कि उस multiplexer container के आधार पर जिसमें वह process मौजूद है।

Process ancestry उन सवालों का जवाब देती है जिनका pane name नहीं दे सकता

Process tree दिखा सकती है कि agent कैसे शुरू हुआ और उसका parent shell तथा tmux server कौन थे। Pane title केवल ऐसा label दिखाता है जिसे कोई बदल, copy या पुराना छोड़ सकता है।

macOS या Linux पर investigation उस समय शुरू करें जब process अभी चल रहा हो:

ps -axo pid,ppid,lstart,tty,stat,command | grep -E '[t]mux|[s]creen|[a]gent'

Output का ढांचा exact command names से अधिक महत्वपूर्ण है:

 8421     1 Tue Mar 12 09:14:03 2025 ??       Ss   tmux new-session -s release
 8430  8421 Tue Mar 12 09:14:04 2025 ttys002  S    -zsh
 9917  8430 Tue Mar 12 10:02:51 2025 ttys002  S+   agent-tool run deploy check

PID 9917 संभावित agent process है। PID 8430 वह shell है जिसने इसे launch किया। PID 8421 tmux server है। tty value process को उसके pane से जोड़ने में मदद कर सकती है, लेकिन इसे स्थायी identity न मानें। Process के exit होने पर pseudo-terminal assignment गायब हो सकती है और terminal दोबारा बनने पर अलग दिख सकती है।

macOS में pstree default रूप से installed नहीं होता। Software install किए बिना parent-child view के लिए यह command उपयोगी है:

ps -axo pid,ppid,user,lstart,command | sort -n

किसी खास PID के लिए उसके parent को बार-बार inspect करें, जब तक tmux server या launch service तक न पहुंच जाएं:

ps -p 9917 -o pid=,ppid=,user=,lstart=,tty=,command=
ps -p 8430 -o pid=,ppid=,user=,lstart=,tty=,command=

कुछ बंद करने से पहले values record करें। अगर operator पहले tmux kill-session चलाता है, तो command lines, parent relationships और start times जैसे सबसे उपयोगी live evidence मिट सकते हैं। Session को kill करना सही containment action हो सकता है, लेकिन जब स्थिति अनुमति दे तो पहले छोटा snapshot ले लें।

Process ancestry की सीमाएं हैं। कोई process daemonize, fork या जानबूझकर खुद को reparent कर सकता है। Agent किसी external helper से भी काम करा सकता है, जिससे child tree helper पर समाप्त हो जाती है। Ancestry को launch context का evidence समझें, human intent का proof नहीं। आपको ऐसे action records भी चाहिए जो requesting process और उसे अनुमति देने वाले authorization की पहचान करें।

Approval attached terminal के पीछे नहीं, agent process के साथ होना चाहिए

Per-session authorization एक agent process run पर लागू होना चाहिए और process exit होते ही समाप्त होना चाहिए। Attach, detach, pane focus और terminal emulator restart से approval न मिले, न renew हो और न चुपचाप transfer हो।

Sallyport का per-session authorization इसी सिद्धांत पर चलता है: नए agent process की पहली call approval मांगती है, code-signing authority के जरिए process की पहचान बताती है और approval केवल उसी process run के लिए रखती है। Approval tmux session name या shell prompt की property नहीं बनता।

यह सीमा कई उलझे हुए मामलों को स्पष्ट करती है। यदि कोई व्यक्ति detach करके बाद में reattach करता है और वही agent process चलता रहता है, तो process बदला नहीं है। उसका मौजूदा session authorization सार्थक रह सकता है, vault gate और उन credentials की शर्तों के अधीन जिन्हें हर call पर approval चाहिए। अगर agent exit हो जाता है, pane का shell नया agent शुरू करता है और pane वैसा ही दिखता है, तो नए process को नया approval decision मिलना चाहिए।

tmux attachment को approval event बनाने की कोशिश न करें। यह विचार लोकप्रिय है क्योंकि human action, tmux attach, उपयोगी signal जैसा लगता है। Credential use के लिए यह गलत signal है। Attachment agent के शुरू होने के बाद हो सकता है, उसी local account का इस्तेमाल करने वाला दूसरा व्यक्ति कर सकता है या कोई केवल output देखने के लिए attach कर सकता है। इससे भी महत्वपूर्ण बात यह है कि कोई process तब भी काम करता रह सकता है जब कोई tmux client attached न हो।

दूसरी गलती भी आम है: attached pane में typed हर command को human-supervised मान लेना। कोई व्यक्ति attach करके वहां से चला जा सकता है और agent को काम करने के लिए छोड़ सकता है। दिखाई दे रहा terminal presence check नहीं है।

Sensitive credentials के लिए हर use पर approval का उद्देश्य अलग है। इससे process का owner तय नहीं होता। इसका मतलब है कि किसी खास credential action के request किए जाने के उसी क्षण human decision चाहिए। इन विचारों को अलग रखें:

• Vault gate तय करता है कि secrets protected रहते हुए कोई action आगे बढ़ सकता है या नहीं।
• Per-process authorization तय करता है कि यह agent run calls कर सकता है या नहीं।
• Per-credential approval तय करता है कि किसी खास credential use के लिए नया human decision चाहिए या नहीं।

ये controls अलग-अलग सवालों का जवाब देते हैं। जो team लंबे समय तक चलने वाले terminal session के लिए केवल एक broad approval इस्तेमाल करती है, उसने defendable boundary के बजाय सुविधा को चुना है।

Reused pane अलग-अलग runs के बीच approval confusion ला सकता है

Failure अक्सर ऐसे persistent «work» session से शुरू होता है जो अधूरी commands के लिए shared drawer बन गया हो। कोई agent शुरू करता है, detach करता है, घंटों बाद लौटकर उसे रोकता है और उसी shell में दूसरा agent शुरू करता है। Pane में पुराना transcript, environment variables और prompt अब भी रहते हैं। लोग ऐसी continuity मान लेते हैं जो operating system में मौजूद नहीं है।

मान लें कि 16:43 पर API को destructive request मिलती है। Activity record agent process की पहचान करता है। Team tmux खोलती है और prod-fix नाम का pane पाती है जिसका output 09:00 से शुरू हो रहा है। वे मान लेते हैं कि prod-fix बनाने वाले engineer ने request approve की थी। यह निष्कर्ष कई कारणों से गलत हो सकता है:

• Original agent 10:15 पर exit हो गया हो और 16:40 पर दूसरा process शुरू हुआ हो।
• दूसरे engineer ने attach करके नया launch command दिया हो।
• Pane title पहले के task से inherited हो।
• Shell startup file ने credentials या target environment export किया हो जो वर्तमान काम से मेल न खाता हो।
• Process tmux के बाहर शुरू हुआ हो और किसी अन्य mechanism से output pane में भेजा गया हो।

सही सवाल अधिक सीमित है: 16:43 पर action का request किस executable process ने किया, उस process को किसने approve किया और approval interface ने कौन सी code-signing authority दिखाई? फिर पूछें कि वह process machine की process tree में कैसे आया।

इसका मतलब tmux पर प्रतिबंध लगाना नहीं है। Fresh, narrowly named session incident work को बेहतर बना सकता है, क्योंकि वह operators को visible workspace देता है और unstable connection के दौरान output का record बनाए रखता है। Risk तब आता है जब general-purpose session को अलग-अलग agent runs के container के रूप में reuse किया जाता है।

ऐसे names इस्तेमाल करें जिनमें purpose और short-lived run identifier हो, जैसे work या main की जगह deploy-4812। Name human aid है, authorization input नहीं। Run खत्म होने पर session retire करें।

Detached work के लिए ownership और expiry decision जरूरी है

Detached tmux या screen session तभी सुरक्षित ढंग से चल सकता है जब कोई व्यक्ति स्पष्ट रूप से स्वीकार करे कि terminal attached न होने पर भी यह जारी रहेगा। «मुझे लगा यह रुक गया होगा» ownership model नहीं है।

Authenticated actions लेने वाले agent को detach करने से पहले ticket, incident note या handoff record में चार तथ्य लिखें: agent process PID, tmux session name, stated task और उसे रोकने के लिए जिम्मेदार व्यक्ति। वह समय भी लिखें जब review करना है कि इसे जारी रहना चाहिए या नहीं। यह साधारण काम elaborate pane naming schemes से ज्यादा परेशानी रोकता है।

एक उपयोगी launch pattern durable personal server में नया window जोड़ने के बजाय run के लिए नया socket namespace बनाता है:

tmux -L agent-4812 new-session -d -s agent-4812 \\
  'exec agent-tool run "verify deployment 4812"'

tmux -L agent-4812 display-message -p \\
  '#{session_name} #{session_created} #{pane_pid} #{pane_tty}'

पहली command detached session launch करती है। exec महत्वपूर्ण है क्योंकि यह shell process को agent command से replace करता है, जिससे pane PID investigation का अधिक सीधा starting point बन जाता है। exec के बिना pane पहले shell का होता है जो बाद में agent को child के रूप में बनाता है। यह भी संभाला जा सकता है, लेकिन inspect करने के लिए एक अतिरिक्त layer आती है।

दूसरी command इस तरह का metadata output देती है:

agent-4812 1731000000 9917 /dev/ttys002

इस output को task tracking record में save करें। Process बाद में children fork कर सकता है या exit हो सकता है, इसलिए यह complete audit record नहीं है। फिर भी process data और action logs की तुलना करते समय यह responders को शुरुआती anchor देता है।

Task समाप्त होने पर named socket को जानबूझकर terminate करें:

tmux -L agent-4812 kill-session -t agent-4812

फिर verify करें कि expected agent PID exit हो चुका है। यह न मानें कि kill-session ने हर descendant को साफ कर दिया। अपने sessions या background helpers बनाने वाले programs original pseudo-terminal के बाद भी जीवित रह सकते हैं। Process list फिर inspect करें और अगर records दिखाते हैं कि active agent run अब भी authorized है, तो action gateway से उसे revoke करें।

Screen में भी यही identity trap है, बस clues कम हैं

GNU screen detached session बनाता है जिसे बाद में resume किया जा सकता है। इसके परिचित numeric session identifiers उससे अधिक precise लग सकते हैं जितने वे वास्तव में हैं। वे screen server instance की पहचान करते हैं, किसी खास agent process या human approval की नहीं।

The GNU screen manual detached sessions और screen -ls तथा screen -r जैसी commands का documentation देता है। ये commands बताती हैं कि attachment के लिए screen server उपलब्ध है या नहीं। वे यह नहीं बतातीं कि window के अंदर चल रहा process वही है जो पहले चला था या current operator वही व्यक्ति है जिसने पहले authorization decision दिया था।

जब screen किसी incident में शामिल हो, तो इन checks से शुरू करें:

screen -ls
ps -axo pid,ppid,lstart,tty,stat,command | grep -E '[s]creen|[a]gent'

12345.build (Detached) जैसा result जांचे जाने योग्य screen session की पहचान करता है। Attach करने से पहले इसे process start times और terminals से मिलाएं। Attach करने पर user को दिखने वाली चीज बदल सकती है, shell hooks चल सकते हैं या interactive program फिर से आगे बढ़ सकता है। Sensitive incident में पहले evidence सुरक्षित करें और designated responder को तय करने दें कि interaction जरूरी है या नहीं।

screen का multiuser mode अतिरिक्त सावधानी मांगता है। इससे दूसरे local users को shared terminal session का access मिल सकता है। Controlled machine पर यह उचित हो सकता है, लेकिन «जिस व्यक्ति ने attach किया वही processes का owner है» जैसे सहज दावे को कमजोर करता है। Authorization में requesting agent process की पहचान और credential gateway नियंत्रित करने वाले local human का decision अब भी जरूरी होना चाहिए।

Audit records को tmux के बाहर एक join point चाहिए

Defensible investigation तीन records को जोड़ती है: operating-system process record, authorization record और individual action record। tmux या screen output इन records का supporting evidence हो सकता है, किसी का विकल्प नहीं।

Review में शामिल हर credential action के लिए यह sequence स्थापित करें:

1. Activity record में action का timestamp, destination, method और outcome पहचानें।
2. वह agent run पहचानें जिसने request किया और उससे जुड़ा authorization decision ढूंढें।
3. Run के process details और start time की तुलना live या captured process tree से करें।
4. Operator के workspace और handoffs को reconstruct करने के लिए ही tmux या screen session metadata इस्तेमाल करें।
5. Verify करें कि capture के बाद audit record बदला नहीं है।

Action journal और terminal scrollback के बीच अंतर स्पष्ट है। Scrollback में output छूट सकता है, rotate होकर हट सकता है, किसी दूसरे process से pasted text हो सकता है या session access रखने वाला user उसे बदल सकता है। Action journal में attempted operation और result लिखा होना चाहिए। अगर वह tamper evident है, तो investigators terminal पर भरोसा किए बिना देख सकते हैं कि records intact हैं या नहीं।

Sallyport agent runs और individual calls को hash-chained encrypted audit log में record करता है और sp audit verify vault key के बिना offline उस chain को verify कर सकता है। यह recorded sequence की integrity साबित करता है, यह नहीं कि tmux title उस human की सही पहचान करता है जिसने command type की थी। Incident reports में इन दोनों दावों को अलग रखें।

Useful incident note में «release tmux session ने यह किया» जैसी भाषा से बचें। लिखें: «16:43 पर agent run [identifier] ने [action] का request किया। Request process [identifier] से आया, जो [time] पर शुरू हुआ था। Capture के समय process [shell or service] का descendant था और tmux server [PID] से जुड़ा था। Displayed process authority की समीक्षा के बाद [Person] ने run approve किया।» केवल वे facts भरें जिन्हें आप support कर सकते हैं।

यह wording gaps को भी सामने लाती है। अगर containment से पहले parent chain capture नहीं हुई, तो यह बात लिखें। अगर system जरूरी process identity retain नहीं करता, तो gap को pane name से भरने की कोशिश न करें।

Code-signing identity और local-account identity अलग समस्याएं हल करते हैं

Local macOS account operating-system user की पहचान करता है। Code-signing authority बताती है कि executable पर किसने sign किया। tmux session terminal server की पहचान करती है। इनमें से कोई identifier दूसरे के अर्थ का नहीं है और हर एक अलग failure पकड़ता है।

Local account identity यह बताने में मदद करती है कि process किस account के पास था। इससे यह पता नहीं चलता कि binary expected publisher से आया है या किसी दूसरे व्यक्ति ने unlocked account इस्तेमाल किया। Code-signing authority व्यक्ति को access मांगने वाले executable को पहचानने में मदद करती है। इससे यह पता नहीं चलता कि process सही tmux pane में launch हुआ था या task उचित था।

इसीलिए नए agent process के action की मांग करने पर code-signing authority से शुरू होने वाला approval card उपयोगी है। यह approver को ऐसा stable signal देता है जो renamed panes, copied tmux configuration और terminal emulator restart के बाद भी बना रहता है। इससे उस क्षण unexpected unsigned या अलग तरह से signed executable भी दिखाई देता है जब यह सबसे महत्वपूर्ण है।

इसे अंधे «same signer equals safe» rule में न बदलें। Trusted signer खराब version भेज सकता है, local wrapper approved binary को unsafe context में चला सकता है और signed process को खतरनाक instructions मिल सकती हैं। Process identity approval target को सीमित करती है। Selected credentials के लिए per-call approval और complete action trail उन risks को संभालते हैं जिन्हें identity अकेले नहीं संभाल सकती।

macOS investigation में codesign से binary की signing information देखी जा सकती है:

codesign -dv --verbose=4 "$(command -v agent-tool)" 2>&1 | \\
  grep -E 'Identifier=|TeamIdentifier=|Authority='

Output में सामान्यतः Identifier=, TeamIdentifier= और एक या अधिक Authority= entries होती हैं। जब आपको समझाना हो कि approval interface ने process को क्यों पहचाना, तब इन्हें capture करें। /usr/local/bin/agent-tool जैसे path को signer evidence का विकल्प न बनाएं। Paths को आसानी से shadow, replace या symlink किया जा सकता है।

Privileged agent work के लिए permanent shared sessions छोड़ दें

dev, main या shared नाम का permanent tmux server उन agents को चलाने के लिए खराब जगह है जो production credentials तक पहुंच सकते हैं। इससे active work आसान होता है, लेकिन लोग, tasks, shell history, environment state और process lifetimes मिलकर इतने अस्पष्ट हो जाते हैं कि कोई नहीं बता पाता कि एक run कहाँ खत्म हुआ।

Personal interactive multiplexing को agent execution से अलग रखें। हर agent run को अपना session या socket दें। उसे recorded command से launch करें, PID और start time capture करें और detach होने से पहले owner तय करें। अगर किसी दूसरे engineer को task जारी रखना है, तो उसे नया agent process शुरू करना चाहिए और नया authorization decision मिलना चाहिए, पुराने pane को परंपरा के आधार पर inherit नहीं करना चाहिए।

Teams अक्सर इसका विरोध करती हैं क्योंकि session reuse efficient लगता है। यह तब तक efficient है जब तक agent original task खत्म होने के बाद request नहीं भेजता और response team scrollback पढ़ने में एक घंटा नहीं लगाती। Fresh process boundaries में कुछ seconds लगते हैं। Blurred boundary को reconstruct करने में कहीं अधिक समय लगता है और अक्सर answer के बजाय assumption मिलती है।

पहला operational change सरल है: authenticated access वाले agents के लिए unnamed long-lived tmux और screen sessions को रोकें। हर run के लिए short-lived session बनाएं, launch identity record करें और run खत्म होने पर उसे बंद करें। इससे approval systems और investigators को काम करने के लिए वास्तविक boundary मिलती है।