Prompts de aprovação de agentes de IA não são autorização

O Agents SDK da OpenAI agora trata a aprovação humana como estado do ambiente de execução: uma chamada sensível de ferramenta pode pausar a execução, exibir uma interrupção, armazenar a decisão em RunState e retomar a mesma execução depois da aprovação ou rejeição.¹

Esse formato de produto acerta em um ponto. A aprovação pertence ao ambiente de execução, não apenas a uma transcrição de chat.

A pergunta mais difícil vem em seguida: o que o humano realmente autorizou?

Um prompt de aprovação que diz “Permitir comando shell?” ou “Aprovar chamada de ferramenta?” pede que o usuário confie em um momento. Um registro real de autorização delimita uma ação, nomeia o risco, captura evidências, expira e cria uma trilha revisável. Agentes de IA precisam desse segundo formato porque agentes planejam em várias etapas, chamam ferramentas aninhadas, tentam de novo depois de rejeições e levam explicações fluentes para decisões em que uma pessoa pode se sentir pressionada a clicar em sim.

Resumo rápido

Prompts de aprovação de agentes de IA não são autorização. Um prompt pode pausar o trabalho, mas a autorização precisa definir quem concede autoridade, qual agente a recebe, qual ferramenta pode ser executada, qual recurso ela pode tocar, qual faixa de risco se aplica, por quanto tempo a concessão vale, quais evidências sustentaram a decisão e como o operador pode revogá-la. Equipes devem projetar aprovações como objetos de autoridade delimitada, não como interrupções de chat. A pergunta certa não é “alguém clicou em aprovar?”. A pergunta certa é “qual ação concreta uma pessoa responsável autorizou, sob quais restrições?”.

Principais pontos

Para equipes de produto: - Represente a aprovação como um objeto de decisão tipado: ação, recurso, risco, evidência, expiração e reversão. - Separe confirmações de baixo risco de autorizações de alto risco.

Para equipes de segurança: - Trate prompts repetidos de aprovação como uma superfície de ataque, não apenas como um problema de UX. - Registre cada permissão, negação, permissão automática, negação automática, expiração e revogação.

Para criadores de agentes: - Pause antes da ação irreversível, não depois que o agente já tiver moldado o resultado. - Devolva a rejeição ao modelo como uma instrução restrita, não como uma falha vaga.

Para operadores: - Nunca aprove uma chamada de ferramenta quando você não consegue ver o recurso de destino, o escopo da autoridade e o caminho de reversão. - Prefira concessões delimitadas e de curta duração a hábitos persistentes de “sempre aprovar”.

Por que prompts de aprovação falham?

Prompts de aprovação falham quando comprimem uma decisão de alto contexto em um clique de baixo contexto.

Um agente tem mais contexto do que o prompt mostra. Ele pode ter lido arquivos, resumido uma conversa, planejado uma sequência, escolhido uma ferramenta, preenchido argumentos e decidido o momento da ação. O prompt de aprovação costuma mostrar apenas a última etapa. O usuário vê um comando, uma chamada de API, uma ação no navegador ou uma frase escrita pelo mesmo agente pedindo permissão.

Essa interface cria 4 falhas:

O Agentic Top 10 da OWASP nomeia diretamente a falha de persuasão. O post de lançamento diz que explicações confiantes podem induzir operadores humanos a aprovar ações prejudiciais em ASI09, Human-Agent Trust Exploitation.² O risco não exige um modelo malicioso. Um agente prestativo ainda pode vender demais um plano fraco, minimizar incertezas ou esconder uma chamada arriscada de ferramenta dentro de uma sequência de ações inofensivas.

Por isso, a aprovação precisa de um formato melhor. Uma pessoa deve aprovar um registro de ação, não uma bolha de pedido.

O que uma aprovação deve autorizar?

Uma aprovação séria deve autorizar 1 ação concreta sob condições delimitadas.

O artigo “Authenticated Delegation and Authorized AI Agents” enquadra o problema mais amplo como autoridade delegada: usuários precisam de uma forma de restringir permissões de agentes e manter cadeias claras de responsabilidade, usando credenciais específicas de agentes, metadados e configurações auditáveis de controle de acesso.³

Esse enquadramento se traduz bem em design de produto. Uma aprovação deve conter:

Sem esses campos, aprovação vira intuição com botão. Um modelo pode pedir com educação. Um humano pode clicar rápido. Nenhum dos dois eventos prova que a ação fazia sentido.

Como o estado de aprovação deve funcionar?

O estado de aprovação deve sobreviver à pausa, mas continuar estreito.

A documentação do Agents SDK da OpenAI descreve um padrão útil de ambiente de execução. Ferramentas podem declarar needs_approval; o runner avalia a regra de aprovação antes da execução; aprovações não resolvidas aparecem como interrupções; o desenvolvedor pode aprovar ou rejeitar cada item pendente; e a execução retoma a partir de RunState.¹ A documentação também descreve decisões persistentes, como always_approve e always_reject, para chamadas posteriores na mesma execução.¹

A máquina de estados importa porque uma execução pausada de agente não deve reiniciar a partir da memória, recriar a intenção nem perder o contexto da aprovação. Ela deve retomar do ponto interrompido com a decisão anexada.

A opção de decisão persistente cria o próximo requisito de design: toda aprovação persistente precisa de escopo e expiração.

A aprovação persistente pode reduzir a fadiga. A aprovação persistente ampla demais pode transformar um clique cansado em todo o raio de impacto de uma execução.

Onde a aprovação deve ficar no ambiente de execução?

A aprovação deve ficar antes do ponto de commit.

Um ponto de commit é o momento em que um agente cruza de trabalho reversível para efeito colateral: modificar um recurso de produção, enviar uma mensagem, gastar dinheiro, publicar conteúdo, excluir dados, rotacionar uma chave, alterar permissões ou fazer deploy de código. Aprovação humana depois do ponto de commit vira resposta a incidente, não autorização.

A literatura sobre supervisão humana sustenta essa distinção. Um artigo de 2026 na AI and Ethics separa agência operativa, em que a IA gera ou age, de agência avaliativa, em que o humano pode avaliar, contestar e sobrescrever.⁴ Supervisão eficaz não pode depender de uma pessoa acompanhando cada token. A interface precisa reservar o julgamento humano para pontos em que o julgamento ainda pode mudar o resultado.

Isso dá aos produtos de agentes uma regra simples:

Um prompt que aparece depois que o agente já executou a parte arriscada só cria encenação. A pessoa não consegue exercer agência avaliativa se o sistema já gastou a autoridade.

Como evitar fadiga de aprovação?

Fadiga de aprovação é uma falha de segurança porque a fadiga muda a decisão.

Se uma execução pede 40 aprovações, o produto provavelmente falhou antes do clique do usuário. O operador deixa de julgar cada item e passa a administrar incômodo. Atacantes podem explorar esse padrão gerando pedidos repetidos, escondendo ações arriscadas em lotes ou usando linguagem que faz uma chamada perigosa parecer rotineira.

O Agentic Top 10 da OWASP trata a exploração da confiança humano-agente como uma categoria de risco de primeira classe.² A pesquisa em segurança de agentes chega ao mesmo formato pelo lado do sistema. Uma sistematização de março de 2026 sobre segurança de IA agêntica mapeia limites de confiança em prompt injection, envenenamento de RAG, exploração de ferramentas e plugins e ameaças multiagente; ela também pede monitoramento em tempo de execução e controles de resposta a incidente.⁵ Um artigo de maio de 2026 sobre agentes auditáveis em segurança argumenta que listas estáticas de materiais e logs de execução oferecem evidências fragmentadas, a menos que o sistema consiga conectar capacidades, memória, objetivos, trajetórias de raciocínio e ações em caminhos de auditoria consultáveis.⁶

O design de aprovação deve reduzir a fadiga removendo prompts de baixo valor e elevando a qualidade dos prompts de alto valor:

O objetivo não é ter menos controles. O objetivo é ter menos controles sem sentido.

O que a UI de aprovação deve mostrar?

A UI de aprovação deve mostrar a decisão, não a personalidade do agente.

Comece com um cartão compacto de decisão:

Esse cartão ajuda o usuário a responder a uma pergunta: a ação solicitada corresponde às evidências e ao escopo?

O cartão não deve esconder os argumentos exatos. Não deve dificultar a negação. Não deve fazer de “aprovar” o único caminho bem desenhado enquanto “rejeitar” se comporta como exceção. Uma boa superfície de aprovação trata a rejeição como um sinal de controle normal. O agente deve receber uma mensagem precisa: “Negado porque as URLs de origem não foram verificadas” ou “Negado porque o comando toca arquivos fora do escopo da release”.

O que as equipes devem construir primeiro?

Construa um livro-razão de aprovações antes de construir um prompt mais bonito.

Campos mínimos do livro-razão:

1. ID da execução.
2. ID do agente.
3. ID do operador.
4. Nome da ferramenta.
5. Argumentos da ferramenta.
6. Recurso de destino.
7. Faixa de risco.
8. Regra de aprovação acionada.
9. Ponteiros de evidência.
10. Decisão: aprovado, rejeitado, aprovado automaticamente, rejeitado automaticamente, expirado ou revogado.
11. Horário da decisão.
12. Condição de expiração.
13. Resultado depois da execução.
14. Ponteiro de reversão ou contenção.

O livro-razão transforma uma aprovação de evento de UI em registro de responsabilidade. Ele também permite que as equipes façam perguntas melhores depois:

• Quais ferramentas pedem aprovação com frequência demais?
• Quais operadores aprovam ações de alto risco mais rapidamente?
• Quais regras de aprovação geram falsos positivos?
• Quais ações negadas depois encontraram alternativas seguras?
• Quais ações aprovadas causaram rollback?
• Quais concessões persistentes ficaram ativas por tempo demais?

O artigo de maio de 2026 sobre segurança de OS (sistemas operacionais) argumenta que agentes enfrentam problemas familiares de estilo OS: isolamento de recursos, separação de privilégios e comunicação mediada.⁷ Aprovação pertence a essa mesma família. O ambiente de execução deve mediar autoridade como um sistema operacional medeia operações privilegiadas: de forma estreita, consistente e com logs que sobrevivem ao pedido.

Resumo final

Aprovações de agentes de IA precisam virar objetos de autorização. Um prompt de pausar e clicar pode interromper uma chamada de ferramenta, mas não carrega responsabilidade por si só. Sistemas úteis de aprovação definem ator, ação, recurso, risco, evidência, duração, expiração, revogação e auditoria.

A lição de produto é direta: torne silencioso o trabalho de baixo risco, torne explícito o trabalho de alto risco e nunca peça que um humano aprove uma explicação fluente quando o sistema pode mostrar um registro de ação delimitado.

FAQ

Qual é a diferença entre aprovação e autorização para agentes de IA?

Aprovação é um evento de decisão humana. Autorização é a autoridade delimitada que permite que um agente realize uma ação concreta sob condições definidas. Sistemas fortes de agentes conectam as duas coisas: uma aprovação humana cria um registro estreito de autorização com campos de recurso, risco, expiração, evidência e auditoria.

Toda chamada de ferramenta de um agente de IA deve exigir aprovação?

Não. Equipes devem encaminhar aprovações por risco. Leituras de baixo risco dentro de um escopo conhecido podem rodar silenciosamente com logs. Ações de risco médio podem ser agrupadas para revisão. Ações de alto risco, como enviar mensagens, publicar, excluir, fazer deploy, gastar, exportar ou alterar permissões, devem pausar antes da execução.

Aprovações persistentes são seguras para agentes de IA?

Aprovações persistentes podem ajudar quando o escopo continua estreito, curto e visível. Uma aprovação limitada à execução para uma ferramenta somente leitura pode fazer sentido. Uma aprovação persistente ampla para shell, deploy, pagamento, envio de email ou exclusão cria autoridade demais a partir de uma única decisão.

O que um prompt de aprovação de agente de IA deve incluir?

Um prompt de aprovação deve incluir a ação, o recurso, os argumentos da ferramenta, o ator, a faixa de risco, a evidência, a expiração, o caminho de reversão e o ponteiro de auditoria. O prompt também deve oferecer rejeitar, solicitar evidência e dividir escopo, não apenas aprovar.

Como as equipes podem reduzir fadiga de aprovação em produtos com agentes?

Equipes podem reduzir a fadiga permitindo automaticamente ações de baixo risco dentro da política, agrupando decisões de risco médio, interrompendo apenas em pontos de commit, mostrando evidência estruturada, expirando concessões e registrando negação como um caminho normal de controle. Aprovações melhores fazem menos perguntas vagas e mais perguntas precisas.

Referências