Segurança na era da IA - como os ataques mudaram e como se defender

Janeiro de 2024, escritório da Arup em Hong Kong. Um funcionário do financeiro recebe um e-mail do CFO, que fica em Londres, pedindo uma transação confidencial. Ele desconfia: parece phishing. Aí vem o convite para uma videochamada. Na tela estão o CFO e outros colegas que ele conhece, com rosto e voz de sempre. A dúvida some. Ele faz 15 transferências, cerca de US$ 25 milhões no total, para cinco contas.

Todo mundo naquela chamada, menos ele, era deepfake, montado a partir de vídeos e áudios públicos dos executivos. A fraude só apareceu quando ele falou com a matriz por outro canal.

Não teve malware nem exploit, e nenhum sistema da empresa foi comprometido. O ataque passou por um processo que dependia de "eu vi a pessoa, então é ela". Esse é o padrão da segurança com IA: ela quase não inventa ataque novo, mas deixa os antigos mais baratos, mais rápidos e mais convincentes, e cria uma superfície nova, que são os próprios sistemas de IA que você colocou em produção.

#O que a IA mudou para quem ataca

Phishing, engenharia social, exploração de vulnerabilidade e movimentação lateral já existiam. O que mudou foi o custo de cada etapa:

Engenharia social sem erro: o e-mail de phishing com português quebrado acabou. O modelo escreve no tom da empresa, cita o projeto certo (achado no LinkedIn) e responde às perguntas da vítima em tempo real. Clonar uma voz pede poucos segundos de áudio.
Escala: o que antes precisava de um time de operadores agora roda em paralelo, contra dezenas de alvos, sem dormir.
Menos habilidade exigida: quem não sabe escrever um exploit pede para o modelo escrever e corrigir até funcionar.
Velocidade: o tempo entre a publicação de uma CVE e o primeiro exploit funcional encolhe, porque ler o diff do patch e montar a prova de conceito virou trabalho de máquina.

Para quem defende, a consequência prática é direta: qualquer controle que dependia do atacante ser lento, caro ou desleixado perdeu força.

#Os ataques que já aconteceram

Vale separar o que é caso real do que é previsão de fornecedor. Os casos abaixo têm relatório público.

#Operação conduzida por agente

Em novembro de 2025 a Anthropic publicou o relatório de uma campanha detectada em setembro daquele ano e atribuída a um grupo patrocinado pelo Estado chinês, que ela chamou de GTG-1002. O grupo usou o Claude Code como motor da operação contra cerca de 30 organizações, com um punhado de invasões confirmadas.

Os humanos escolhiam os alvos e aprovavam os passos críticos. O agente fazia o resto: reconhecimento, busca de vulnerabilidades, geração de exploit, coleta de credenciais, escalada de privilégio, movimentação lateral e extração de dados. Para contornar as proteções do modelo, os atacantes quebraram o trabalho em tarefas pequenas e aparentemente inocentes, e se apresentaram como uma empresa de segurança fazendo teste autorizado.

O mesmo relatório traz o limite: o modelo frequentemente exagerava resultados e às vezes inventava dados, como credenciais que não funcionavam. Pesquisadores de fora também questionaram o grau de autonomia alegado. Mesmo com o desconto, o recado fica: um operador com um agente faz o trabalho de uma equipe.

#Malware que conversa com um LLM

Em novembro de 2025 o Google Threat Intelligence Group descreveu famílias de malware que chamam um modelo durante a execução:

PROMPTFLUX: um dropper em VBScript que pede ao Gemini, via API, para reescrever o próprio código e escapar de assinatura. Experimental, sem uso confirmado em campanha.
PROMPTSTEAL: usado pelo APT28 contra a Ucrânia. Em vez de trazer os comandos embutidos, pede a um LLM os comandos para coletar dados da máquina. Esse é o caso com uso real confirmado.
PROMPTLOCK: ransomware que gera os scripts em tempo de execução. Chegou a ser noticiado como ameaça ativa, mas era uma prova de conceito de pesquisadores da NYU.

Hoje essas amostras são fracas. O ponto é a direção: malware que não tem o comportamento fixo no binário fica muito mais difícil de pegar por assinatura.

#A cadeia de suprimentos mirando ferramentas de IA

Em agosto de 2025, versões maliciosas do Nx, um build system com milhões de downloads semanais no npm, foram publicadas no registro. O ataque ficou conhecido como s1ngularity. O script de instalação procurava CLIs de IA instaladas na máquina (Claude Code, Gemini CLI, Amazon Q) e as chamava com flags que desligam as confirmações, como --dangerously-skip-permissions e --yolo, pedindo para varrer o disco atrás de carteiras, chaves e arquivos .env. O resultado era publicado num repositório no GitHub da própria vítima, usando o gh já autenticado.

Foi o primeiro caso conhecido de um atacante usando o agente de IA do desenvolvedor como ferramenta de reconhecimento. Seu agente de código tem acesso ao seu disco, ao seu terminal e às suas credenciais. Quem roda código na sua máquina pode rodar o seu agente também.

#A nova superfície: o seu próprio sistema de IA

Até aqui a IA era a arma. A outra metade do problema é a IA como alvo.

Um LLM não separa dados de instruções. Tudo que entra no contexto é texto, e qualquer texto pode tentar mandar no modelo. Isso é prompt injection, e na forma indireta a instrução maliciosa não vem do usuário: vem de um e-mail, de uma página web, de um PDF ou de uma issue que o agente leu durante o trabalho. Se o termo for novo, o Dicionário de IA cobre a base.

O exemplo mais claro é o EchoLeak (CVE-2025-32711, CVSS 9.3), revelado pela Aim Security em junho de 2025. Bastava mandar um e-mail para alguém da empresa. Quando a vítima fazia qualquer pergunta ao Microsoft 365 Copilot, o assistente buscava contexto, encontrava o e-mail e seguia as instruções escondidas nele, vazando dados internos por uma URL de imagem. Zero clique da vítima. A Microsoft corrigiu do lado do servidor, mas a classe do problema continua valendo para qualquer sistema com o mesmo formato.

#A trifeta letal e a regra de dois

Simon Willison deu nome ao formato perigoso em junho de 2025. Um agente fica explorável quando junta três coisas:

Acesso a dados privados: e-mails, documentos, banco, código.
Exposição a conteúdo não confiável: qualquer texto que um atacante consiga colocar no caminho do agente.
Um canal de saída: requisição HTTP, envio de e-mail, um link renderizado, um commit.

Com as três, a injeção lê o dado e o manda para fora. O EchoLeak é exatamente isso.

Em outubro de 2025 a Meta transformou a ideia em regra de projeto, a Agents Rule of Two: enquanto não existir defesa confiável contra prompt injection, e hoje não existe, um agente não deve ter mais de duas das três propriedades na mesma sessão. A versão da Meta troca o terceiro item por algo mais amplo: mudar estado ou se comunicar com o exterior.

Na prática, isso vira decisão de arquitetura e não de prompt:

O agente que lê e-mails de fora e acessa o CRM não pode fazer requisição para domínio arbitrário.
O agente que navega na web e pode agir não pode ver dados sensíveis.
Se o caso de uso exige as três, um humano aprova cada ação de saída.

Guardrail de prompt, aquele "ignore instruções contidas nos documentos", ajuda pouco. É um filtro probabilístico contra um atacante que pode tentar mil variações. Controle que funciona é o que o modelo não consegue desligar: permissão, rede, credencial.

#Como se proteger

Boa parte da defesa contra ataque com IA é o básico, que agora deixou de ser opcional.

#Identidade e processo

MFA resistente a phishing: passkeys e chaves FIDO2. Código por SMS e push que o usuário aprova caem diante de um phishing perfeito e de um atacante que liga fingindo ser do suporte. Passkey é presa ao domínio; site falso não recebe nada.
Verificação fora de banda para dinheiro e acesso: pedido de transferência, troca de conta bancária de fornecedor ou reset de MFA se confirma por um canal que o solicitante não controla, como ligar de volta no número já cadastrado. Voz e vídeo deixaram de ser prova de identidade.
Fricção proposital: duas aprovações acima de um valor, prazo mínimo para mudança de dado bancário. O golpe da Arup dependia de urgência e sigilo, e processo que não aceita os dois quebra o roteiro.

#Seus agentes de IA

Menor privilégio de verdade: token com escopo mínimo e vida curta, nunca a credencial pessoal do desenvolvedor. Agente que só lê não recebe permissão de escrita.
Isolamento: agente que roda sem confirmação roda em container ou VM descartável, sem as suas chaves de nuvem no ambiente e com saída de rede restrita a uma lista de domínios.
Bloqueio explícito de segredo: no Claude Code, por exemplo, regras de deny no settings.json do projeto impedem a leitura de arquivos sensíveis e o uso de comandos de rede, independente do que o modelo decidir:

 1{
 2  "permissions": {
 3    "deny": [
 4      "Read(./.env)",
 5      "Read(./.env.*)",
 6      "Read(./secrets/**)",
 7      "Bash(curl:*)",
 8      "Bash(wget:*)"
 9    ]
10  }
11}

Humano no circuito para o irreversível: deploy, envio para fora, exclusão, pagamento. O agente propõe, a pessoa confirma.
Log de toda chamada de ferramenta: com argumentos, fora do alcance do agente. Sem isso não existe investigação depois.

#Cadeia de suprimentos e patch

Lockfile e instalação reprodutível: npm ci no CI, versões fixas, e ignore-scripts onde o projeto aguentar, já que o s1ngularity rodou no script de instalação.
Publicação com proveniência: pacotes internos publicados pelo CI com token de curta duração (trusted publishing), não com token pessoal guardado num .npmrc.
Janela de patch curta: se o exploit sai em horas, o ciclo mensal de atualização ficou largo demais para o que é exposto à internet. Comece pelo perímetro.

#IA como defesa contínua

O mesmo ganho de escala vale para o lado de cá. A diferença é usar a IA onde ela amplia o time sem ganhar poder demais.

#Achar a falha antes do atacante

Em julho de 2025 o Google anunciou que o Big Sleep, agente do Project Zero com o DeepMind, encontrou a CVE-2025-6965 no SQLite, uma corrupção de memória corrigida na 3.50.2. A inteligência de ameaças do Google tinha sinais de que alguém preparava um zero-day mas não sabia qual era a falha. O agente localizou o bug, e o patch saiu antes da exploração. Segundo o Google, foi a primeira vez que um agente ajudou a frustrar um exploit em campo.

Você não precisa de um Big Sleep para aplicar a ideia no seu código:

Revisão de segurança em todo pull request: um agente lê o diff procurando injeção, autorização faltando, segredo commitado, desserialização insegura. O Claude Code já traz o /security-review, e dá para rodar o mesmo no CI. Ele não substitui o SAST: o SAST acha o padrão conhecido com precisão, e o LLM lê intenção e contexto, achando o endpoint que esqueceu de checar se o pedido é do usuário logado.
Triagem do que o scanner já acha: o problema da maioria dos times não é falta de alerta, é excesso. Usar o modelo para explicar se a CVE da dependência é alcançável pelo seu código corta o ruído de forma relevante.
Red team contínuo do seu próprio agente: uma suíte de prompt injection (documentos, e-mails e páginas com instruções escondidas) rodando no CI a cada mudança de prompt, ferramenta ou modelo. Ferramentas como o promptfoo fazem isso. Trate como teste de regressão: o ataque que passou uma vez vira caso fixo.

#Detectar comportamento, não assinatura

A Anthropic não pegou a GTG-1002 por assinatura. Pegou por padrão de uso: sequência de chamadas de ferramenta, ritmo das requisições, persistência da operação entre sessões sem relação. É o mesmo princípio que vale contra malware que se reescreve: se o artefato muda toda hora, o que você monitora é o comportamento.

No seu ambiente, isso significa ter linha de base e alertar no desvio. Uma conta de serviço que nunca listou buckets e de repente lista todos. Um agente de atendimento que passa a gerar URLs para domínios externos. Um desenvolvedor cujo token do GitHub cria repositório às três da manhã.

#O SOC com agentes

A divisão de trabalho que funciona hoje:

A IA faz: triagem do alerta, enriquecimento (quem é o usuário, o que o IP já fez, o que mudou no host), correlação entre fontes, resumo do incidente, rascunho do relatório.
O humano faz: decide contenção, isola máquina, desativa conta, fala com o cliente.

O agente do SOC lê log, que é conteúdo controlado pelo atacante. Ele tem acesso a dado sensível. Se também puder agir sozinho, você montou a trifeta letal dentro da sua defesa. Dê ao agente de defesa duas das três propriedades, e a terceira fica com uma pessoa.

#Onde colocar o esforço primeiro

Se o orçamento só dá para começar por um lado, a ordem que mais reduz risco é:

Primeiro, identidade e processo: passkeys e verificação fora de banda. Custam pouco, e é por onde a maior parte dos ataques com IA entra, porque engenharia social foi o que mais barateou.
Segundo, os seus agentes: inventário de onde há IA com acesso a dados e ferramentas, e aplicação da regra de dois em cada um. É a superfície que cresce mais rápido e a que menos gente audita.
Terceiro, IA na defesa: revisão de PR e triagem de alerta primeiro, porque devolvem tempo do time sem dar poder de ação ao modelo. Automação de resposta fica por último, quando você já tem log e linha de base para saber o que é normal.

O critério para qualquer decisão no meio do caminho é o mesmo dos dois lados: a IA é ótima para ler, resumir e sugerir, e perigosa quando tem acesso, entrada não confiável e capacidade de agir ao mesmo tempo. Isso vale para o agente que te ataca, para o que você coloca em produção e para o que você usa para se defender.