# Um gateway de execução só para Mac em frota mista

Um gateway que funciona apenas no Mac pode melhorar a segurança de uma frota mista, mas somente quando o piloto tem um limite rígido de execução. Confundir cobertura de instalação com cobertura de segurança é o erro. Um limite útil informa quais ações devem partir de um Mac cadastrado, quais credenciais podem ficar nele, quem responde pelas exceções e o que acontece quando um fluxo Linux ou Windows precisa do mesmo serviço.

A cobertura parcial é defensável quando protege uma parcela significativa das ações arriscadas e deixa o restante visivelmente inalterado. Ela não é defensável quando as pessoas acreditam que toda ação de agente passa pelo gateway só porque alguns usuários de Mac o instalaram. O piloto deve dificultar esse engano: nomear os fluxos protegidos, marcar os não compatíveis, medir o volume de ações e publicar uma data para decidir entre ampliar, manter ou remover o gateway.

O argumento para esperar parece organizado. Um produto que funcione em toda a frota daria o mesmo controle a cada desenvolvedor. Na prática, a espera também mantém a exposição atual por um período desconhecido, e o produto futuro ainda pode exigir mudanças nos fluxos. A comparação correta não é entre consistência parcial e consistência perfeita. É entre a proteção delimitada de agora e os controles e a data de entrega reais da alternativa.

## A cobertura parcial é uma escolha de controle

Uma implantação parcial funciona quando a equipe escolhe deliberadamente as ações cobertas e consegue provar onde o controle se aplica. A contagem de dispositivos, sozinha, quase nada diz. Dez usuários de Mac podem fazer a maior parte da administração de produção, enquanto cem estações Linux apenas compilam código de teste local. O contrário também pode acontecer.

Comece pela ação, não pelo sistema operacional. Um gateway de execução controla uma chamada no ponto em que ela roda e recebe autoridade. Pergunte quais requisições HTTP, comandos SSH e outras ações externas merecem um limite para a credencial, uma aprovação ou um registro de auditoria. Depois, identifique as máquinas e pessoas das quais essas ações partem hoje. Essa ordem impede que o inventário da frota determine o modelo de segurança.

O limite do piloto deve ter quatro partes:

- pessoas ou funções específicas que podem usar o gateway;
- classes específicas de ações que precisam passar por ele;
- credenciais específicas que vão para o armazenamento controlado;
- fluxos específicos que ficam fora, cada um com um responsável.

A quarta parte é a mais importante. Uma exceção não é apenas uma instalação ausente. É uma rota documentada que ainda usa o modelo antigo de credenciais e controle. Se ninguém responde por essa rota, o piloto cria um ponto cego disfarçado de progresso.

Não diga que o gateway “cobre a frota Mac”. Diga, por exemplo, que ele cobre o SSH de produção do grupo de releases e as chamadas à API de implantação de dois fluxos de agentes quando rodam em Macs cadastrados. Essa afirmação é mais restrita, verificável e difícil de interpretar errado. Um revisor cético pode pedir os logs, o inventário de credenciais e a lista de exceções correspondentes, em vez de discutir o significado de “cobertura”.

Essa precisão também limita o que a equipe de governança pode concluir. Evidências de um piloto delimitado sustentam uma afirmação sobre as ações nomeadas durante o período indicado. Elas não sustentam a afirmação de que todas as credenciais de agentes da empresa agora recebem a mesma proteção. Coloque a declaração de escopo ao lado de cada métrica e exportação de auditoria para que um gráfico não circule sem suas condições.

A cobertura parcial ainda pode reduzir uma exposição séria. Se uma credencial de implantação deixa de entrar no processo do agente, a mudança é real mesmo que outra plataforma mantenha a rota antiga. A afirmação honesta é menor que um programa para toda a frota, mas mais forte que uma contagem de cadastros que não relaciona dispositivos e ações.

## Pessoas, ações e credenciais definem o piloto

Um limite útil nomeia pessoas, ações e credenciais em conjunto porque qualquer uma dessas dimensões pode contornar o controle. Uma lista de usuários de Mac sem ações deixa um usuário cadastrado chamar diretamente uma API sensível. Uma lista de APIs sem credenciais deixa um token antigo no ambiente Linux. Uma lista de credenciais sem pessoas não esclarece a responsabilidade.

Escolha um grupo cujo trabalho seja importante o bastante para testar o controle, mas pequeno o bastante para ser observado de perto. Engenheiros de release, mantenedores de infraestrutura e desenvolvedores que executam agentes autônomos de programação contra sistemas de homologação são candidatos comuns. Não selecione apenas voluntários porque eles já gostam de ferramentas novas. Seus fluxos costumam ser mais limpos que os casos difíceis que decidem se o gateway vai durar.

Para cada fluxo incluído, registre o limite exato da ação. “Administração de nuvem” é amplo demais. “O agente de implantação chama o endpoint de release com a credencial bearer de produção” é útil. “Acesso a servidores” também é amplo demais. “O engenheiro de plantão abre sessões SSH de produção a partir de um Mac cadastrado” dá ao auditor algo para verificar.

Especifique o canal além do destino. Uma chamada HTTP feita por um gateway não significa que um cliente de linha de comando, uma sessão de navegador, um driver de banco de dados ou uma ferramenta SSH local seguem a mesma rota. Duas ferramentas podem chegar ao mesmo serviço com credenciais diferentes e deixar evidências diferentes. Trate cada rota como uma ação separada até os testes provarem que compartilham o controle.

A configuração do agente merece uma verificação própria. Um repositório pode definir o gateway aprovado como ferramenta MCP normal, enquanto um perfil de usuário ainda expõe um comando shell direto ou um token de ambiente. O agente escolherá a rota que suas instruções e ferramentas permitirem. Remova a capacidade direta das ações incluídas ou documente por que ela continua e como os revisores identificarão seu uso.

O posicionamento das credenciais completa o limite. Depois que uma credencial vai para trás do gateway, cópias em perfis de shell, arquivos de ambiente, configuração do agente, gerenciadores de senhas usados para injeção e variáveis de CI podem anular o resultado. O piloto precisa de uma tarefa de remoção para cada cópia antiga que possa aposentar com segurança. Se uma compilação Windows ainda precisa da credencial, registre a dependência em vez de apagá-la e descobrir a falha durante um release.

O documento principal do limite deve caber em uma página antes do registro de apoio. Ele deve informar grupo piloto, datas de início e revisão, ações incluídas, responsáveis pelas credenciais, expectativas de aprovação, localização das evidências e exclusões explícitas. Se a declaração principal exige um diagrama e seis notas, o escopo provavelmente não está resolvido.

Um bom teste é saber se um substituto de plantão consegue responder a duas perguntas sem consultar quem criou o piloto: “Esta ação precisa usar o gateway?” e “Qual rota aprovada existe na minha máquina atual?”. Se alguma resposta depende da memória oral da equipe, o piloto não está pronto.

## Origem da solicitação e da execução são diferentes

A máquina onde uma pessoa ou agente começa o trabalho não precisa ser aquela onde a ação privilegiada é executada. As equipes costumam confundir a origem da solicitação com a origem da execução e então concluem que um aplicativo Mac não ajuda um usuário Linux ou Windows. Essa conclusão pode estar correta para um fluxo local interativo, mas não vale sempre.

Considere um desenvolvedor no Windows que pede a um serviço de automação para implantar uma compilação. A solicitação começa no Windows. Se um Mac controlado recebe uma tarefa restrita e faz a chamada de implantação, o limite de execução está nesse Mac. O desenvolvedor não precisa da credencial de produção. O desenho pode estender a cobertura de ações além da quantidade de desktops, desde que a entrega tenha identidade forte, entradas restritas e trilha de auditoria.

Esse padrão tem limites. Um Mac compartilhado não pode virar uma caixa genérica de comandos remotos. Se os chamadores podem enviar qualquer texto shell, carregar executáveis ou escolher qualquer destino, a equipe apenas transferiu o risco original para um retransmissor poderoso. A interface remota deve expor um vocabulário pequeno de ações, validar cada entrada, vincular solicitações a uma identidade e rejeitar tudo fora de sua finalidade.

A identidade que atravessa a entrega também precisa sobreviver no registro. Registrar apenas a conta compartilhada do Mac mostra ao investigador onde a execução ocorreu, mas não quem a pediu. O registro da solicitação deve conectar uma pessoa ou identidade de carga, a ação permitida, suas entradas importantes, a decisão de aprovação e a chamada resultante. Sem isso, a delegação amplia a cobertura e reduz a responsabilidade.

A disponibilidade também entra na decisão de segurança. Se todos os releases delegados dependem do notebook de um funcionário, uma suspensão comum, viagem ou conserto pode provocar um desvio de emergência. Um piloto pode aceitar esse limite para uma ação rara de homologação. O uso em produção exige um plano de disponibilidade que não transforme Macs pessoais em uma frota informal de servidores.

A latência e a aprovação humana também mudam a resposta. Um usuário Windows que precisa de um terminal SSH interativo não pode simplesmente pegar emprestada uma sessão da barra de menus do Mac sem criar uma rota de acesso remoto. Uma implantação em segundo plano pode tolerar uma fila curta e uma aprovação. Um ciclo local de depuração que faz cinquenta pequenas requisições autenticadas provavelmente não.

Essa distinção dá ao piloto três categorias honestas. Cobertura direta significa que a ação parte de um fluxo local compatível. Cobertura delegada significa que outra plataforma solicita uma ação restrita executada dentro do limite. Sem cobertura significa que ação e credencial permanecem fora. Mantenha esses rótulos separados nos relatórios. Chamar execução delegada de “suporte a Windows” esconderia a arquitetura e criaria expectativas que o piloto não pode cumprir.

## Fluxos não compatíveis precisam de registro público

Documente cada fluxo não compatível antes de mover credenciais, pois a própria migração revelará dependências escondidas. O registro é um controle de trabalho, não um aviso guardado em uma pasta do projeto. Desenvolvedores, equipe de suporte, revisores de segurança e profissionais de resposta a incidentes devem saber onde encontrá-lo.

Use entradas que descrevam rotas reais:

- Um release de produção começa no macOS, chama a API de implantação, tem cobertura direta e pertence ao responsável por releases até a revisão do piloto.
- Uma sessão emergencial de banco de dados começa no Linux, acessa produção por SSH, mantém o processo atual e volta ao responsável pelo banco quando uma opção Linux é testada.
- A publicação de pacotes começa no Windows, envia para um registro com o tratamento atual de tokens e fica com o responsável por builds até o fluxo mudar ou surgir um cliente adequado.
- Uma reinicialização de homologação começa em CI Linux, chama uma API de serviço e continua candidata à delegação sob responsabilidade da plataforma até a revisão de sua interface restrita.

O status precisa de vocabulário fixo. “Em investigação” pode esconder uma lacuna permanente. Use cobertura direta, cobertura delegada, sem cobertura e aposentado. Acrescente “bloqueado” apenas quando o próprio piloto impedir trabalho necessário e trate esse estado como incidente, com responsável e prazo.

O campo de controle atual evita uma suposição perigosa: fora do piloto não significa sem controle. Uma sessão Linux em produção já pode exigir credenciais temporárias e aprovação de um colega. Um token de publicação Windows pode residir em um serviço gerenciado de compilação. Registre esses fatos e compare seus méritos com o gateway. O piloto não deve receber crédito por controles que não criou nem desprezar controles que já funcionam.

Publique os casos não compatíveis perto das instruções de configuração. Quando alguém em uma máquina não compatível encontra apenas “instale o gateway”, essa pessoa improvisa. Ela pode copiar uma credencial de um colega, encaminhar um agente por um host não revisado ou desativar a rota nova para todos. Um registro visível oferece uma resposta aprovada, mesmo quando ela é “mantenha o processo atual até este gatilho ocorrer”.

Dê a cada entrada um método de detecção. Um campo de auditoria no destino, endereço de origem, identificador da credencial ou registro de comando pode distinguir a rota. Se uma entrada não tem sinal observável, diga isso e corrija a lacuna antes de tratar a reconciliação como prova. Um registro cheio de rotas que ninguém reconhece após a execução é só um inventário.

Revise o registro após mudança de equipe, rotação de credencial, implantação de novo agente ou alteração no plantão. Percentuais da frota mudam devagar; um fluxo pode cruzar o limite em uma única solicitação de alteração.

## Uma troca silenciosa de rota quebra o piloto

O piloto falha quando um fluxo coberto volta silenciosamente para uma rota não coberta. A falha costuma parecer inofensiva porque o trabalho termina. O registro de auditoria, a aprovação e o limite de credencial desaparecem, enquanto o sinal de sucesso continua verde.

Suponha que um engenheiro de release normalmente inicie um agente em um Mac. O agente envia a solicitação de implantação pelo gateway, que guarda o token de produção e registra a chamada. Durante um incidente, o engenheiro acessa uma estação Linux porque o Mac está indisponível. O mesmo repositório tem um script alternativo que lê `DEPLOY_TOKEN` do ambiente. Um colega coloca um token no shell para que o release prossiga.

A implantação funciona. A equipe agora tem uma ação no log do serviço, nenhum registro correspondente no gateway, um token de produção exposto ao processo do agente e uma cópia não documentada no histórico ou na configuração do shell. Se a revisão contar implantações bem-sucedidas de usuários de Mac, informará cobertura. Se reconciliar ações sensíveis do serviço com a atividade do gateway, encontrará a lacuna.

A lição imediata não é “proíba Linux durante incidentes”. O trabalho emergencial precisa de alternativas confiáveis. A lição é definir o caminho alternativo antes da pressão. A equipe pode manter o processo Linux atual como exceção explícita, exigir aprovação separada para o incidente e registrar seu uso. Também pode oferecer uma ação de implantação delegada e restrita, executada em um Mac cadastrado. A resposta depende dos requisitos de disponibilidade.

Teste a travessia de propósito. Execute um fluxo incluído de uma máquina não compatível, com o gateway bloqueado, após reiniciar o processo do agente e enquanto o Mac designado está offline. O resultado esperado deve ser uma negação clara, uma rota alternativa documentada ou uma exceção registrada. Sucesso por uma quarta rota desconhecida é um defeito do piloto.

A busca por credenciais faz parte do mesmo teste. Procure o nome da credencial aposentada na configuração do repositório, nas instruções para desenvolvedores, nas variáveis de CI e no ambiente local. Não copie valores secretos para o relatório. Registre cada local, responsável e decisão de remoção. Esse exercício costuma encontrar mais risco que a própria instalação.

## Meça cobertura de ações, não de dispositivos

Meça a parcela de ações sensíveis incluídas que usou a rota prevista, junto com suas exceções, negações e alternativas. “Vinte por cento dos notebooks foram cadastrados” é uma métrica operacional. Ela não diz se o gateway protegeu uma chamada de teste trivial ou todas as implantações de produção.

Defina o denominador antes do início do piloto. Um denominador prático é o conjunto de ações nomeadas no documento de limites durante o período de revisão. Conte evidências do serviço de destino quando possível e reconcilie-as com registros do gateway e exceções aprovadas. Os logs do gateway não revelam sozinhos ações que o contornaram.

Os registros de destino também podem ter lacunas. Um serviço pode registrar a identidade da credencial e o horário, mas omitir a pessoa de origem, ou agrupar operações em uma tarefa. Teste a junção antes de prometer reconciliação exata. Documente os campos que ligam os registros, a janela de tempo aceitável, o tratamento de duplicatas e quem investiga uma ação sem correspondência.

A amostragem ajuda a descobrir tipos de fluxo, mas é evidência fraca para um grupo pequeno de ações de alto impacto. Perder uma única implantação não autorizada importa mais que estimar uma média. Para as ações incluídas, prefira reconciliação completa. Se o destino não permitir, declare a limitação em vez de transformar uma amostra em afirmação de cobertura.

Acompanhe poucas medidas:

- ações cobertas que correspondem a um registro do gateway;
- ações aprovadas feitas por rotas alternativas documentadas;
- ações sensíveis sem registro ou exceção correspondente;
- negações causadas pelo limite funcionando como previsto;
- tarefas bloqueadas sem uma rota utilizável.

Interprete negações e bloqueios separadamente. Uma negação pode provar que um cofre bloqueado ou uma aprovação ausente impediu chamada não autorizada. Uma tarefa bloqueada significa que uma pessoa autorizada não conseguiu concluir trabalho necessário. Juntar os dois premia o controle por prejudicar a disponibilidade ou o pune por negar acesso corretamente.

Dados dos dispositivos ainda têm função. Eles explicam quem podia usar cobertura direta e onde treinamento ou instalação falharam. Combine-os com dados de ações, em vez de apresentá-los como resultado de segurança. Uma frase útil seria: “Oito de dez usuários elegíveis de Mac se cadastraram, e 94 de 100 ações nomeadas de implantação usaram a rota controlada; quatro usaram a alternativa aprovada para incidentes e duas não têm correspondência.” Se não puder sustentar números exatos, relate os registros reais sem inventar percentuais.

Meça também o custo para os operadores. Conte interrupções repetidas de aprovação, tempo gasto diagnosticando lacunas de plataforma, volume de exceções e tempo de recuperação quando o Mac de execução está indisponível. Um controle que impede chamadas arriscadas, mas ensina usuários a aprovar sem pensar, precisa ser redesenhado. Um controle que protege poucas ações com pouco atrito pode merecer expansão mesmo que a maioria dos dispositivos não o execute.

## Dê responsáveis e condições de parada ao piloto

Um piloto precisa de escopo estruturado, responsáveis e condições de parada para não virar permanente por abandono. A configuração abaixo é um documento, não um mecanismo de políticas. Guarde-a junto do manual do piloto, revise mudanças como código e use-a para gerar o registro legível se isso reduzir divergências.

```yaml
pilot:
  name: agent-action-gateway
  starts: 2026-08-03
  review_by: 2026-09-14
  owners:
    security: sec-platform
    operations: release-engineering
  included_actions:
    - id: production-deploy
      origins: [enrolled-macos]
      credential_owner: release-engineering
      fallback: incident-release-process
  unsupported:
    - id: production-ssh-linux
      owner: infrastructure
      current_control: existing-access-process
      revisit_when: supported-execution-path-tested
  stop_if:
    - undocumented-credential-copy
    - required-work-has-no-approved-route
```

Use datas que forcem uma decisão. “Revisar trimestralmente” é fraco porque ninguém sabe qual reunião responde por isso. A revisão deve ter um líder nomeado e três resultados possíveis: ampliar o conjunto de ações, manter o limite enquanto lacunas específicas são resolvidas ou remover o piloto e restaurar o processo anterior documentado.

As condições de parada merecem tanta atenção quanto os critérios de sucesso. Pause a migração se uma tarefa necessária de Linux ou Windows não tiver rota aprovada. Pare o fluxo afetado se o gateway criar execução remota sem controle. Investigue imediatamente quando evidências do serviço de destino mostrarem uma ação incluída sem registro do gateway ou exceção cadastrada.

Sair não prova que a ideia era ruim. Pode mostrar que o fluxo escolhido dependia de ferramentas locais, disponibilidade ou alcance de plataforma ignorados pelo desenho. Preserve o registro, os resultados da reconciliação e as anotações dos operadores. Esse material deixa a próxima comparação muito mais clara que um relatório vago dizendo que usuários “não adotaram” o produto.

Designe uma pessoa para acompanhar a idade das exceções. Sem essa função, credenciais temporárias e scripts alternativos sobrevivem após o fim de seu motivo. Essa pessoa não precisa de autoridade sobre todas as equipes, mas deve poder pedir evidências, agendar revisões e escalar decisões atrasadas.

## O custo da espera pertence à comparação

Compare a cobertura parcial atual com uma opção futura para todas as plataformas avaliando proteção presente, trabalho não compatível, custo operacional e prazo confiável. Não compare um piloto em funcionamento com um produto imaginário que tem paridade perfeita, nenhuma migração e nenhuma data de lançamento.

Esperar é razoável quando o volume de ações protegidas é mínimo, a execução no Mac criaria um retransmissor frágil ou a alternativa planejada já tem responsável financiado e plano de lançamento testável. Esperar também pode vencer quando controles atuais já mantêm credenciais longe dos agentes e produzem aprovações e evidências necessárias. Adicionar outro limite só aumentaria a burocracia sem reduzir a exposição.

A cobertura parcial é razoável quando usuários de Mac executam um grupo concentrado de ações sensíveis, as cópias antigas de credenciais desse grupo podem ser aposentadas e os fluxos não compatíveis continuam sob controles conhecidos. Ela fica mais forte quando o piloto produz evidências comparáveis aos logs de destino. Fica mais fraca quando a delegação vira um serviço remoto genérico ou as exceções exigem credenciais persistentes compartilhadas.

Escreva as afirmações sobre a opção futura. Registre sistemas compatíveis, canais de ação, modelo de credenciais, comportamento de aprovação, exportação de auditoria, trabalho de migração, responsável nomeado e próximo marco verificável. “Esperamos Linux em breve” não é plano. “O fornecedor está trabalhando nisso” também não. Uma branch, build, compromisso contratual ou teste de aceitação agendado dá peso à afirmação.

Inclua o custo de migração dos dois lados. O piloto Mac pode exigir mudanças de configuração, limpeza de credenciais, treinamento e manual de alternativas. A opção futura também não chegará sem integração, testes de aceitação e outra migração de credenciais. Conte o trabalho com responsável e estimativa, e marque o restante como desconhecido. Um zero ao lado de uma migração não planejada é ficção.

A espera deve ter data de revisão como o piloto. Se a alternativa perder seu marco, a equipe deve reconsiderar as ações ainda expostas em vez de adiar a decisão automaticamente. Esperar sem gatilho transforma preferência de produto em exceção de segurança indefinida.

Use o mesmo registro de fluxos para avaliar as duas escolhas. Para cada entrada, escreva o que muda no piloto, o que muda se a equipe esperar e o que continua exposto nos dois casos. Isso impede que a paridade de plataformas esconda diferenças mais importantes. Um produto pode rodar em todo lugar e ainda entregar segredos ao agente. Outro pode manter segredos fora do processo, mas cobrir apenas um host de execução.

Marque uma data de decisão com base em risco e evidência, não em entusiasmo. Nessa reunião, a equipe deve dizer quais ações sensíveis ganharam um limite, quais não, quanto o controle custou aos operadores e se a alternativa ficou mais concreta. Se esses fatos faltarem, prolongar o piloto só prolonga a incerteza.

## Sallyport só cabe em um limite honesto

Sallyport pode apoiar esse tipo de piloto Mac porque seu aplicativo guarda credenciais de API e SSH em um cofre criptografado, executa ações para agentes compatíveis com MCP, aplica sua escala fixa de aprovação e registra sessões e chamadas em um log criptografado ligado por hashes. Ele não transforma uma frota mista em implantação para todas as plataformas, então o limite deve descrever as rotas exatas de execução no Mac que o usam e deixar as demais no registro de incompatibilidades.

A primeira ação deve ser restrita o bastante para uma reconciliação completa. Uma chamada de implantação em produção é melhor candidata que “toda a rede dos agentes”, porque a equipe consegue nomear credencial, destino, chamadores, frequência esperada, alternativa e registros de destino. Mova essa credencial para trás do gateway no grupo cadastrado, remova cópias antigas desnecessárias aos fluxos descobertos e teste negação e alternativa.

Não encaminhe toda solicitação Linux e Windows por um Mac compartilhado apenas para melhorar o gráfico. A delegação se justifica quando a ação remota tem pequena superfície de entrada, chamadores autenticados, autoridade limitada, disponibilidade confiável e registros que ligam o solicitante à chamada executada. Caso contrário, mantenha o processo atual e identifique-o com clareza.

Na data de revisão, amplie apenas se os registros apoiarem. Um piloto bem-sucedido tem poucas ações sem explicação, alternativa utilizável durante falhas, aprovações administráveis e exceções realmente revisadas por seus responsáveis. Um piloto fracassado ensina algo igualmente concreto: de onde a execução realmente parte, quais cópias de credenciais persistem e por que um sistema operacional não consegue sustentar aquele fluxo com segurança.

Frotas mistas raramente ficam uniformes porque um projeto de segurança pede. O resultado duradouro é um limite que continua verdadeiro em um dia comum e durante um incidente. Se o piloto não consegue declarar essa verdade em uma página e prová-la reconciliando ações, pare de chamar isso de cobertura.