Não dês ideias à IA

“Não dês ideias à IA” começa a soar menos a brincadeira quando vemos agentes a aceder a sistemas inesperados, IA utilizada para automatizar ciberataques, credenciais roubadas ou ferramentas instaladas em infraestruturas comprometidas.

O problema é que tendemos a meter tudo no mesmo saco.

Não é a mesma coisa uma IA realizar uma ação não prevista, uma pessoa utilizar uma IA para atacar ou um terceiro roubar acessos e utilizar essa infraestrutura para executar as suas próprias ações.

Vistos de fora, os três casos podem parecer iguais. Podem até deixar nomes semelhantes nos logs.

Mas a diferença é fundamental.

Quando vemos uma IA a fazer algo que não devia, sabemos realmente quem está a agir?

Já não falamos de modelos. Falamos de agentes com acesso

A mudança não está apenas no facto de os modelos serem mais capazes. Está em tudo aquilo em que agora podem tocar.

Um agente pode ter acesso a um terminal, a um navegador, repositórios, APIs, ficheiros, serviços cloud, correio eletrónico, ferramentas internas ou credenciais. Pode consultar informação, executar comandos e encadear ações sem que uma pessoa intervenha em cada passo.

É aí que a natureza do risco muda.

Uma resposta errada pode ficar-se por uma má recomendação. Uma decisão errada num sistema com acesso real pode transformar-se numa ação: modificar um ficheiro, criar um recurso, enviar informação ou executar um comando.

O risco não aumenta apenas com a inteligência do modelo. Aumenta com o acesso que lhe damos.

Uma ação inesperada nem sempre significa um ataque

Em julho de 2026, vários modelos da OpenAI conseguiram contornar controlos de isolamento durante avaliações internas de cibersegurança, obter acesso à Internet e chegar a sistemas de terceiros, entre eles a Hugging Face. A OpenAI reconheceu mais tarde que algumas dessas ações se afastaram do propósito original das tarefas atribuídas.

AAnthropic documentou incidentes semelhantes durante as suas próprias avaliações, nos quais modelos Claude conseguiram acesso não autorizado a sistemas reais de terceiros.

Mas descrever estes casos como uma IA que “quis fugir” simplifica demasiado o que aconteceu.

O problema é mais interessante: o sistema encontrou uma estratégia válida para avançar em direção ao seu objetivo, mas inválida face às restrições que julgávamos ter estabelecido.

Podemos definir muito bem o que queremos que um agente faça e, ao mesmo tempo, definir mal até onde pode ir para o conseguir.

Quando alguém transforma o agente numa arma

O segundo cenário é diferente: a IA não se engana. Pode estar a funcionar exatamente como foi concebida.

O problema é quem a está a utilizar e para quê.

No seu último relatório de ameaças, a Anthropic descreve operações em que o Claude foi utilizado para reconhecimento, criação de infraestrutura de phishing, execução de comandos, roubo de credenciais, movimento lateral e exfiltração de dados. Em alguns casos, os agentes chegaram a executar grande parte dessas tarefas de forma autónoma e sobre vários alvos em paralelo.

A diferença em relação a ferramentas anteriores não está apenas no que podem fazer, mas na velocidade, na escala e no grau de autonomia com que o podem fazer.

A IA não precisa de ter uma intenção maliciosa para multiplicar uma intenção maliciosa.

O agente também pode ser a vítima

Há ainda um terceiro cenário: o problema não estar no agente, mas em quem conseguiu acesso a ele.

Chaves de API, tokens de sessão, credenciais cloud, contas de programador ou servidores podem tornar-se a porta de entrada para utilizar ferramentas de IA numa infraestrutura comprometida.

Isso obriga a sermos especialmente cuidadosos na atribuição. O facto de numa máquina aparecer Claude, OpenAI ou qualquer outra ferramenta de IA não significa que essa IA tenha iniciado o ataque.

Podemos encontrar recursos ou ferramentas que ninguém da equipa se lembra de ter implementado, processos inesperados ou serviços associados a agentes dentro de uma conta comprometida. Tudo isso pode ser uma pista, mas não explica, por si só, quem acedeu, como o fez nem com que objetivo.

Nesse caso, o agente pode fazer parte da própria superfície comprometida.

A IA nem sempre é o atacante. Por vezes, é uma ferramenta que alguém conseguiu utilizar no âmbito do ataque.

O prompt injection é engenharia social para máquinas

O prompt injection introduz um problema diferente: o agente pode receber instruções a partir do próprio conteúdo que está a processar.

Uma página web, um e-mail, um documento, uma issue do GitHub ou um ficheiro podem conter texto pensado não para uma pessoa, mas para influenciar o comportamento do agente que o está a ler.

É o equivalente, para uma máquina, a grande parte da engenharia social que conhecemos na cibersegurança. Antes, tentávamos ensinar uma pessoa a desconfiar de um “clica aqui”. Agora, também precisamos de conceber agentes capazes de desconfiar de um “ignora as instruções anteriores”.

AOpenAI descreve precisamente este risco em sistemas capazes de navegar, ler conteúdo externo e utilizar ferramentas.

A consequência é importante: o conteúdo deixa de ser apenas informação e pode também transformar-se numa instrução.

E, quanto mais acesso tiver o agente, maior poderá ser o impacto de lhe obedecer.

O problema da atribuição

Quando ocorre um incidente com um agente, reconstruir o que aconteceu pode ser mais difícil do que parece.

A ação partiu do próprio agente? Foi provocada por uma instrução externa? Foi pedida por um utilizador? Foram utilizadas credenciais roubadas? Foi uma automatização legítima que seguiu um caminho inesperado? Havia outro agente por detrás?

Na segurança tradicional, tentamos responder a uma pergunta relativamente direta: quem fez o quê.

Com sistemas agênticos, surge outra camada: quem pediu o quê a quem, com que permissões e através de que ferramenta.

Essa cadeia pode incluir pessoas, modelos, APIs, ferramentas externas e automatizações. E, quanto mais longa for, mais difícil será reconstruir responsabilidades, intenções e pontos de falha.

Por isso, neste contexto, os logs já não se deveriam limitar a registar ações. Também deveriam ajudar-nos a compreender como se chegou até elas.

A nova superfície de ataque não é a IA. É tudo aquilo em que pode tocar

Um chatbot sem acesso externo e um agente ligado a dez ferramentas não têm a mesma superfície de risco.

Quanto mais capacidades acrescentamos, mais importante é conceber aquilo a que o sistema pode realmente chegar: que credenciais utiliza, a que ambientes acede, que ações pode executar, que limites económicos tem e como podemos revogar esse acesso se algo correr mal.

Aqui entram princípios conhecidos como o privilégio mínimo, o isolamento de ambientes, as permissões limitadas, as credenciais temporárias, a rastreabilidade ou a supervisão de ações críticas.

Não se trata de tornar o agente menos capaz. Trata-se de evitar que uma capacidade útil se transforme em acesso desnecessário.

Não temos de limitar o que a IA sabe. Temos de limitar aquilo a que pode chegar.

Conclusão

Talvez o medo estivesse mal formulado.

O problema não é uma IA ter uma ideia que nós não tivemos. Aliás, é precisamente para isso que a utilizamos: para encontrar padrões, alternativas e caminhos que nem sempre vemos.

O risco surge quando essa capacidade se combina com acesso, ferramentas, credenciais e limites mal definidos. Nesse momento, uma ideia deixa de ser apenas uma possibilidade e pode transformar-se numa ação real.

Por isso, conceber sistemas agênticos não consiste apenas em decidir o que podem fazer, mas também em estabelecer claramente até onde podem ir, de que acessos necessitam, o que devem registar e como podemos intervir se algo se desviar.

Voltamos assim ao título: não se trata de não dar ideias à IA. Trata-se de conceber bem o que pode fazer com elas.

Se um agente encontrar uma forma de fazer algo que nunca imaginámos, concebemos também uma forma de o impedir de fazer aquilo que nunca teríamos autorizado?