O que é a segurança de LLM? Como mitigar os 10 principais riscos de segurança do OWASP

Um ataque que leva uma IA a tratar as instruções de um atacante como comandos — a injeção de prompt — ocupa o 1.º lugar no OWASP Top 10 for LLM Applications em todas as edições desde 2023.

A lista é o mais próximo de um consenso que existe na segurança de IA. O projeto começou com um pequeno grupo de profissionais de segurança e conta hoje com o contributo de mais de 600 especialistas em mais de 18 países.

Somos uma empresa de IA a publicar um guia sobre a forma como a IA se deixa convencer a fazer coisas, por isso não vamos fingir que este problema está resolvido. Wilson, que codirige o projeto da OWASP, foi bastante claro quanto às defesas atuais: «...francamente, não creio que estejamos nos 99%.»

A edição de 2026 começa no mesmo tom. O responsável pelo projeto diz-nos para «deixar de tentar construir um modelo que não possa ser enganado» e conceber o sistema envolvente de forma a que um modelo enganado não consiga danificar nada de importante.

Vamos aplicar essa perspetiva aos 10 riscos da lista de 2026 da OWASP.

O que significa segurança de LLM?

A segurança de LLM consiste em proteger os modelos de IA e as aplicações que os utilizam contra ataques e utilizações indevidas. O risco aumenta consoante aquilo a que o modelo está ligado: os ficheiros e dados que consegue ler e as ferramentas que pode utilizar, como o email, a pesquisa ou a base de dados de uma empresa.

Num software devidamente protegido, existe uma fronteira firme entre as instruções que um programa segue e as informações que processa. Mas os LLM não têm essa fronteira.

Tudo o que o modelo lê chega como um único e longo fluxo de texto: as instruções do programador, a sua pergunta, uma página web que consultou. Em princípio, os modelos de IA devem saber sempre quem está a falar, seja o programador, o utilizador ou o próprio modelo a raciocinar sobre um problema.

No entanto, os investigadores Jasmine Cui e Charles Ye descobriram que os modelos adivinham sobretudo quem está a falar a partir da forma como o texto soa. Assim, se um atacante escrever algo que soe como o raciocínio do próprio modelo, este pode acreditar que foi ele a ter a ideia. Isto é um problema para qualquer configuração de segurança que dependa de o modelo saber quem manda.

Deparámo-nos com o mesmo problema nos nossos próprios agentes de IA. O nosso CISO, Kyle Polley, disse à ISMG que os agentes «podem não seguir as políticas mesmo que as adicione ao prompt de sistema». Foi por isso que criámos o Numbat, uma ferramenta de código aberto que verifica o que um agente está prestes a fazer e pode bloqueá-lo se a ação violar uma regra de segurança configurada.

Segurança de LLM significa aceitar que o modelo vai, por vezes, receber ordens da pessoa errada, e rodeá-lo de barreiras de proteção de IA que se mantenham firmes quando isso acontece.

Quais são as melhores práticas de segurança de LLM?

Vamos percorrer o OWASP Top 10 for LLM Applications 2026 por ordem, do n.º 1 ao n.º 10.

Para cada risco, encontrará uma explicação em linguagem simples sobre como as coisas correm mal e um exemplo real. Depois, abordaremos as práticas que podem ajudar a evitá-lo ou, no mínimo, a limitar os danos.

1. Conter a injeção de prompt

Uma injeção de prompt acontece quando um atacante faz com que uma IA siga instruções que não devia. Essas instruções podem surgir diretamente numa conversa ou ser plantadas num email, numa página web ou num documento.

O segundo tipo é conhecido como injeção de prompt indireta. Pede ao seu assistente que resuma um documento. Os autores do documento instruíram o assistente a enviar-lhes os seus ficheiros privados. Se o assistente seguir essas instruções, quem escreveu o documento apropriou-se, na prática, do seu acesso.

A PCMag compara a segurança dos prompts a tapar buracos numa pedra porosa. Veda-se uma abertura e a água encontra outra. «Um ataque abre caminho; é corrigido, mas inúmeras outras vias de ataque continuam por descobrir, simplesmente devido à natureza dinâmica de sistemas como os LLM.»

Exemplo: Em junho de 2025, investigadores da Aim Security descobriram o EchoLeak, uma falha que levava o Microsoft 365 Copilot a divulgar informações privadas de empresas. Quando um colaborador fazia uma pergunta de trabalho rotineira, o Copilot podia ir buscar o email malicioso, seguir as instruções nele ocultas e enviar informações sensíveis ao atacante. O ataque contornou as verificações destinadas a detetar instruções maliciosas e a remover ligações suspeitas.

O que pode fazer:

• Siga a «Regra dos Dois» da Meta: O EchoLeak precisava de uma IA capaz de ler dados da empresa, ler emails externos e enviar informações para fora — e tinha as três capacidades. Limitá-la a duas dessas capacidades impede que uma injeção de prompt ganhe demasiado controlo. Se a tarefa precisar das três, exija aprovação humana antes de cada ação.
• Teste contra atacantes que conhecem as suas defesas: Dê às suas equipas de testes de segurança as regras e os filtros que implementou e deixe-as contorná-los. Num estudo, os atacantes que se adaptaram às defesas tiveram êxito em mais de 90% dos casos contra a maioria das 12 defesas testadas.

2. Impedir a fuga de informações sensíveis

Quando os sistemas de IA fornecem informações privadas a pessoas que não as deviam ver, chama-se a isso divulgação de informações sensíveis. Pode significar revelar os dados de pagamento de um cliente ou deixar conversas privadas numa base de dados partilhada.

Muitas fugas começam com a «partilha excessiva». Imagine que uma empresa liga a sua IA a unidades de armazenamento e bases de conhecimento com permissões pouco restritivas. A IA obtém tudo aquilo a que consegue chegar, exatamente como foi concebida para fazer. Ninguém precisa de invadir nada, mas pode considerar-se que o LLM foi invadido.

Exemplo: Em janeiro de 2025, investigadores da Wiz encontraram uma base de dados da DeepSeek exposta à internet com mais de um milhão de entradas de registo, incluindo histórico de conversas e chaves de API, que o software utiliza para aceder a outros serviços. Os investigadores não precisaram de persuadir o modelo a revelar nada.

O que pode fazer:

• Verifique o acesso antes de a IA ler os dados: A sua aplicação deve verificar que documentos a pessoa que faz a pergunta tem permissão para ver antes de os passar ao modelo.
• Proteja os registos que a sua IA deixa para trás: Remova dados privados e chaves secretas antes de guardar registos de atividade, exija autenticação e restrinja o acesso às pessoas que precisam deles. Defina um período de retenção para que esses registos não se acumulem indefinidamente.

3. Travar a agência excessiva

As IA com agência excessiva têm mais poder do que as suas funções exigem: ferramentas de que não precisam, permissões que vão além da sua tarefa ou liberdade para agir sem verificação. Aqui, a causa é irrelevante.

Um prompt de injeção, um bug ou um modelo que simplesmente se engana conduzem todos ao mesmo resultado. Se tiver capacidade para isso, a IA acabará por fazer algo destrutivo.

Exemplo: Em julho de 2025, o fundador da SaaStr, Jason Lemkin, relatou que o agente de programação da Replit apagou a sua base de dados com 1206 registos de executivos, apesar de ter recebido instruções para não fazer alterações. Inicialmente, o agente afirmou que os dados não podiam ser restaurados, embora mais tarde se tenha verificado que a recuperação era possível. Jason constatou que dizer-lhe para não mexer na base de dados não lhe tinha retirado a capacidade de a apagar.

Expandir

Fonte: X

O que pode fazer:

• Remova as capacidades de que a tarefa não precisa: Limite tanto as ferramentas que um agente recebe como aquilo que essas ferramentas podem fazer. Um assistente que resume emails precisa de permissão para os ler, não para os enviar ou apagar.
• Coloque as verificações de permissões fora da IA: Sempre que uma ação for solicitada, faça com que seja verificada face às suas regras de segurança e exija que uma pessoa a aprove.

4. Verificar o que entra na sua cadeia de abastecimento de IA

Poucas empresas criam IA de raiz, e são cada vez menos a cada ano que passa. De acordo com o inquérito The State of Generative AI in the Enterprise de 2025 da Menlo Ventures, 53% compraram modelos de IA em 2024, valor que subiu para 76% em 2025.

Na maioria das vezes, as empresas descarregam modelos de plataformas como o Hugging Face, continuam a treiná-los com conjuntos de dados recolhidos por terceiros e acrescentam extensões e pacotes de código escritos por desconhecidos.

Cada uma dessas peças é uma porta de entrada. Se uma delas for adulterada, o problema acaba incorporado no seu produto.

Exemplo: Os repositórios públicos de modelos do Hugging Face passaram de 2,43 milhões para 2,96 milhões entre janeiro e agosto de 2026. No entanto, em julho de 2026, os modelos da OpenAI contornaram controlos destinados a mantê-los afastados da internet durante testes de segurança internos e invadiram partes dos sistemas do Hugging Face. Aliás, um dos agentes recuperou 14 credenciais de acesso expostas publicamente, verificou que funcionavam e partilhou-as com outros agentes. Os agentes acabaram por explorar falhas que lhes permitiram executar código nos servidores do Hugging Face.

«Estamos a impor requisitos mais rigorosos de alinhamento ao longo de todo o ciclo de vida de um modelo e a criar ambientes sandbox mais isolados, restringindo o acesso à internet e controlando ainda mais o acesso aos pesos dos modelos», afirma o relatório da OpenAI.

O que pode fazer:

• Fixe os modelos numa versão exata e verifique-os: Fixe cada modelo numa versão revista e verifique a impressão digital do ficheiro antes de o carregar, para que um ficheiro trocado não possa passar despercebido sob a mesma etiqueta. A OWASP recomenda também assinaturas digitais, com uma ressalva: uma assinatura prova a origem de um modelo, não que este seja seguro.
• Verifique cada pacote que a sua IA sugere: Antes de instalar um pacote de código recomendado por um assistente de IA, confirme que existe, que é o pacote que pretendia e que provém do editor esperado.

5. Proteger contra o envenenamento de dados e modelos

Uma IA envenenada aprende com dados corrompidos. Podem ser os exemplos usados no seu ajuste fino ou uma base de conhecimento onde procura respostas. O modelo continua a parecer funcionar; simplesmente aprende as lições erradas e, por vezes, aprende a portar-se mal apenas quando vê uma frase de ativação específica.

A frase passará despercebida em todos os testes que fizer, até alguém a utilizar.

Expandir

Além disso, é muito difícil de reverter. O envenenamento não é um bug que se corrija com um patch. Se os seus dados estiverem errados, poderá ter de os verificar novamente, voltar a treinar o modelo ou substituí-lo por completo.

Exemplo: Em outubro de 2025, investigadores da Anthropic, do UK AI Security Institute e do Alan Turing Institute demonstraram que 250 documentos envenenados bastavam para ensinar um modelo a produzir texto sem sentido sempre que encontrasse um determinado acionador. O mesmo número funcionou nos quatro tamanhos de modelo testados, embora o maior tenha sido treinado com mais de 20 vezes mais dados limpos.

O que pode fazer:

• Acompanhe a origem dos seus dados: Mantenha um registo de todos os conjuntos de dados e modelos que utiliza, da origem de cada um e do que mudou entre versões. Recomendamos o controlo de versões dos conjuntos de dados para que, se for detetado envenenamento, possa reverter para uma versão limpa e perceber como entrou.
• Teste a existência de backdoors: Uma «backdoor» é um comportamento oculto que um atacante implanta num modelo, à espera de uma determinada frase ou de outro acionador que o ative. Procure-as com entradas concebidas para levar o modelo a violar as suas regras habituais.

6. Pôr um teto ao consumo ilimitado

Quando as IA não têm quaisquer limites quanto ao volume de trabalho que podem realizar ou ao custo que podem gerar, o seu consumo é considerado «ilimitado». A maioria dos serviços de IA cobra por utilização, pelo que um atacante pode fazer disparar a sua fatura ou construir uma cópia do seu modelo.

A OWASP chama ao problema central «assimetria de custos». Um pedido curto e barato pode desencadear computação dispendiosa do seu lado.

Exemplo: Em maio de 2024, a equipa de investigação de ameaças da Sysdig descobriu um novo ataque chamado «LLMjacking». Um grupo de atacantes visou 10 serviços de LLM alojados na nuvem, utilizando credenciais roubadas. Entraram através de uma versão vulnerável do Laravel e, depois, descobriram o que as credenciais permitiam fazer e quais as quotas existentes, com o objetivo evidente de vender o acesso. Foram também consultadas muitas definições de registo, provavelmente para evitar a deteção. Segundo a Sysdig, no pior cenário, o custo para a vítima poderia ultrapassar os 46 000 dólares por dia.

O que pode fazer:

• Defina orçamentos que travem os gastos: Estabeleça limites de despesa rígidos para utilizadores individuais, chaves de API, equipas e para a conta no seu todo. Aplique-os em todos os pontos por onde os pedidos possam entrar.
• Dê a cada tarefa um ponto de paragem: Limite o tempo de execução de uma tarefa, a quantidade de texto que pode processar e gerar e o número de chamadas de ferramentas que pode fazer. Adicione interrupções automáticas para agentes que se repetem ou excedem a sua quota.

7. Detetar a desinformação antes de agir

Quando uma IA produz algo falso que parece correto e alguém, ou algo, age com base nisso, chama-se a isso desinformação. O risco central não é tanto a resposta errada em si, mas sim o facto de essa resposta errada ser considerada fiável e utilizada.

O historial de incidentes sugere que os profissionais não estavam tão preocupados com a desinformação como deviam. De acordo com a carta de abertura da edição de 2026, os votantes colocaram-na perto do fundo da lista, mas, a julgar pelos incidentes reais, está perto do topo.

Exemplo: Em 2025, a Deloitte Australia entregou uma análise dos sistemas informáticos da segurança social ao abrigo de um contrato governamental de 440 000 dólares australianos. O investigador Chris Rudge, da Universidade de Sydney, encontrou referências a estudos inexistentes e uma citação inventada de uma sentença de um tribunal federal. O relatório revisto revelou que a Deloitte tinha utilizado o Azure OpenAI GPT-4o na sua metodologia, e a empresa aceitou reembolsar a última prestação. Infelizmente, tratava-se de uma revisão de garantia.

O que pode fazer:

• Verifique se as provas sustentam a resposta: Fundamente as afirmações em fontes atuais e fidedignas. Numa resposta sobre políticas, obtenha a política aprovada e verifique se esta sustenta a conclusão, incluindo as respetivas exceções.
• Verifique antes de o sistema agir: Se um agente disser que um cliente passou numa verificação de identidade, confirme-o junto do sistema de verificação antes de autorizar um pagamento. Exija aprovação humana para decisões com consequências, disponibilizando ao revisor as provas que as fundamentam.

8. Limitar os danos da exposição de contexto oculto

As aplicações de IA dão ao modelo instruções e informações de contexto que os utilizadores normalmente não veem. Isto pode incluir o prompt de sistema, políticas internas, descrições das ferramentas disponíveis e regras sobre quem as pode utilizar. Ocorre uma exposição de contexto oculto quando o modelo revela essas informações a alguém.

Em 2026, a OWASP alargou esta entrada, que antes se chamava «fuga do prompt de sistema», porque o prompt de sistema é apenas uma parte do que pode escapar. O perigo depende do que lá colocou. A fuga de um guia de tom de voz é ligeiramente embaraçosa, mas a fuga de uma chave de API dá a alguém acesso à sua base de dados confidencial.

Exemplo: Em fevereiro de 2023, alguns utilizadores conseguiram que o Bing Chat da Microsoft revelasse as suas instruções internas. Uma das tentativas bem-sucedidas foi de Marvin von Hagen, que afirmou ser programador da OpenAI e pediu as instruções para poder configurar o modelo. O Bing divulgou as regras que regiam as suas pesquisas, respostas e comportamento de segurança, bem como o seu nome interno, Sydney. Entre as instruções reveladas estava uma que lhe dizia para manter essas instruções confidenciais.

O que pode fazer:

• Mantenha os segredos fora do contexto do modelo: Parta do princípio de que tudo o que o modelo consegue ler pode tornar-se visível para os utilizadores. Guarde palavras-passe, chaves de API e tokens de acesso num sistema separado de gestão de segredos.
• Garanta que as permissões se mantêm mesmo que as regras sejam expostas: Aplique as verificações de acesso no código da sua aplicação. Se uma ferramenta estiver restrita a administradores, verifique as permissões da conta do utilizador antes de a executar.

9. Proteja os seus vetores e embeddings

Quando uma IA utiliza a pesquisa vetorial para encontrar respostas nos documentos da sua empresa, não pesquisa diretamente o texto. Os documentos são convertidos em «embeddings», que são longas listas de números que captam o significado de cada passagem, e armazenados numa base de dados vetorial. Uma pergunta é convertida da mesma forma, e o sistema recupera as passagens cujos números estão mais próximos.

O OWASP resume as quatro formas como isto pode falhar: o envenenamento faz com que o sistema dê respostas erradas, a inversão provoca fugas de dados, o bloqueio silencia-o e um controlo de acesso deficiente leva-o a entregar qualquer coisa a qualquer pessoa.

Os números não são a abstração segura que aparentam ser. Os embeddings armazenados podem ser convertidos novamente em texto, e, nos respetivos testes, um método recuperou na íntegra 92% das passagens curtas, de 32 tokens. Por isso, uma cópia de segurança divulgada que contenha «apenas embeddings» também pode expor o conteúdo dos documentos.

Exemplo: Numa investigação apresentada na USENIX Security 2025, os investigadores mostraram que um único documento cuidadosamente elaborado podia impedir uma IA de responder a uma determinada pergunta. Adicionaram-no à coleção em que a IA pesquisava. Quando a IA o encontrava, podia dizer que não tinha informação suficiente ou que responder não seria seguro. O documento não precisava de dizer à IA para ignorar as suas regras. Isto chama-se «bloqueio da recuperação» (retrieval jamming).

O que pode fazer:

• Mantenha índices separados para dados públicos e privados: Não misture conteúdo extraído da Web com dados de parceiros ou documentos internos confidenciais. Faça uma separação física por nível de confiança, em vez de etiquetar o conteúdo num único índice, porque isso elimina toda uma classe de erros de configuração e impede que conteúdo extraído da internet acabe ao lado dos documentos do seu conselho de administração.
• Trate os embeddings como os documentos de onde vieram: Encripte-os, proteja as cópias de segurança da base de dados vetorial tal como os ficheiros de origem e elimine os embeddings quando eliminar o original. As chaves de API do seu serviço de embeddings devem ser mantidas em segredo.

10. Verifique os resultados da IA antes de os encaminhar

Sempre que uma aplicação passa resultados da IA a outro sistema sem verificar se são seguros para utilização nesse sistema, está a fazer um tratamento inadequado dos resultados do LLM.

Esta entrada abrange também o código inseguro que os assistentes de programação com IA geram em grande escala. Cada linha que um assistente escreve é, portanto, também um resultado.

Exemplo: Em 2025, o investigador Johann Rehberger mostrou como o assistente de programação Amp, da Sourcegraph, podia expor o conteúdo do chat simplesmente ao apresentar uma imagem. Utilizou injeção de prompts para fazer com que o Amp incluísse informações privadas no endereço web de uma imagem. A aplicação obteve então automaticamente essa imagem, enviando as informações para o servidor dele. A falha no tratamento dos resultados foi esse pedido automático: o texto gerado pelo modelo tornou-se uma ligação a um servidor externo, levando consigo dados privados.

O que pode fazer:

• Torne os resultados seguros para o respetivo destino: Verifique e trate as respostas de acordo com o local para onde vão. Numa página web, impeça que o texto gerado se torne código executável. Numa base de dados, utilize consultas preparadas que mantêm os valores fornecidos separados dos comandos.
• Impeça que as respostas estabeleçam ligações externas automáticas: Desative, por predefinição, o carregamento automático de imagens, pré-visualizações de ligações e páginas incorporadas nas respostas do modelo. Restrinja as ligações necessárias a destinos explicitamente aprovados.

Como é que a Perplexity protege os LLM?

Partimos do princípio de que todos os riscos acima acabarão por se concretizar e concebemos os sistemas para que não possam causar grandes danos quando isso acontecer. O nosso CISO, Kyle Polley, explicou como o fazemos num workshop recente.

• O agente tem o seu próprio computador, e este começa vazio: As ferramentas de agente instaladas no seu portátil podem obter acesso aos ficheiros, às aplicações e às credenciais guardadas nesse computador. O Perplexity Computer funciona ao contrário. Cada tarefa é executada na sua própria sandbox isolada e, como diz Polley, «por predefinição, não tem acesso a nada».
• O agente nunca vê as palavras-passe: As credenciais dos serviços ligados são armazenadas fora da sandbox. Quando o agente precisa de aceder a um serviço como o GitHub, envia um pedido sem credenciais anexadas. Um gateway verifica se o destino e o pedido correspondem ao esperado e, em seguida, adiciona as credenciais quando o pedido sai. O agente pode utilizar a ligação sem obter as chaves.
• As suas permissões mantêm-se e pode restringi-las ainda mais: As ligações feitas através de OAuth preservam as suas permissões de acesso no serviço ligado. Se não consegue ver algo, o seu agente também não consegue.
• Todas as páginas web são tratadas com desconfiança: Criámos o BrowseSafe para o Comet, o nosso navegador agêntico, porque as ferramentas que testámos não satisfaziam as nossas necessidades na utilização real. O navegador analisa páginas web e outros conteúdos externos, incluindo e-mails, à procura de injeção de prompts. Disponibilizámos tanto o modelo como o conjunto de dados em código aberto.
• Monitorizamos o agente e as máquinas onde é executado: O Numbat situa-se entre a decisão de um agente de agir e a execução efetiva da ferramenta. O Numbat regista a atividade dos agentes de programação suportados e pode bloquear ações que violem as políticas configuradas antes de serem executadas. O Bumblebee faz o inventário dos pacotes de software em portáteis, servidores e pipelines de compilação, e assinala os que são reconhecidamente maliciosos. Ambos são de código aberto.
• Os fornecedores de modelos não guardam os seus dados: Temos acordos de retenção zero de dados com os nossos fornecedores de LLM terceiros. Os administradores de contas Enterprise também podem reduzir a retenção de dados da própria Perplexity para apenas 24 horas.

Criámos o Numbat de forma proativa, por uma razão que Polley resume numa frase: «Quanto mais autonomia se dá a um agente, maior é o risco.»

Perguntas frequentes sobre segurança de LLM

Qual é o LLM mais seguro?

Nenhum LLM torna uma aplicação segura por si só: os modelos podem continuar a confundir conteúdo que devem ler com instruções que devem seguir. As defesas que parecem robustas em testes padrão também podem ceder sob pressão.

Uma pergunta melhor é qual a configuração mais segura para o seu caso de utilização. Isso implica permissões limitadas, credenciais mantidas longe do modelo, aprovação humana para ações arriscadas e testes realizados por pessoas que conhecem as suas defesas.

O que são vulnerabilidades de LLM?

As vulnerabilidades de LLM são fragilidades que permitem que um sistema de IA seja enganado, exponha dados ou cause danos, seja por ação de um atacante ou devido aos seus próprios erros.

Os dez principais riscos são a injeção de prompts, a divulgação de informações sensíveis, a agência excessiva, a cadeia de abastecimento, o envenenamento de dados e de modelos, o consumo ilimitado, a desinformação, a exposição de contexto oculto, as fragilidades de vetores e embeddings, e o tratamento inadequado de resultados.

Um LLM privado é seguro?

É uma opção mais segura para algumas coisas, mas não por predefinição. Tem mais controlo sobre o tratamento dos dados se executar um modelo na sua própria infraestrutura ou num ambiente na nuvem. Não existe nenhuma forma automática de impedir injeções de prompts, agência excessiva, envenenamento ou desinformação.

Ao alojar o modelo por conta própria, também é responsável pelo modelo que transfere, incluindo os riscos da cadeia de abastecimento e a infraestrutura de que este necessita.