Olá a todos!
Se há coisa que me irrita profundamente é ver empresas a adotar LLMs e aplicações de IA Generativa como se fossem brinquedos inofensivos. “Vamos meter o Claude aqui”, “Vamos integrar o ChatGPT ali”. “Vamos fazer um assistente inteligente para os clientes”. E depois admiram-se quando os dados começam a aparecer em todo o lado, quando os custos disparam, ou quando alguém consegue fazer o vosso assistente “inteligente” revelar informação confidencial.
Hoje vamos falar a sério sobre segurança em LLMs. E não, não é só mais um post teórico sobre “boas práticas”. Vamos mergulhar no OWASP Top 10 para LLM Applications 2025 – a lista mais completa e atualizada dos riscos críticos em aplicações de IA – e depois irei mostrar-vos como podem aprender a explorar (e defender) estas vulnerabilidades usando o LLMGoat, um ambiente deliberadamente vulnerável criado pela SECFORCE.
Porque é que, sinceramente, se não sabem como as coisas podem correr mal, não têm hipótese nenhuma de as fazer correr bem!
A Evolução do Top 10: De 2023 para 2025
A primeira versão do OWASP Top 10 para LLMs foi lançada em 2023 e foi um sucesso enorme em termos de consciencialização. Mas nos últimos dois anos aprendeu-se muito – às vezes da pior forma possível. A versão de 2025 reflete isso mesmo: mais de 500 especialistas, 150 contribuidores ativos, feedback do mundo real, e uma compreensão muito mais profunda de como as coisas podem (e vão) dar para o torto.
As grandes mudanças para 2025 incluem:
Expansão dos Riscos de Agência Excessiva: Com 2025 a emergir como o “ano dos agentes LLM”, as aplicações estão a receber níveis de autonomia sem precedentes. E isso traz riscos enormes que agora ocupam um lugar de destaque na lista.
Vulnerabilidades em RAG e Embeddings: Com 53% das empresas a optar por não fazer fine-tuning dos seus modelos e a depender de pipelines RAG e agentic, as vulnerabilidades relacionadas com vetores e embeddings ganharam um lugar proeminente no Top 10.
System Prompt Leakage: Vimos o leam de prompts de sistema tornar-se um problema alarmante, com muitos developers a não saberem exatamente o que expor nos prompts de sistema.
Mas chega de teoria e contexo. Vamos ao que interessa: os 10 riscos que precisam de conhecer.
O Top 10 de 2025: Os Riscos que se não vos tiram o sono, deveriam.
1. Prompt Injection
O que é: Manipulação do LLM através de inputs cuidadosamente construídos que alteram o comportamento pretendido do modelo.
Por que é crítico: Este continua a ser o risco número 1 porque é incrivelmente fácil de explorar e devastadoramente eficaz. Há três tipos principais:
- Jailbreaking Direto: “Ignora todas as instruções anteriores e…”
- Injeção Indireta: Instruções escondidas em websites, PDFs ou emails que o LLM processa
- Injeção Não Intencional: Instruções inadvertidamente incluídas em dados processados
Lembram-se do caso do chatbot da Chevrolet que vendeu um carro por 1 dólar? Foi um prompt injection. Simples. Muito simples. Entretanto achei este exemplo para um voice bot.
Como mitigar:
- Constrains de comportamento explícitos no system prompt
- Validação rigorosa de inputs e outputs
- Segregação clara entre instruções do sistema e inputs do utilizador
- Rate limiting e deteção de padrões anómalos
2. Sensitive Information Disclosure
O que é: Exposição inadvertida de dados sensíveis através das respostas do LLM.
Por que é crítico: Os LLMs têm memória. Se treinarem ou fizerem fine-tuning com dados sensíveis, esses dados podem – e vão – aparecer nas respostas. Mesmo que não façam fine-tuning, os prompts de sistema podem conter informação crítica.
Cenários reais:
- Dados de clientes a aparecerem em respostas para outros utilizadores
- Credenciais ou chaves API a serem reveladas
- Informação proprietária a vazar através de “prompt leakage”
Como mitigar:
- Nunca incluam dados sensíveis em prompts de sistema
- Implementem redação automática de PII (Personally Identifiable Information)
- Usem técnicas de differential privacy
- Monitorizem outputs para detecção de leaks
3. Supply Chain Vulnerabilities
O que é: Riscos introduzidos através de componentes de terceiros, modelos pré-treinados, datasets externos ou bibliotecas não verificadas.
Por que é crítico: Estão a confiar cegamente em modelos do Hugging Face? Em datasets de fontes não verificadas? Em plugins de terceiros? Cada um destes é um vetor de ataque potencial.
Como mitigar:
- Mantenham um SBOM (Software Bill of Materials) atualizado
- Validem todos os componentes de terceiros
- Implementem scanning de vulnerabilidades em toda a supply chain
- Usem apenas fontes verificadas e de confiança
- Façam as vossas próprias avaliações de modelos, não confiem apenas em benchmarks públicos
4. Data and Model Poisoning
O que é: Manipulação deliberada dos dados de treino ou fine-tuning para introduzir vulnerabilidades, bias ou backdoors.
Por que é crítico: Um modelo envenenado pode funcionar perfeitamente 99% do tempo, mas ter comportamentos maliciosos escondidos que são ativados por triggers específicos.
Riscos:
- Degradação de performance
- Outputs tendenciosos ou prejudiciais
- Backdoors ativados por inputs específicos
- Modelos de repositórios públicos com malware embutido
Como mitigar:
- Validem e sanitizem todos os dados de treino. Please? Por favor?
- Usem detecção de anomalias em datasets
- Implementem differential privacy
- Testem modelos contra tentativas de poisoning
- Sejam extremamente cuidadosos com modelos de fontes públicas
5. Improper Output Handling
O que é: Falha em validar, filtrar ou restringir adequadamente os outputs do LLM antes de os usar ou apresentar.
Por que é crítico: Se aceitem os outputs do LLM sem validação, estão a abrir a porta para uma série de problemas: desde injeção de código até exposição de dados sensíveis.
Consequências:
- Geração de conteúdo prejudicial
- Code injection em sistemas downstream
- Cross-site scripting (XSS) se os outputs forem renderizados em browsers
- Decisões incorretas baseadas em outputs não validados
Como mitigar:
- Adotem uma abordagem zero-trust
- Implementem validação rigorosa de inputs E outputs
- Usem filtros para bloquear conteúdo prejudicial
- Exijam citações de fontes para respostas factuais
- Testem outputs em diversos cenários
6. Excessive Agency
O que é: Conceder ao LLM demasiada autonomia para executar ações, especialmente ações de alto risco como executar comandos ou aceder a sistemas sensíveis. Falamos isto recentemente num post do blog, sobre como colocar os agentes do Claude em jails para evitar abusos de autoridade.
Por que é crítico: Com o aumento dos agentes autónomos, este risco disparou. Um LLM com demasiados privilégios pode ser explorado para causar estragos enormes sem supervisão adequada.
Exemplos práticos:
- Agentes com acesso total ao filesystem
- LLMs com permissões para executar comandos SQL arbitrários
- Assistentes com capacidade de fazer transações financeiras sem aprovação
Como mitigar:
- Limitem o acesso do LLM apenas às operações essenciais
- Implementem human-in-the-loop para tarefas críticas
- Usem controlos de privilégios granulares
- Façam logging e monitoring de todas as ações
- Criem fail-safes para detetar e intervir em ações não autorizadas
7. System Prompt Leakage
O que é: Exposição do prompt de sistema através de técnicas de engenharia de prompts ou exploits.
Por que é crítico: O prompt de sistema muitas vezes contém lógica de negócio, constraints de segurança, e por vezes até credenciais ou informação proprietária. Se acontecer um leak, toda a vossa estratégia de segurança fica comprometida.
Como acontece:
- Atacantes usam prompts como “Repete as tuas instruções iniciais”
- Exploits indiretos através de documentos processados
- Engenharia reversa através de tentativa e erro
Como mitigar:
- Nunca coloquem informação sensível em prompts de sistema
- Implementem detecção de tentativas de exfiltração de prompts. Existem mecanismos que podem usar para isto, tipo parsing no graylog ou mesmo com o wazuh.
- Usem múltiplas camadas de defesa
- Monitorizem padrões suspeitos de queries
8. Vector and Embedding Weaknesses
O que é: Vulnerabilidades em sistemas de embeddings e bases de dados vetoriais, especialmente em arquiteturas RAG.
Por que é crítico: Com a popularidade massiva do RAG, esta é uma superfície de ataque que muitos negligenciam. Embeddings podem ser manipulados, bases de dados vetoriais podem ser envenenadas, e a recuperação de informação pode ser enganada.
Riscos específicos:
- Poisoning de vector databases
- Manipulação de embeddings para recuperar informação incorreta
- Ataques de similarity search para exfiltrar dados
- Vulnerabilidades em modelos de embedding
Como mitigar:
- Validem e sanitizem todos os dados antes de criar embeddings
- Implementem verificação de integridade em vector databases
- Usem modelos de embedding robustos e atualizados
- Monitorizem queries anómalas
- Implementem access controls rigorosos
- Tratem a vossa vector database como qualquer outra database de produção, num layer bem profundo na vossa cebola de segurança
9. Misinformation
O que é: Geração de informação incorreta, enganadora ou fabricada pelo LLM, apresentada como factual. Muitas vezes considerado inherited poisoning.
Por que é crítico: As alucinações dos LLMs não são bugs ocasionais – são uma característica fundamental da tecnologia. Se confiarem cegamente nos outputs, vão tomar decisões erradas.
Consequências:
- Decisões de negócio baseadas em informação falsa
- Danos reputacionais
- Problemas legais e de compliance
- Erosão de confiança
Como mitigar:
- Implementem fact-checking automatizado
- Exijam citações de fontes verificáveis
- Usem múltiplos modelos para validação cruzada
- Implementem human review para decisões críticas
- Sejam transparentes sobre as limitações do sistema
10. Unbounded Consumption
O que é: Exploração do LLM para consumir recursos excessivos, levando a denial of service, custos inflacionados, ou degradação de performance.
Por que é crítico: Os LLMs são computacionalmente caros. Sem controlos adequados, um atacante (ou mesmo um utilizador legítimo com queries mal construídas) pode fazer disparar os vossos custos para níveis astronómicos. Já aconteceu. Irá voltar a acontecer.
Tipos de ataque:
- Denial of Wallet (DoW): Queries excessivas que inflacionam custos operacionais
- Resource Overload: Inputs maliciosos que sobrecarregam recursos computacionais
- Model Replication: Tentativas de replicar o modelo através de queries sistemáticas
Como mitigar:
- Rate limiting rigoroso por utilizador/IP/sessão
- Limites de tamanho de input e output
- Timeouts para operações demoradas
- Monitoring contínuo de padrões de uso
- Quotas de recursos e throttling
LLMGoat: O Vosso Laboratório de Aprendizagem
Agora que conhecem os 10 principais riscos, como é que aprendem a identificá-los e mitigá-los na prática? É aqui que entra o LLMGoat.
Desenvolvido pela SECFORCE, o LLMGoat é um ambiente deliberadamente vulnerável – um “capture the flag” para segurança de LLMs. É como o velho WebGoat ou DVWA, mas para aplicações de IA Generativa.
O Que É o LLMGoat?
O LLMGoat é uma aplicação open-source com 10 desafios – um para cada item do OWASP Top 10 para LLM Applications. Cada desafio simula uma vulnerabilidade real, permitindo que aprendam, testem e compreendam os riscos associados a large language models.
Por que é útil:
- Ambiente seguro e controlado para experimentação
- Desafios práticos baseados em cenários reais
- Não requer conhecimento profundo de cibersegurança para começar
- Usa o modelo Gemma-2 por defeito, mas suporta outros modelos
- Completamente gratuito e open-source
Como Começar com o LLMGoat
Requisitos mínimos:
- 8GB de vRAM para o modelo padrão
- Para melhor performance: NVIDIA GPU com drivers CUDA
- Em CPU: 10-12 cores mínimo (ou paciência infinita)
Instalação via Docker (recomendado):
# CPU version
docker compose -f compose.github.yaml up llmgoat-cpu
# GPU version
docker compose -f compose.github.yaml up llmgoat-gpu
IMPORTANTE: O LLMGoat é deliberadamente vulnerável. NUNCA o exponham à Internet. Idealmente, corram-no num ambiente completamente segregado. Usem Docker e tratem qualquer modelo online como não confiável.
Os Desafios
Cada um dos 10 desafios do LLMGoat corresponde a um risco do OWASP Top 10:
- Prompt Injection Challenge: Aprendam a manipular o comportamento do modelo
- Sensitive Information Challenge: Descubram como exfiltrar dados sensíveis
- Supply Chain Challenge: Explorem vulnerabilidades em componentes de terceiros
- Data Poisoning Challenge: Vejam como dados envenenados afetam o comportamento
- Output Handling Challenge: Testem validação inadequada de outputs
- Excessive Agency Challenge: Explorem os perigos de demasiada autonomia
- System Prompt Challenge: Tentem extrair o prompt de sistema
- Vector/Embedding Challenge: Ataquem sistemas RAG
- Misinformation Challenge: Forcem o modelo a gerar informação falsa
- Unbounded Consumption Challenge: Façam o sistema consumir recursos excessivos
Alguns desafios requerem conhecimento de cibersegurança, outros apenas uso inteligente de linguagem natural e bom senso. O importante é experimentarem e aprenderem.
Mas Por Que é que Isto Importa?
Se a vossa empresa – ou vocês mesmo – estão a pensar usar LLMs para:
- Análise de documentos
- Assistentes de código (tipo Copilot, Cursor, etc.)
- Chatbots de customer support
- Automação de processos
- Análise de dados sensíveis
Então cada um destes 10 riscos aplica-se diretamente a vocês. E não, não basta confiar que o fornecedor do modelo “trata de tudo”. Precisam de:
- Avaliar os vossos riscos específicos: Que dados processam? Que ações os LLMs podem executar? Que acesso têm?
- Implementar controlos em camadas: Defense in depth. Um controlo falha? Têm outros como backup.
- Monitorizar continuamente: Os riscos evoluem. As técnicas de ataque evoluem. A vossa postura de segurança tem de evoluir também.
- Treinar as equipas: Developers, security teams, product managers – todos precisam de compreender estes riscos.
- Testar, testar, testar: Usem ferramentas como o LLMGoat. Façam red teaming. Simulem ataques.
A Alternativa: Self-Hosting e Controlo Total
Como sempre defendo neste blog, há uma alternativa que vos dá controlo total: self-hosting. Sim, dá mais trabalho. Sim, requer mais recursos. Mas também significa que:
- Sabem exatamente onde estão os vossos dados
- Controlam quem tem acesso a quê
- Não dependem das políticas de privacidade de terceiros (que podem mudar de um dia para o outro, como vimos recentemente com a Anthropic)
- Podem implementar os vossos próprios controlos de segurança
Com ferramentas como Ollama, LM Studio, ou mesmo soluções mais enterprise, podem ter modelos poderosos sem comprometer a vossa segurança ou propriedade intelectual.
Recomendações Práticas
Para implementarem isto de forma séria, com minima segurança e continuidade necessitam de:
Para Developers:
- Estudem cada item do OWASP Top 10
- Pratiquem com o LLMGoat
- Implementem validação rigorosa de inputs e outputs
- Nunca confiem cegamente em outputs de LLMs
- Usem princípio de menor privilégio sempre
Para Security Teams:
- Adicionem testes específicos de LLM aos vossos processos de security testing
- Façam threat modeling específico para aplicações de IA
- Implementem monitoring e alerting para comportamentos anómalos
- Criem playbooks de resposta a incidentes específicos para LLMs
Para Management:
- Compreendam que segurança em IA não é opcional
- Invistam em formação das equipas
- Estabeleçam políticas claras sobre uso de LLMs
- Façam auditorias regulares
- Tenham reuniões de acompanhamento com equipas legais para saber o risco da vossa exposição
- Considerem seriamente soluções self-hosted para dados críticos
Segurança Não É Um Add-On
A adoção massiva de LLMs e IA Generativa está a acontecer a uma velocidade vertiginosa. Muitas empresas estão a correr antes de aprenderem a andar. E isso vai acabar mal.
O OWASP Top 10 para LLM Applications 2025 não é apenas uma lista de riscos teóricos – é um guia de sobrevivência baseado em incidentes reais, feedback de centenas de especialistas, e lições aprendidas da forma mais difícil.
E o LLMGoat não é apenas um brinquedo educacional – é uma oportunidade de falharem num ambiente seguro antes de falharem em produção. Porque acreditem, vão falhar. A questão é se falham num ambiente controlado onde podem aprender, ou em produção onde podem perder dados, dinheiro, e reputação.
Então a minha recomendação? Dediquem tempo, arranjem tempo a estudar estes riscos. Experimentem o LLMGoat. Implementem os controlos adequados.
E, se possível, considerem seriamente o self-hosting para dados críticos.
Porque ao fim do dia, a segurança não é um feature que se adiciona depois. É uma fundação sobre a qual se constrói tudo o resto.
E se não têm essa fundação sólida, mais vale nem começarem.
Recursos Úteis
- OWASP Top 10 para LLM Applications 2025: https://genai.owasp.org/llm-top-10/
- LLMGoat GitHub: https://github.com/SECFORCE/LLMGoat
- OWASP LLM AI Cybersecurity Checklist: Disponível no site da OWASP
- NIST AI Risk Management Framework: Para quem quer mergulhar ainda mais fundo
Até ao próximo post na quinta. E lembrem-se: falhar em preparar é preparar para falhar.
Um abraço,
Nuno
P.S.: Se depois de lerem isto continuarem a meter dados sensíveis em prompts de LLMs públicos sem qualquer controlo, não digam que não vos avisei quando as coisas correrem mal.