Segurança da Troca Rápida de Usuário para ações de agentes de IA locais

Um Mac compartilhado muda o significado de autoridade «local». A Troca Rápida de Usuário permite que várias sessões permaneçam conectadas ao mesmo tempo. Assim, a pessoa no teclado, um processo de agente, um cofre de credenciais e um aviso de aprovação podem pertencer a contextos de segurança diferentes. Tratar tudo isso como uma única identidade é a receita para transformar uma transferência rotineira em uma chamada de produção sem revisão.

A regra prática é simples: a propriedade da conta, o acesso ao cofre e a autoridade de aprovação precisam continuar vinculados à mesma sessão de usuário do macOS. Trocar de usuário não dá permissão para continuar a execução do agente de outra pessoa. É um sinal para verificar qual processo ainda existe, de quem são as credenciais que ele pode solicitar e quem consegue ver ou atender ao próximo aviso.

A segurança da Troca Rápida de Usuário diz respeito a sessões simultâneas

A segurança da Troca Rápida de Usuário importa porque o macOS pode manter a conta anterior conectada enquanto outra pessoa usa o mesmo hardware. A Apple descreve a Troca Rápida de Usuário no Guia do Usuário do macOS como uma forma de alternar entre contas sem desconectar o outro usuário. Essa conveniência é justamente o objetivo do recurso. Ela também significa que a troca não prova que o trabalho anterior foi interrompido.

Muitas pessoas imaginam um laptop como uma única cadeira: uma pessoa se levanta, outra se senta e o controle muda de mãos. Um Mac compartilhado com a troca de usuários ativada se parece mais com vários cômodos em um mesmo prédio. A área de trabalho visível mostra quem controla o console naquele momento. Ela não mostra se um terminal, uma extensão do editor, um serviço local ou um iniciador de agente continua ativo em outra conta conectada.

Essa diferença se torna séria quando um agente pode chamar uma API ou se conectar por SSH. O agente pode ter sido iniciado na conta de Alex antes do almoço. Depois, Sam pode trocar para a própria conta e ver uma área de trabalho limpa. O processo de Alex ainda pode existir, a fila de tarefas pode conter trabalho pendente e um estado de aprovação pode continuar válido para aquela execução. O Mac não transferiu essa autoridade para Sam, mas um software descuidado pode esconder essa diferença.

Não trate bloqueio de tela, troca de usuário e encerramento de processos como sinônimos. Eles resolvem problemas diferentes.

• O bloqueio de tela impede o uso casual da área de trabalho visível atual.
• A troca de usuário muda a conta ativa no console, preservando outra sessão de login.
• Sair da conta pede ao macOS que encerre a sessão gráfica daquele usuário e seus processos.
• Revogar uma execução do agente remove a permissão daquela execução para fazer novas chamadas externas.

Esse último item é o controle que as equipes esquecem. Uma sessão de agente deve ter seu próprio ciclo de vida e seu próprio caminho de revogação. Se ela apenas pega emprestado o ciclo de vida de uma janela de terminal ou de uma ideia vaga de «computador do desenvolvedor», vai se comportar mal em um Mac usado por várias pessoas.

A Troca Rápida de Usuário não é automaticamente insegura. Ela se torna insegura quando um sistema de ações locais presume que todo processo ativo e toda pessoa que possa tocar na máquina pertencem ao mesmo usuário. Essa suposição só funciona em um Mac pessoal com uma única conta ativa. Mesmo nesse caso, ela falha assim que outra pessoa conhece a senha de login ou usa uma mesa desbloqueada.

O usuário ativo do console não deve herdar a autoridade de outra conta

O usuário ativo do console deve controlar apenas as credenciais e aprovações atribuídas à própria conta. Um cofre local de credenciais pertence a uma identidade, não ao computador físico. Se um aplicativo torna o cofre válido para toda a máquina, qualquer usuário que consiga acessar a interface do aplicativo ganha um caminho para a autoridade de outra pessoa.

É aqui que as equipes confundem duas afirmações diferentes. «O segredo nunca entra no agente» trata da exposição do segredo. «Somente a pessoa certa pode autorizar a ação» trata da autoridade. Você precisa das duas coisas. Uma separação perfeita do segredo não ajuda se um usuário conectado diferente puder aprovar seu uso, ou se uma sessão antiga continuar aprovada depois que o proprietário deixar a mesa.

Deixe esse vínculo explícito no projeto e nas regras de operação:

1. Armazene as credenciais de cada pessoa na conta correspondente do macOS, com material de cofre separado e autenticação local separada.
2. Exija que o cofre seja desbloqueado pela conta proprietária da credencial antes que qualquer ação externa possa ocorrer.
3. Faça a aprovação valer para um processo de agente em uma conta específica e expire-a quando esse processo terminar ou quando um operador a revogar.
4. Não permita que a troca para outra conta atenda a um aviso originado na primeira conta.
5. Registre o contexto da conta e o processo de origem em cada autorização e chamada.

O caso extremo mais delicado é o de um profissional de suporte que tem acesso de administrador ao Mac. O acesso de administrador pode alterar muitas condições locais, mas não deve se transformar no uso casual das credenciais de API de outra pessoa. Pergunte se o sistema exige um novo evento de autenticação do proprietário da credencial e se o registro de auditoria torna visível a troca de conta. Se a resposta não estiver clara, o projeto também não está claro.

O Touch ID torna esse ponto mais evidente, não mais simples. Uma aprovação por impressão digital deve confirmar a pessoa autorizada para a conta ativa e para a ação exibida no aviso. Ela não deve se transformar em um sinal genérico de presença física que qualquer pessoa cadastrada possa usar para gastar a autoridade de outra conta. A autenticação local protegida por hardware só oferece uma barreira forte quando o aplicativo preserva a identidade do outro lado dessa barreira.

Não tente resolver isso com uma regra informal como «só trocamos de usuário quando a outra pessoa está longe». Máquinas compartilhadas envolvem interrupções, manutenção, carregadores emprestados e transferências apressadas. Os controles precisam resistir ao comportamento humano normal, porque é justamente quando as pessoas deixam de lembrar regras não escritas.

Um processo oculto pode continuar depois que a pessoa deixa a mesa

Uma troca de usuário pode deixar um agente local ativo, e você precisa testar isso exatamente da forma como sua equipe inicia os agentes. Alguns processos param quando o terminal pai é fechado. Outros funcionam por meio de um editor, executor de tarefas, item de login ou mecanismo de inicialização em segundo plano e continuam ativos. Os limites entre contas do macOS restringem o que esses processos podem acessar, mas não garantem que todo processo desapareça quando outro usuário chega à tela de login.

Faça um teste pequeno antes de permitir trabalho autônomo em hardware compartilhado. Use uma tarefa inofensiva de agente que gere um registro local reconhecível a cada minuto e não mantenha nenhuma credencial. Inicie-a pelo mesmo terminal, editor ou iniciador que os desenvolvedores usam no trabalho real. Troque de usuário sem sair da conta, espere, volte à conta original e verifique se a tarefa continuou. Repita o teste depois de bloquear a tela e depois de sair da conta.

Registre o resultado em termos operacionais. «O agente para» não basta. Anote o iniciador, a conta, o evento que o interrompeu e quanto tempo isso levou. Um processo que continua depois de uma troca pode ser aceitável para uma tarefa local de análise de código. Ele merece muito mais atenção se puder enviar uma solicitação que altere um ambiente hospedado.

Uma falha comum parece inofensiva no início. Um desenvolvedor inicia uma execução autônoma de programação que pode criar comentários em issues e atualizar um ambiente de testes. Ele aprova o processo para a tarde. Depois troca de conta para que outra pessoa use o Mac. A execução entra em um ciclo de novas tentativas após um erro temporário e continua mais tarde. A segunda pessoa não a iniciou e talvez nem saiba que ela existe. Mesmo assim, a execução mantém uma aprovação válida porque o software vinculou a aprovação ao calendário, ao dispositivo ou a uma sessão ampla, em vez de vinculá-la ao processo de origem.

A correção não é apenas reduzir o tempo limite da aprovação. Tempos muito curtos interrompem o trabalho real e ensinam as pessoas a passar pelos avisos sem pensar. Vincule a aprovação a uma instância do processo. Quando o processo termina, a concessão acaba. Quando alguém transfere o trabalho intencionalmente, revogue a execução antiga e inicie uma nova. O novo processo cria um novo evento de aprovação com um responsável identificável.

Você também precisa de uma forma visível de responder: «o que ainda está em execução na minha conta?». A resposta não pode depender da memória. Ofereça aos operadores um diário de sessões que mostre a execução, indique se ela continua autorizada e ofereça uma ação direta de revogação. Em uma máquina pessoal, isso é conveniente. Em um Mac compartilhado, faz parte da barreira de segurança.

Os avisos de aprovação precisam da identidade do processo, não de um nome simpático

Um aviso de aprovação precisa mostrar informação suficiente para distinguir o verdadeiro solicitante de uma imitação. Um rótulo como «assistente de programação» não serve quando duas extensões, dois shells ou um script copiado podem usar o mesmo nome. O operador precisa ver o processo de origem e, quando o macOS oferecer essa informação, sua autoridade de assinatura de código.

A autoridade de assinatura de código responde a uma pergunta específica, mas importante: qual identidade de desenvolvedor assinou este processo? Ela não prova que o processo tomará boas decisões. Ajuda o operador a detectar uma solicitação de uma ferramenta sem assinatura, de outra compilação ou de um auxiliar inesperado. Isso é muito melhor do que aprovar uma solicitação anônima só porque ela apareceu durante uma tarde movimentada.

O aviso também deve indicar a credencial ou a categoria de ação em termos que uma pessoa consiga avaliar. «Usar a credencial X» obriga o usuário a consultar uma planilha mental. «Enviar uma solicitação HTTP à API de implantação usando a credencial de publicação do ambiente de testes» oferece uma base concreta para a decisão. Evite colocar o corpo completo da solicitação em todos os avisos. Avisos longos criam fadiga de aprovação e expõem dados que não deveriam aparecer em uma notificação da área de trabalho. Mostre a ação, o destino, o método e a identidade da credencial de forma fácil de consultar.

A aprovação por sessão e a aprovação por chamada resolvem problemas diferentes. A aprovação por sessão diz: «Reconheço este processo de agente e permito sua execução dentro dos limites definidos». A aprovação por chamada diz: «Estou verificando este uso específico desta credencial». Não substitua a segunda pela primeira só porque a primeira interrompe menos.

Use aprovação por chamada quando as consequências forem difíceis de reverter: uma credencial que possa alterar dados de produção, remover recursos, publicar conteúdo externamente ou acessar uma interface administrativa ampla. Uma aprovação para cada chamada acrescenta atrito. Esse atrito deve aparecer justamente no momento em que uma pessoa precisa parar e pensar.

Use aprovação por sessão para trabalhos em que o processo seja identificável e a credencial permitida tenha impacto limitado. A sessão precisa terminar quando o processo terminar. Uma concessão geral para «agentes neste Mac» é uma brecha de política com um nome amigável.

A recomendação popular de desativar aprovações em uma máquina local de desenvolvimento confiável está errada para Macs compartilhados. Ela é popular porque os avisos interrompem o fluxo e porque os desenvolvedores consideram os processos locais privados. A Troca Rápida de Usuário elimina essa premissa. Uma máquina local pode conter vários contextos de usuário ativos, e um processo familiar pode continuar muito depois de seu proprietário deixar o teclado.

Macs compartilhados precisam de um procedimento de transferência que encerre a autoridade

Uma transferência adequada encerra a autoridade da pessoa anterior antes de iniciar o trabalho da próxima. Passar uma aba do terminal, uma descrição da tarefa ou uma mensagem de chat não transfere responsabilidade. A pessoa que chega precisa de um processo novo e da própria autorização para usar qualquer credencial.

Use este procedimento quando outra pessoa precisar assumir uma tarefa de agente local:

1. Pare o agente atual se ele ainda estiver tomando decisões. Deixe que grave seus arquivos de trabalho normais, mas não permita que continue chamando sistemas externos durante a transferência.
2. Revogue a sessão do agente no registro de sessões. Confirme que a revogação alterou o estado da sessão antes que o usuário original saia.
3. Bloqueie o cofre do usuário original ou encerre a sessão dessa conta se a máquina permanecer com a próxima pessoa por um período longo.
4. Peça à pessoa que chega para trocar para a própria conta do macOS e iniciar ali um novo processo de agente.
5. Exija uma nova autorização que identifique o processo novo e revise o estado da tarefa antes de permitir ações externas.

Esse procedimento parece rígido até a primeira vez que uma transferência ambígua envia uma solicitação. O custo de reiniciar um agente é pequeno se comparado ao esforço para descobrir quem autorizou uma alteração depois do fato. Se um fluxo não tolera uma reinicialização, ele precisa de um projeto multiusuário deliberado, não de uma transferência acidental por uma área de trabalho compartilhada.

Evite compartilhar uma conta para tornar as transferências mais rápidas. Um login compartilhado destrói as evidências de que você precisará depois. Não será possível saber qual pessoa desbloqueou o cofre, qual terminal iniciou o processo ou quem aprovou a chamada. Contas separadas do macOS não resolvem todos os problemas, mas preservam uma barreira útil e um registro que pode ser usado.

As equipes também precisam de uma regra para proprietários ausentes. Se um processo de agente estiver em execução na conta de uma pessoa indisponível, ninguém deve mantê-lo ativo clicando na conta dela. Pare-o, revogue-o e reinicie-o sob um proprietário presente. O trabalho pode esperar. Uma permissão sem supervisão para modificar sistemas externos não deve esperar.

Bloquear o cofre deve interromper as ações antes que os avisos apareçam

Uma barreira do cofre deve negar todas as ações enquanto estiver bloqueada, mesmo que um processo de agente tenha recebido anteriormente uma aprovação de sessão. Essa é a diferença entre autorização para executar e permissão atual para usar uma credencial. A primeira identifica o processo que a pessoa reconhece. A segunda pergunta se o armazenamento de credenciais está disponível neste momento.

O Sallyport usa essa ordem de propósito: sua barreira do cofre é absoluta e, no macOS, usa Secure Enclave e Touch ID, enquanto as ações com o cofre bloqueado são negadas. Essa ordem impede que uma autorização antiga do agente substitua o acesso ao cofre depois que o usuário bloqueia a própria sessão.

Mantenha os controles separados no seu modelo mental. A barreira do cofre protege o acesso ao material das credenciais. A autorização da sessão reconhece uma execução específica do agente. A aprovação por chamada acrescenta uma revisão direta para determinadas credenciais. Quando um controle assume o trabalho de outro, os operadores perdem a capacidade de entender o motivo de uma negação.

Por exemplo, não faça dos avisos por chamada a única proteção para uma credencial ampla. Uma pessoa pode aprovar por engano a solicitação errada depois de voltar a uma área de trabalho cheia. O cofre bloqueado já deveria ter negado a ação até que o proprietário da credencial se autenticasse localmente. Então o aviso por chamada pode fazer a pergunta mais específica: este uso merece permissão?

Da mesma forma, não mantenha o cofre permanentemente desbloqueado porque uma tarefa longa de programação talvez precise dele mais tarde. Essa escolha transforma uma breve falta de atenção em um período durante o qual um processo antigo pode agir. Desbloqueie para o trabalho supervisionado e bloqueie quando o proprietário se afastar ou entregar o Mac a outra pessoa. Se o trabalho realmente exigir autoridade sem supervisão, transfira-o para um ambiente projetado para identidades de serviço, credenciais limitadas e responsabilidade operacional explícita. Uma sessão pessoal compartilhada não é o lugar certo para imitar um servidor.

A expressão «humano no circuito» costuma esconder a questão da identidade. Qual humano? Em qual conta? Aprovando qual processo? Um aviso que não responde a essas perguntas não oferece um controle significativo. Ele apenas registra que alguém clicou em um botão.

Os registros de auditoria esclarecem a linha do tempo, não a decisão de permissão

Uma trilha de auditoria à prova de adulteração permite reconstruir uma execução do agente depois de uma ação contestada, mas não impede uma autorização ruim no momento em que ela acontece. Use o registro para esclarecer a sequência e a propriedade, depois corrija o controle que permitiu a ação. Não trate o histórico de auditoria como substituto de um cofre bloqueado ou de um limite claro de aprovação.

O registro precisa de duas visões porque os operadores fazem duas perguntas diferentes. Um diário de sessões responde: «Qual execução de agente foi autorizada e posso revogá-la?». Um diário de atividades responde: «Qual chamada ocorreu, por qual canal e quando?». Os dois registros devem vir de uma única fonte somente de acréscimo, em vez de dois bancos de dados sem relação que possam ficar divergentes.

O Sallyport projeta os dois diários a partir de um registro de auditoria criptografado, encadeado por hash e gravado sem possibilidade de sobrescrita. Assim, o histórico de atividades e o histórico de execuções compartilham uma única fonte de registro. A verificação offline está disponível por meio deste comando:

sp audit verify

Execute essa verificação ao arquivar uma máquina, investigar uma transferência contestada ou receber um armazenamento de auditoria exportado. O verificador confere a cadeia sobre o texto cifrado e não precisa da credencial de descriptografia. Essa característica importa em Macs compartilhados: um investigador pode verificar se os registros ainda formam um histórico válido sem receber os tokens de API ou o material SSH a que o histórico se refere.

A verificação informa se a cadeia permaneceu internamente consistente. Ela não prova que todos os eventos foram sensatos, que uma pessoa entendeu cada aviso ou que o próprio dispositivo não sofreu comprometimento. Seja preciso sobre o que está afirmando. Uma cadeia verificada torna mais difícil esconder alterações silenciosas em registros antigos. Ela não transforma uma conta compartilhada insegura em uma conta segura.

Durante uma investigação, compare o contexto da conta, a identidade do processo, o horário da autorização da sessão, o evento de desbloqueio do cofre e a ordem de cada chamada. Uma pergunta útil não é apenas «um agente fez isso?». Pergunte se a mesma conta era proprietária do cofre, do processo do agente e da aprovação. Se esses elementos forem diferentes, você encontrou uma barreira que precisa de atenção.

Chamadas HTTP e SSH trazem riscos diferentes em sessões compartilhadas

Ações HTTP e SSH gastam autoridade, mas deixam rastros operacionais diferentes e falham de maneiras distintas. As credenciais HTTP geralmente apontam para um serviço remoto com amplo escopo de API. As credenciais SSH podem fornecer um shell em um host remoto, onde uma única conexão aceita pode executar vários comandos. Não dê às duas o mesmo tratamento de aprovação apenas porque partem do mesmo agente local.

Para HTTP, examine o destino, o método e o escopo da credencial. Uma solicitação de leitura para uma API de desenvolvimento restrita merece uma regra diferente de uma solicitação de gravação para um endpoint de gerenciamento de ambientes. O agente deve solicitar a ação por meio de um gateway local que injete a credencial, para que o agente receba o resultado, não o token de acesso. Isso limita a exposição do segredo, mas não reduz o impacto de uma solicitação destrutiva aprovada.

Para SSH, concentre-se na identidade do host, na identidade da conta e na intenção do comando. Uma conexão a um host de desenvolvimento com uma conta restrita é muito diferente de uma conexão a uma conta compartilhada de produção. Se a credencial conceder um shell interativo, trate-a como uma permissão de alto impacto, mesmo quando o primeiro comando parecer inofensivo. O próximo pode não ser.

A Troca Rápida de Usuário acrescenta uma condição local aos dois canais. Um processo de agente ativo em uma conta não deve continuar emitindo solicitações HTTP ou abrindo sessões SSH apenas porque outro usuário tornou o Mac ativo. O gateway precisa associar a solicitação ao processo de origem e exigir que o proprietário do cofre atenda à barreira. A tela da segunda pessoa não deve se tornar uma superfície de aprovação para a execução da primeira.

Mantenha credenciais separadas para pessoas diferentes quando a responsabilidade importar. Um token de implantação compartilhado dificulta distinguir um problema do processo de um problema na transferência entre pessoas. Credenciais individuais e entradas de cofre vinculadas à conta tornam o histórico de auditoria útil quando você precisa encontrar o verdadeiro responsável.

Algumas cargas de trabalho não pertencem a uma estação compartilhada

Um Mac compartilhado é um lugar razoável para desenvolvimento local supervisionado, com credenciais restritas e aprovações deliberadas. É um lugar ruim para um agente autônomo de longa duração com autoridade para alterar sistemas de produção, acessar APIs administrativas amplas ou manter shells remotos sem uma pessoa presente.

A divisão não depende de o agente ser inteligente. Depende de ele continuar agindo depois que seu responsável deixa o console. Se puder, use um ambiente criado para esse trabalho. Dê à carga de trabalho uma identidade de serviço dedicada, um proprietário definido, credenciais limitadas e registros que a equipe de operações possa consultar sem pegar emprestada a sessão da área de trabalho de alguém.

Não confunda um projeto de servidor com um projeto de aplicativo local. Um servidor tem outro modelo de ameaça, outros controles de ciclo de vida e expectativas diferentes para execução sem supervisão. Um aplicativo na barra de menus do Mac pode oferecer ao desenvolvedor um controle humano rigoroso sobre ações locais. Ele não deve fingir ser um sistema de automação sem interface só porque alguém quer manter uma tarefa em execução durante a noite.

Para o Mac compartilhado que você já tem, transforme a primeira política em algo concreto: nenhum agente mantém autoridade externa durante uma transferência sem responsável. Teste o que sobrevive à troca de usuário, imponha o bloqueio do cofre quando o proprietário da credencial sair e revogue execuções antigas em vez de esperar que a próxima pessoa perceba que elas existem. É nesse ponto que a Troca Rápida de Usuário deixa de ser uma conveniência da área de trabalho e passa a receber o tratamento de segurança de que precisa.