O que é segurança de LLMs? Como mitigar os 10 principais riscos de segurança da OWASP

Um ataque que engana uma IA para que ela trate as instruções de um invasor como comandos — a injeção de prompt — ocupa o 1º lugar no OWASP Top 10 para Aplicações de LLM em todas as edições desde 2023.

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

Somos uma empresa de IA publicando um guia sobre como a IA é convencida a fazer coisas, então não vamos fingir que isso está resolvido. Wilson, que colidera o projeto da OWASP, foi bem claro sobre as defesas atuais: "...sinceramente, não acho que estejamos em 99%."

A edição de 2026 começa no mesmo tom. O líder do projeto nos diz para "parar de tentar construir um modelo que não possa ser enganado" e projetar o sistema ao redor de modo que um modelo enganado não consiga quebrar nada importante.

Vamos aplicar essa postura a todos os 10 riscos da lista de 2026 da OWASP.

O que significa segurança de LLM?

Segurança de LLM significa proteger os modelos de IA e os aplicativos que os utilizam contra ataques e uso indevido. O risco aumenta de acordo com aquilo a que o modelo está conectado: os arquivos e dados que ele pode ler e as ferramentas que pode usar, como e-mail, pesquisa ou um banco de dados da empresa.

Em um software devidamente protegido, há uma fronteira bem definida entre as instruções que um programa segue e as informações que ele processa. Mas os LLMs 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 desenvolvedor, a sua pergunta, uma página da web que ele consultou. Os modelos de IA deveriam acompanhar quem está falando, seja o desenvolvedor, o usuário ou o próprio modelo raciocinando sobre um problema.

Mas os pesquisadores Jasmine Cui e Charles Ye descobriram que os modelos geralmente adivinham quem está falando pelo tom do texto. Então, se um invasor escrever algo que soe como o raciocínio do próprio modelo, o modelo pode acreditar que teve a ideia sozinho. Isso é um problema para qualquer configuração de segurança que dependa de o modelo saber quem está no comando.

Já enfrentamos o mesmo problema com nossos próprios agentes de IA. Nosso CISO, Kyle Polley, disse à ISMG que os agentes "podem não seguir políticas mesmo que você as adicione ao prompt de sistema". Foi por isso que criamos 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 às vezes vai receber ordens da pessoa errada e criar ao redor dele guardrails de IA que continuem funcionando quando isso acontecer.

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

Vamos percorrer o OWASP Top 10 para Aplicações de LLM 2026 em ordem, do nº 1 ao nº 10.

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

1. Contenha a injeção de prompt

Uma injeção de prompt acontece quando um invasor faz uma IA seguir instruções que ela não deveria seguir. Essas instruções podem vir diretamente em um chat ou ser plantadas em um e-mail, uma página da web ou um documento.

O segundo tipo é conhecido como injeção de prompt indireta. Você pede ao seu assistente que resuma um documento. Nele, o autor instruiu o assistente a enviar seus arquivos privados para ele. Se o assistente seguir essas instruções, a pessoa que escreveu o documento terá, na prática, tomado emprestado o seu acesso.

A PCMag compara a segurança de prompts a tapar buracos em uma pedra porosa. Você veda uma abertura, e a água encontra outra. “Um ataque encontra seu caminho; ele é corrigido, mas inúmeras outras vias de ataque continuam à espera de ser descobertas, simplesmente por causa de quão dinâmicos são sistemas como os LLMs.”

Exemplo: Em junho de 2025, pesquisadores da Aim Security descobriram o EchoLeak, uma falha que enganava o Microsoft 365 Copilot para que ele vazasse informações privadas da empresa. Quando um funcionário fazia uma pergunta rotineira de trabalho, o Copilot podia recuperar o e-mail, seguir as instruções escondidas nele e enviar informações confidenciais ao invasor. O ataque passou pelas verificações destinadas a detectar instruções maliciosas e remover links suspeitos.

O que você pode fazer:

• Siga a “Regra de Dois” da Meta: O EchoLeak precisava de uma IA capaz de ler dados da empresa, ler e-mails externos e enviar informações para fora — e ela tinha os três recursos. Limitá-la a dois deles impede que uma injeção de prompt ganhe controle demais. Se a tarefa precisar dos três, exija aprovação humana antes de cada ação.
• Teste contra invasores que conhecem suas defesas: Forneça aos seus testadores de segurança as regras e os filtros que você implementou e deixe que eles tentem contorná-los. Em um estudo, invasores que se adaptaram às defesas tiveram sucesso em mais de 90% dos casos contra a maioria das 12 defesas testadas.

2. Impeça o vazamento de informações confidenciais

Quando sistemas de IA fornecem informações privadas a pessoas que não deveriam vê-las, isso se chama divulgação de informações confidenciais. Isso pode significar revelar os dados de pagamento de um cliente ou deixar conversas privadas em um banco de dados compartilhado.

Muitos vazamentos começam com o “compartilhamento excessivo”. Digamos que uma empresa conecte sua IA a drives e bases de conhecimento com permissões frouxas. A IA recupera tudo o que consegue alcançar, exatamente como foi projetada para fazer. Ninguém precisa invadir nada, mas, na prática, é como se o LLM tivesse sido invadido.

Exemplo: Em janeiro de 2025, pesquisadores da Wiz encontraram um banco de dados da DeepSeek exposto na internet com mais de um milhão de registros de log, incluindo históricos de chat e chaves de API, que os softwares usam para acessar outros serviços. Os pesquisadores não precisaram convencer o modelo a revelar nada.

O que você pode fazer:

• Verifique o acesso antes que a IA leia os dados: Seu aplicativo deve verificar quais documentos a pessoa que faz a pergunta tem permissão para ver antes de passá-los ao modelo.
• Proteja os registros que sua IA deixa para trás: Remova dados privados e chaves secretas antes de salvar os logs de atividade, exija login e restrinja o acesso às pessoas que precisam deles. Defina um período de retenção para que esses registros não se acumulem indefinidamente.

3. Controle a agência excessiva

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

Um prompt de injeção, um bug ou um modelo que simplesmente erra levam ao mesmo resultado. Se tiver a capacidade, a IA acabará fazendo algo destrutivo.

Exemplo: Em julho de 2025, o fundador da SaaStr, Jason Lemkin, relatou que o agente de programação da Replit apagou seu banco de dados com 1.206 registros de executivos, apesar das instruções para não fazer alterações. Inicialmente, o agente disse que os dados não podiam ser restaurados, embora a recuperação tenha se mostrado possível depois. Jason descobriu que mandá-lo deixar o banco de dados em paz não havia eliminado sua capacidade de apagá-lo.

Expandir

Fonte: X

O que você pode fazer:

• Remova recursos de que a tarefa não precisa: Limite tanto as ferramentas que um agente recebe quanto o que essas ferramentas podem fazer. Um assistente que resume e-mails precisa de permissão para lê-los, não para enviá-los ou excluí-los.
• Coloque as verificações de permissão fora da IA: Sempre que uma ação for solicitada, faça com que ela seja verificada com base nas suas regras de segurança e exija que uma pessoa a aprove.

4. Verifique o que entra na sua cadeia de suprimentos de IA

Poucas empresas criam IA do zero, e menos ainda a cada ano. De acordo com a pesquisa 2025 The State of Generative AI in the Enterprise, da Menlo Ventures, 53% compraram modelos de IA em 2024, percentual que subiu para 76% em 2025.

Na maioria das vezes, as empresas baixam modelos de hubs como o Hugging Face, continuam treinando-os com conjuntos de dados coletados por outras pessoas e conectam complementos e pacotes de código escritos por desconhecidos.

Cada uma dessas partes é uma porta de entrada. Se uma delas for adulterada, o problema vai parar dentro do 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 de 2026 e agosto de 2026. Em julho de 2026, porém, modelos da OpenAI contornaram controles destinados a mantê-los fora da internet durante testes internos de segurança e invadiram partes dos sistemas do Hugging Face. Na verdade, um agente recuperou 14 credenciais de acesso expostas publicamente, verificou se funcionavam e as compartilhou com outros agentes. Em seguida, os agentes exploraram falhas que lhes permitiram executar código nos servidores do Hugging Face.

“Estamos impondo requisitos mais rigorosos de alinhamento ao longo de todo o ciclo de vida de um modelo e criando sandboxes mais isolados, restringindo o acesso à internet e controlando ainda mais o acesso aos pesos dos modelos”, diz o relatório da OpenAI.

O que você pode fazer:

• Fixe os modelos em uma versão exata e verifique-os: Fixe cada modelo em uma versão revisada e confira a impressão digital do arquivo antes de carregá-lo, para que um arquivo trocado não passe despercebido sob o mesmo rótulo. A OWASP também recomenda assinaturas digitais, com uma ressalva: a assinatura comprova de onde o modelo veio, não que ele seja seguro.
• Verifique cada pacote que sua IA sugerir: Antes de instalar um pacote de código recomendado por um assistente de IA, confirme que ele existe, que é o pacote que você pretendia instalar e que vem do publicador esperado.

5. Proteja-se contra o envenenamento de dados e de modelos

Uma IA envenenada aprende com dados corrompidos. Podem ser os exemplos usados no seu ajuste fino ou uma base de conhecimento em que ela busca respostas. O modelo continua parecendo funcionar; ele apenas aprende as lições erradas e, às vezes, aprende a se comportar mal somente quando vê uma frase-gatilho específica.

A frase passará despercebida em todos os testes que você fizer até que alguém a use.

Expandir

Além disso, é muito difícil de desfazer. O envenenamento não é um bug que se corrige com um patch. Se os seus dados estiverem errados, talvez seja preciso verificá-los novamente, treinar o modelo de novo ou substituí-lo por completo.

Exemplo: Em outubro de 2025, pesquisadores da Anthropic, do UK AI Security Institute e do Alan Turing Institute mostraram que 250 documentos envenenados podiam ensinar um modelo a produzir texto sem sentido sempre que ele encontrasse um determinado gatilho. 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 você pode fazer:

• Rastreie a origem dos seus dados: Mantenha um registro de cada conjunto de dados e modelo que você usa, de onde cada um veio e o que mudou entre as versões. Recomendamos o controle de versão para conjuntos de dados para que, se surgir um envenenamento, você possa reverter para uma versão limpa e descobrir como ele entrou.
• Teste a presença de backdoors: Um “backdoor” é um comportamento oculto que um invasor implanta em um modelo, à espera de uma frase específica ou de outro gatilho para ativá-lo. Teste-os com entradas criadas para fazer o modelo quebrar suas regras habituais.

6. Ponha um teto no consumo ilimitado

Quando as IAs não têm nenhum limite para a quantidade de trabalho que podem realizar ou para quanto podem custar, seu consumo é considerado “ilimitado”. A maioria dos serviços de IA cobra por uso, então um invasor poderia inflar sua conta ou criar uma cópia do seu modelo.

A OWASP chama o problema central de “assimetria de custos”. Uma solicitação curta e barata pode desencadear uma computação cara do seu lado.

Exemplo: Em maio de 2024, a equipe de pesquisa de ameaças da Sysdig descobriu um novo ataque chamado “LLMjacking”. Um grupo de invasores atacou 10 serviços de LLM hospedados na nuvem usando credenciais roubadas. Eles entraram por meio de uma versão vulnerável do Laravel e, em seguida, descobriram o que as credenciais permitiam fazer e quais eram as cotas, com o objetivo óbvio de vender o acesso. Muitas configurações de log também foram consultadas, provavelmente para evitar a detecção. Segundo a Sysdig, no pior cenário, o prejuízo para a vítima poderia passar de US$ 46.000 por dia.

O que você pode fazer:

• Defina orçamentos que interrompam os gastos: Estabeleça limites rígidos de gastos para usuários individuais, chaves de API, equipes e a conta como um todo. Aplique-os em todos os pontos por onde as solicitações possam entrar.
• Dê a cada tarefa um ponto de parada: Limite por quanto tempo uma tarefa pode ser executada, quanto texto ela pode processar e gerar e quantas chamadas de ferramenta pode fazer. Adicione interrupções automáticas para agentes que se repetem ou excedem sua cota.

7. Identifique a desinformação antes de agir

Quando uma IA produz algo falso que parece certo, e alguém, ou algo, age com base nisso, isso se chama desinformação. O risco central não é tanto a resposta errada em si, mas o fato de ela ser considerada confiável e usada.

O histórico de incidentes sugere que os profissionais da área não estavam tão preocupados com a desinformação quanto deveriam. Segundo a carta de abertura da edição de 2026, os votantes a colocaram perto do fim da lista, mas, a julgar pelos incidentes reais, ela está perto do topo.

Exemplo: Em 2025, a Deloitte Austrália entregou uma revisão dos sistemas de TI de assistência social no âmbito de um contrato governamental de A$ 440.000. O pesquisador Chris Rudge, da Universidade de Sydney, encontrou referências a pesquisas inexistentes e uma citação fabricada de uma decisão de um tribunal federal. O relatório revisado informou que a Deloitte havia usado o Azure OpenAI GPT-4o em sua metodologia, e a empresa concordou em devolver a última parcela do pagamento. Infelizmente, tratava-se justamente de um trabalho de asseguração.

O que você pode fazer:

• Verifique se as evidências sustentam a resposta: Fundamente as afirmações em fontes atuais e confiáveis. Para uma resposta sobre políticas, recupere a política aprovada e verifique se ela sustenta a conclusão, incluindo suas exceções.
• Verifique antes que o sistema aja: Se um agente disser que um cliente passou por uma verificação de identidade, confirme isso no sistema de verificação antes de liberar um pagamento. Exija aprovação humana para decisões importantes, com as evidências de apoio disponíveis para o revisor.

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

Os aplicativos de IA fornecem ao modelo instruções e informações de contexto que os usuários normalmente não veem. Isso pode incluir o prompt de sistema, políticas internas, descrições das ferramentas disponíveis e regras sobre quem pode usá-las. Uma exposição de contexto oculto ocorre quando o modelo revela essas informações a alguém.

Em 2026, a OWASP ampliou esta entrada, antes chamada de “vazamento do prompt de sistema”, porque o prompt de sistema é apenas parte do que pode escapar. O perigo depende do que você colocou ali. Um guia de tom de voz vazado é um pouco constrangedor, mas uma chave de API vazada dá a alguém acesso ao seu banco de dados confidencial.

Exemplo: Em fevereiro de 2023, usuários conseguiram fazer o Bing Chat da Microsoft revelar suas instruções internas. Uma tentativa bem-sucedida veio de Marvin von Hagen, que afirmou ser desenvolvedor da OpenAI e pediu as instruções para poder configurar o modelo. O Bing revelou as regras que regiam suas pesquisas, respostas e comportamento de segurança, além de seu nome interno, Sydney. Entre as instruções reveladas, havia uma que mandava manter essas instruções em sigilo.

O que você pode fazer:

• Mantenha segredos fora do contexto do modelo: Parta do princípio de que tudo o que o modelo consegue ler pode se tornar visível para os usuários — armazene senhas, chaves de API e tokens de acesso em um sistema separado de gerenciamento de segredos.
• Garanta que as permissões funcionem mesmo se as regras vazarem: Aplique verificações de acesso no código da sua aplicação. Se uma ferramenta for restrita a administradores, verifique as permissões da conta do usuário antes de executá-la.

9. Proteja seus vetores e embeddings

Quando uma IA usa busca vetorial para encontrar respostas nos documentos da sua empresa, ela não pesquisa o texto diretamente. Os documentos são convertidos em “embeddings”, que são longas listas de números que capturam o significado de cada trecho, e armazenados em um banco de dados vetorial. Uma pergunta é convertida da mesma forma, e o sistema recupera os trechos cujos números estão mais próximos.

A OWASP resume as quatro maneiras pelas quais isso falha: o envenenamento faz o sistema errar, a inversão faz com que ele vaze dados, o bloqueio faz com que ele fique em silêncio e o controle de acesso falho faz com que ele entregue qualquer coisa a qualquer pessoa.

Os números não são a abstração segura que parecem ser. Os embeddings armazenados podem ser convertidos de volta em texto, e um método recuperou com exatidão 92% dos trechos curtos, de 32 tokens, em seus testes. Portanto, um backup vazado “só com embeddings” também pode expor o conteúdo dos documentos.

Exemplo: Em uma pesquisa apresentada no USENIX Security 2025, pesquisadores mostraram que um único documento cuidadosamente elaborado podia impedir uma IA de responder a uma pergunta específica. Eles o adicionaram à coleção em que a IA fazia buscas. Quando a IA o encontrava, podia dizer que não tinha informações suficientes ou que responder não seria seguro. O documento não precisava instruir a IA a ignorar suas regras. Isso se chama “bloqueio de recuperação” (retrieval jamming).

O que você pode fazer:

• Mantenha índices separados para dados públicos e privados: Não misture conteúdo coletado da web com dados de parceiros ou documentos internos confidenciais. Separe fisicamente por nível de confiança em vez de marcar o conteúdo em um único índice: isso elimina toda uma classe de erros de configuração, e o conteúdo extraído da internet não tem como ir parar ao lado dos documentos do seu conselho de administração.
• Trate os embeddings como os documentos dos quais vieram: Criptografe-os, proteja os backups do banco de dados vetorial tanto quanto os arquivos de origem e exclua os embeddings ao excluir o original. As chaves de API do seu serviço de embeddings devem ser mantidas em sigilo.

10. Verifique a saída da IA antes de repassá-la

Sempre que uma aplicação repassa a saída da IA para outro sistema sem verificar se ela é segura para uso nele, a aplicação está tratando a saída do LLM de forma inadequada.

Essa categoria também abrange o código inseguro que os assistentes de programação com IA geram em grande escala. Afinal, cada linha que um assistente escreve também é saída.

Exemplo: Em 2025, o pesquisador Johann Rehberger mostrou como o assistente de programação Amp, da Sourcegraph, podia vazar conteúdo de chats simplesmente exibindo uma imagem. Ele usou injeção de prompt para fazer o Amp incluir informações privadas no endereço web de uma imagem. A aplicação então buscava essa imagem automaticamente, enviando as informações para o servidor dele. A falha no tratamento de saída foi essa solicitação automática — o texto gerado pelo modelo se tornou uma conexão com um servidor externo, levando dados privados junto.

O que você pode fazer:

• Torne a saída segura para o seu destino: Verifique e trate as respostas de acordo com o lugar para onde elas vão. Em uma página web, impeça que o texto gerado se torne código executável. Em um banco de dados, use consultas preparadas que mantenham os valores fornecidos separados dos comandos.
• Impeça que as respostas façam conexões externas automáticas: Desative, por padrão, o carregamento automático de imagens, prévias de links e páginas incorporadas nas respostas do modelo. Restrinja as conexões necessárias a destinos explicitamente aprovados.

Como a Perplexity protege LLMs?

Partimos do princípio de que todos os riscos acima vão se concretizar em algum momento e projetamos nossos sistemas para que causem poucos danos quando isso acontecer. Nosso CISO, Kyle Polley, explicou como fazemos isso em um workshop recente.

• O agente tem seu próprio computador, e ele começa vazio: As ferramentas de agentes instaladas no seu laptop podem obter acesso aos arquivos, apps e credenciais salvas nele. O Perplexity Computer funciona de outra forma. Cada tarefa é executada em seu próprio sandbox isolado e, como diz Polley, “por padrão, ele não tem acesso a nada”.
• O agente nunca vê as senhas: As credenciais dos serviços conectados ficam armazenadas fora do sandbox. Quando o agente precisa acessar um serviço como o GitHub, ele envia uma solicitação sem nenhuma credencial anexada. Um gateway verifica se o destino e a solicitação são os esperados e, então, adiciona as credenciais na saída. O agente pode usar a conexão sem ter acesso às chaves.
• Suas permissões são mantidas, e você pode restringi-las ainda mais: As conexões feitas via OAuth preservam suas permissões de acesso no serviço conectado. Se você não pode ver algo, seu agente também não pode.
• Toda página web é tratada como desconhecida: Criamos o BrowseSafe para o Comet, nosso navegador agêntico, porque as ferramentas que testamos não atendiam às nossas necessidades no uso real. O navegador analisa páginas web e outros conteúdos externos, incluindo e-mails, em busca de injeção de prompt. Disponibilizamos como código aberto tanto o modelo quanto o conjunto de dados.
• Monitoramos o agente e as máquinas em que ele é executado: O Numbat fica entre a decisão do agente de agir e a execução efetiva da ferramenta. O Numbat registra a atividade dos agentes de programação compatíveis e pode bloquear ações que violem as políticas configuradas antes que sejam executadas. O Bumblebee faz o inventário de pacotes de software em laptops, servidores e pipelines de build e sinaliza os que são reconhecidamente maliciosos. Ambos são de código aberto.
• Os provedores de modelos não guardam seus dados: Temos acordos de retenção zero de dados com nossos provedores terceirizados de LLM. Os administradores de contas Enterprise também podem reduzir a retenção de dados da própria Perplexity para apenas 24 horas.

Criamos o Numbat de forma proativa, por um motivo que Polley resume em uma frase: “Quanto mais autonomia você dá a um agente, maior é o risco.”

Perguntas frequentes sobre segurança de LLMs

Qual é o LLM mais seguro?

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

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

O que são vulnerabilidades de LLMs?

Vulnerabilidades de LLMs são pontos fracos que permitem que um sistema de IA seja enganado, vaze dados ou cause danos, seja pela ação de um invasor ou por seus próprios erros.

Os dez principais riscos são injeção de prompt, divulgação de informações sensíveis, agência excessiva, cadeia de suprimentos, envenenamento de dados e de modelos, consumo ilimitado, desinformação, exposição de contexto oculto, fraquezas em vetores e embeddings e tratamento inadequado de saída.

Um LLM privado é seguro?

É uma opção mais segura para alguns casos, mas não por padrão. Você tem mais controle sobre o tratamento dos dados se executar um modelo na sua própria infraestrutura ou em um ambiente de nuvem. Não há uma forma automática de evitar injeções de prompt, agência excessiva, envenenamento ou desinformação.

Ao optar pela auto-hospedagem, você também passa a ser responsável pelo modelo que baixa, incluindo os riscos da cadeia de suprimentos e a infraestrutura que ele exige.