Separe o acesso de staging e produção para agentes de programação

Agentes de programação nunca devem alternar entre staging e produção trocando uma variável, uma URL ou uma instrução vaga. Credenciais e destinos separados dificultam uma chamada acidental ao ambiente errado. Uma decisão humana na fronteira de produção torna uma chamada intencional responsabilizável.

Já vi equipes chamarem sua configuração de «ambientes separados» porque tinham dois hostnames em um repositório. Depois, um script de implantação herdou um token de produção, um fixture de teste apontou para um projeto ativo ou um agente encontrou uma credencial em uma sessão de shell e usou o caminho que funcionava. O hostname era de staging. A autoridade era de produção. Isso não é separação.

A regra útil é simples: o acesso ao staging deve permitir que um agente prove que uma alteração funciona sem ter autoridade capaz de afetar a produção. O acesso à produção deve existir como uma capacidade separada e restrita, concedida por uma pessoa para uma execução específica e revogável enquanto a execução estiver ativa.

Nomes de ambientes não criam uma fronteira de segurança

Um rótulo de staging não protege nada por si só. Existe uma fronteira de segurança quando uma chamada direcionada ao staging não consegue se autenticar na produção e quando uma chamada que chega à produção não consegue realizar um trabalho relevante sem uma identidade de produção concedida separadamente.

As equipes costumam misturar três coisas diferentes:

• Roteamento decide para onde vai uma solicitação, como https://api.staging.example.
• Autenticação decide qual principal o serviço enxerga, como uma conta de serviço ou uma chave SSH.
• Autorização decide o que esse principal pode fazer depois que a autenticação é bem-sucedida.

Alterar apenas o roteamento deixa as outras duas partes intactas. Alterar apenas a credencial também deixa uma possibilidade perigosa: uma credencial de staging pode se autenticar na produção porque um administrador reutilizou um cliente, uma função ou uma chave nos dois ambientes. Uma fronteira de ambiente bem definida altera os três elementos.

Comece com contas, projetos, tenants, namespaces ou assinaturas separadas do provedor quando o serviço permitir. Eles fornecem um identificador concreto para conferir. Bancos de dados, armazenamentos de objetos, filas e destinos de implantação separados vêm naturalmente depois. Se um provedor obrigar staging e produção a compartilhar uma conta, crie principais e escopos de recursos distintos. Trate a conta compartilhada como uma fragilidade aceita, que exige revisão adicional.

Não use dados de clientes de produção para tornar o staging mais realista. Copiá-los sem um processo deliberado de anonimização transforma o problema de controle de acesso em exposição de privacidade. Use dados sintéticos no desenvolvimento comum. Se um teste precisar de registros com o formato da produção, gere um conjunto reduzido e higienizado e documente quem aprovou seu uso.

Uma fronteira prática tem evidências que um revisor consegue inspecionar:

A diferença entre um ambiente e um domínio de autorização importa. É possível executar muitos ambientes dentro de um único domínio de autorização, mas um agente com uma credencial compartilhada e ampla pode circular entre eles. Essa configuração ajuda a operação, não a contenção.

Uma credencial de produção precisa ser outra identidade

O acesso à produção precisa de um principal distinto, não de um segundo rótulo preso à credencial de staging. Se o mesmo token de API, função de nuvem, usuário de banco de dados ou chave SSH puder operar nos dois ambientes, um erro de roteamento pode virar um incidente.

Crie identidades com base na ação que o agente precisa executar. Um agente de programação que precisa inspecionar uma implantação não deve herdar permissão para alterar configurações de identidade, excluir armazenamento, ler todas as tabelas de um banco ou abrir um shell interativo em todos os hosts. «Administrador, porque o agente pode precisar» é um atalho que transforma caminhos de código desconhecidos em autoridade de produção.

Divida o acesso pelo impacto, não pelo cargo. As divisões comuns incluem:

• Uma identidade de implantação em staging que pode escrever somente nos recursos de staging.
• Uma identidade de observação em produção que pode ler uma pequena superfície de saúde ou versão.
• Uma identidade de implantação em produção que pode atualizar um único serviço ou canal de versão.
• Uma identidade separada de emergência para pessoas, fora dos fluxos rotineiros dos agentes.

Não dê ao agente o token pessoal de um desenvolvedor. Tokens pessoais acumulam permissões com o tempo, sobrevivem a mudanças de função e costumam funcionar em mais sistemas do que o próprio dono lembra. Eles também deixam o rastro de auditoria ambíguo: o log mostra uma pessoa, mas um processo autônomo fez a solicitação.

Se o provedor oferecer identidade de workload, credenciais de curta duração ou contas de serviço com escopo, use esses recursos. A duração ajuda, mas não corrige um escopo amplo. Uma credencial de administrador válida por dez minutos ainda pode excluir um banco de produção no primeiro minuto.

A Publicação Especial 800-53 do NIST descreve o princípio do menor privilégio no controle AC-6: as organizações devem conceder apenas o acesso necessário às tarefas atribuídas. Isso parece óbvio até que um agente precise de uma correção rápida e alguém escolha uma função de proprietário. O padrão não define a permissão exata para cada caso. Ele torna inevitável a pergunta certa na revisão: qual ação única deixa de funcionar se removermos esta permissão?

Para SSH, chaves separadas são obrigatórias, mas insuficientes. Dê à chave de produção acesso a hosts nomeados ou a uma conta restrita, desative caminhos amplos de encaminhamento quando o ambiente permitir e evite colocar um shell geral atrás de uma credencial destinada a um único comando de implantação. Uma chave que abre um shell irrestrito em produção oferece ao agente uma superfície de ação grande e difícil de revisar.

A separação de endpoints precisa de uma verificação executável

A configuração deve fazer uma mistura entre ambientes falhar antes que uma chamada de API saia da máquina. Não peça ao agente para lembrar em qual ambiente está. Faça o perfil selecionado carregar o destino e o nome da identidade, depois rejeite combinações que você nunca pretende permitir.

Este padrão de shell não armazena segredos. Ele valida os valores que selecionam o segredo e o endpoint antes que um wrapper ou corretor de credenciais faça a solicitação:

#!/usr/bin/env sh
set -eu

case "${AGENT_ENV:?set AGENT_ENV}" in
  staging)
    API_BASE="https://api.staging.example.internal"
    CREDENTIAL_REF="agent-staging-deploy"
    ;;
  production)
    API_BASE="https://api.example.com"
    CREDENTIAL_REF="agent-production-deploy"
    ;;
  *)
    printf '%s\n' "AGENT_ENV must be staging or production" >&2
    exit 64
    ;;
esac

printf 'environment=%s\nendpoint=%s\ncredential_ref=%s\n' \
  "$AGENT_ENV" "$API_BASE" "$CREDENTIAL_REF"

Uma chamada ao staging produz uma saída com este formato:

environment=staging
endpoint=https://api.staging.example.internal
credential_ref=agent-staging-deploy

Trate essa saída como um registro de pré-verificação, não como prova de autorização. O script apenas impede uma associação local incorreta. O armazenamento de credenciais ou o gateway de ações ainda precisa recusar a resolução de agent-production-deploy enquanto uma pessoa não tiver concedido acesso à produção.

Evite configurações que aceitem URLs arbitrárias do agente. Uma interface de solicitação como curl "$TARGET" com um token bearer transforma toda string gerada em um possível destino. Mesmo agentes cuidadosos cometem erros, e texto não confiável em um repositório pode influenciar as chamadas de suas ferramentas. Em vez disso, ofereça ao agente ações nomeadas ou perfis de endpoint fixos.

O mesmo princípio vale para SSH. Não exponha um argumento genérico host junto com uma chave de produção. Vincule uma ação de implantação em produção a um grupo de hosts e a um comando remoto esperados, ou faça a pessoa escolher o destino no momento da aprovação.

Uma verificação que compara apenas uma string como production tem um ponto fraco: nomes podem mentir. Confira também os identificadores do provedor. Um número de conta na nuvem, ID de projeto, ID de assinatura, proprietário do repositório ou ID do cluster de banco de dados oferece algo menos sujeito a mudanças quando alguém copia um arquivo de configuração.

Prompts não podem autorizar uma alteração ativa

Uma instrução que diz «nunca toque na produção» é um contexto útil, mas não é controle de acesso. Agentes seguem saídas de ferramentas, arquivos do repositório, descrições de tarefas e seus próprios planos intermediários. Qualquer um deles pode criar conflito ou confusão. Um prompt não fica diante da solicitação de rede para negá-la.

Uma decisão de produção precisa de um ponto de aplicação fora do processo do agente. Esse ponto deve saber qual processo solicitou a ação, qual identidade de produção ele quer usar, para onde a chamada irá e qual é a ação. Depois, deve exigir uma escolha humana explícita ou rejeitar a chamada.

A aprovação por sessão e a aprovação por chamada resolvem problemas diferentes.

A aprovação por sessão funciona quando uma pessoa revisou uma execução limitada, como um agente aplicando um plano de implantação revisado a um serviço. Ela reduz interrupções repetidas e ainda vincula a autoridade a um processo específico. A aprovação deve expirar quando o processo terminar, não permanecer válida pelo resto do dia porque o terminal continua aberto.

A aprovação por chamada é adequada para ações irreversíveis ou de alto impacto: excluir dados, rotacionar credenciais, alterar a exposição da rede, publicar uma versão ou escrever em um banco de produção. Exigir um clique ou autenticação local a cada uso é intencionalmente mais lento. Esse atrito indica que a ação merece atenção.

Não treine as pessoas a aprovar cartões opacos. Uma tela de aprovação deve tornar a decisão clara, mostrando a identidade do processo, o destino, a identidade da credencial, o método e um resumo da solicitação. «O agente solicita acesso» não oferece nada para o revisor avaliar. «Processo de programação assinado solicita POST para o endpoint de implantação em produção usando a identidade de implantação em produção» já permite identificar uma incompatibilidade.

O Sallyport usa essa separação diretamente: o cofre permanece bloqueado até ser aberto por autenticação local; depois, um novo processo de agente exige autorização de sessão por padrão, enquanto credenciais individuais podem exigir aprovação a cada uso. O agente nunca recebe o segredo de API ou SSH.

Essa escolha rejeita uma recomendação popular: colocar um token de produção em uma variável de ambiente rigorosamente controlada e confiar em um prompt cuidadoso. Ela é popular porque é fácil de conectar aos scripts existentes. Falha porque o processo do agente ainda detém a autoridade, e qualquer chamada de ferramenta capaz de ler seu ambiente ou reutilizar seu processo pode gastá-la.

A falha geralmente começa com uma conveniência inofensiva

Incidentes entre ambientes raramente começam com alguém decidindo atacar a produção. Eles começam com uma pequena conveniência que remove uma das verificações.

Considere um repositório de versões com dois perfis. A equipe usa DEPLOY_ENV=staging nos testes e DEPLOY_ENV=production nas execuções ativas. Os dois perfis obtêm DEPLOY_TOKEN do mesmo shell do desenvolvedor porque isso facilitou os primeiros testes. O token tem acesso aos dois projetos de implantação.

Um agente recebe a tarefa de validar uma implantação no staging. Ele lê um script que constrói o endpoint a partir de DEPLOY_ENV. Um comando anterior no mesmo terminal deixou DEPLOY_ENV=production, enquanto um auxiliar posterior imprime um rótulo de staging com base em um arquivo de configuração separado. O agente vê o rótulo, executa o auxiliar e a solicitação vai para o endpoint de produção com um token aceito nesse ambiente.

Nada nessa sequência exige malícia ou uma exploração incomum. A equipe tinha dois rótulos, uma credencial compartilhada, duas fontes de verdade e nenhum ponto de aprovação. Os logs podem até mostrar uma conta normal de desenvolvedor, porque o token compartilhado pertencia a essa pessoa.

Corrigir o problema visível definindo DEPLOY_ENV=staging com mais cuidado não corrige o projeto. O reparo é estrutural:

1. Substitua o token compartilhado por identidades específicas para cada ambiente.
2. Vincule cada identidade à conta, ao projeto ou ao conjunto de recursos permitido.
3. Resolva a identidade por um corretor ou cofre, em vez de usar o ambiente de shell do agente.
4. Exija autorização humana antes que a identidade de produção possa fazer uma chamada.
5. Registre o processo, o destino, a referência da identidade, a ação, o resultado e a decisão de aprovação.

Mantenha as configurações de produção e staging em uma única fonte de verdade revisada quando possível, mas não as torne intercambiáveis. Um bloco copiado com um hostname alterado é onde começa a deriva silenciosa. Torne cada perfil explícito o suficiente para que um revisor possa comparar lado a lado o ID da conta, a referência da credencial e as operações permitidas.

A aprovação de produção deve descrever uma execução limitada

Uma aprovação humana só tem valor quando a pessoa consegue associá-la a um trabalho pretendido. «Permitir produção para este agente» é amplo demais. Isso entrega uma capacidade sem um ponto final que o revisor consiga reconhecer.

Defina uma execução de produção com limites concretos: o processo do agente, o repositório ou a tarefa, o serviço pretendido, a classe de ação permitida e uma condição de expiração. Os detalhes dependem das suas ferramentas, mas a decisão deve responder a estas perguntas antes da primeira chamada:

• Qual processo local está solicitando e é possível identificar sua autoridade de assinatura de código ou seu executável?
• Qual conta ou endpoint de produção receberá a solicitação?
• Qual identidade de credencial será usada pela ação?
• Que ação o agente poderá executar durante esta execução?
• Quando a autorização termina e quem pode revogá-la agora?

A identidade do processo merece mais atenção. Um rótulo de terminal ou um nome de agente declarado é fácil de imitar. Em uma máquina de desenvolvimento gerenciada, a autoridade de assinatura de código fornece uma indicação mais forte de qual programa abriu a solicitação. Isso não prova que a tarefa é sensata, mas ajuda a impedir que outro processo local use um nome conhecido.

A fadiga de aprovações é uma falha de projeto. Se toda solicitação inofensiva de staging pedir um clique, as pessoas aprovarão sem ler. Mantenha o trabalho normal de staging disponível por meio de suas próprias credenciais restritas. Reserve os prompts de produção para chamadas cujo destino e impacto justifiquem a interrupção.

O erro oposto é pior: uma aprovação que silenciosamente cubra todos os processos futuros do agente. Depois de alguns dias, isso não se distingue de acesso permanente à produção. Vincule a aprovação à execução, faça-a expirar quando a execução terminar e torne a revogação imediata, em vez de depender de um ticket tratado mais tarde.

Para uma implantação que altera vários recursos de produção, não finja que cinco aprovações independentes tornam a revisão melhor. Peça uma autorização de sessão somente se o próprio plano for limitado e visível. Exija aprovação por chamada quando cada chamada puder criar um efeito irreversível diferente. O controle deve corresponder à ação, não cumprir um ritual.

Os registros de auditoria precisam mostrar quem usou a autoridade

Um log de auditoria de produção deve permitir reconstruir uma ação sem confiar no próprio relato do agente. Uma transcrição de conversa ou histórico de terminal pode ajudar na investigação, mas qualquer um deles pode estar incompleto, editado ou desconectado da credencial que realmente fez a chamada.

Registre o caminho da solicitação no ponto de aplicação, onde a credencial é usada. Capture a identidade do processo do agente, o identificador da sessão, a referência da credencial solicitada, o destino resolvido, o método ou a classe do comando SSH, o horário, o resultado da aprovação, o status da resposta e o evento de revogação. Oculte segredos e corpos de solicitações sensíveis. Um registro de auditoria útil não precisa se transformar em outra fonte de vazamento de dados de clientes.

O controle AU-2 do NIST SP 800-53 exige a definição dos eventos registrados por uma organização. Esse detalhe importa. «Registramos a atividade do agente» não é uma definição. Decida se uma solicitação negada, uma aprovação, um uso de credencial, uma incompatibilidade de destino e uma revogação de sessão contam como eventos. Se você não consegue ver uma solicitação negada, não sabe se a fronteira interrompeu um erro ou se a solicitação nunca chegou até ela.

A evidência de adulteração importa depois de um incidente, porque os logs comuns da aplicação costumam ficar em um local que um administrador ou processo comprometido pode alterar. Um diário encadeado por hashes torna as mudanças detectáveis quando a cadeia é verificada contra os registros armazenados. Ele não transforma decisões ruins em boas nem substitui backups, revisão de acesso ou retenção externa. Ele oferece aos investigadores uma forma de detectar alterações.

O Sallyport grava as visões de Sessões e Atividade a partir de um único log de auditoria criptografado e encadeado por hashes, e sp audit verify pode verificar essa cadeia offline sem uma chave do cofre. Isso é útil quando a pergunta é se o registro mudou, e não se o agente afirma que se comportou bem.

Crie uma rotina de revisão compatível com o risco. Revise autorizações de produção e tentativas negadas depois de execuções relevantes do agente. Compare periodicamente as identidades de produção em uso com as ações que elas realmente executaram. Permissões que nunca aparecem no log são candidatas à remoção. Permissões que você não consegue explicar já são amplas demais.

Rotação e revogação precisam funcionar durante o incidente

Credenciais separadas só limitam o dano se você puder parar rapidamente de usar a credencial de produção. Um plano de rotação que exige encontrar todos os scripts, editar todas as estações de trabalho e esperar uma janela semanal de implantação não é um controle de incidente.

Dê a cada identidade de agente em produção um responsável, um local onde ela é emitida, uma lista de seus destinos permitidos e um caminho de revogação documentado. Mantenha essas informações separadas do valor secreto. Durante um incidente, as pessoas que respondem precisam saber o que desativar sem abrir arquivos que possam conter credenciais.

Teste esta sequência antes de precisar dela:

1. Inicie uma execução aprovada do agente em produção que possa realizar uma operação inofensiva e reversível.
2. Revogue a sessão ou desative a credencial de produção.
3. Faça o agente repetir a operação.
4. Confirme que o ponto de aplicação a nega e que a negativa aparece no registro de auditoria.
5. Emita uma credencial substituta e confirme que o acesso ao staging continua funcionando de forma independente.

Esse teste detecta uma falha operacional comum: a interface mostra «revogado», mas um token em cache, uma conexão SSH persistente ou um processo de longa duração continua funcionando. Para APIs, examine a duração do token e o comportamento de renovação. Para SSH, examine as conexões existentes e a multiplexação. Um botão de revogação só é confiável quando a próxima ação tentada falha.

Faça a rotação das identidades de staging e produção separadamente. Se um segredo de staging vazar, você não deve precisar interromper a produção. Se a autoridade de produção se tornar incerta, revogue e substitua a credencial mesmo quando a exposição suspeita parecer pequena. As pessoas costumam subestimar a distância percorrida por um token no histórico do shell, na saída de depuração, em logs copiados ou no contexto de ferramentas do agente.

Crie a fronteira antes de conceder acesso ativo

As equipes devem conquistar o acesso à produção por meio de evidências, não da confiança em um prompt ou em um modelo de agente. Uma tarefa de programação geralmente tem um caminho de staging, uma simulação, uma consulta somente leitura ou um fluxo de publicação operado por uma pessoa que pode comprovar a maior parte do trabalho primeiro.

Use este teste de prontidão antes de permitir uma nova ação em produção:

• Staging e produção usam credenciais diferentes que não conseguem se autenticar entre os ambientes.
• O agente não consegue ler segredos em texto simples de arquivos, variáveis de ambiente, prompts ou saídas de ferramentas.
• O caminho da solicitação verifica um destino fixo e um identificador de conta ou projeto do provedor.
• Uma pessoa vê a ação de produção e concede a autoridade fora do processo do agente.
• Revogação, registro de negativas e verificação de auditoria foram exercitados, não apenas presumidos.

Se um item falhar, mantenha a ação no staging ou faça uma pessoa executar o trabalho de produção diretamente. Isso não é uma derrota da automação por agentes. É uma declaração precisa de que o caminho de controle ainda não está concluído.

A melhor primeira permissão de produção costuma ser uma ação restrita de observação contra um endpoint de status não sensível. Ela testa seleção de destino, separação de identidades, aprovação, registro e revogação sem permitir que o agente altere o estado visível para os clientes. Depois que esse caminho sobreviver ao uso real, adicione uma ação de escrita por vez e remova as permissões de que o agente nunca precisa.

Não mescle o acesso de staging e produção mais tarde porque as aprovações parecem inconvenientes. O atrito na fronteira de produção é o preço de saber quem autorizou uma ação ativa, qual processo a executou e como interrompê-la. Mantenha essa fronteira deliberada.