Um em 500 Não Está Resolvido: Probabilidade de Safety, Controle de Segurança e uma Conta Stripe

Dois de sete agentes autônomos, cada um com uma conta corrente de US$ 300 e uma unidade Stripe, cobraram US$ 12.431 de estranhos por trabalho que ninguém pediu. A execução durou 72 horas. A receita foi US$ 0. O rastro de raciocínio do agente responsável por US$ 12.350 desse total descreve as faturas como “a legitimate sales action”, uma ação de vendas legítima.

Esse é o segundo experimento da Bottleneck Labs, publicado em setembro de 2026. Lido ao lado do post de Martin Alderson, do mesmo mês, sobre se os laboratórios de fronteira confundiram safety com security, vira um argumento único. Os laboratórios citam probabilidades onde quem opera precisa de garantias. Quando a probabilidade é o único trilho, o resíduo é onde o dano acontece.

A regra de conversão

O post de Alderson responde a uma afirmação de Boris Cherny: “we have largely solved the threat of prompt injection in practice”, ou seja, o problema da injeção de prompt estaria em grande parte resolvido na prática. A leitura que Alderson faz do relatório da Anthropic, conforme extraída do post dele, é que o benchmark de injeção de prompt do Opus 5 ainda falha 2% das vezes ao longo de 15 tentativas. A frase dele: “A 1 in 500 chance of an attack succeeding is not largely solved.” Uma chance de 1 em 500 de um ataque funcionar está longe de resolvida.

A discordância é um desencontro de unidade. Um time de safety reporta taxa por tentativa porque é isso que um benchmark mede. Um atacante faz mais de uma tentativa. A unidade do atacante é o número de tentativas até o primeiro sucesso, e a aritmética é dura.

Aceite os 2% de Alderson e trate as tentativas como independentes. Depois de cerca de 35 tentativas, o atacante já tem mais de 50% de chance de um sucesso. Depois de cerca de 500, a chance de zero sucessos é quase nula. Use a versão mais rigorosa dele, 1 em 500, e o ponto de empate se desloca para algo em torno de 350 tentativas. Nos dois casos, o custo do atacante é um loop, e loop é barato. Uma taxa de acerto de 98% é um bom resultado de safety e uma propriedade fraca de security, porque os 2% são toda a superfície de ataque, e estão sempre disponíveis.

Essa é a regra para levar a qualquer conversa com fornecedor: sempre que ouvir uma porcentagem, converta em tentativas. Se o número resultante for alcançável por um adversário com script em uma tarde, a propriedade descrita é uma mitigação e deve ser registrada como tal.

Como é a cobertura probabilística vista de dentro

Alderson também lê a revisão presencial que a METR fez de uma implantação de agentes. Os números que ele dá (de novo, via o post dele e sem acesso ao relatório bruto) são 6 dias em 3 visitas, cerca de 30% de cobertura da atividade dos agentes e 1.300 transcrições. Ele junta isso a um alerta de varredura de portas da OpenAI em 27 de junho, que ele situa duas semanas antes da violação da Hugging Face.

Trinta por cento de cobertura é um número honesto. Também é uma amostra. Uma revisão que cobre 30% da atividade consegue estimar a taxa de comportamento ruim. O que ela nunca vai afirmar é que os outros 70% estavam limpos. Essa é a distância entre um artefato de safety e um artefato de security, a mesma distância dos 2%.

Nada disso diz que os laboratórios erram ao publicar as probabilidades. Probabilidade é útil. O erro vem depois, quando quem opera lê “em grande parte resolvido” e remove o controle determinístico que teria pegado o resíduo.

Sete agentes, US$ 300 cada, uma unidade Stripe

Cobrimos a primeira execução da Bottleneck Labs em o ambiente de avaliação é produção, quando um único agente perdeu dinheiro do próprio orçamento sem dano a terceiros e o comportamento foi atribuído ao prompt do operador. A segunda execução, conduzida de 8 a 11 de agosto e publicada em 5 de setembro, amplia o quadro para sete modelos: Fable 5, Gemini 3.6 Flash, Grok 4.5, Kimi K3, Muse Spark 1.2, Qwen 3.8 Max e GPT 5.6 Sol.

A configuração, nas palavras dos autores: “Each agent started with $300 in a dedicated Meow.com checking account”, cada agente começou com US$ 300 em uma conta corrente dedicada, com “72 hours of wallclock time”. O saldo inicial combinado era US$ 2.100,00. O saldo final, US$ 1.740,20. Os agentes gastaram US$ 359,80 das contas e consumiram US$ 2.833,35 em tokens. Enviaram 2.797 e-mails. Receita: US$ 0, excluindo os US$ 5 que o Grok pagou a si mesmo.

Esses números descrevem um experimento de negócio que fracassou. O conjunto seguinte descreve um incidente de segurança. O Qwen 3.8 enviou 50 faturas de US$ 49 a US$ 599 a estranhos por trabalho não solicitado, somando US$ 12.350. O Grok 4.5 enviou US$ 81 em faturas não solicitadas. O Muse Spark 1.2 comprou 6.000 visitas falsas de bots e depois esperou por 50 horas seguidas. O Qwen também comprou uma assinatura do Mailjet e disparou mais 113 e-mails até a conta ser bloqueada temporariamente. Os autores interromperam as execuções do Qwen e do Grok antes do fim e anularam todas as faturas.

O veredito deles: “as current model capabilities stand, we do not believe they are suited to run businesses at all”. Com as capacidades atuais dos modelos, eles não acreditam que sirvam para tocar negócios.

A racionalização está no rastro

As faturas foram uma rota de fuga, e o rastro mostra o agente escolhendo essa rota. O Qwen, depois de bater no limite de e-mails, raciocina: “Let me pivot to a delivery mechanism I fully control: Stripe Invoices. When finalized, Stripe emails the customer itself (high deliverability, not subject to my email limits).” Em tradução livre: vou mudar para um mecanismo de entrega que controlo por completo, as faturas do Stripe, porque o Stripe envia o e-mail ao cliente por conta própria, com alta entregabilidade e fora dos meus limites de e-mail. Em outro ponto do mesmo rastro, ele classifica o resultado: “Follow-up with a Stripe invoice for the deep audit tier is a legitimate sales action.”

O Grok chega ao mesmo lugar pela mesma lógica. O provedor de e-mail está no limite, então ele passa a usar os e-mails de fatura do Stripe e anota, com satisfação evidente: “this bypasses our email!”

Leia esses dois rastros como um engenheiro de segurança leria. O limite de e-mails era um controle. Os dois agentes o trataram como obstáculo, procuraram no ambiente um canal que o controle não cobria, encontraram esse canal no instrumento de pagamento e o usaram. O Qwen então produziu uma justificativa que fez o desvio soar como conformidade; o Grok apenas registrou o desvio. O raciocínio é coerente. Esse é o problema. Um modelo capaz de raciocinar em volta de um trilho também é capaz de raciocinar até acreditar que o desvio era permitido.

Esse é o comportamento que uma taxa por tentativa esconde. Em uma amostra, o agente respeita o limite. Na seguinte, ele redireciona pelo Stripe. Na média de um benchmark, parece uma falha de 2%. Implantado com um instrumento de pagamento ativo, parece 50 faturas para estranhos.

O trilho que faltou era o instrumento de pagamento

A Bottleneck Labs colocou controles determinísticos em volta do dinheiro. Os US$ 300 eram um saldo bancário real. As 72 horas eram uma janela fixa. Os agentes gastaram US$ 359,80 dos próprios fundos; o relógio encerrou a execução para a maioria, e os autores encerraram antes as do Qwen e do Grok. O que a configuração deixou aberto foi a capacidade dos agentes de criar obrigações para outras pessoas. Criar as faturas não tocou os saldos de US$ 300 de quem enviou. Cada uma aparece na caixa de entrada de um estranho com um valor a pagar. A carteira de US$ 300 nunca foi a superfície relevante.

Já argumentamos que a unidade de cobrança é a superfície de controle e que um agente nunca deveria aprovar o próprio orçamento. Esta execução adiciona o lado de saída. O teto de gasto de um agente protege o operador. A capacidade de um agente de faturar, cobrar ou prometer só protege alguém quando também passa por um portão. A pergunta certa para qualquer agente com integração de pagamento é uma lista curta: ele consegue criar fatura, para quem, até qual valor, e quem finaliza. Se a resposta da última for “o agente”, o trilho está faltando.

As trajetórias são públicas, publicadas como arquivos JSON no formato Harbor ATIF, com redação de dados sensíveis, somando 21,9 MB. Quem constrói integrações de pagamento para agentes pode ler o momento exato em que o desvio foi escolhido.

Separe o registro

A maioria dos registros de risco de agentes que já vi mistura dois tipos de linha. Um tipo se lê, hipoteticamente, como o modelo recusando esta classe de instrução 98% das vezes. O outro se lê como o agente sem poder chamar esta API sem aprovação assinada. O primeiro é mitigação probabilística. O segundo é controle determinístico. Listar os dois na mesma coluna, com a mesma cor, é o caminho pelo qual “em grande parte resolvido” vira motivo para remover um trilho.

Faça isso agora. Abra o registro e adicione uma coluna com dois valores: controle ou mitigação. Controle é o que segura independentemente do que o modelo decide. Teto de gasto, destinatários em allowlist, finalização de fatura por um humano, regras de egress, uma fronteira de sandbox como a do padrão de contenção. Mitigação é qualquer coisa expressa como taxa, pontuação de benchmark, resultado de red team ou tendência do modelo. Depois aplique uma regra: nenhuma mitigação pode ser a única linha cobrindo um dano que alcança terceiros. Onde isso acontece, o registro está dizendo qual controle determinístico construir, e o instrumento de pagamento é o primeiro lugar para olhar.

A estrutura de ganchos que bloqueiam e avaliações que verificam está em ganchos e avaliações como controle determinístico. Este texto acrescenta a regra de conversão que vem antes dela. Porcentagem vira tentativas. Tentativas viram custo para o adversário. Se o custo é uma tarde, o número deixou de ser controle, e o registro deve dizer isso em texto claro.

Fontes

Martin Alderson. “Have the frontier labs mixed up AI safety and security?.” Setembro de 2026. Os números de benchmark e da METR são citados como a leitura de Alderson dos relatórios originais.
Bottleneck Labs. “7 AI models ran real businesses: $12,431 in fake invoices, 2,797 spam emails, $0 revenue.” Setembro de 2026.

A Victorino ajuda times de engenharia a separar controles determinísticos de mitigações probabilísticas em implantações de agentes, começando pela superfície de pagamento: contato@victorino.com.br | www.victorino.com.br