Propriedade da sessão de agente no tmux: aprovações e auditorias

Os multiplexadores de terminal resolvem um problema operacional real: mantêm o trabalho ativo quando a conexão SSH cai, o laptop entra em repouso ou uma janela de terminal é fechada por engano. Essa mesma persistência pode confundir quem é responsável por um agente de IA, se a aprovação ainda se aplica e qual processo realmente enviou uma solicitação autenticada.

O erro é tratar uma janela do tmux como uma sessão de segurança. Ela não é. O tmux é um gerenciador de processos para sessões de terminal. O servidor pode continuar ativo depois que o cliente do terminal termina, e seus painéis podem sobreviver à pessoa que os criou. O GNU screen tem a mesma característica básica. Se seu modelo de aprovação, suas anotações de incidente ou seu processo de auditoria usam a expressão «a sessão do tmux» como se ela identificasse um único ator e uma única execução de agente, a investigação já ficou mais difícil do que precisava.

Isso importa principalmente quando um agente pode acessar APIs ou hosts SSH por meio de um gateway controlado por uma pessoa. Alguém pode iniciar um agente em um painel, desconectar-se, passar o nome da sessão a um colega, reconectar-se de outra máquina e depois iniciar um segundo agente no mesmo painel. Para o operador, cada evento parece contínuo. Na tabela de processos, são fatos separados.

Uma sessão do tmux não é uma execução de agente

Uma sessão do tmux é um conjunto nomeado de janelas e painéis mantido por um servidor tmux de longa duração. Uma execução de agente é um processo e os filhos que ele cria, limitado pelo início e pelo encerramento do processo. São objetos diferentes. Confundi-los cria escopos de aprovação amplos demais ou impossíveis de explicar depois.

Quando você executa tmux new-session -s build, o tmux inicia um servidor ou se conecta a um já existente. O servidor cria um pseudo-terminal para o painel inicial e inicia um shell. Quando esse shell inicia um agente, o agente se torna descendente do shell. Desconectar remove a conexão do cliente com o tmux. Normalmente, isso não encerra o servidor, o shell nem o agente.

Uma sequência comum parece inofensiva:

1. Maya inicia tmux new -s release e executa um agente no painel 0.
2. Maya se desconecta para participar de uma reunião enquanto o agente continua trabalhando.
3. Mais tarde, seu colega se conecta a release, lê a saída do painel e executa um comando de acompanhamento.
4. Naquela noite, Maya reutiliza o painel 0 para um processo de agente diferente.

O nome da sessão continuou sendo release. As entidades relevantes para a segurança não continuaram as mesmas. Houve pelo menos dois processos de agente, duas interações humanas e possivelmente eventos de autorização separados. O histórico do terminal não pode transformar tudo isso em uma única identidade coerente.

O GNU screen funciona de forma parecida. Um servidor screen desconectado controla janelas de terminal e processos filhos. Os comandos exatos mudam, mas a conclusão de segurança não: o estado de conexão descreve o acesso a um multiplexador de terminal, não a propriedade de todos os processos dentro dele.

O manual do tmux descreve um modelo cliente-servidor e afirma que o servidor gerencia sessões, janelas e painéis. Isso é mais do que um detalhe de implementação. Mostra onde a continuidade vive: no servidor, não no aplicativo de terminal que a pessoa está vendo. Crie autorizações com base no processo que solicita uma ação, não no contêiner do multiplexador que por acaso o abriga.

A ancestralidade do processo responde ao que os nomes dos painéis não conseguem

Uma árvore de processos pode mostrar como um agente foi iniciado e qual shell e servidor tmux foram seus pais. O título de um painel só mostra um rótulo que alguém pode ter alterado, copiado ou deixado desatualizado.

No macOS ou no Linux, comece a investigação com uma visão restrita dos processos enquanto o processo ainda estiver ativo:

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

O formato da saída importa mais do que os nomes exatos dos comandos:

 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

O PID 9917 é o processo de agente candidato. O PID 8430 é o shell que o iniciou. O PID 8421 é o servidor tmux. O valor de tty pode ajudar a relacionar um processo a um painel enquanto ele existe, mas não o use como identidade permanente. As atribuições de pseudo-terminal podem desaparecer quando um processo termina e parecer diferentes depois que o terminal é recriado.

No macOS, o pstree não vem instalado por padrão. Este comando fornece uma visão útil da relação entre pais e filhos sem instalar software:

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

Para um PID específico, examine repetidamente o processo pai até chegar ao servidor tmux ou a um serviço de inicialização:

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

Registre os valores antes de encerrar qualquer coisa. Um operador que execute tmux kill-session primeiro pode apagar as evidências ativas mais úteis: linhas de comando, relações entre pais e filhos e horários de início. Encerrar uma sessão ainda pode ser a ação correta de contenção, mas, quando a situação permitir, capture primeiro um resumo curto.

A ancestralidade do processo tem limites. Um processo pode se transformar em daemon, criar novos processos ou alterar deliberadamente seu processo pai. Um agente também pode solicitar que um auxiliar externo realize o trabalho, produzindo uma árvore de filhos que termina no auxiliar. Trate a ancestralidade como evidência do contexto de inicialização, não como prova da intenção de uma pessoa. Ainda são necessários registros de ações que identifiquem o processo solicitante e a autorização que permitiu a ação.

A aprovação deve acompanhar o processo do agente, não o terminal conectado

A autorização por sessão deve se aplicar a uma única execução do processo do agente e terminar quando esse processo sair. Conexão, desconexão, foco do painel e reinicializações do emulador de terminal não devem conceder, renovar ou transferir essa aprovação silenciosamente.

A autorização por sessão do Sallyport segue esse princípio: a primeira chamada de um novo processo de agente solicita aprovação, identifica o processo por meio de sua autoridade de assinatura de código e mantém a aprovação somente durante aquela execução do processo. A aprovação não se torna uma propriedade do nome de uma sessão tmux nem de um prompt de shell.

Essa separação resolve vários casos confusos. Se uma pessoa se desconecta e depois se reconecta enquanto o mesmo processo de agente continua, o processo não mudou. Sua autorização de sessão existente pode continuar válida, sujeita ao bloqueio do cofre e a qualquer credencial que exija aprovação para cada chamada. Se o agente termina, um shell no painel inicia um novo agente e o painel parece igual, o novo processo precisa receber uma nova decisão de aprovação.

Não tente transformar a conexão ao tmux no evento de aprovação. A ideia é popular porque uma ação humana, tmux attach, parece um sinal útil. É o sinal errado para o uso de credenciais. Uma conexão pode ocorrer depois que o agente começou, vir de outra pessoa usando a mesma conta local ou servir apenas para inspecionar a saída. Além disso, um processo pode continuar agindo quando não há nenhum cliente tmux conectado.

O erro oposto também aparece nas equipes: tratar todo comando digitado em um painel conectado como supervisionado por uma pessoa. Alguém pode se conectar, sair e deixar um agente trabalhando. Um terminal visível não é uma verificação de presença.

Para credenciais sensíveis, a aprovação a cada uso tem outra finalidade. Ela não estabelece quem é responsável pelo processo. Ela exige uma decisão humana no momento em que uma ação específica com a credencial é solicitada. Mantenha essas ideias separadas:

• O bloqueio do cofre decide se alguma ação pode prosseguir enquanto os segredos continuam protegidos.
• A autorização por processo decide se essa execução do agente pode fazer chamadas.
• A aprovação por credencial decide se um uso específico da credencial precisa de uma nova decisão humana.

Esses controles respondem a perguntas diferentes. Uma equipe que usa apenas uma aprovação ampla para uma sessão de terminal longa escolheu conveniência em vez de uma fronteira defensável.

Um painel reutilizado pode levar a confusão de aprovação entre execuções

A falha normalmente começa com uma sessão persistente chamada «work», que se transformou em uma gaveta compartilhada para comandos inacabados. Alguém inicia um agente, desconecta-se, volta horas depois, interrompe o agente e inicia outro no mesmo shell. O painel ainda contém a transcrição anterior, as variáveis de ambiente e o prompt. As pessoas inferem uma continuidade que o sistema operacional não reconhece.

Considere um incidente em que uma API recebe uma solicitação destrutiva às 16:43. O registro da atividade identifica um processo de agente. A equipe abre o tmux e encontra um painel chamado prod-fix, com saída começando às 09:00. Presume que o engenheiro que criou prod-fix aprovou a solicitação. Essa conclusão pode estar errada de várias maneiras:

• O agente original pode ter terminado às 10:15, e outro processo pode ter sido iniciado às 16:40.
• Um segundo engenheiro pode ter se conectado e emitido o novo comando de inicialização.
• O título do painel pode ter sido herdado de uma tarefa anterior.
• Um arquivo de inicialização do shell pode ter exportado credenciais ou um ambiente de destino que já não corresponde ao trabalho atual.
• O processo pode ter sido iniciado fora do tmux e escrito a saída no painel por outro mecanismo.

A pergunta correta é mais específica: qual processo executável solicitou a ação às 16:43, quem aprovou esse processo e qual autoridade de assinatura de código a interface de aprovação exibiu? Depois, pergunte como esse processo entrou na árvore de processos da máquina.

Não exagere na correção proibindo o tmux. Uma sessão nova e com nome específico pode melhorar o trabalho de incidentes, pois fornece um espaço visível e mantém um registro da saída durante uma conexão instável. O risco vem de reutilizar uma sessão genérica como contêiner de execuções de agentes sem relação entre si.

Use nomes que expressem uma finalidade e um identificador curto da execução, como deploy-4812 em vez de work ou main. O nome ajuda as pessoas, mas não é uma entrada de autorização. Encerre a sessão quando a execução terminar.

O trabalho desconectado precisa de um responsável e de uma decisão de expiração

Uma sessão tmux ou screen desconectada só pode executar com segurança quando alguém aceita explicitamente que ela continuará sem um terminal conectado. «Achei que tinha parado» não é um modelo de responsabilidade.

Antes de desconectar um agente que pode realizar ações autenticadas, registre no chamado, na anotação do incidente ou no registro de transferência quatro fatos: o PID do processo do agente, o nome da sessão tmux, a tarefa declarada e a pessoa responsável por interrompê-la. Acrescente um horário em que alguém deverá revisar se ela deve continuar. É um trabalho simples, mas evita mais problemas do que esquemas elaborados de nomes de painéis.

Um padrão de inicialização útil cria um novo namespace de socket para uma execução, em vez de adicionar outra janela a um servidor pessoal duradouro:

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}'

O primeiro comando inicia uma sessão desconectada. exec é importante porque substitui o processo do shell pelo comando do agente, tornando o PID do painel um ponto de partida mais direto para a investigação. Sem exec, o painel inicialmente pertence a um shell que depois cria o agente como filho. Isso continua sendo administrável, mas acrescenta uma camada à inspeção.

O segundo comando imprime metadados com um formato semelhante a este:

agent-4812 1731000000 9917 /dev/ttys002

Salve essa saída onde a tarefa é acompanhada. O processo pode criar filhos depois ou terminar, portanto isso não é um registro de auditoria completo. Ainda assim, fornece uma referência inicial quando os responsáveis precisam comparar dados dos processos com os registros de ações.

Quando a tarefa terminar, encerre deliberadamente o socket nomeado:

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

Depois, verifique se o PID esperado do agente terminou. Não presuma que kill-session encerrou todos os descendentes. Programas que criam suas próprias sessões ou auxiliares em segundo plano podem sobreviver ao pseudo-terminal original. Inspecione novamente a lista de processos e use o gateway de ações para revogar a execução ativa do agente se os registros mostrarem que ela continua autorizada.

O screen tem a mesma armadilha de identidade, com menos pistas

O GNU screen cria uma sessão desconectada que pode ser retomada depois, e seus conhecidos identificadores numéricos podem parecer mais precisos do que realmente são. Eles identificam uma instância do servidor screen, não um processo de agente específico nem uma aprovação humana.

O manual do GNU screen documenta sessões desconectadas e comandos como screen -ls e screen -r. Esses comandos respondem se há um servidor screen disponível para conexão. Eles não respondem se o processo dentro de uma janela é o mesmo que executou algo antes ou se o operador atual é a pessoa que tomou uma decisão de autorização anterior.

Comece estas verificações quando o screen aparecer em um incidente:

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

Um resultado como 12345.build (Detached) identifica uma sessão screen que merece ser examinada. Compare-a com os horários de início dos processos e os terminais antes de se conectar. A conexão pode alterar o que um usuário vê, executar hooks do shell ou fazer um programa interativo continuar. Em um incidente sensível, preserve primeiro as evidências e deixe o responsável designado decidir se a interação é necessária.

O modo multiusuário do screen exige cuidado extra. Ele pode conceder a outros usuários locais acesso a uma sessão de terminal compartilhada. Isso pode ser adequado em uma máquina controlada, mas enfraquece qualquer alegação casual de que «a pessoa que se conectou» é responsável pelos processos. A autorização ainda deve identificar o processo de agente solicitante e exigir uma decisão da pessoa local que controla o gateway de credenciais.

Os registros de auditoria precisam de um ponto de ligação fora do tmux

Uma investigação defensável relaciona três registros: o registro do processo do sistema operacional, o registro de autorização e o registro de cada ação. A saída do tmux ou do screen pode complementar essas evidências, mas não substitui nenhuma delas.

Para cada ação de credencial analisada, estabeleça esta sequência:

1. Identifique o horário, o destino, o método e o resultado da ação no registro de atividade.
2. Identifique a execução do agente que a solicitou e a decisão de autorização associada a essa execução.
3. Compare os detalhes do processo e o horário de início da execução com a árvore de processos ativa ou capturada.
4. Use os metadados da sessão tmux ou screen apenas para reconstruir o espaço de trabalho e as transferências do operador.
5. Verifique se o registro de auditoria não mudou desde a captura.

A diferença entre um diário de ações e o histórico do terminal é clara. O histórico pode omitir a saída, ser rotacionado, conter texto colado de outro processo ou ser alterado por um usuário com acesso à sessão. Um diário de ações deve declarar a operação tentada e o resultado. Se for evidente qualquer adulteração, os investigadores poderão verificar se o conjunto de registros permaneceu íntegro sem confiar no terminal que o exibiu.

O Sallyport registra execuções de agentes e chamadas individuais em um registro de auditoria criptografado e encadeado por hash, e sp audit verify pode verificar essa cadeia offline sem uma chave do cofre. Essa verificação prova a integridade da sequência registrada, não que um título do tmux identifique corretamente a pessoa que digitou um comando. Mantenha essas afirmações separadas nos relatórios de incidentes.

Uma boa anotação de incidente evita frases como «a sessão release do tmux fez isso». Escreva: «Às 16:43, a execução do agente [identificador] solicitou [ação]. A solicitação veio do processo [identificador], iniciado às [horário]. No momento da captura, o processo era descendente de [shell ou serviço] associado ao servidor tmux [PID]. [Pessoa] aprovou a execução depois que a autoridade do processo exibida foi revisada.» Preencha apenas fatos que possam ser comprovados.

Essa formulação também revela lacunas. Se ninguém capturou a cadeia de processos antes da contenção, diga isso. Se o sistema não retém a identidade de processo necessária, não preencha a lacuna com o nome de um painel.

A identidade de assinatura de código e a identidade da conta local resolvem problemas diferentes

Uma conta local do macOS identifica um usuário do sistema operacional. A autoridade de assinatura de código identifica quem assinou um executável. Uma sessão tmux identifica um servidor de terminal. Nenhum desses identificadores significa a mesma coisa, e cada um detecta uma falha diferente.

A identidade da conta local ajuda a responder qual conta era proprietária do processo. Ela não informa se um binário veio do editor esperado ou se outra pessoa usou uma conta desbloqueada. A autoridade de assinatura de código ajuda a pessoa a reconhecer o executável que solicita acesso. Ela não informa se o processo foi iniciado no painel tmux correto ou se a própria tarefa era apropriada.

Por isso, é útil que um cartão de aprovação mostre primeiro a autoridade de assinatura de código quando um novo processo de agente pede para agir. Isso oferece ao aprovador um sinal estável, que permanece mesmo depois da renomeação de painéis, da cópia da configuração do tmux ou da reinicialização do emulador de terminal. Também torna executáveis inesperadamente não assinados ou assinados de outra forma visíveis no momento importante.

Não reduza isso a uma regra cega de «mesmo assinante significa seguro». Um assinante confiável pode distribuir uma versão defeituosa, um wrapper local pode chamar um binário aprovado em um contexto inseguro e um processo assinado pode receber instruções perigosas. A identidade do processo restringe o alvo da aprovação. A aprovação por chamada para credenciais selecionadas e um registro completo de ações tratam riscos que a identidade, sozinha, não consegue resolver.

Nas investigações do macOS, você pode inspecionar as informações de assinatura de um binário com codesign:

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

A saída normalmente inclui linhas como Identifier=, TeamIdentifier= e uma ou mais entradas Authority=. Capture essas informações quando precisar explicar por que uma interface de aprovação reconheceu um processo. Não substitua a evidência do assinante por um caminho como /usr/local/bin/agent-tool. Caminhos podem ser facilmente ocultados, substituídos e ligados por symlink.

Pare de usar sessões compartilhadas permanentes para agentes privilegiados

Um servidor tmux permanente chamado dev, main ou shared é um lugar ruim para executar agentes que podem acessar credenciais de produção. Ele facilita o trabalho ativo, mas mistura pessoas, tarefas, histórico do shell, estado do ambiente e ciclos de vida dos processos até que ninguém consiga dizer onde uma execução terminou.

Mantenha a multiplexação interativa pessoal separada da execução de agentes. Dê a cada execução de agente sua própria sessão ou socket. Inicie-a a partir de um comando registrado, capture seu PID e horário de início e atribua um responsável antes da desconexão. Se outro engenheiro precisar continuar a tarefa, ele deve iniciar um novo processo de agente e receber uma nova decisão de autorização, em vez de herdar um painel antigo por convenção.

As equipes costumam resistir porque reutilizar sessões parece eficiente. É eficiente até que um agente envie uma solicitação depois do fim da tarefa original e a equipe de resposta passe uma hora lendo o histórico. Fronteiras novas entre processos custam segundos. Reconstruir uma fronteira confusa custa muito mais tempo e frequentemente termina em uma suposição, não em uma resposta.

A primeira mudança operacional é simples: proíba sessões tmux e screen sem nome e de longa duração para agentes com acesso autenticado. Crie uma sessão curta por execução, registre a identidade de inicialização e encerre-a quando a execução terminar. Essa política oferece aos sistemas de aprovação e aos investigadores uma fronteira real para trabalhar.