DEFCON 34: a IA industrializou o ataque. E ainda esquecemos o básico.

• A IA não inventou vetor novo. Ela industrializou os antigos.
• O sandbox é uma sugestão
• Nenhuma credencial roubada
• Às vezes a porta de entrada é uma credencial que você esqueceu exposta
• E no varejo? O mesmo roteiro, agora com agentes
• A IA como amplificador, não como mágica
• Nem tudo deveria precisar virar um “controle de IA”
• Mais blá blá blá
• Referências 📚
  • Outras publicações deste blog

Há poucas semanas escrevi aqui sobre Patchphobia , tentando entender por que ainda precisamos convencer profissionais de tecnologia de que a tecnologia pela qual são responsáveis precisa ser mantida. Estive em Las Vegas este ano, e confesso que abri a agenda da DEF CON 34 esperando um assunto completamente diferente. Este era o ano da IA. Agentes autônomos competindo em CTF, ferramentas que caçam vulnerabilidades sozinhas, o discurso de que o atacante agora é uma máquina que não dorme.

E os agentes realmente dominaram o evento. Mas acompanhando e vendo o que sobrou depois dos holofotes (os slides, os whitepapers, os advisories, os relatos que aguentam ser lidos com calma), encontrei algo desconfortavelmente familiar. Quase nenhum daqueles ataques brilhantes de IA começou num vetor novo. Eles começaram num fundamento que já era nossa responsabilidade muito antes de os agentes existirem.

A IA não inventou vetor novo. Ela industrializou os antigos.  

Essa é, para mim, a leitura mais honesta da DEF CON 34. A superfície de ataque não mudou de natureza; ela mudou de escala e de velocidade. Credencial exposta continua sendo credencial exposta. Papel de execução com privilégio demais continua sendo privilégio demais. Cadastro sem proteção continua sendo cadastro sem proteção. O que a IA fez foi pegar esses velhos pecados e transformá-los em algo que roda em minutos, em paralelo, sem cansar.

Isso importa porque muda o lugar onde vale colocar esforço. Se o problema fosse uma classe inteiramente nova de vulnerabilidade, faria sentido correr atrás de uma defesa inteiramente nova. Mas se a IA está apenas apertando as brechas que já deixamos abertas, então o investimento certo não é o produto mais reluzente da feira. É fechar o básico com disciplina, pois agora o básico é atacado em escala industrial.

O sandbox é uma sugestão  

O exemplo que melhor resume o ano veio das pesquisas sobre o runtime dos próprios agentes. Não estive na BlackHat este ano, mas uma coisa e certa, a semana em Las Vegas começou com uma parede de produtos corporativos prometendo proteger IA e terminou com pesquisadores desmontando, um a um, os ambientes que deveriam isolar esses agentes. A conclusão incômoda que ficou registrada na cobertura do evento é que boa parte dessas falhas não são bugs a serem corrigidos, e sim características da arquitetura agêntica atual, lacunas de projeto, não deslizes de implementação.

Numa das apresentações, mostrou-se que os sandboxes de agentes de código amplamente usados podem ser tratados mais como recomendação do que como fronteira, incluindo uma falha de execução remota de código pré-tarefa avaliada com a nota máxima de severidade. Pare um segundo nessa ideia: o ambiente cuja única função é conter o agente foi contornado antes mesmo de o agente começar a trabalhar.

E aqui está o ponto que conversa direto com o meu incômodo de sempre. Havia, na mesma semana, uma fila de ferramentas comerciais se propondo a resolver “segurança de IA”. Só que um problema de arquitetura não se resolve com uma licença. Comprar não é o mesmo que fazer. Se a fronteira de isolamento não existe de verdade, nenhum painel bonito por cima dela vai criá-la.

Nenhuma credencial roubada  

Se o parágrafo anterior soou abstrato, a trilha de Cloud da conferência trouxe a versão concreta. Encadeando referências como o OWASP Top 10 for Agentic Applications e o MITRE ATLAS, uma das apresentações caminhou por uma cadeia de ataque completa contra um agente rodando em nuvem: uma injeção indireta de prompt contamina o contexto do agente, o agente abusa de uma função com um papel de execução privilegiado demais, esse acesso é usado para modificar a própria política de IAM e, ao final, um backdoor persistente é criado.

O detalhe que eu peço para você guardar é este: tudo isso sem uma única credencial roubada. Não houve phishing, não houve senha vazada, não houve exploit de kernel. Houve um agente com mais permissão do que precisava, num ambiente onde ninguém tinha revisado o que aquele papel realmente podia fazer.

E qual foi o conjunto de defesas recomendado? IAM de menor privilégio com escopo por agente, atenção às limitações reais das guardrails do provedor e arquitetura com humano no laço para ações de alto impacto. Ou seja: menor privilégio, conhecer os limites das ferramentas que você comprou, e não deixar a máquina decidir sozinha o que é irreversível. Nada disso é novo. É o feijão com arroz de sempre, aplicado a um ativo novo.

Às vezes a porta de entrada é uma credencial que você esqueceu exposta  

Teve ainda um caso que parece feito sob medida para ilustrar o argumento. Pesquisadores mostraram como uma credencial de uma plataforma de rastreamento de erros, deixada publicamente exposta, combinada com uma integração de agente, podia ser encadeada até execução remota de código. Uma chave que não deveria estar visível, um agente conectado a ferramentas demais, e o resultado é o tipo de comprometimento que costumávamos associar a exploits sofisticados.

A parte que mais me faz pensar é que o fabricante, segundo o relato, resolveu não tratar a causa raiz. E aqui aparece de novo a mesma escolha de sempre: alguém decidiu que aquilo era exceção aceitável, não problema a ser corrigido. De novo, a exceção virando processo. A credencial exposta é um pecado antigo, de higiene básica. O que mudou foi o raio de explosão quando um agente com acesso amplo passa a existir do outro lado dela.

E no varejo? O mesmo roteiro, agora com agentes  

Como boa parte da minha vida profissional acontece perto de varejo e e-commerce, essa foi a palestra que mais me interessou. O pesquisador apresentou uma década de guerra contra bots de compra a partir da cadeira do atacante, e o roteiro é quase entediante de tão conhecido: um exército de contas montado semanas antes com cadastro falso e credential stuffing, alvos escolhidos pela margem de revenda, APIs de pré-lançamento vazando produtos antes de o SKU existir, um vigia monitorando o estoque até a hora da abertura, e agentes de carrinho competindo pelo checkout com maior probabilidade de aprovação.

O gancho novo é que esse mesmo modus operandi agora pode ser decomposto em agentes de IA, numa velocidade que antes seria considerada impossível. Mas repare: cada peça desse ataque é um fundamento que já tínhamos que defender. Credential stuffing tem folha de referência da OWASP há anos. Criação de contas falsas e scalping estão catalogados no OWASP Automated Threats desde sempre. A automação ficou mais esperta; a defesa continua sendo a mesma que adiamos por não ser glamourosa: MFA onde dói, detecção de abuso já no cadastro (e não só no checkout), limitação por comportamento e não só por IP.

A IA como amplificador, não como mágica  

Não quero passar a impressão de que a IA é só ameaça, ou que o hype é todo vazio. O contraponto mais interessante do evento veio justamente de quem usou IA a favor da defesa. Um dos pesquisadores de web mais respeitados do mercado construiu um sistema de IA que encontrou centenas de sites vulneráveis a uma técnica de contrabando de requisições e ainda identificou uma classe genuinamente nova de problema. Mas o achado que ele fez questão de destacar não foi a autonomia da máquina. Foi o contrário: o especialista humano projetou o sistema, fez as perguntas certas, descartou as respostas fracas e restringiu o comportamento do agente com código determinístico. A IA foi um amplificador enorme de um profissional que sabia o que estava fazendo, não um substituto para ele.

Nem tudo deveria precisar virar um “controle de IA”  

Volto, no fim, ao mesmo lugar de sempre. Assim como patch não deveria ser uma atividade iniciada pelo time de Segurança, segurança de agentes não deveria virar uma categoria mística que exige uma disciplina completamente nova. Boa parte do que protege um agente é o que já deveríamos saber fazer, aplicado a um tipo de ativo diferente.

Se você tem um agente em produção, ele é um componente tecnológico como outro qualquer. Qual é o inventário de ferramentas, modelos e integrações que ele pode acionar? Ele opera com menor privilégio ou herda tudo que ninguém revisou? Existe um ponto de aprovação humana antes de uma ação irreversível? A entrada que chega até ele é tratada como não confiável, do mesmo jeito que tratamos qualquer input externo há vinte anos? Existe log auditável do que ele fez? Existe um jeito de desligar?

Nenhuma dessas perguntas é sobre inteligência artificial. Todas são sobre prudência, inventário, menor privilégio e responsabilidade sobre aquilo que colocamos em produção, os mesmos princípios que sustentam qualquer operação madura. A DEFCON 34 mostrou que não precisamos de uma defesa nova e brilhante. Ela mostrou que o custo de deixar a defesa antiga frouxa acabou de subir.

Mais blá blá blá  

Então, como da última vez, prefiro terminar com perguntas em vez de respostas.

Se você opera nuvem: seus papéis de execução seguem menor privilégio de verdade, ou um agente comprometido herdaria permissões que ninguém revisa há meses? Se você constrói com IA e MCP: você sabe exatamente quais ferramentas cada agente pode chamar, ou concedeu acesso amplo só “para funcionar”? Se você cuida de e-commerce: seu cadastro e seu checkout aguentam um exército de contas automatizado, ou foram desenhados apenas para o tráfego educado de sempre? Se você lidera Segurança: sua estratégia para agentes é um processo de fundamentos, ou uma linha de orçamento reservada para o próximo produto com “AI” no nome?

E, principalmente: se amanhã você tirasse a palavra “IA” de todos esses ataques, sobraria algum problema que você já não deveria saber resolver?

Se a resposta for “não”, talvez a gente esteja com menos medo do futuro e mais devendo o presente. E o presente, como quase sempre, é feijão com arroz bem feito.

👾

Referências 📚  

“The Sandbox is a Suggestion: Deconstructing AI Agent Sandboxes” - Elad Meged (Novee Security) Writeup do autor: https://novee.security/blog/breaking-ai-agent-sandboxes/ Abstract oficial: https://defcon.org/html/defcon-34/dc-34-speakers.html

“Your WAF Blocked Us, That Was The Exploit” (Agentjacking) - Barak Sternberg, Nevo Poran e Ron Bobrov (Tenet Security) Writeup do autor: https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

Agentes de IA como motores de escalonamento de privilégio em nuvem - DEF CON 34 Cloud Village https://www.cloud-village.org/dc34

“Shopping Is The Attack: A Decade of E-Commerce Scalper Wars, and the Multi-Agent AI Era” - Yaniv “PSYMAG” Menasherov Abstract oficial : https://defcon.org/html/defcon-34/dc-34-speakers.html

“HTTP/1.1 Must Die: The Desync Endgame” — James Kettle (PortSwigger) Whitepaper e pesquisa do autor: https://portswigger.net/research/http1-must-die

Forkast - The Architecture of Failure: Why DEF CON 34 Shattered the AI Agent Security Narrative https://forkast.news/the-architecture-of-failure-why-def-con-34-shattered-the-ai-agent-security-narrative/

As divulgações agênticas da DEF CON 34 lidas como um único argumento https://promptinjection.wtf/

OWASP Top 10 for LLM Applications (2025) https://owasp.org/www-project-top-10-for-large-language-model-applications/

OWASP Top 10 for Agentic Applications (2026) - referenciado nas trilhas de Cloud/AI da DEF CON 34 https://genai.owasp.org/

OWASP Automated Threats to Web Applications - especialmente OAT-005 Scalping e OAT-008 Credential Stuffing https://owasp.org/www-project-automated-threats-to-web-applications/

OWASP Credential Stuffing Prevention Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html

MITRE ATLAS — Adversarial Threat Landscape for AI Systems https://atlas.mitre.org/

DEF CON 34 - Cloud Village https://www.cloud-village.org/dc34

DEF CON 34 - AI Village https://aivillage.org/events/defcon-34/

DEF CON 34 - Main Stage Talks (abstracts; vídeos e slides no media server) https://defcon.org/html/defcon-34/dc-34-speakers.html

Outras publicações deste blog  

Patchphobia: O ano é 2026, e ainda … https://tiagotavares.io/blog/patchphobia-em-2026/

Processo de Gestão de Vulnerabilidades e Automação para OffSec e AppSec utilizando Atlassian Jira https://tiagotavares.io/blog/vulnerability_management_jira_context_offsec_appsec/