Aprovador de ações de agentes de IA: responsabilidade por turno

Um aprovador de ações de agentes de IA deve ser a pessoa responsável pelo sistema afetado durante o turno relevante. Essa função não deve ser atribuída automaticamente ao desenvolvedor que abriu a sessão de programação. Muitas vezes são pessoas diferentes, e tratá-las como equivalentes produz aprovações que parecem legítimas até que uma chamada de produção dê errado.

Já vi isso falhar de uma forma comum, sem sabotagem dramática. Um desenvolvedor pede a um agente que investigue um problema de compilação. O agente encontra um endpoint de produção relacionado, solicita uma escrita para ajustar uma configuração, e o desenvolvedor aprova porque o prompt apareceu em seu terminal. O responsável pelo serviço descobre a mudança mais tarde, durante seu turno de plantão, sem contexto e sem uma resposta útil para «quem aceitou esse risco?».

A responsabilidade precisa acompanhar o sistema, seu estado atual e a pessoa que está com o pager. Um bom desenho de aprovação torna esse fato visível antes que a ação seja executada.

Quem inicia a sessão raramente assume a consequência

A pessoa que inicia um agente é responsável pela solicitação que digitou. Ela não passa automaticamente a ser responsável pelo banco de dados, pela conta do fornecedor, pelo destino da implantação ou pelos dados dos clientes que o agente pode alcançar.

Essa distinção parece minuciosa até que uma tarefa de programação atravesse uma fronteira. Um repositório pode conter scripts de implantação, credenciais operacionais, ferramentas de migração e links para sistemas mantidos por várias equipes. Um agente pode seguir esses caminhos mais rápido que um humano que conhece bem o repositório. A familiaridade de quem iniciou a sessão com uma base de código não concede autoridade operacional sobre todos os sistemas alcançáveis.

Separe três funções no seu desenho:

• O solicitante pede ao agente que investigue, altere ou implante algo.
• O responsável pelo sistema aceita o risco operacional do serviço-alvo durante o turno atribuído.
• O executor tem a capacidade de realizar a chamada ou o comando depois da autorização.

Uma mesma pessoa pode ocupar as três funções em uma equipe pequena. Não há problema, desde que isso seja explícito. O erro é juntá-las silenciosamente porque o agente roda no computador de um desenvolvedor.

Isso também esclarece uma discussão frequente: «O desenvolvedor é responsável pelo agente». Ele é responsável por orientá-lo e pelo código que envia. O responsável de plantão responde pelo comportamento do serviço, pelo tratamento dos dados, pelas decisões de reversão e pelo impacto nos clientes. O prompt de permissão deve chegar à pessoa capaz de tomar essa segunda decisão.

A NIST SP 800-53 Rev. 5, controle AC-2, exige gerentes de contas designados e procedimentos de gestão de contas. Ela não prescreve uma tela de aprovação para agentes, mas a disciplina subjacente se aplica bem: atribua responsabilidade pelo acesso, em vez de tratá-lo como uma propriedade automática de quem está conectado no momento. Para ações de agentes, o gerente de contas relevante costuma ser o responsável atual pelo serviço, não o usuário da estação de trabalho.

A responsabilidade pelo serviço precisa incluir o turno

Um registro duradouro de responsabilidade deve indicar tanto o serviço quanto a pessoa responsável naquele momento. Um nome estático de equipe não basta às 2h da manhã, durante uma ausência ou no meio de um incidente.

Para cada sistema que um agente pode afetar, mantenha uma escala pequena com quatro campos: equipe principal responsável, responsável do turno atual, substituto e caminho de escalonamento. A escala pode ficar em um sistema de plantão, em um repositório ou em um diretório interno. O local importa menos que sua atualização contínua e que um sistema de aprovação consiga consultá-la.

Use o limite de serviço que os operadores usam quando recebem um alerta. «API de pagamentos em produção» é um alvo útil. «Backend» não é. Um rótulo amplo de equipe esconde bancos de dados, fornecedores, classificações de dados e procedimentos de reversão diferentes.

Um registro mínimo pode ser assim:

service: billing-api-production
active_owner: billing-oncall
backup_owner: payments-duty-manager
escalation: incident-commander
approval_rules:
  read_customer_records: session
  change_remote_configuration: per_call
  production_database_write: per_call
  create_vendor_credentials: prohibited

Isso não é uma linguagem de políticas para um agente interpretar. É uma declaração, mantida por pessoas, sobre quem pode tomar decisões e quanto escrutínio uma ação exige. Ela evita uma falha conhecida: uma solicitação de aprovação chega a um canal geral de engenharia, alguém reconhece o nome do repositório e ninguém reconhece o sistema de produção por trás dele.

Trate a escala como dado operacional. Uma reorganização da equipe, um novo serviço gerenciado ou uma mudança na escala de plantão pode torná-la inválida. Se o roteamento das aprovações depender de uma planilha que apenas um gerente pode editar, você criou um ponto único de falha silencioso.

O risco da ação pertence ao alvo, não ao verbo

«Ler» e «escrever» são categorias rudimentares demais para definir direitos de aprovação. Uma leitura em um endpoint público de status é diferente de uma leitura que retorna uma exportação de clientes, um segredo de implantação ou uma lista completa de hosts internos. Uma escrita que cria uma branch temporária é diferente de uma escrita que altera uma configuração de um provedor de pagamentos.

Classifique as ações pelas consequências de um resultado bem-sucedido. Comece pelo sistema e pelos dados-alvo, depois considere a possibilidade de reversão e o alcance do impacto. Assim, os responsáveis têm uma base significativa para escolher o escopo da aprovação.

Um conjunto prático de categorias pode ser pequeno:

• Leituras operacionais rotineiras não retornam material sensível nem alteram o estado.
• Alterações limitadas afetam um recurso conhecido e têm uma reversão documentada.
• Alterações de alto impacto afetam configurações de produção, dados de clientes, acesso ou compromissos externos.
• Ações proibidas nunca devem passar por um canal de agente autônomo.

Não classifique uma ação como de baixo risco porque o método HTTP é GET. Já vi endpoints de diagnóstico retornarem variáveis de ambiente, links assinados e detalhes operacionais que nunca deveriam ter chegado a um agente de programação. O responsável que conhece o endpoint deve classificá-lo.

Da mesma forma, não exija confirmação manual para toda verificação de status inofensiva. Esse desenho cria fadiga de aprovação. Com o tempo, as pessoas clicam em um prompt rotineiro porque esperam que ele seja rotineiro e aprovam justamente a chamada que não era. Reserve a aprovação por chamada para credenciais e alvos em que cada execução merece uma decisão consciente.

O texto da aprovação deve identificar o alvo concreto. «O agente solicita acesso à API» não informa nada ao responsável. «O processo do agente solicita PATCH para a configuração de cobrança em produção usando a credencial billing-admin» oferece informação suficiente para parar e fazer as perguntas certas.

Uma sessão limitada não é um cheque em branco

Uma aprovação de sessão deve abranger um único processo de agente identificável por um período definido, não todos os processos futuros iniciados no mesmo repositório ou pela mesma conta de usuário.

Essa distinção importa quando um terminal permanece aberto durante uma troca de turno, quando um desenvolvedor reinicia um agente depois de alterar suas instruções ou quando um processo local malicioso imita um comando conhecido. Uma aprovação vinculada apenas à identidade do usuário é ampla demais. Uma aprovação vinculada a um processo sem identidade clara é fácil de interpretar mal.

Uma boa aprovação de sessão responde, em linguagem simples, a cinco pontos: qual processo solicitou, quem assinou ou forneceu esse processo, qual canal de ação ele pode usar, qual escopo de serviço se aplica e quando a permissão termina. A sessão deve terminar quando o processo for encerrado. Um novo processo exige uma nova decisão.

A autorização por sessão do Sallyport segue esse padrão ao mostrar a autoridade de assinatura de código do processo solicitante e aprovar aquela execução somente até seu encerramento. Esse é um padrão melhor que confiar em uma aba do terminal, porque uma aba do terminal não é um limite de identidade.

Mantenha as credenciais de alto impacto fora da concessão da sessão. Uma escrita em banco de dados de produção ou uma alteração de acesso de fornecedor deve solicitar o responsável atual a cada uso, mesmo que ele tenha aprovado a sessão de diagnóstico do agente dez minutos antes. A primeira aprovação diz: «Este processo pode trabalhar neste sistema». A aprovação posterior diz: «Aceito exatamente esta ação irreversível ou sensível». São decisões diferentes.

Evite aprovações permanentes chamadas «ferramentas do desenvolvedor». Elas se transformam em conjuntos invisíveis de direitos. Também tornam a revisão de incidentes muito difícil, porque ninguém consegue saber se a pessoa que aprovou esperava que aquele agente usasse a capacidade.

A troca de turno deve transferir autoridade, não apenas informação

Uma mensagem de troca que diz «Alex está de plantão agora» não resolve as aprovações de agentes se as sessões e aprovações de ontem continuarem funcionando sob o responsável anterior.

A pessoa que sai deve transferir o trabalho ativo dos agentes da mesma forma que transfere um alerta parcialmente mitigado. Registre a identidade do processo, os serviços-alvo, o escopo solicitado, a expiração e quaisquer ações aguardando confirmação. A pessoa que entra deve conseguir consultar esse registro antes de aceitar o turno.

Use esta sequência de troca:

1. Encerre ou revogue as sessões que a pessoa que sai não deseja mais patrocinar.
2. Liste as sessões ativas que precisam continuar, com seus alvos e prazos de expiração.
3. Transfira a escala de serviços para a pessoa que entra e confirme seu canal de notificação.
4. Exija que a pessoa que entra tome novas decisões para chamadas de alto impacto.

Não transfira uma aprovação ampla de um turno para outro apenas porque a tarefa de engenharia ainda não terminou. A pessoa que entra pode ter outro contexto de incidente, restrições de manutenção ou conhecimento de um problema em andamento com um fornecedor. A aprovação deve ser dela.

O caso mais delicado é uma ação já em andamento no momento da troca. Se ela for reversível e observável, deixe-a terminar sob a autorização registrada e torne o resultado visível para a nova pessoa responsável. Se for destrutiva, visível externamente ou estiver aguardando uma segunda chamada, pare no limite e peça nova aprovação. Alguns minutos de atraso custam menos que fazer um desconhecido herdar uma mudança de produção não revisada.

Incidentes exigem autoridade mais limitada, não memória mais permissiva

Durante um incidente, as equipes naturalmente querem velocidade. Muitas respondem concedendo a um agente uma permissão ampla e duradoura para «ajudar a corrigir a produção». Essa permissão sobreviverá à urgência e acabará se tornando uma brecha sem explicação.

Atribua a aprovação ao comandante do incidente ou à pessoa formalmente delegada por ele para o sistema afetado. O responsável normal de plantão pelo serviço deve continuar envolvido quando possível, mas um incidente precisa de uma pessoa decisora quando várias equipes tocam a mesma dependência.

Inclua a referência do incidente no registro de aprovação. Limite o escopo ao serviço e à ação de correção. Defina uma expiração curta, compatível com o trabalho, e encerre ou revogue a permissão quando o incidente acabar.

Considere um agente encarregado de mitigar uma fila descontrolada. Ele inspeciona métricas, propõe uma alteração de configuração e solicita um comando que elimina mensagens. O comandante do incidente pode aprovar um ajuste temporário de concorrência depois de revisar a reversão. Não deve aprovar a exclusão de mensagens apenas porque é rápida. A solicitação precisa indicar explicitamente qual fila e quais mensagens serão afetadas, qual caminho de recuperação existe e se os clientes perderão trabalho.

A velocidade vem de caminhos de autoridade preparados, responsáveis claros e solicitações compreensíveis. Ela não vem de transformar todo o pessoal de resposta em administrador de produção durante uma tarde.

Os prompts de aprovação devem levar a uma decisão útil

Um prompt falha quando um responsável competente não consegue entender o que está aprovando em poucos segundos. Ele também falha quando exige uma análise de segurança inédita para uma ação comum. O prompt deve expor os pontos de decisão que o responsável já usa nas operações normais.

Inclua a identidade do solicitante, a identidade do processo do agente, o canal de ação, o rótulo da credencial, o alvo, a operação e o escopo. Para um comando, mostre o comando exato e o host remoto. Para uma chamada HTTP, mostre o método, o host, o caminho e uma descrição segura do corpo. Nunca exiba o segredo como prova de que a credencial existe.

Esta é a diferença entre prompts úteis e inúteis:

Request: production configuration change
Process: signed coding-agent process, session 8f3a
Owner: billing-oncall
Credential: billing-admin
Action: PATCH https://api.internal.example/v1/routing/default
Body: {"provider":"secondary"}
Scope: one call
Reason supplied: mitigate provider timeout during INC-482

Um prompt que diz apenas «Permitir acesso à ferramenta?» empurra o responsável para uma aprovação automática. Ele não informa o alvo nem o efeito. Se sua ferramenta não consegue produzir contexto suficiente para uma decisão, deve negar a ação até que o solicitante o forneça.

Não coloque um campo livre de «motivo» no comando da segurança. Agentes conseguem gerar textos persuasivos com facilidade. Trate o motivo como contexto para a pessoa, enquanto o sistema aplica o alvo, a credencial e o escopo da aprovação.

Os registros de auditoria devem responder às perguntas desconfortáveis

Depois de uma mudança inesperada, as pessoas perguntam quem a aprovou, qual processo a realizou, qual credencial utilizou, qual alvo alcançou e se alguém alterou o registro depois. Uma trilha de auditoria que não responde a todas essas perguntas é apenas um recurso de depuração.

Mantenha as decisões de sessão separadas dos eventos de ações individuais, mas conecte-os. Um registro de sessão estabelece o processo e o responsável que aprovou. Um registro de atividade estabelece cada chamada ou comando e seu resultado. Inclua recusas e revogações. Tentativas malsucedidas muitas vezes explicam uma solução alternativa posterior ou revelam um processo sondando os limites.

Torne o registro resistente a alterações. Um log encadeado por hash permite detectar remoções e modificações quando alguém pode verificar a cadeia de forma independente. Ele não transforma uma aprovação ruim em uma boa e não substitui os controles de acesso. Ele oferece aos investigadores uma forma de testar se o histórico ainda corresponde à sequência registrada.

O Sallyport projeta diários de sessão e atividade a partir de um log criptografado, encadeado por hash e sem permissão de escrita, e sp audit verify consegue verificar a cadeia offline sobre o texto cifrado. Esse desenho é útil porque o revisor não precisa acessar os segredos operacionais para testar a integridade do registro.

Não esconda as ações dos agentes em logs genéricos da aplicação. Esses logs costumam omitir a decisão humana, girar rapidamente e misturar ruído não relacionado à trilha de eventos. Mantenha um registro que um responsável de plantão, um revisor de segurança e um comandante de incidente consigam ler sem reconstruir uma história a partir de seis sistemas.

As falhas de responsabilidade geralmente começam com uma exceção conveniente

O padrão perigoso começa com um atalho razoável. Um desenvolvedor sênior precisa terminar uma migração. O responsável pelo serviço está em outro fuso horário. Alguém adiciona um grupo geral de aprovação, concede uma credencial reutilizável ou mantém uma sessão aberta durante o fim de semana. A exceção funciona e se torna o processo informal.

Então o agente recebe uma tarefa mais ampla. Ele consegue alcançar mais alvos do que a solicitação original exigia. O desenvolvedor original pode estar dormindo, o responsável pode ter mudado de turno e o grupo amplo pode presumir que outra pessoa verificou o prompt. Cada decisão individual parecia defensável. Juntas, elas removeram a responsabilidade.

Corrija isso tornando as exceções estruturadas, não informais. Uma exceção deve indicar serviço, aprovador, motivo, horário de término e ponto de revisão. Deve produzir um registro visível. Não deve ampliar silenciosamente as permissões permanentes de um desenvolvedor.

Resista à recomendação popular de resolver isso com um mecanismo de regras gigantesco. As regras parecem atraentes porque as equipes imaginam que podem codificar cada repositório, branch, endpoint, janela de tempo e cargo. Na prática, ninguém consegue explicar por que uma chamada específica correspondeu a uma regra, e regras antigas se transformam em permissões que ninguém pretendia manter. Comece com um modelo pequeno de decisão: acesso ao cofre, uma decisão de sessão limitada e confirmação por chamada para as ações que merecem isso.

Esse modelo força as equipes a resolver a parte difícil em linguagem simples: quem é responsável por este sistema agora e o que exatamente essa pessoa aceita autorizar?

Coloque o modelo de responsabilidade à prova em um turno real

Você pode encontrar a maioria das falhas de desenho antes de um incidente sério realizando um exercício controlado. Use um sistema de não produção parecido com um serviço que tenha uma escala real de plantão. Inicie uma sessão de agente perto de uma troca planejada de turno, solicite uma leitura rotineira e depois peça uma alteração que exija confirmação individual.

Observe os pontos em que as pessoas hesitam. A pessoa que sai consegue ver as sessões ativas? A pessoa que entra sabe qual serviço passou a controlar? A solicitação de aprovação identifica o processo e o alvo? Qualquer uma das duas consegue revogar a sessão? O registro de auditoria mostra, na ordem, as ações recusadas, aprovadas e executadas?

Não aceite «resolveríamos isso no chat» como resposta. O chat é útil para coordenação, mas não estabelece um limite de decisão nem preserva o registro completo da ação. Uma troca que depende da memória falhará na noite mais movimentada.

Comece registrando o responsável atual e o substituto do primeiro serviço de produção que seus agentes podem acessar. Depois, faça um agente solicitar uma ação limitada contra esse serviço. Se você não consegue identificar a pessoa que deveria aprovar a chamada sem perguntar a outras pessoas, o agente chegou à produção antes do seu modelo de responsabilidade.