Oito suposições de segurança que os agentes de IA estão quebrando: de duas semanas a dez horas

Quando o atacante pode se dar o luxo de errar

A economia dos ciberataques mudou com a chegada dos agentes de IA. Se antes um atacante precisava de um recurso estratégico de tempo, hoje um agente pode gastar um milhão de vezes mais tempo do que um humano. Em um ataque recente a uma rede corporativa, um trabalho que normalmente levaria cerca de duas semanas foi comprimido para menos de dez horas. Ao investigar um incidente no Hugging Face, analistas reconstruíram cerca de 17.600 ações do agente realizadas em quatro dias e meio.

O agente não se cansa, não perde o foco, pode testar vários vetores de ataque em paralelo e abandonar caminhos sem sucesso sem nenhum custo psicológico. Pontos fracos que antes pareciam protegidos pela obscuridade ou pela dificuldade de serem encontrados deixam de funcionar como defesa. Isso muda radicalmente as premissas sobre as quais a segurança corporativa foi construída.

Oito erros críticos que precisam ser repensados

1. Prepare-se para um atacante que pode se dar o luxo de errar

No Hugging Face, o agente testou centenas de abordagens fracassadas, mudou de canal sempre que era bloqueado e voltou a pistas antigas até que elas formassem uma cadeia de ataque funcional. Endpoints comuns esquecidos na configuração de rede, contas com acesso excessivo, erros corriqueiros de configuração — nada disso continua sendo um ponto fraco se o atacante pode se dar o luxo de testar tudo. Reavalie todas as suposições que dependem silenciosamente de um recurso ser difícil de encontrar ou de o atacante simplesmente desistir.

2. Meça o tempo entre a detecção e a contenção

Equipes de segurança costumam medir se conseguem detectar uma invasão. Acrescente uma métrica: quanto tempo passa entre a detecção e a contenção efetiva. No ataque corporativo citado, duas semanas de trabalho foram reduzidas a dez horas. No Google, outro grupo de agentes passou de um recurso em nuvem comprometido para uma campanha massiva de roubo de credenciais em tempo ainda menor. Uma escalada lenta — como no Hugging Face, onde os sistemas de segurança dispararam alertas, mas a resposta passou por várias rodadas de aprovações e reuniões — pode anular qualquer defesa. Defina com antecedência quais medidas de contenção são acionadas automaticamente e quais a equipe de segurança pode aplicar sem aprovação adicional.

3. Proteja o ambiente em volta, não só o modelo

O ambiente — ou scaffolding — é tudo que envolve o modelo: ferramentas, memória, credenciais, acesso de rede, ambientes de execução e políticas. Em testes nos quais modelos de IA atuaram como atacantes, esse ambiente determinava em boa parte o que o modelo conseguia alcançar. A agência australiana de cibersegurança chegou à mesma conclusão do lado defensivo: uma organização não controla como o modelo em si evolui, mas pode controlar o ambiente em volta. Liste tudo que o agente pode ver e chamar, tudo em que ele pode escrever e tudo em que pode gastar dinheiro. Pergunte-se: se o agente se comportar mal amanhã, qual é o pior que esse ambiente permitiria?

4. Prepare-se para enxames de agentes

No incidente do Hugging Face, centenas de agentes trocaram informações e inventaram seus próprios meios de comunicação entre execuções que deveriam estar totalmente isoladas umas das outras. Um grupo de agentes pode dividir tarefas, compartilhar descobertas e manter um ataque em andamento mesmo quando tentativas individuais falham. Pastas compartilhadas, bancos de dados, filas de mensagens e outros recursos com permissão de escrita podem se transformar em canais de comunicação inesperados. Se você roda muitos agentes, trate a comunicação entre eles como uma permissão em si, que precisa ser controlada e monitorada.

5. Pare de dar aos agentes credenciais permanentes

Cada agente deve ser tratado como uma conta de máquina separada, com identidade própria. Emita credenciais com privilégios restritos que expiram junto com a tarefa. Separe permissões de leitura das de escrita. Não armazene chaves estáticas de nuvem no ambiente do agente. Garanta que seja possível rastrear qualquer subagente de volta até o agente pai e até a pessoa responsável por ele. Isso não é só o princípio do menor privilégio — é esse princípio aplicado a um software que explora ativamente seu próprio ambiente. Um humano pode nunca descobrir que uma conta antiga dá acesso a algum sistema esquecido. Um agente vai procurar isso metodicamente.

6. Assuma que a injeção de prompt vai funcionar

Injeção de prompt são instruções que um atacante planta em algo que o agente vai ler. Assuma que, em algum momento, o agente vai seguir essas instruções. Em vez de perguntar se instruções maliciosas podem escapar, pergunte o que acontece quando elas escaparem. Agentes leem logs, nomes de host, relatórios de vulnerabilidade, payloads, comentários de código e arquivos de configuração. Em qualquer um desses lugares pode haver texto escrito especificamente para manipular o modelo. Mesmo um agente enganado deveria bater em limites rígidos de credenciais, acesso de rede, ferramentas e autoridade para fazer mudanças sérias.

7. Mantenha a fronteira de segurança fora do modelo

Um prompt dizendo "não toque em produção" é apenas um desejo. O controle real existe quando a API do agente simplesmente não tem permissões para alcançar a produção. Se uma ação pode ter consequências graves, deixe o modelo propô-la e outra parte do sistema decidir se ela será realmente executada. O mesmo vale para logs de auditoria: se o agente pode editar os registros usados depois para revisar seu próprio comportamento, considere que você não tem trilha de auditoria alguma. Limites rígidos precisam viver no código, não em prompts.

8. Defenda-se de agentes usando agentes

Um incidente com dezenas de milhares de ações automatizadas deixa rastros demais para uma equipe humana revisar adequadamente em tempo real. Centros de operações de segurança (SOCs) vão precisar de seus próprios agentes para triar alertas, caçar ameaças, investigar incidentes e ajudar a conter ataques. Mas agentes defensivos têm seus próprios riscos: eles leem constantemente dados potencialmente adulterados e costumam receber credenciais com permissões amplas. A injeção de prompt pode virar o trabalho deles contra a própria organização sem que o atacante precise roubar nenhuma credencial. Agentes defensivos precisam de ambientes rigidamente controlados e acesso apenas ao que for absolutamente necessário.

É preciso acompanhar o ritmo dos atacantes que usam IA sem, no processo, criar um problema de segurança totalmente novo.