Como a aprovação local versus upstream muda o controle de agentes

Um botão de aprovação não é, por si só, uma propriedade de segurança. Seu valor depende de onde a decisão é aplicada, do que o revisor consegue ver, de qual identidade o serviço registra e do que ocorre após um tempo limite ou uma conexão interrompida.

Para um agente de IA que chama uma API, a aprovação local e a aprovação upstream respondem a perguntas diferentes. Uma barreira local pode decidir se este processo de agente pode usar uma credencial ou enviar uma solicitação preparada. Uma barreira upstream pode decidir se o sistema remoto deve aplicar a alteração solicitada ao próprio recurso. Quando uma API já pede confirmação, o projeto adequado raramente é «escolher a opção mais rígida». Escolha a barreira que controla o fato em análise e conecte sua evidência ao restante da ação.

A distinção importa porque uma tela de aprovação bem feita pode esconder uma grande falha de autorização. Um revisor pode aprovar localmente uma solicitação para «implantar a versão 184», enquanto o serviço upstream recebe um token reutilizável e uma carga útil diferente. Ou o serviço upstream pode registrar uma aprovação de implantação sem saber que um processo de agente não confiável montou a solicitação. Os dois registros podem ser verdadeiros e ainda assim não explicar a ação.

Barreiras locais e upstream autorizam coisas diferentes

A aprovação local autoriza o uso de uma capacidade antes que a solicitação atravesse a fronteira da máquina. A aprovação upstream autoriza uma transição de recurso dentro do serviço que controla o recurso. Tratar as duas como equivalentes faz você perder o contexto de quem chama ou o contexto do recurso.

Uma barreira local fica ao lado do agente, do cofre de credenciais, do executor de comandos ou do gateway de ações de saída. Ela pode inspecionar o executável, a assinatura de código, o processo pai, o início da sessão, a credencial escolhida, o host de destino, o método da solicitação e os argumentos propostos. Também pode manter o segredo fora do agente e realizar a chamada por conta própria. Isso responde bem à pergunta: «este processo local pode exercer essa capacidade agora?»

Uma barreira upstream fica no provedor da API ou em um plano de controle conectado a ele. Ela pode inspecionar a versão atual do recurso, a associação à organização, o ambiente protegido, a política do serviço, o estado de conflito e a identidade remota do aprovador. Isso responde bem à pergunta: «esta transição remota exata deve ocorrer considerando o estado atual do serviço?»

A NIST Special Publication 800-207 descreve um ponto de decisão de política e um ponto de aplicação de política, e defende aproximar a aplicação do recurso para manter pequena a zona de confiança implícita. Esse princípio favorece a aplicação upstream para fatos que apenas o proprietário do recurso conhece. Ele não torna uma barreira local dispensável. Um serviço não consegue inspecionar a identidade de um processo local se o cliente não transmitir e vincular essa identidade, e a maioria das chamadas com token de portador identifica quem possui o token, não o processo que causou a chamada.

O OpenSSH torna o caso local concreto. O manual do ssh-add do OpenBSD informa que a opção -c exige confirmação antes que um agente use uma identidade adicionada. O servidor SSH remoto ainda realiza sua própria autorização após essa assinatura. Uma barreira pergunta se o cliente local pode usar a chave. A outra pergunta se a autenticação resultante atende à política do servidor. Chamar qualquer uma delas de duplicada ignora a fronteira que cada uma protege.

A regra prática é simples: a aprovação deve ser aplicada pelo componente capaz de impedir a ação que ela descreve. Uma notificação local que não consegue reter a credencial ou a chamada é encenação. Um comentário upstream registrado depois de uma alteração é revisão, não autorização.

A matriz começa pelo fato em análise

Escolha a barreira principal avaliando o que ela consegue conhecer e aplicar, não contando avisos. A tabela abaixo é a matriz de decisão que uso antes de adicionar qualquer fluxo de aprovação.

<table> <thead> <tr><th>Critério</th><th>Aprovação local</th><th>Aprovação upstream</th><th>Consequência para o projeto</th></tr> </thead> <tbody> <tr><td>Latência</td><td>Normalmente uma interação local mais o tempo da chamada</td><td>Inclui rede, fila do provedor, notificação e tempo do revisor</td><td>Prefira o modelo local para chamadas frequentes e reversíveis quando o contexto local bastar</td></tr> <tr><td>Contexto do agente</td><td>Pode vincular processo, sessão, autoridade do executável, chamada de ferramenta e usuário local</td><td>Em geral vê um token, app, carga de trabalho ou conta de serviço</td><td>Mantenha uma barreira local quando a procedência do processo mudar a decisão</td></tr> <tr><td>Contexto do recurso</td><td>Vê apenas o estado buscado ou fornecido, que pode ficar desatualizado</td><td>Pode avaliar a versão atual, regras de proteção, propriedade e conflitos</td><td>Use revisão upstream para transições cuja segurança depende do estado remoto atual</td></tr> <tr><td>Identidade humana</td><td>Pode vincular a pessoa presente no dispositivo</td><td>Pode vincular uma conta da organização, papel da equipe ou separação de funções</td><td>Use o domínio de identidade que controla a responsabilidade ou preserve ambos</td></tr> <tr><td>Exposição de credenciais</td><td>Pode manter o segredo fora do agente e liberar apenas uma ação</td><td>Em geral começa depois que o cliente já possui credenciais utilizáveis</td><td>A aplicação local é necessária quando a guarda do segredo faz parte do modelo de ameaça</td></tr> <tr><td>Indisponibilidade do serviço</td><td>Pode negar localmente e reter uma intenção pendente</td><td>Não pode aprovar enquanto o serviço ou seu plano de aprovação estiver indisponível</td><td>Defina expiração e cancelamento. Nunca interprete uma indisponibilidade como consentimento</td></tr> <tr><td>Indisponibilidade local</td><td>Bloqueia chamadas protegidas naquele dispositivo</td><td>Pode continuar disponível por outro cliente confiável</td><td>Decida se clientes alternativos são permitidos ou se contornam a proteção</td></tr> <tr><td>Detalhe de auditoria</td><td>Pode registrar avisos, negativas, encerramentos de processo e tentativas de chamada</td><td>Pode registrar solicitações aceitas e alterações autorizadas no recurso</td><td>Conecte os dois registros com um identificador de ação estável</td></tr> <tr><td>Fronteira contra adulteração</td><td>Um host comprometido pode atacar registros ou a interface local</td><td>O provedor controla o registro remoto</td><td>Não peça a um log que prove eventos fora de sua fronteira de confiança</td></tr> <tr><td>Cobertura</td><td>Pode envolver muitas APIs de modo consistente</td><td>Cobre apenas operações que o provedor expõe à sua barreira</td><td>Liste caminhos desprotegidos antes de depender apenas da aprovação upstream</td></tr> </tbody> </table>

Não transforme a tabela em um sistema de pontos com um vencedor universal. Algumas linhas são vetos. Se o agente nunca pode receber uma chave de API, uma confirmação upstream não resolve a exposição da credencial, mesmo que tenha melhor pontuação no contexto do recurso. Se uma implantação de produção exige um aprovador do grupo de operações, um aviso local do Touch ID do desenvolvedor que iniciou o agente não atende à separação de funções.

Classifique a ação antes de escolher um padrão. Chamadas de leitura com baixo risco de exposição podem exigir autorização por sessão, mas não um aviso por chamada. Escritas reversíveis podem usar uma barreira local, uma validade curta e uma chave de idempotência. Transições irreversíveis ou regulamentadas em geral precisam de revisão upstream, pois o serviço controla o estado final e a identidade da organização. Um comando que combina uso de segredo e transição irreversível pode justificar ambas as barreiras, desde que cada aviso deixe claro o que sua própria decisão significa.

Latência inclui espera, expiração e recuperação humana

A aprovação local em geral tem menor latência de interação, mas a medida relevante é o tempo até um resultado seguro e sem ambiguidade. Um aviso rápido seguido de uma nova tentativa incerta não é baixa latência.

Para uma pessoa supervisionando um agente em um Mac, um cartão local pode aparecer enquanto o contexto da solicitação ainda está fresco. O aprovador pode responder imediatamente, e o gateway pode enviar a chamada sem uma segunda ida e volta de notificação. Isso serve para ações como abrir uma pull request rotineira, consultar uma API interna protegida ou executar um comando SSH conhecido durante uma sessão acompanhada, desde que a consequência da ação seja visível localmente.

Os fluxos upstream têm mais pontos de espera. O serviço precisa criar um objeto pendente, selecionar revisores elegíveis, enviar ou exibir uma notificação, esperar por uma identidade da organização, verificar novamente a política atual e, por fim, aplicar a transição. Essa demora é útil quando cria uma separação real de funções ou permite que o revisor veja o estado autorizado. É desperdício quando a mesma pessoa aprova a mesma carga útil duas vezes sem informação nova.

A documentação do GitHub sobre ambientes traz um exemplo útil. Um job que faz referência a um ambiente com revisores obrigatórios espera antes de iniciar e não consegue acessar os segredos desse ambiente até receber aprovação. O GitHub também permite que um ambiente impeça a autoaprovação. Esses detalhes dão sentido à demora upstream: a barreira controla tanto o estado do serviço quanto a liberação de segredos, e pode vincular um revisor diferente de quem iniciou a ação. Uma aprovação local não consegue reproduzir essa relação organizacional apenas exibindo o e-mail do revisor.

Meça pelo menos quatro intervalos em produção: da criação da intenção ao aviso, do aviso à decisão humana, da decisão à execução e da execução ao resultado autorizado. Mantenha negativas e expirações nos mesmos dados. Uma mediana de tempo de aprovação que exclui solicitações abandonadas fará um fluxo quebrado parecer melhor do que é.

A frequência dos avisos também muda o comportamento. Um aviso local a cada chamada em um loop de cinquenta leituras semelhantes treina o revisor a clicar sem ler. Mover os cinquenta avisos para upstream não resolve esse problema. Agrupe apenas ações que compartilham uma capacidade delimitada, um conjunto claro de destinos e um período curto. Mantenha transições destrutivas separadas, mesmo quando agrupá-las seria mais rápido.

Defina uma validade que reflita a velocidade com que os fatos podem mudar. Dez minutos podem ser demais para uma solicitação baseada em uma branch que muda rapidamente e pouco para uma revisão formal de produção. Não renove a aprovação silenciosamente. Se a carga útil, a versão de destino, a credencial ou o conjunto de revisores elegíveis mudar, crie uma nova decisão.

O contexto determina se o revisor consegue avaliar

Um aviso útil contém o menor conjunto completo de fatos necessário para a decisão. Sistemas locais e upstream veem metades diferentes, então copiar uma tela para a outra quase nunca funciona.

O lado local deve mostrar quem está solicitando em termos que a pessoa consiga verificar: identidade do executável, autoridade de assinatura quando disponível, sessão pai, nome da ferramenta, alias da credencial, destino, operação e um resumo legível da carga útil. Ele deve diferenciar os dados que o gateway observou do texto que o agente forneceu. Uma explicação fornecida pelo agente, como «limpeza segura», não é evidência.

O lado upstream deve mostrar o objeto autorizado e a transição proposta: repositório e ambiente, conta e região, versão do recurso, diff, verificações de política, identidade de quem iniciou e aprovadores elegíveis. Ele não deve fingir que conhece a procedência local quando recebeu apenas um token de portador.

Vincule a intenção aprovada à execução com um hash dos campos canônicos da ação. O envelope abaixo é intencionalmente pequeno o bastante para implementar. O action_id conecta os sistemas. O hash impede que uma carga útil posterior aproveite uma aprovação anterior.

{
  "action_id": "act_01JQ7M6F4R2K",
  "session_id": "ses_01JQ7KZ9J1AA",
  "caller": {
    "executable": "/usr/local/bin/agent",
    "signing_authority": "Developer ID Application: Example Team"
  },
  "target": {
    "service": "deploy-api",
    "resource": "production/payments",
    "version": "184"
  },
  "request": {
    "method": "POST",
    "operation": "promote",
    "body_sha256": "98b0...e42c"
  },
  "approval": {
    "scope": "single_action",
    "expires_at": "2026-07-24T14:05:00Z"
  }
}

O executor deve recalcular body_sha256, comparar o recurso e a versão, confirmar a validade e consumir uma aprovação de ação única somente uma vez. Se o agente mudar um argumento após a aprovação, a comparação deve falhar de modo seguro. A solicitação upstream deve transportar action_id em um campo de metadados ou correlação compatível com o provedor, quando possível. Não o esconda em um campo que altere o comportamento de negócio.

Uma captura de tela oferece uma vinculação fraca. Ela pode ajudar uma pessoa a entender uma solicitação, mas o código deve aplicar a relação entre os bytes aprovados e os bytes enviados. Já vi sistemas exibirem um resumo amigável a partir de um objeto e executarem outro objeto montado depois. Revise o caminho de serialização, não apenas a interface.

Uma ação tem três identidades, não uma

Uma ação de agente tem ao menos três identidades: o processo que a propôs, a identidade da credencial que a executou e a pessoa que a aprovou. Resumir as três em um único campo de ator gera logs atraentes que respondem à pergunta errada.

A identidade do processo pode incluir o caminho e hash do executável, a autoridade de assinatura, o processo pai, a sessão de protocolo do agente e o usuário local do sistema operacional. Nada disso se transforma automaticamente em identidade remota. A API normalmente vê um cliente OAuth, conta de serviço, chave de implantação, sessão de função ou token de usuário.

A pessoa que aprova também pertence a um domínio de identidade. A confirmação biométrica local pode comprovar que uma pessoa cadastrada estava presente no dispositivo, dependendo do mecanismo do sistema operacional, mas pode não comprovar qual papel organizacional essa pessoa exerce no momento. Uma conta de revisor upstream pode comprovar a participação na equipe e a separação de quem iniciou a ação, mas talvez não saiba qual binário local solicitou a ação.

Mantenha as três identidades e informe o método de vinculação.

<table> <thead> <tr><th>Identidade</th><th>Exemplo de evidência</th><th>Pergunta que responde</th></tr> </thead> <tbody> <tr><td>Proponente</td><td>Assinatura do processo, hash do executável, ID da sessão</td><td>Qual código em execução solicitou?</td></tr> <tr><td>Executor</td><td>Identidade da API, impressão digital da chave pública SSH, sessão de função</td><td>Qual autoridade realizou a chamada?</td></tr> <tr><td>Aprovador</td><td>Presença do usuário local ou conta da organização upstream</td><td>Qual pessoa aceitou qual risco?</td></tr> </tbody> </table>

Credenciais de portador tornam isso especialmente importante. Se cinco processos de agente compartilham um token, a trilha de auditoria upstream pode identificar corretamente a identidade do token e ainda não distinguir os processos. Um gateway local pode fornecer essa procedência ausente, mas apenas se os registros de sessão resistirem a edição casual e se correlacionarem ao evento remoto.

Não identifique o agente como aprovador quando uma pessoa clicou. Não identifique a pessoa como quem chamou a API quando uma conta de serviço executou a solicitação. Registre a delegação diretamente: o proponente P solicitou a ação A, o aprovador H autorizou o escopo S, o executor E aplicou o resultado R.

A separação de funções é um ponto forte do upstream quando o serviço controla a associação ao grupo e impede a autoaprovação. A aprovação local é mais forte para a presença do usuário e a procedência do processo. Quando a política exigir ambas, peça evidências distintas, em vez de dois cliques da mesma pessoa no mesmo dispositivo.

Uma indisponibilidade precisa deixar um estado durável

Sistemas de aprovação falham gravemente quando tratam erros de rede como problemas de interface. A ação precisa de uma máquina de estados durável que sobreviva a encerramentos de processo, respostas perdidas e à recuperação do serviço.

Use estados explícitos como created, locally_approved, submitted, upstream_pending, executing, succeeded, denied, expired e unknown. Estados finais devem continuar finais. Armazene cada transição com o hash da ação e o horário. Uma reinicialização local pode retomar a observação de uma solicitação upstream pendente, mas não deve criar uma nova alteração, a menos que as regras de nova tentativa permitam.

As regras seguras para indisponibilidade são rígidas:

1. Se a barreira local estiver indisponível, ações protegidas não saem da máquina.
2. Se o plano de aprovação upstream estiver indisponível, ações que dependem dele permanecem pendentes ou expiram.
3. Se a aprovação for bem-sucedida, mas o status da execução for desconhecido, consulte pelo identificador de ação ou de idempotência antes de tentar de novo.
4. Se o recurso mudar enquanto a aprovação aguarda, invalide a decisão ou peça ao serviço upstream que a reavalie.
5. Se um revisor negar ou revogar, cancele qualquer execução pendente e registre se o cancelamento chegou ao serviço.

Falhar com abertura não é estratégia de recuperação. Às vezes, equipes criam um desvio de emergência porque o serviço de aprovação está no caminho crítico. Um desvio pode ser legítimo, mas é uma operação privilegiada separada, com uma pessoa identificada, escopo restrito, duração curta e seu próprio registro durável. Escondê-lo sob «tentar novamente sem aprovação» destrói o controle justamente quando incidentes tornam a revisão mais importante.

As indisponibilidades local e upstream não são simétricas. Uma barreira local ainda pode registrar uma tentativa negada enquanto a rede está indisponível. O provedor não pode registrar uma solicitação que nunca recebeu. Por outro lado, o provedor pode concluir uma ação depois que o processo local falha, deixando o registro local em submitted. A reconciliação precisa aceitar que cada lado possui conhecimento incompleto.

Projete o cancelamento antes do lançamento. Pergunte se uma ação aprovada, mas em fila, pode ser retirada, se uma aprovação expira enquanto a execução está em andamento e qual estado prevalece quando uma negativa disputa com a conclusão. O estado do recurso remoto prevalece para determinar o que ocorreu. O registro de aprovação ainda explica se houve autorização.

Novas tentativas não podem gastar uma aprovação duas vezes

A aprovação e a execução são operações separadas, portanto uma nova tentativa pode duplicar qualquer uma delas. O maior risco aparece quando um cliente recebe aprovação, envia uma alteração, perde a resposta e envia a alteração de novo.

A RFC 9110 define um método idempotente pelo efeito pretendido de repetir uma solicitação idêntica. Ela afirma que clientes não devem tentar automaticamente de novo uma solicitação não idempotente, a menos que conheçam semântica idempotente ou possam determinar que a solicitação original não foi aplicada. A aprovação não muda essa regra. Uma pessoa que consentiu com um pagamento, uma implantação ou uma exclusão não consentiu com um número desconhecido de tentativas.

Use uma chave de idempotência gerada quando a intenção imutável é criada, não quando a execução começa. Vincule-a ao hash da carga útil e preserve-a em novas tentativas seguras. O serviço upstream deve retornar o resultado original para uma chave duplicada ou oferecer uma consulta de status. Se a API não oferecer nenhum dos dois, o gateway deve mover alterações ambíguas para unknown e exigir reconciliação, em vez de adivinhar.

Mantenha identificadores de aprovação distintos de identificadores de idempotência. Uma aprovação pode autorizar uma tentativa de execução, um conjunto limitado de novas tentativas idênticas ou uma capacidade de sessão. Uma chave de idempotência informa ao serviço qual alteração deve ter um único efeito. Juntar os dois significados em um token dificulta expiração, revogação e investigação.

Uma sequência de teste útil não precisa de uma estrutura de injeção de falhas:

1. Crie uma ação aprovada com action_id, hash e chave de idempotência fixos.
2. Envie-a e interrompa a conexão do cliente depois que o corpo da solicitação sair.
3. Reinicie o agente local e deixe a recuperação inspecionar o estado armazenado.
4. Verifique se ele consulta o provedor antes de qualquer nova tentativa.
5. Confirme uma transição autorizada do recurso e uma cadeia vinculada de registros de tentativa.

Execute a mesma sequência quando a aprovação upstream estiver pendente e quando a aprovação expirar durante a desconexão. Se uma reinicialização criar um segundo aviso com um novo identificador, o caminho de recuperação já quebrou a cadeia de custódia.

Para APIs que usam um endpoint de confirmação, inspecione sua semântica. Um padrão de duas chamadas, como preparar e depois confirmar, é seguro somente se a confirmação consumir uma vez um objeto imutável do servidor ou aplicar uma chave de idempotência. Se confirmar apenas repetir campos fornecidos pelo cliente, pode ser mais um endpoint de alteração com um nome tranquilizador.

Auditorias completas conectam intenção, decisão, tentativa e resultado

Nenhum log isolado é completo, a menos que um componente observe a intenção proposta, a decisão de aprovação, a tentativa de saída, a aceitação pelo provedor e o estado final do recurso. Na maioria dos sistemas reais, a completude vem de registros conectados entre fronteiras de confiança.

A auditoria local deve incluir solicitações rejeitadas e expiradas, pois elas nunca aparecem upstream. Ela deve registrar a identidade do processo e da sessão, a versão do resumo exibido, o hash canônico da carga útil, o alias da credencial em vez do segredo, a decisão humana, a tentativa de saída, o código de resposta e qualquer incerteza. A auditoria upstream deve incluir a identidade autorizada, o objeto de aprovação, a identidade do revisor, a versão da política, a versão do recurso, o evento de execução e o status final.

Use um único action_id estável em todos os lugares que você controla, além dos IDs de eventos do provedor quando disponíveis. Não conecte registros apenas por timestamps. Desvio de relógio, agrupamento e chamadas simultâneas acabarão produzindo uma correspondência falsa.

Este formato de evento basta para uma primeira implementação:

{
  "event_id": "evt_01JQ7N2AZ8S4",
  "action_id": "act_01JQ7M6F4R2K",
  "phase": "upstream_result",
  "observed_by": "local_gateway",
  "principal": "service-account:deploy-agent",
  "approver": "org-user:release-reviewer",
  "payload_sha256": "98b0...e42c",
  "provider_event_id": "dep_91358",
  "outcome": "succeeded",
  "recorded_at": "2026-07-24T14:02:18Z"
}

Encadeamento de hashes ou armazenamento somente para acréscimo podem revelar edições posteriores, mas nenhum deles prova que um evento omitido ocorreu. Testes de cobertura devem comparar as fases esperadas para cada classe de ação. Uma leitura pode precisar de intenção, decisão local, tentativa e resposta. Uma implantação protegida também pode precisar de pendência upstream, decisão upstream, execução e versão final do recurso.

A documentação do AWS CloudTrail ilustra o lado do provedor nas evidências de identidade: seus eventos do IAM Identity Center podem identificar se uma solicitação veio de um usuário, função, usuário federado ou outro serviço, e alguns eventos incluem identificadores do Identity Center. Essa é uma evidência autorizada útil, mas ainda não revela qual processo de agente local formou a solicitação, a menos que você propague dados de correlação e mantenha o registro local.

Audite os caminhos de desvio com o mesmo rigor do caminho principal. Uso direto de uma credencial, perfis alternativos de CLI, endpoints de API sem proteção, desvio por administrador e repetição de um objeto aprovado pelo servidor podem tornar irrelevante um log de aprovação perfeito. Sua declaração de cobertura deve informar quais canais a barreira controla, em vez de afirmar que «todas as ações são aprovadas» sem ter um inventário.

Duas barreiras só são úteis se continuarem independentes

Use aprovação local e upstream em camadas quando elas controlarem fatos ou pessoas diferentes. Remova uma delas quando ela apenas repetir a mesma decisão e causar fadiga.

Um fluxo de implantação forte em camadas pode funcionar assim. A barreira local verifica o processo do agente e pede ao desenvolvedor autorização para usar a capacidade de implantação para um único candidato de versão imutável. Ela envia esse candidato sem expor a credencial. O ambiente upstream então pede a um revisor elegível de operações que aprove a promoção com base nas verificações atuais e no estado do ambiente protegido. O log final conecta as duas decisões a uma ação e a uma versão implantada.

Um fluxo fraco em camadas mostra «implantar em produção?» localmente e depois mostra as mesmas palavras upstream para a mesma pessoa. Nenhum aviso inclui hash ou versão, as duas aprovações duram indefinidamente e o agente mantém o token o tempo todo. O segundo clique acrescenta latência sem acrescentar uma fronteira de confiança.

A recomendação popular «sempre aprove o mais perto possível do recurso» é incompleta. Ela vem de um princípio sólido de aplicação, mas ignora a guarda da capacidade e a identidade do processo local. Use aprovação upstream para a verdade sobre o recurso. Mantenha o controle local quando precisar controlar qual processo pode invocar a capacidade ou impedir que o processo veja o segredo.

O Sallyport ocupa esse papel local para ações HTTP API e SSH: o agente se conecta por meio de seu shim MCP, enquanto os segredos permanecem no cofre criptografado e o app executa a ação. Sua autorização por sessão e a aprovação opcional a cada uso não substituem o ambiente protegido ou o revisor da organização do provedor de API. Elas acrescentam evidências sobre o processo e o uso de credenciais do lado local.

Antes de lançar duas barreiras, escreva uma frase para cada uma: «Esta barreira impede X porque só ela observa Y e aplica Z». Se as frases nomearem o mesmo X, Y e Z, consolide. Se qualquer componente não puder realmente interromper a ação descrita, corrija o ponto de aplicação antes de aperfeiçoar seu aviso.

Um passo a passo de implantação revela as conexões ausentes

Considere um agente autônomo de programação promovendo a versão 184 para um ambiente de produção cuja API já exige revisão. O fluxo seguro preserva uma única intenção entre a aprovação local, a espera upstream, a execução e a reconciliação.

O agente primeiro propõe uma solicitação canônica com o ambiente, a versão da release, a versão atual esperada e a chave de idempotência. O gateway local atribui action_id, registra a sessão do processo e o hash da carga útil e decide se a aprovação local é obrigatória. A aprovação autoriza apenas aquele hash até uma validade curta. O gateway então injeta a credencial e envia a solicitação preparada.

O provedor cria um objeto de implantação pendente. Seu revisor vê as verificações atuais, o ambiente protegido, a release exata e a identidade da organização que iniciou a operação. A aprovação consome esse objeto pendente. Se a produção tiver avançado da versão esperada, o provedor rejeita ou reabre a revisão, em vez de aplicar um consentimento desatualizado.

Agora interrompa a conexão depois da aprovação upstream. O lado local não deve retornar sucesso nem enviar outra promoção imediatamente. Ele armazena unknown, consulta o provedor usando o ID da implantação pendente ou a chave de idempotência e registra o resultado autorizado. Se o provedor informar sucesso, o diário local encerra a ação existente. Se o provedor não tiver registro, o gateway poderá tentar novamente sob o contrato de idempotência original, se a aprovação continuar válida.

Esse passo a passo revela perguntas que revisões de interface não percebem. O agente pode alterar a release depois do clique local? Outro cliente pode confirmar a implantação pendente? Uma negativa upstream revoga a autorização local? Um desvio por administrador do provedor aparece no registro conectado? Investigadores conseguem provar qual processo propôs a release sem confiar em um rótulo escrito pelo agente?

Escolha a arquitetura a partir dessas respostas. Use apenas aprovação local quando o uso da capacidade local for todo o risco e a ação remota for rotineira, delimitada e recuperável. Use apenas aprovação upstream quando clientes confiáveis já tiverem credenciais aceitáveis e apenas o estado atual do recurso ou o papel da organização puder decidir. Use ambas quando a guarda do segredo ou a procedência do processo importar localmente e a revisão autorizada da transição importar remotamente.

Não prometa que duas aprovações tornam uma ação segura. Elas tornam duas decisões visíveis. A segurança vem de vincular cada decisão a uma intenção imutável, aplicá-la na fronteira que controla o fato, lidar com a incerteza sem efeitos duplicados e preservar evidências conectadas suficientes para reconstruir o resultado quando todos já tiverem esquecido o aviso.