Quem aperta o sim: onde as ferramentas de agentes de IA realmente perguntam antes de agir

Quase toda ferramenta de agentes diz que vai consultar você antes de fazer algo que não dá para desfazer. A pergunta que vale fazer é onde essa verificação fica. Ela pode estar nas instruções do agente, no cliente que roda o agente, em um gateway entre o agente e aquilo que ele controla, ou em lugar nenhum. Só uma dessas opções consegue parar um agente que decidiu não perguntar, e até ela tem uma porta dos fundos.

Este artigo lê as análises que publicamos nesta semana com uma única pergunta: quem aperta o sim. Ele não trata de modelos de triagem nem de filtros contra injeção de prompt, que o nosso guia de guardrails para apps e agentes de IA cobre, nem de sandboxes para agentes de programação, que estão no nosso guia de cinco camadas. Todos os fatos abaixo vêm das análises e dos documentos dos projetos que elas citam; não rodamos essas ferramentas nós mesmos.

Quatro lugares onde um sim pode morar

• No prompt. Uma linha em um skill ou em um prompt de sistema dizendo ao modelo para perguntar antes. O modelo lê isso como conselho.
• No cliente. Claude Code, Codex, Cursor e os demais mostram um pedido de aprovação antes de uma ferramenta rodar. Ele vale até alguém desligá-lo, e a maioria dos clientes permite isso.
• Em um gateway. Um programa no caminho entre o agente e o celular, a conta ou a casa sobre a qual ele age, que segura a ação até uma pessoa responder. É o único tipo que o modelo não consegue contornar no papo.
• Em lugar nenhum. A ferramenta faz o que mandam, e a única verificação é a que o cliente tiver ligada no momento.

O prompt: um pedido, não uma tranca

O Agent Autoloop (3.8) é incomumente franco sobre isso. Ele roda Claude Code ou Codex sem supervisão a partir de tarefas cron e webhooks, e cada regra pode levar askFirst, uma instrução para consultar você antes de passos arriscados. As próprias notas de segurança do projeto dizem que askFirst é só um pedido escrito no prompt: o agente pode ignorá-lo e o hub não consegue impedir. O que de fato limita uma execução é o nível de acesso, que corresponde aos modos de permissão do próprio cliente, e o nível full corresponde a bypassPermissions no Claude Code e a danger-full-access no Codex, ou seja, nenhuma aprovação para nada.

O Google Agent Skills (4.2) mostra a mesma brecha pelo outro lado. O skill de gcloud diz que mudanças de IAM, ativação de APIs e exclusões precisam da sua aprovação explícita e, no mesmo arquivo, manda o agente adicionar --quiet a todo comando para que o gcloud nunca pare na própria confirmação. O skill cloud-run-basics ativa APIs, concede um papel de IAM e publica um serviço público com --allow-unauthenticated, cada passo com --quiet. A única confirmação que um programa impunha foi removida, e a que sobra é uma frase que o modelo pode seguir ou não.

O cliente: a confirmação que dá para desligar

Na maioria dos servidores MCP, o pedido de aprovação do cliente é toda a história de segurança. O X MCP (3.8), servidor oficial do X, não tem nada do lado do X que pergunte antes de um post sair; sem a chave de somente leitura, a única verificação é o pedido do seu cliente, que a maioria dos clientes deixa desligar. Um post custa $0.015 e um post com link $0.200, então um agente solto gasta dinheiro além de reputação.

Várias ferramentas analisadas nesta semana estão a uma configuração de distância de esse pedido sumir. O nível full do Autoloop é uma delas. O llama-modchip (3.6) pode iniciar o Claude Code apontado para o modelo local, e o script dele só adiciona --dangerously-skip-permissions quando MODCHIP_CLAUDE_SKIP_PERMS=1 está definido, o que é o padrão certo e fácil de mudar. O pedido do cliente é um controle real, mas pertence a quem edita a configuração, e uma instalação sem supervisão costuma ser montada justamente desligando-o.

Um pedido do cliente também não prova quem respondeu. O Call Me (3.6) liga para o seu celular quando um agente para em uma pergunta e devolve sua resposta falada como transcrição. Um "sim, pode publicar" chega como texto puro, sem nada que mostre que foi você, o endpoint hospedado não tem autenticação além do seu número de 10 dígitos, e a análise deixa claro que uma segunda confirmação precisa vir das configurações de permissão do próprio agente.

O gateway: o que segura

O Pinky (3.6) é o gateway mais claro que já lemos. Todo toque que um agente dá no seu celular passa por ele. Um toque em Pagar ou Enviar volta para o agente como approval_pending, nada acontece no celular até você clicar em Allow, e sem resposta em 60 segundos conta como não. Apps de banco e gerenciadores de senha ficam ocultos para os agentes, e códigos de uso único chegam a eles como pontinhos. Dois limites importam. De fábrica, só pagamentos, operações na bolsa e transferências esperam por você; envios, exclusões, chamadas e instalações precisam ser ligados em Settings. E botões arriscados são reconhecidos pelos rótulos em 10 idiomas, então um rótulo estranho pode passar, e por isso existe um modo que pergunta antes de cada passo.

O Codex Security (4.1) coloca o limite em uma sandbox, não em uma pessoa. A validação roda em somente leitura e sem rede; a geração de patches, o passo que escreve, verifica se a sandbox inicia e recusa com SANDBOX_UNAVAILABLE se não iniciar. A opção --external-sandbox desliga essa proteção e deixa o isolamento por conta do seu contêiner, e os workers do Deep scan são somente leitura, mas, nas palavras da OpenAI, não são um ambiente isolado e offline.

O Stroq (3.8) fica nos hooks do agente, pergunta a você sobre comandos que repetem texto que o agente acabou de ler em uma página, issue ou arquivo, e nega curl | sh de cara. O próprio README o chama de filtro, não de sandbox: a comparação é feita no texto, então um comando que o modelo escreve do zero não tem como ser ligado a uma fonte, e no Codex e no Windsurf o hook pode recusar, mas não perguntar.

Em lugar nenhum: ferramentas que simplesmente agem

O HomeMCPBridge (2.8) conecta um agente ao HomeKit da Apple. A ferramenta control_device recebe o nome de um dispositivo e uma ação, e entre as ações estão destravar uma fechadura e abrir um portão de garagem. Pela nossa leitura do código, não há etapa de confirmação, nem lista de permissões, nem como deixar fechaduras em somente leitura. O iPhone MCP (3.2) controla um iPhone real pelo app de espelhamento da Apple sem etapa de confirmação, sem lista de apps permitidos e sem modo somente leitura; o próprio aviso do projeto cita mensagens indesejadas, dados apagados e compras.

O design mais forte deste grupo é uma ferramenta que não existe. O WhatsApp MCP (finereli) (3.8) não tem ferramenta de envio, de propósito, então a pior falha de um agente de mensagens não pode acontecer. O read_only=true do X MCP faz o mesmo no servidor: ferramentas que postam, enviam mensagens ou alteram qualquer coisa saem da lista, e o servidor recusa essas chamadas mesmo que o token tenha permissão de escrita. Uma ferramenta ausente não precisa de ninguém apertando nada.

Todo gateway tem uma porta dos fundos

Um gateway só segura se for a única entrada. O FAQ do Pinky diz isso sem rodeios: um agente que consegue rodar comandos como você alcança um celular Android pelo adb e pula todas as regras. O conselho é rodar esses agentes em uma sandbox sem acesso ao celular, ou ligar o celular em outro computador e se conectar ao Pinky lá por HTTP. Isso descreve o Claude Code e o Codex na configuração normal, então, para a maioria dos leitores, o gateway só protege o celular depois desse passo extra.

A mesma lógica vale ao contrário. Um proxy no caminho vê tudo o que passa. O billion-context (3.4) fica entre um agente de programação e a API do modelo para dobrar o contexto antigo, o que significa que todo prompt e toda chave de API passam por ele, sem autenticação, e por padrão ele consulta o npm a cada 3 minutos em busca de uma versão nova de si mesmo. Antes de confiar que um gateway vai segurar ações, pergunte o que ele consegue ler e quem pode mudar o código dele.

Onde mora o sim, ferramenta por ferramenta

Ferramenta	O que pode fazer sem volta	Onde fica a confirmação	Como apertar
Pinky	Pagar, enviar, apagar no seu celular	Gateway; por padrão só pagamentos	Ligar envios e exclusões; manter agentes com shell longe do adb
Agent Autoloop	Tudo o que a CLI do agente faz	Modo de permissão do cliente; askFirst é um prompt	Ficar em edit; dar full só onde rodar sem supervisão for aceitável
Codex Security	Escreve patches	Sandbox, exceto com --external-sandbox	Manter a sandbox embutida; ler cada patch
Google Agent Skills	Publicar, conceder papéis de IAM, ativar APIs	Só o prompt; --quiet remove a do gcloud	Papéis de projeto limitados, orçamento de cobrança, aprovações do cliente ligadas
X MCP	Publicar posts e Articles	Só o cliente, ou read_only=true	Começar em somente leitura; definir um teto de gasto
HomeMCPBridge	Abrir fechaduras e portões de garagem	Em lugar nenhum	Manter longe de agentes que rodam sozinhos
Call Me	Transmite suas aprovações faladas	Configurações de permissão do agente	Tratar um sim por voz como não verificado
Stroq	Pergunta sobre comandos ou os nega	Hooks do agente, comparação de texto	Combinar com um contêiner ou uma conta separada

Regras para aplicar nesta semana

1. Encontre o sim de cada ação irreversível. Para cada pagamento, envio, exclusão, deploy ou ação física, anote qual programa a segura. Se a resposta for "o prompt manda perguntar", conte como nenhuma confirmação.
2. Prefira uma ferramenta ausente a uma confirmada. Uma chave de somente leitura ou um servidor sem ferramentas de escrita vale mais que qualquer prompt. Comece o X MCP com read_only=true e escolha servidores sem enviar e apagar quando o trabalho for ler.
3. Ligue o que o gateway deixa desligado. Os padrões são estreitos. O Pinky só pergunta antes de pagamentos até você incluir envios, exclusões, chamadas e instalações.
4. Feche a porta dos fundos antes de confiar na da frente. Um agente com shell alcança tudo o que sua conta de usuário alcança, adb incluído. Rode-o em uma sandbox ou como outro usuário que não enxergue o dispositivo nem as credenciais que o gateway protege.
5. Procure as chaves nas suas configurações. bypassPermissions, danger-full-access, --dangerously-skip-permissions, --quiet e --external-sandbox removem, cada um, uma confirmação. Saiba onde cada um está definido e por quê.
6. Reforce o prompt com limites que um modelo não pode contestar. Papéis de nuvem estreitos, orçamento de cobrança e teto de gasto em APIs pagas continuam valendo quando o agente pula um passo.
7. Trate um sim remoto como não verificado. Uma ligação ou resposta de chat não prova quem respondeu. Mantenha deploys e pagamentos atrás de uma aprovação ligada ao seu próprio login.

O porém: os gateways que mais seguram são os mais novos. O Pinky tem uma semana, o Autoloop dez dias e o Stroq cerca de dez semanas, e as notas de segurança deles vêm dos mantenedores, não de uma revisão externa. Os controles maduros, pedidos de aprovação do cliente e permissões de nuvem, são justamente os que as pessoas desligam para um agente rodar sem supervisão. Nenhuma ferramenta desta lista torna seguro deixar um agente sozinho com o seu dinheiro ou a porta da sua casa.

Nossa opinião: faça a cada configuração de agente a pergunta que você faria a um funcionário novo com cartão corporativo: quem aprova, e ele consegue aprovar sem você? Se a resposta honesta for o próprio funcionário, não há aprovação. Coloque o sim em um programa que o agente não pode editar, tire as ferramentas de que o trabalho não precisa e guarde sua atenção para os poucos cliques que importam.