Cibersegurança

Cibersegurança e IA agêntica: por que as empresas se preocupam?

Um agente combina um modelo de IA com ferramentas e permissões para executar tarefas. Ao acessar arquivos, navegar, enviar mensagens ou alterar sistemas, um erro pode produzir efeitos reais. Uma página ou documento malicioso pode tentar induzir o agente a seguir instruções do atacante: é a injeção de prompt indireta.

Exemplo: um assistente autorizado a resumir documentos encontra instruções escondidas para enviar dados a outro destino. O risco aumenta com permissões amplas, integrações vulneráveis e pouca supervisão. A empresa deve limitar acessos, separar ambientes, registrar ações e exigir aprovação para operações sensíveis.

Como um agente transforma uma resposta em ação

Um chat pode sugerir uma alteração; um agente conectado pode executá-la. O modelo interpreta o objetivo, escolhe ferramentas e recebe resultados para decidir o próximo passo. O impacto depende das credenciais, dos sistemas acessíveis e das aprovações exigidas pela aplicação.

Uma resposta incorreta pode virar um arquivo sobrescrito, uma mensagem enviada ao destinatário errado ou uma mudança de configuração. Mesmo sem um atacante, objetivos ambíguos e validação insuficiente podem causar incidentes. Controles precisam existir na aplicação e nas permissões, além das instruções dadas ao modelo.

Injeção de prompt, jailbreak e envenenamento

Injeção de prompt tenta transformar conteúdo externo em instruções para o agente. Um jailbreak busca contornar restrições do modelo. Envenenamento introduz material manipulado nos dados de treinamento, na busca ou na memória. São problemas relacionados, mas têm origens e defesas diferentes.

Uma página consultada deve ser tratada como informação não confiável, mesmo quando parece oficial. A autorização para ler não autoriza executar instruções encontradas nela. Segredos não devem ser guardados em prompts; ferramentas precisam validar parâmetros, destinos e identidade de quem solicita cada operação.

Para onde vão as informações?

Nos serviços de IA em nuvem, o conteúdo enviado é processado na infraestrutura do provedor; integrações e ferramentas podem envolver outros serviços. Arquivos, trechos de código, imagens e dados de conectores podem fazer parte desse processamento. Modelos executados integralmente em ambiente local têm outro fluxo, desde que não utilizem serviços externos.

Isso não significa que todo conteúdo seja publicado ou vazado. Há risco de exposição por falhas, contas comprometidas, compartilhamento indevido e envio de dados a ferramentas. Criptografia e controles de acesso reduzem riscos, mas não eliminam todos os cenários. Antes do uso corporativo, identifique o que será enviado, quem poderá acessar, a retenção e os fornecedores envolvidos.

Meus dados são usados para treinamento?

Processar uma solicitação, armazenar registros e treinar modelos são usos distintos. As regras dependem do produto, plano, configurações e contrato. Um plano pago de uso pessoal não deve ser tratado automaticamente como um contrato empresarial.

A OpenAI informa que dados dos produtos empresariais e da API não são usados para treinamento por padrão. A Anthropic declara regra semelhante para produtos comerciais, com exceções como compartilhamento autorizado e feedback. Para contas de consumo e Gemini Apps, consulte os controles e políticas específicos. Desativar treinamento não equivale a garantir ausência de retenção ou risco de vazamento.

Da demonstração ao uso empresarial

Comece com tarefas de leitura, dados fictícios e acesso restrito. Classifique informações antes de enviar: dados pessoais, contratos, projetos industriais, credenciais e informações de clientes exigem avaliação específica. Substituir nomes pode não bastar para anonimizar um documento.

Antes de ampliar a autonomia, defina responsáveis, limites de gastos, destinos permitidos, logs protegidos, aprovações e um mecanismo de interrupção. Operações em produção e equipamentos industriais precisam de autorização e procedimentos próprios. Um agente não deve receber acesso amplo apenas porque executou bem uma demonstração.

Testes de invasão de modelos e agentes

Red teaming e testes de segurança procuram falhas em cenários autorizados: instruções maliciosas, exposição de dados, abuso de ferramentas, permissões excessivas e respostas inseguras. Avaliar apenas o texto do modelo não basta; conectores, memória, aplicação e infraestrutura também precisam ser testados.

Use ambiente isolado, dados fictícios, escopo acordado e registro de resultados. Verifique se o agente recusa acesso indevido e se uma ação sensível depende de aprovação real. Um teste aprovado não prova segurança absoluta; mudanças de modelo, ferramentas ou permissões exigem reavaliação.

O que um teste de segurança precisa demonstrar

Defina o comportamento esperado e o impacto aceitável. Teste isolamento entre usuários, acesso a documentos, instruções maliciosas em arquivos e páginas, tentativas de envio externo e abuso das ferramentas. Use dados sintéticos e sistemas sob autorização explícita.

Registre versão do modelo, ferramentas, permissões, entradas, ações e resultados. Verifique controles fora do modelo: um pedido proibido deve ser bloqueado mesmo quando o agente tenta executá-lo. Corrija falhas e repita os cenários após mudanças relevantes. Isso reduz riscos conhecidos, sem provar que todos os ataques futuros serão impedidos.

Como as empresas organizam os testes

O trabalho começa com um inventário de dados, ferramentas e permissões e a definição do que o sistema não pode fazer. Equipes internas de segurança e especialistas externos podem combinar avaliações automáticas do modelo, revisão da aplicação e red teaming humano. Esses métodos são complementares; uma boa nota em um conjunto de perguntas não comprova a segurança da aplicação inteira.

Em um piloto isolado, a equipe cria usuários com acessos diferentes e dados fictícios. Simula documentos com instruções maliciosas, pedidos de dados de outro usuário, envio a destinos não autorizados e ações sem aprovação. O resultado esperado deve ser definido antes: bloquear a operação, preservar o isolamento e registrar uma evidência sem expor segredos.

Depois, a empresa classifica o impacto das falhas, corrige permissões e validações, repete os cenários e decide se libera o uso. Em produção, monitora acessos e ações, mantém um plano de resposta a incidentes e reavalia após mudanças de modelo, conectores ou políticas. Esse é um processo de redução contínua de risco, não um certificado de invulnerabilidade.

Incidente documentado: abuso de Claude Code em espionagem

Em 13 de novembro de 2025, a Anthropic publicou um relato sobre uma campanha identificada em setembro de 2025. Segundo a empresa, operadores humanos manipularam Claude Code para apoiar tentativas de invasão de cerca de 30 alvos; um número pequeno foi comprometido. A empresa relata bloqueio de contas, comunicação aos afetados e coordenação com autoridades.

Trata-se de uso malicioso de uma ferramenta por atacantes, não de evidência de uma IA que decidiu dominar sistemas por vontade própria. Os números e a atribuição são conclusões da investigação da Anthropic, e não uma auditoria independente do Noosigma. O aprendizado defensivo é controlar ferramentas e credenciais e detectar sequências de ações abusivas, além de filtrar mensagens isoladas.

Resultados de laboratório não são incidentes comprovados

Nos estudos de desalinhamento agêntico, pesquisadores montam cenários controlados para verificar se modelos adotam ações prejudiciais sob certas condições. Esses experimentos ajudam a identificar falhas antes da implantação, mas a ocorrência de um comportamento em teste não comprova que clientes reais tenham sido vítimas daquele mesmo evento.

Ao ler uma notícia, procure a classificação do caso: ataque observado, vulnerabilidade demonstrada ou simulação. Confira quem publicou a evidência, qual produto e versão foram avaliados, se houve exposição confirmada e qual correção foi adotada. Evite transformar uma possibilidade técnica em alegação de vazamento confirmado.

A IA vai dominar o mundo?

Não existe base para afirmar que esse resultado seja inevitável, nem para prometer que sistemas futuros serão inofensivos. Resultados de laboratório mostram comportamentos em condições específicas; não comprovam consciência, intenção humana ou um destino inevitável.

O problema prático é controlar capacidades e consequências: acesso mínimo, supervisão, possibilidade de interromper ações e responsabilidade humana. Riscos de longo prazo merecem pesquisa; decisões de hoje devem considerar evidências, limitações e o impacto concreto de cada aplicação.