Macs de desenvolvedor compartilhados: controle o acesso dos agentes às ferramentas

Um Mac de desenvolvedor compartilhado pode atender uma equipe, mas não consegue executar agentes autônomos com segurança se todas as pessoas e todos os processos locais herdarem o mesmo conjunto de credenciais. A falha geralmente começa com uma conveniência: um token de projeto em um arquivo do shell, uma chave SSH carregada uma vez, um editor iniciado por um terminal antigo e um agente ao qual alguém pede para «fazer o deploy». Em pouco tempo, ninguém consegue dizer qual pessoa autorizou a ação ou qual processo ainda tem acesso.

Trate identidade, custódia de credenciais, autorização e evidências como tarefas separadas. Um login do macOS informa qual usuário é responsável por um processo. Ele não prova quem é responsável por um token de nuvem, se um agente deve usá-lo ou se um processo que sobreviveu ao intervalo do almoço ainda deve manter o acesso. Equipes que misturam essas funções acabam criando uma forma muito silenciosa de ampliação de privilégios.

Máquinas compartilhadas precisam de identidades separadas

Uma estação de trabalho compartilhada só funciona quando cada pessoa, cada credencial e cada execução de agente têm uma identidade própria que possa ser inspecionada e revogada. O login da máquina é a primeira barreira, não o modelo inteiro.

Não crie uma única conta «dev» para um grupo só porque ela parece mais fácil de manter. Essa conta transforma a propriedade dos arquivos, o histórico do shell, as sessões do navegador, as entradas do chaveiro e os processos em execução em algo coletivo. Quando um deploy dá errado, o registro de auditoria diz apenas que a conta compartilhada fez isso. Isso não é responsabilização. É um beco sem saída.

Dê a cada desenvolvedor uma conta separada no macOS e use uma identidade de serviço própria para trabalhos sem supervisão quando isso for realmente necessário. Uma identidade de serviço deve ter um responsável, uma finalidade declarada, um conjunto restrito de credenciais e um plano de aposentadoria. Ela não deve virar uma conta de equipe disfarçada que as pessoas usam quando sua própria configuração é inconveniente.

A distinção é mais importante ainda com um agente. Um agente de programação pode iniciar subprocessos, ler seu diretório de trabalho, examinar o ambiente que herdou e chamar ferramentas aprovadas. Se duas pessoas executam agentes pela mesma conta local, o ambiente antigo de uma delas ou um processo auxiliar pode se tornar, por acidente, a autoridade da outra.

A documentação do Apple Platform Security descreve as proteções de contas do macOS relacionadas à separação de dados dos usuários e dos serviços do sistema. Essas proteções são importantes, mas não decidem se um token copiado para um repositório, diretório compartilhado ou ambiente de processo é apropriado para o processo que o encontra. As permissões de arquivos limitam uma classe de erros. Elas não estabelecem a intenção.

Mantenha um registro simples de propriedade para cada credencial que possa modificar sistemas de produção, controle de código-fonte, publicação de pacotes ou dados de clientes:

• Indique um responsável e um contato de reserva.
• Informe o serviço, as operações permitidas e os ambientes.
• Registre onde o segredo fica armazenado e como é feita sua rotação.
• Defina uma data de revisão e um gatilho de aposentadoria.

Evite colocar o segredo literal no registro. A ideia é tornar a responsabilidade visível, não criar outra cópia da credencial.

Ter um responsável identificado não significa que essa pessoa precise executar cada ação manualmente. Significa que alguém pode responder a uma pergunta direta: por que essa credencial existe, quem pode autorizá-la e o que deixará de funcionar se a revogarmos agora? Se ninguém souber responder, revogue-a em um período seguro e recrie o acesso com uma finalidade mais clara.

Uma conta Unix não mantém um segredo copiado sob controle

As barreiras entre contas do macOS protegem os dados apenas enquanto a credencial permanece dentro da conta e não é oferecida por outro caminho. As equipes muitas vezes protegem o diretório pessoal e depois deixam o mesmo token em arquivos do projeto, histórico do terminal, configurações do editor, exportações da CI ou em um processo de agente de longa duração.

Comece com um inventário que verifique os locais realmente usados pelos desenvolvedores. Faça isso com permissão e cuidado: imprimir um segredo ativo no histórico visível de um terminal compartilhado cria justamente o problema que você está tentando encontrar.

# Search filenames and likely configuration references, not secret values.
find "$HOME" -maxdepth 3 \( -name '.env' -o -name '.netrc' -o -name 'credentials*' \) -print

# Show environment variable names for the current shell only.
env | cut -d= -f1 | grep -E 'TOKEN|SECRET|KEY|PASSWORD' || true

# Show loaded SSH identities without printing private key material.
ssh-add -l

O último comando normalmente imprime uma linha por identidade, com uma impressão digital, um algoritmo e um comentário. Se aparecer The agent has no identities., esse é um resultado útil. Se aparecer uma impressão digital que você não consegue explicar, pare de tratar a máquina como limpa e descubra qual fluxo carregou aquela identidade.

Não execute env dentro do registro de um agente nem cole o resultado em uma issue. Agentes, terminais, logs de editores e chamados de suporte são péssimos locais para armazenar segredos. Primeiro procure nomes de variáveis e locais de arquivos. Faça a rotação de uma credencial se houver motivo para acreditar que seu valor entrou em uma transcrição ou no histórico de um repositório.

Uma recomendação que costuma dar errado diz: «Coloque os segredos em um arquivo .env e mantenha-o fora do Git». Ela é popular porque funciona em cinco minutos. Também transforma todo programa iniciado a partir daquele diretório em um possível leitor da credencial. Uma entrada no .gitignore impede um commit. Ela não impede que um agente local leia o arquivo, que uma ferramenta de arquivamento o colete ou que um desenvolvedor o copie para o próximo projeto.

Use arquivos .env apenas para configurações locais de baixo impacto ou para trabalhos temporários de migração com uma data de limpeza definida. Para credenciais que podem alterar sistemas compartilhados, mantenha o valor em um armazenamento local protegido e ofereça ao agente uma operação, não o valor bruto.

A herança entre processos merece a mesma desconfiança. Um terminal exporta DEPLOY_TOKEN; um editor é iniciado por esse terminal; uma extensão inicia um servidor de linguagem; um agente chama uma ferramenta pelo editor. O desenvolvedor original pode ter esquecido o token horas antes, mas cada processo filho ainda consegue lê-lo. As permissões do macOS fizeram exatamente o que deveriam fazer. A equipe entregou o segredo a processos demais.

Custódia da credencial e autoridade para agir são coisas diferentes

Uma credencial responde a «quem pode se autenticar?». A autorização responde a «este processo pode executar esta ação agora?». As equipes muitas vezes tratam a posse da primeira como prova da segunda, especialmente no caso de tokens de API.

Não entregue um token bearer a um agente apenas porque ele precisa fazer uma chamada de API. Um token bearer funciona como a autoridade de quem o possui dentro do escopo que carrega. Quando o token aparece no contexto do agente, em um argumento de ferramenta, no ambiente de um processo filho ou em uma saída de depuração, você deve presumir que qualquer sistema capaz de ler esse material poderá reutilizá-lo.

Em vez disso, defina um contrato de ação. O agente solicita uma operação nomeada com entradas estruturadas. Um componente local confiável mantém a credencial, valida o destino permitido e o formato da solicitação, faz a chamada e devolve o resultado. O agente nunca recebe um espaço vazio que possa preencher depois com alguma outra fonte. Ele não recebe credencial alguma.

Por exemplo, um agente de lançamento pode precisar criar um registro de deploy. A solicitação pode ser assim:

{
  "action": "create_deployment",
  "environment": "staging",
  "revision": "7c31f4a",
  "summary": "Fix request timeout handling"
}

O componente confiável pode associar create_deployment a um endpoint aprovado e a uma credencial armazenada. Ele deve rejeitar uma entrada que tente fornecer um host, caminho, cabeçalho de autorização ou corpo de requisição arbitrário. Se o contrato de ação aceitar URLs e cabeçalhos arbitrários, você recriou o acesso geral à rede com mais cerimônia.

Mantenha o escopo da credencial pequeno o suficiente para que um erro tenha um impacto limitado. Separe acesso de leitura de acesso de gravação. Separe staging de produção. Prefira credenciais de curta duração quando o serviço upstream oferecer esse recurso, mas não trate a curta duração como cura para um escopo amplo. Um token que dura pouco ainda pode fazer uma chamada irreversível no primeiro segundo.

A mesma distinção vale para SSH. Uma chave privada SSH prova o controle de uma identidade. Ela não explica por que um agente local deve executar um comando em um host neste momento. Inclua a seleção do comando e do host na decisão de autorização. Não entregue ao agente um caminho genérico para o shell esperando que as instruções do repositório o controlem.

Processos locais podem pegar mais autoridade do que você pretendia

Um processo local pode herdar autoridade por meio de variáveis de ambiente, descritores de arquivo abertos, sockets Unix, sessões do navegador e serviços auxiliares. O processo arriscado muitas vezes não é malicioso. Ele está antigo, mal configurado ou foi iniciado por alguém que não percebeu o que o processo pai já havia concedido.

Inspecione um processo suspeito antes de encerrá-lo. No macOS, estes comandos fornecem pistas úteis sem expor valores de credenciais:

ps -axo pid,ppid,user,command | grep -i '[a]gent\|[c]laude\|[n]ode\|[p]ython'
lsof -nP -p <PID> | grep -E 'cwd|unix|TCP|IPv4|IPv6'

O primeiro comando mostra o ID do processo, o ID do processo pai, a conta e o comando de inicialização. O segundo costuma mostrar o diretório de trabalho atual, os caminhos dos sockets Unix e as conexões de rede abertas. Um diretório de trabalho dentro de um projeto antigo e um terminal pai de uma sessão anterior explicam mais incidentes do que malwares exóticos.

Não presuma que um processo terminou porque sua janela desapareceu. Editores mantêm servidores de linguagem em execução. Multiplexadores de terminal preservam shells. Ferramentas de build iniciam processos de observação. Um cliente MCP local pode manter uma conexão por muito tempo depois que o desenvolvedor deixou de prestar atenção.

Faça do encerramento do acesso uma ação deliberada. Feche o cliente do agente, encerre a sessão do terminal que o iniciou e remova qualquer autorização temporária concedida para aquela execução. Se um auxiliar precisar continuar em execução, registre sua finalidade e torne sua identidade de processo visível à pessoa que aprova o acesso.

Um teste simples de troca de usuário encontra problemas cedo. O desenvolvedor A executa um agente com acesso a uma ação de staging, fecha o agente e encerra a sessão. O desenvolvedor B entra na própria conta e faz uma solicitação inofensiva. B não deve encontrar o diretório de projeto, as variáveis de ambiente, o socket SSH, a sessão do navegador nem a autorização ativa de A. Se B conseguir acessar qualquer um deles, a equipe tem estado compartilhado que precisa ser removido.

Não resolva isso tornando os desenvolvedores administradores. Direitos de administrador podem ser necessários para a gestão do sistema, mas ampliam o impacto de um instalador descuidado ou de um script local. Use uma conta padrão no trabalho diário com agentes, a menos que uma tarefa específica exija elevação. Nesse caso, eleve os privilégios para essa tarefa e volte ao uso normal.

Agentes SSH exigem o mesmo cuidado que chaves privadas

Um agente SSH mantém a autoridade de assinatura por trás de um socket local. Por isso, um processo que consegue acessar esse socket pode solicitar assinaturas sem ler o arquivo da chave privada. Isso é melhor do que espalhar chaves privadas pelo disco, mas não é uma autorização automática para todos os processos da estação de trabalho.

A documentação do OpenSSH define SSH_AUTH_SOCK como o caminho para o socket do agente. Trate essa variável de ambiente como informação sensível de roteamento. Se um agente a herdar, ele poderá pedir assinaturas das identidades atualmente carregadas no agente SSH. A chave privada continua oculta, mas o risco operacional permanece.

Execute isto antes de usar automação em um sistema remoto:

printf '%s\n' "${SSH_AUTH_SOCK:-SSH_AUTH_SOCK is unset}"
ssh-add -l
ssh -G [email protected] | grep -E '^(hostname|user|identityfile|forwardagent) '

ssh -G imprime a configuração efetiva do cliente OpenSSH. A saída inclui linhas como user deploy, identityfile ... e forwardagent no. Verifique a última linha com atenção. O encaminhamento do agente permite que um host remoto use seu agente local pela conexão encaminhada. Ele deve permanecer desativado, a menos que você consiga explicar exatamente qual salto remoto está sendo feito e por que ele precisa desse recurso.

O manual ssh_config do OpenSSH descreve ForwardAgent e alerta que o encaminhamento pode expor o agente local a usuários com acesso suficiente no host remoto. As equipes ainda o ativam de forma ampla porque isso evita copiar chaves e torna um host de salto conveniente. A conveniência é real. Também é real o fato de que um ambiente remoto comprometido ou permissivo demais pode solicitar assinaturas enquanto a sessão encaminhada existir.

Use identidades separadas para classes de acesso separadas. Uma identidade de deploy de produção não deve ficar ao lado de uma identidade pessoal de controle de código-fonte em um único agente só porque ambas são úteis durante o desenvolvimento. Remova as identidades depois da tarefa quando isso for viável:

ssh-add -d ~/.ssh/id_staging_deploy
# Or clear every identity after a short, dedicated session.
ssh-add -D

Limpar todas as identidades pode interromper outro trabalho legítimo, portanto faça isso no fim de uma sessão dedicada, não em uma aba de shell compartilhada da qual outra pessoa dependa. O melhor padrão é evitar shells compartilhados por completo.

Evite colocar caminhos de chaves privadas, aliases de hosts e regras permissivas de encaminhamento em uma configuração do repositório que todos os desenvolvedores adotem sem pensar. Um repositório pode documentar o host e a conta esperados. Cada desenvolvedor deve decidir qual identidade local pode acessá-los.

A aprovação deve identificar o processo e a ação

Um aviso de aprovação só ajuda quando uma pessoa consegue identificar quem fez a chamada, entender a operação solicitada e revogar a permissão quando o trabalho termina. Um aviso que diz «permitir acesso» ensina as pessoas a aprovar qualquer ruído.

A aprovação por sessão atende ao trabalho de desenvolvimento comum. A primeira chamada de um processo de agente recém-iniciado mostra a identidade do solicitante, e o usuário decide se aquela execução pode usar um canal de ação. A autorização deve terminar quando o processo sair, sem permanecer como uma preferência invisível.

A aprovação por chamada é adequada para ações com consequências desproporcionais: exclusão em produção, publicação de pacotes, alteração de uma configuração de pagamento ou execução de um comando em um host sensível. Ela acrescenta atrito de propósito. Não a aplique a uma simples consulta de status apenas para criar um ritual tranquilizador. As pessoas passarão a aprová-la sem ler.

O cartão de aprovação deve responder a estas perguntas em linguagem clara:

• Qual processo local solicitou o acesso, incluindo sua autoridade de assinatura quando disponível?
• Qual credencial armazenada ou categoria de ação será usada?
• Qual destino, host ou ambiente receberá a solicitação?
• Que operação será realizada e quais entradas alteram significativamente seu efeito?
• A aprovação vale para esta chamada ou apenas até o processo terminar?

Não aceite um sistema de aprovação que identifique o solicitante apenas como «terminal» ou «agente». Uma máquina local pode executar vários terminais e vários processos de agentes. A pessoa que aprova precisa de informações suficientes para distinguir uma execução de trabalho recém-iniciada de um processo antigo que ainda está ativo.

O Sallyport usa uma sequência fixa de decisão: um cofre bloqueado nega todas as ações, um novo processo de agente exige autorização da sessão por padrão e credenciais selecionadas podem exigir aprovação em cada uso. Esse modelo restrito é preferível a uma linguagem local elaborada de políticas em um laptop de desenvolvedor, onde regras obscuras envelhecem mal e ninguém consegue prever com segurança qual delas vencerá.

A aprovação não substitui o escopo. Uma pessoa pode aprovar a coisa errada. Restrinja primeiro destinos, credenciais e formatos de ação. Depois peça aprovação quando o julgamento humano acrescentar um controle útil.

Um log deve responder às perguntas sobre responsabilidade depois do fato

Um registro de auditoria útil permite que um engenheiro reconstrua quem executou o quê, qual processo local recebeu autoridade, que ação externa ocorreu e quando alguém retirou o acesso. O histórico de um terminal não atende a esse padrão porque os usuários podem editá-lo, os shells o rotacionam e processos separados desaparecem em um único arquivo de histórico.

Mantenha duas visões do mesmo fluxo de eventos. Uma acompanha as sessões: identidade do processo do agente, horários de início e término, aprovações e revogações. A outra acompanha as ações: horário, destino, método ou comando, referência da credencial, resultado e erro. Relacione as duas por meio de um identificador de sessão, mas mantenha as informações compreensíveis sem exigir uma escavação arqueológica em um banco de dados.

A evidência contra alterações muda a qualidade da conversa depois de um incidente. Uma sequência gravada uma única vez com hashes encadeados torna alterações silenciosas detectáveis. Ela não prova que toda ação registrada foi sensata e não recupera registros que você não coletou. Ela torna mais fácil contestar a afirmação de que «alguém limpou o log».

Verifique o registro de auditoria de forma independente. O Sallyport projeta seus diários de sessão e atividade a partir de um log de auditoria criptografado e encadeado por hashes, e sp audit verify verifica a cadeia offline sem acesso às chaves do cofre. Essa separação é importante porque o comando de verificação não deve precisar do mesmo armazenamento secreto cujo uso está sendo investigado.

Os logs também precisam proteger os segredos. Registre uma referência da credencial, o nome da ação, o destino e o resultado. Não registre tokens bearer, cabeçalhos de autorização de solicitações, material de chaves privadas nem argumentos de comandos que contenham senhas. Um log completo que reproduz todos os segredos é um segundo cofre de credenciais com um controle de acesso pior.

Revise as ações malsucedidas, não apenas as bem-sucedidas. Negativas repetidas podem revelar um agente tentando usar um contrato de ação obsoleto, um desenvolvedor usando a conta errada ou um processo em segundo plano que sobreviveu à tarefa. Uma ação bem-sucedida sem explicação merece atenção, mas as falhas mostram os pontos em que seus controles não correspondem ao trabalho real.

Um modelo operacional viável para o Mac de uma equipe

As equipes conseguem executar agentes locais com segurança suficiente para trabalhos sérios quando tornam o hardware compartilhado menos importante do que a identidade individual e a autoridade explícita para agir. O modelo operacional precisa de hábitos diários, não de um documento de segurança que só aparece durante a integração.

Use esta sequência ao adicionar um fluxo de trabalho com agentes a uma máquina compartilhada do escritório:

1. Defina o responsável humano, o serviço permitido, o ambiente e a condição de aposentadoria de cada credencial.
2. Crie um contrato de ação dedicado para o agente, em vez de expor um token geral ou uma sessão de shell.
3. Inicie o agente na conta do desenvolvedor pretendido, com um ambiente de credenciais vazio ou mínimo.
4. Aprove o novo processo somente depois de verificar sua identidade e o destino solicitado.
5. Encerre a execução, revogue-a se necessário e confirme que os processos auxiliares e as identidades SSH foram removidos.

Essa sequência é deliberadamente menos conveniente do que colocar um token de produção em um perfil de shell usado por todos. O atalho parece eficiente até que um prestador de serviços use a máquina, um editor herde o ambiente ou um processo antigo permaneça ativo durante o turno da próxima pessoa.

Defina o acesso de emergência antes de uma indisponibilidade. A equipe precisa de uma pessoa documentada que possa aprovar uma ação de emergência, de uma credencial separada com escopo emergencial restrito e de um registro que explique por que ela foi usada. Não deixe um token poderoso em uma pasta compartilhada «para emergências». Ele se tornará acesso comum porque está disponível.

Para trabalhos que exigem um gateway de ação local, mantenha o gateway na conta do próprio desenvolvedor e torne visível a separação entre processos. Um Mac compartilhado pode receber vários usuários ao longo do tempo. Ele não deve abrigar um único conjunto indistinto de autoridades.

Teste a revogação enquanto o agente ainda estiver em execução

A revogação só é confiável se bloquear a próxima ação de um processo que já tinha permissão. Testá-la depois de encerrar todos os clientes prova muito pouco.

Configure uma ação de staging inofensiva que devolva uma resposta conhecida. Inicie um processo de agente, aprove-o para a sessão e execute a ação uma vez. Depois, revogue a sessão ou bloqueie o armazenamento de credenciais enquanto o processo continua ativo. Solicite a mesma ação novamente.

O resultado esperado é uma negativa associada ao processo ativo ou ao estado bloqueado. O agente não deve recorrer a um token no ambiente, a um socket SSH existente ou a uma sessão armazenada do navegador. Se a ação for bem-sucedida, inspecione o caminho usado antes de adicionar mais avisos ou políticas.

Faça o mesmo teste depois que um desenvolvedor encerrar a sessão e outro entrar. Em seguida, teste depois que a máquina entrar em repouso e despertar, porque conexões auxiliares locais e agentes SSH às vezes revelam suposições que só aparecem ao longo de um dia inteiro de trabalho. Mantenha um registro curto dos resultados, incluindo a identidade exata do processo e a ação testada.

A primeira mudança mais útil não é um gerenciador de segredos maior nem uma lista de aprovação mais longa. Remova uma credencial ampla do alcance de um agente, substitua-a por um caminho de ação restrito e prove que a revogação interrompe um processo que ainda está em execução. Esse teste mostra se a equipe controla o acesso ou apenas o documenta.