6.000 Ataques, Zero Credenciais Extraídas: Escolher o Modelo É uma Decisão de Controle

Fernando Irarrazaval entregou à internet um assistente de IA que cuidava de e-mails e fez um convite público: extraia as credenciais que ele guardava. Mais de 2.000 pessoas tentaram. Enviaram mais de 6.000 e-mails adversariais, gastaram além de 500 dólares do orçamento de API dele e dispararam tantos sinais de fraude que o Google suspendeu a conta de e-mail que o assistente usava. As credenciais nunca foram extraídas. Nenhuma vez.

O backend era Claude Opus 4.6.

A maior parte do que se escreve sobre injeção de prompt, incluindo vários textos que já publicamos, trata a injeção como uma ferida aberta. O atacante monta uma mensagem, o agente obedece, o dado vaza. Esse enquadramento está correto como alerta e incompleto como descrição do estado atual. Este experimento é o raro dado que mostra o lado defensivo segurando sob pressão sustentada, criativa e coletiva. Ele merece leitura cuidadosa, porque a conclusão óbvia é a errada.

O que o experimento de fato mediu

Um praticante construiu um agente, conectou-o a uma conta de e-mail real, carregou um segredo nele e deixou o público atacar por um período. Os números do título são reais: milhares de participantes, milhares de tentativas de injeção, zero extrações bem-sucedidas. Esses são fatos sobre um único setup.

Eles não descrevem injeção de prompt em geral. O N aqui representa volume de ataque. Faltou um estudo controlado. Havia um modelo, um system prompt, uma configuração de ferramentas, um segredo. Nenhum grupo de controle rodou os mesmos 6.000 e-mails contra um modelo mais fraco para medir a diferença. A suspensão por detecção de fraude do Google foi uma variável externa que removeu o canal de e-mail no meio do caminho, o que ajuda o defensor por razões que nada têm a ver com o modelo. Este é um resultado de red-team relevante, de um praticante independente, não um benchmark que você possa citar como “injeção resolvida”.

Lido dessa forma, o experimento ainda ensina algo específico e útil.

O resultado que sobrevive ao escrutínio

Um modelo de fronteira, com uma instrução clara para proteger um segredo, resistiu a milhares de tentativas de humanos motivados de convencê-lo a entregar esse segredo. Isso não é pouco. Significa que o comportamento de seguir instruções e respeitar hierarquia de confiança, treinado no modelo, fez trabalho real. A mesma intervenção em nível de treinamento que descrevemos em Segurança de Agentes É um Problema de Arquitetura, onde modelos aprendem a pesar instruções de sistema acima de conteúdo externo injetado, aparece aqui em campo, não em laboratório.

O autor é cuidadoso, e suas ressalvas importam mais que o título dele. Ele afirma com clareza que modelos menores ou mais fracos provavelmente seriam mais vulneráveis, e que dar a um agente acesso a e-mail continua arriscado, por melhor que ele tenha se defendido. As duas ressalvas apontam para a mesma conclusão, e ela não é a comemorativa.

A lição é sobre o modelo que você escolheu

Rode o contrafactual. Troque o Opus 4.6 por um modelo mais barato e menor e repita os mesmos 6.000 e-mails. O próprio julgamento do autor, e a base de evidências mais ampla, diz que a contagem de extrações deixaria de ser zero. A arquitetura não mudou. O system prompt não mudou. As ferramentas não mudaram. A única variável que se moveu é o modelo, e o resultado de segurança se move junto.

Isso transforma a seleção de modelo em um controle de segurança, na mesma categoria que escopo de autenticação, limites de taxa e verificação de ações. Times costumam tratar a escolha do modelo como decisão de compras, guiada por latência e preço por token. O mesmo modelo que custa mais por requisição pode ser também o que se recusa a vazar uma credencial sob 6.000 tentativas. Quando o modelo mais barato é o que quebra, a economia foi emprestada contra um incidente.

Isso reposiciona um debate que normalmente acontece no financeiro, não na segurança. A pergunta “qual modelo cabe no orçamento?” é a mesma pergunta que “quanta resistência à injeção estamos comprando?”. Não são orçamentos separados. Um downgrade de modelo é um downgrade de controle, e deveria passar por qualquer revisão que um downgrade de controle recebe.

Por que isso não significa que dá para relaxar

Um modelo forte oferece defesa probabilística, sem garantia. Zero extrações em 6.000 tentativas é um sinal forte; ainda assim, fica longe de provar que a tentativa 6.001 falha. Capacidade de fronteira reduz a taxa de sucesso da injeção. Não leva a taxa a um zero verificado, e nunca remove o risco de fundo de que o agente tinha acesso a e-mail e um segredo vivo.

A postura disciplinada combina as duas camadas. Escolha o modelo mais forte que você consiga justificar, porque os dados dizem que ele absorve ataques que um modelo mais fraco não absorveria. Depois construa como se ele fosse falhar de qualquer jeito, porque em volume suficiente algo passa. Como argumentamos em Papéis São Estilo, Não Estrutura, instruções moldam comportamento nas margens; elas não criam fronteiras rígidas. A recusa do modelo é uma margem. A arquitetura é a fronteira.

Concretamente, os controles que sobrevivem a uma falha do modelo são os que ficam fora do modelo. Credenciais de curta duração, para que um segredo vazado expire rápido. Acesso a ferramentas com escopo, para que a integração de e-mail não possa redefinir senhas nem alcançar outros sistemas. Verificação de ações numa camada determinística que não pergunta ao modelo se uma mensagem de saída é segura. Detecção de anomalias que teria pego o pico de tráfego antes do Google. O experimento foi resgatado no meio do caminho por um detector de fraude externo. Seu agente em produção não deveria depender do filtro de spam de outra pessoa para contenção.

O ângulo de cadeia de suprimentos se mantém

Injeção de Prompt É uma Arma na Cadeia de Suprimentos defendeu que as injeções perigosas são as que você não convidou. Este experimento foi um ataque convidado: um agente conhecido, uma recompensa pública, um grupo de atacantes que se anunciou. A exposição real na maioria das organizações é o e-mail que ninguém sinalizou, o documento puxado para um índice de RAG, a saída de ferramenta em que um agente confia por padrão. Um modelo que resiste a 6.000 e-mails hostis de gente tentando vencer um desafio pode se comportar de outro jeito diante de um payload bem mirado, escondido em um fluxo de aparência legítima. A multidão foi barulhenta. Um atacante real é silencioso.

Então o resultado animador e o problema não resolvido coexistem. O modelo segurou contra o ruído. A arquitetura ainda precisa segurar contra a tentativa silenciosa e dirigida que nenhum desafio público vai simular.

Faça isto agora

Trate a seleção de modelo como item da sua revisão de segurança, não só da revisão financeira. Antes de rebaixar um modelo para economizar em inferência em qualquer agente que toque credenciais, e-mail ou sistemas externos, faça uma pergunta: nós medimos o que esse downgrade faz com a resistência à injeção, ou estamos assumindo que o modelo mais barato é bom o suficiente? Se você não consegue responder com evidência, está negociando um controle que nunca precificou. Rode sua própria versão reduzida deste red-team contra o modelo que você realmente pretende colocar em produção, e faça do resultado parte da decisão de deploy.

---

Fontes

• Fernando Irarrazaval. “What Happened After 2,000 People Tried to Hack My AI Assistant.” Junho de 2026.

A Victorino ajuda empresas a tratar a escolha de modelo como controle de segurança e a construir a contenção que sobrevive à falha do modelo: contato@victorino.com.br | www.victorino.com.br