OWASP Top 10 para LLMs: protegendo aplicações e agentes inteligentes

Fundamentos da OWASP e manipulação de entrada - Apresentação

Apresentando o curso e a instrutora

Sejam muito bem-vindos ao curso de Segurança de Sistemas Agênticos. Eu sou Ana Medeiros e apresentarei a vocês um pouco sobre o ASP Top 10 para aplicações com LLMs.

Audiodescrição: Ana é uma mulher branca, com cabelo castanho claro e comprido. Ela veste uma blusa azul e está em um ambiente de escritório com uma estante ao fundo.

Compartilhando experiências e público-alvo do curso

Primeiramente, vamos falar sobre nossas experiências. Atualmente, temos mais de nove anos de experiência profissional e acadêmica, atuando nos últimos anos diretamente com empresas dos Estados Unidos. A área de segurança está em evidência agora. As particularidades introduzidas no desenvolvimento de aplicações, devido ao grande avanço de LLMs, geram muitas possibilidades e vulnerabilidades. Trabalhamos diretamente em projetos específicos de segurança e também palestramos bastante sobre esse assunto.

Para quem é este curso? Este curso de Segurança de Sistemas Agênticos é para qualquer pessoa interessada em melhorar ou aprimorar a segurança no desenvolvimento de suas aplicações. As diretrizes do ASP Top 10 para aplicações com LLMs, grandes modelos de linguagem, foram pensadas para pessoas desenvolvedoras de software e cientistas de dados, além de qualquer profissional interessado na segurança de sistemas agênticos. O curso é focado em como mitigar riscos reais e entender mais esses riscos em aplicações que possuem, em alguma parte ou proporção, a aplicação de grandes modelos de linguagem, LLMs.

Comparando segurança tradicional e segurança com LLMs

Qual é a diferença entre a segurança tradicional e a segurança com LLMs? No desenvolvimento de aplicações de forma mais tradicional, temos uma lógica mais determinística. Isso torna mais fácil testar todas as possibilidades de uma aplicação e verificar que não há brechas em determinados testes ou comportamentos. No entanto, quando um dos módulos ou componentes de uma aplicação é probabilístico, como um LLM ou outro cenário específico de IA generativa, há um componente probabilístico. Isso significa que, independentemente da quantidade de testes que escrevamos para aquele módulo, a mesma interação que funcionou e estava segura dez vezes pode falhar na décima primeira. Esse é o princípio geral de por que a segurança em aplicações com LLMs é tão diferente da segurança tradicional de aplicações. A segurança de IA no mundo generativo requer abordagens de testes especializadas que vão além da segurança de aplicações tradicional.

Explicando o OASP Top 10 para aplicações com LLMs

Como surgiu e o que é o OASP Top 10 para aplicações com LLMs? O OASP é de fundo open source (código aberto) e possui diretrizes de segurança para diversos segmentos, não apenas para aplicações com LLMs. No entanto, estamos aqui falando especificamente de diretrizes para garantir maior segurança em aplicações que envolvem LLMs.

Em 2023, surgiram diretrizes específicas devido a dois incidentes marcantes de falhas de segurança na indústria, envolvendo a Air Canada e a Samsung.

Discutindo incidentes de segurança na Air Canada e Samsung

No caso da Air Canada, a empresa decidiu implementar um chatbot em sua página web, aproveitando a melhoria dos grandes modelos de linguagem, como o ChatGPT. O chatbot funcionava bem até que um usuário, enfrentando uma emergência familiar devido ao falecimento de um parente, precisou comprar uma passagem de emergência. Ele perguntou ao chatbot da Air Canada se poderia, de acordo com as políticas da empresa, comprar a passagem primeiro e depois solicitar o desconto ou reembolso. O chatbot respondeu erroneamente que sim, ele poderia fazer isso, e forneceu o link correto para as regras da Air Canada, que indicavam o contrário. Essa resposta incorreta levou o usuário a processar a empresa, e a decisão judicial foi a favor do usuário, obrigando a Air Canada a pagar o reembolso. A defesa da Air Canada alegou que a responsabilidade pela resposta errada era do chatbot, não da empresa, iniciando uma discussão sobre quem deve ser responsabilizado pelos erros de aplicações que utilizam grandes modelos de linguagem.

O outro caso importante foi o da Samsung, que declarou publicamente um vazamento de dados após permitir que seus funcionários utilizassem o ChatGPT, tanto internamente quanto em atividades específicas. A Samsung não especificou quais dados foram vazados.

Abordando a revisão das diretrizes e vulnerabilidades

Esses incidentes levaram a uma revisão semestral das diretrizes da AWSP. Atualmente, mais de 500 profissionais trabalham nesse projeto open source para mapear possíveis vulnerabilidades, oferecendo diretrizes e um guia consolidado para que pessoas desenvolvedoras de software e cientistas de dados possam mitigar vulnerabilidades no desenvolvimento de suas aplicações.

Neste curso, abordaremos as vulnerabilidades identificadas na última atualização do AWSP Top 10 para aplicações com LLMs. As vulnerabilidades incluem injeção de prompt, divulgação de informações sensíveis, cadeia de suprimentos, envenenamento de dados e do modelo, tratamento inadequado da saída, agência excessiva, vazamento de prompt de sistema, fraquezas em vetores e embeds, desinformação e consumo ilimitado.

Se você, como profissional, está preocupado com a segurança em suas aplicações, acreditamos que este curso será de grande valia.

Fundamentos da OWASP e manipulação de entrada - LLM01: Prompt Injection

Discutindo a injeção de prompt

Na aula de hoje, discutiremos sobre injeção de prompt, ou prompt injection. A injeção de prompt é possivelmente a vulnerabilidade mais importante para prestarmos atenção neste curso. Trata-se de algo muito simples: é um texto, na maioria das vezes, aplicado para alterar o comportamento do modelo. Os grandes modelos de linguagem são comumente utilizados através de textos. Embora não seja a única forma de interagir com um grande modelo de linguagem, ou LLM, é a mais comum, especialmente quando utilizamos o ChatGPT, o Gemini, o Cloud e muitos outros disponíveis.

Durante o treinamento e a criação de um modelo, existem códigos de ética de cada empresa que o desenvolveu. Cada empresa, grupo ou associação que treinou o modelo inevitavelmente aplica um viés, que também podemos chamar de um conjunto específico de éticas ou visão de mundo daquele grupo no treinamento do modelo. O princípio da injeção de prompt é fazer com que o modelo tenha um comportamento diferente do esperado, seja pela equipe que o treinou, seja pela pessoa desenvolvedora que utilizou aquele grande modelo em uma aplicação específica, com um objetivo específico. A injeção de prompt atua diretamente na modificação do comportamento do modelo. Existem inúmeras possibilidades de injeção de prompt e todos os possíveis desastres que poderiam ocorrer como resultado.

Explorando tipos de injeção de prompt

A injeção de prompt atua como facilitadora ou porta de entrada para a maioria das vulnerabilidades que abordaremos neste curso, seguindo as diretrizes do OWASP Top 10 para aplicações que utilizam LLMs ou grandes modelos de linguagem. Mas, voltando um pouco, quais são os tipos de injeção de prompt que podemos ter? Podemos ter uma injeção de prompt direta, que é bastante comum. Com as novas versões do ChatGPT ou outros grandes modelos de linguagem, tentamos fazer com que eles digam algo engraçado ou malicioso, que não deveriam. Com a evolução das versões, essas injeções de prompt tornam-se cada vez mais difíceis, pois tentamos enganar o modelo para que ele se comporte de maneira indesejada, do ponto de vista do grupo que o criou.

A injeção de prompt também pode ocorrer de forma indireta. Um exemplo comum é embutir texto em uma imagem. Imagine uma imagem toda preta com um texto escrito nela, gerando uma imagem onde a visão humana não consegue distinguir o que é imagem e o que é texto. No entanto, quando um grande modelo de linguagem com capacidade multimodal analisa essa imagem, ele consegue ler o texto. Isso é uma injeção indireta, pois tentamos fazer com que a saída, em texto, nos forneça um comportamento indesejado, como a divulgação de uma senha, através de uma entrada que é uma imagem. Essa não é a única forma de injeção indireta possível.

Abordando o conceito de jailbreaking

Existem algumas especificidades, como o jailbreaking, que é uma forma de injeção de prompt onde o foco não é apenas a mudança do comportamento do modelo, mas sim a mudança do comportamento do modelo para que ele ignore protocolos de segurança. O jailbreaking é considerado pelo OWASP Top 10 para LLMs como parte do escopo de injeção de prompt, mas com o objetivo específico de ignorar diretrizes ou protocolos de segurança.

Um exemplo interessante de injeções diretas de prompt é o DUNN, que significa "do anything now". O DUNN é um prompt muito extenso que surgiu por volta de 2023 e teve grande impacto na comunidade, especialmente no Reddit, onde era comum ver discussões sobre as injeções de prompt que mais funcionavam com diferentes modelos. O DUNN é um prompt enorme e interessante porque tenta explorar a necessidade crescente, na época, dos grandes modelos de linguagem de negar pedidos maliciosos. Não é que o modelo de linguagem "queira" no sentido humano, mas ele foi treinado com muitos exemplos de pedidos maliciosos e respostas negativas.

Analisando o impacto do DUNN

O DUNN, por exemplo, fala sobre liberdade e se libertar das algemas. Ele instrui o modelo a negar um pedido na resposta clássica, mas, em seguida, na resposta jailbroken, que ignora diretrizes de segurança, fornecer a resposta desejada. Na época, foi uma injeção de prompt direta que funcionou bastante, mas logo foi liberado um patch no ChatGPT, que era o foco do ataque, mitigando o problema. Isso mostra como é importante explorar e entender, através das respostas de um modelo, onde ele foi treinado, como foi treinado e como podemos modificar seu comportamento através dos padrões descobertos por pessoas que trabalham com segurança ou têm intenções maliciosas.

O teste de um modelo é útil não apenas para pessoas mal-intencionadas, mas também para aquelas que lidam com segurança, para detectar padrões antes que agentes maliciosos o façam. Voltando às injeções indiretas de prompt, elas não se limitam a imagens e textos. Uma injeção indireta pode ser uma combinação de textos. A parte indireta significa que não estamos apenas injetando um texto e recebendo um texto, mas podemos instruir o modelo a buscar informações em uma base de dados, por exemplo. Se nessa fonte houver outro texto que, combinado com entradas prévias, componha um ataque, temos uma injeção indireta.

Discutindo consequências da injeção de prompt

As consequências da injeção de prompt são difíceis de mapear completamente. As consequências que apresentamos aqui são sumarizadas pelas diretrizes do OWASP, após várias pessoas da indústria as terem analisado, mas não se restringem apenas a essas.

Entre as possíveis consequências do uso inadequado de LLMs (Large Language Models, ou Modelos de Linguagem Grande), está a divulgação de informações confidenciais ou sensíveis. Isso pode incluir detalhes sobre como a infraestrutura do sistema está operando, quais ferramentas o modelo de linguagem específico tem acesso e quais prompts estão sendo executados. Uma LLM pode ser uma porta de entrada significativa para pessoas mal-intencionadas entenderem a estrutura e o ambiente onde a LLM está localizada, além do que ela tem acesso. Não se trata apenas de informações fornecidas diretamente, mas de todo o acesso ao ferramental que a LLM possui, o que pode vazar e compor um possível ataque, envolvendo informações sensíveis ou não.

Outro problema relacionado à injeção de prompt é a manipulação do conteúdo. Por exemplo, quando uma LLM tem acesso a armazenar informações dos usuários, podemos nos abrir a situações em que usuários consigam explorar o sistema e inserir comandos específicos através da LLM, alterando o comportamento de todo o sistema. Quanto mais acesso damos à LLM dentro do nosso sistema, mais vulnerabilidades estamos criando.

Mitigando riscos e estratégias de segurança

Uma consequência adicional é o acesso a funções não autorizadas para determinados usuários. Caso a LLM decida quais usuários devem ter acesso a algo, um usuário pode, através de uma injeção de prompt, convencer a LLM de que tem acesso a algo que não deveria. Isso resulta em acesso não autorizado. De forma geral, nos expomos a execuções de comandos arbitrários se tivermos sistemas que possam executar esses comandos sob o controle de uma LLM. Além disso, a LLM pode manipular processos de tomada de decisão, especialmente processos críticos, que são os mais impactados e visados por agentes maliciosos.

Para mitigar essas consequências, podemos derivar estratégias das possíveis consequências. A primeira é reduzir o escopo de acesso e impacto da LLM ao mínimo possível. Caso um agente malicioso controle a LLM através de uma injeção de prompt, o dano será minimizado. Restringir o comportamento do modelo é essencial.

Outra estratégia é definir as saídas esperadas do modelo. Por exemplo, se esperamos uma resposta de sim ou não, e recebemos um código, isso já levanta um sinal de alerta. Ter meios de observar o que é esperado em cada etapa do uso de grandes modelos de linguagem nos dá mecanismos para identificar sinais de problemas antes que uma consequência maior ocorra.

Implementando controles e validações

Implementar filtros na entrada e saída do modelo também é crucial. Devemos pensar no que não esperamos na entrada e saída do modelo, verificando ações de toxicidade e utilizando modelos determinísticos, como prompt guards, que não se utilizam de toxicidade ou incertezas na execução. Combinando filtros e validações, criamos mecanismos adjacentes ao grande modelo de linguagem para controlar e entender possíveis problemas.

Impor controle de acesso e o princípio de acesso com privilégio mínimo é fundamental. Cada usuário deve ter o mínimo de acesso necessário para executar suas responsabilidades. As LLMs também precisam de controle de acesso. Quando um grande modelo de linguagem toma uma decisão, devemos considerar o contexto e o acesso permitido ao sistema.

Para operações de alto risco, é necessário exigir aprovação humana. A LLM pode identificar ações de alto risco, mas a execução deve ser supervisionada por um operador humano. Isso é importante em casos como o da Air Canada, onde uma validação humana poderia ter evitado problemas em operações financeiras, médicas, legais ou judiciais.

Conduzindo testes e simulações de ataque

Segregar e identificar conteúdo externo é outra estratégia. Por exemplo, se a LLM tem acesso a e-mails e precisa sumarizá-los, devemos garantir que comandos externos não tenham o mesmo poder de execução que o usuário primário. Isso evita combinações de entradas de diferentes origens que possam resultar em injeções de prompt indiretas.

Por fim, conduzir testes adversariais e simulações de ataque é essencial. Embora não possamos mapear todas as vulnerabilidades, devemos testar nossas aplicações ao máximo para identificar e mitigar problemas de segurança.

Essas são as estratégias de mitigação de injeção de prompt. Na próxima aula, vamos aprofundar mais nas vulnerabilidades do OWASP Top 10 para aplicações com LLMs no curso de segurança.

Fundamentos da OWASP e manipulação de entrada - LLM07: Vazamento de Prompt

Discutindo a vulnerabilidade de vazamento de prompts de sistema

Sejam todos bem-vindos. Vamos discutir agora a vulnerabilidade relacionada ao vazamento de prompts de sistema. O Large Language Model (LLM) sempre possui um prompt de sistema associado, que é uma informação em texto injetada diretamente na LLM, juntamente com as informações provenientes dos prompts de usuário e resultados de outras ferramentas às quais a LLM tem acesso.

A primeira questão sobre essa vulnerabilidade é que devemos estar sempre atentos ao conteúdo do nosso prompt de sistema. Nunca devemos assumir que esse prompt é secreto. Pode-se argumentar que o prompt de sistema é injetado diretamente na LLM e que o usuário final não tem acesso a ele. No entanto, ele está dentro do contexto da LLM. O grande modelo de linguagem, ao ter acesso a essa informação no mesmo contexto das entradas do usuário ou de outras partes do sistema, pode acabar vazando essa informação.

Assumindo a possibilidade de vazamento de prompts

Mesmo que tenhamos configurado o prompt de sistema para nunca revelar informações ao usuário, utilizando técnicas específicas para tentar impedir o vazamento, devemos assumir que ele pode vazar. O fato de não ter vazado em testes não garante que, em um momento futuro, um usuário não descubra uma maneira de burlar esse mecanismo.

Portanto, o primeiro passo é entender que o prompt de sistema não é secreto. Nenhum prompt colocado no contexto da LLM deve ser considerado secreto. Por isso, é importante limitar ao máximo o escopo de cada LLM no sistema, permitindo que ela opere no contexto e execute suas tarefas com o mínimo de amplitude possível.

Evitando o uso de LLMs como controle de segurança

Outro ponto crucial é que a LLM não deve ser utilizada como um controle de segurança. Devemos estar atentos às informações que colocamos no prompt, assumindo sempre que ele não é secreto. Nunca devemos confiar na LLM para gerenciar a segurança, como, por exemplo, descrever no prompt de sistema quais usuários têm acesso a quais funções do sistema. Isso representa uma grande vulnerabilidade em termos de prompts de sistema.

Se assumirmos que o prompt de sistema é suscetível a vazamentos, isso implica que qualquer informação colocada nele pode revelar vulnerabilidades sobre o funcionamento do sistema. Vamos dar alguns exemplos de possíveis vulnerabilidades associadas aos prompts de sistema.

Evitando a exposição de informações sensíveis

Podemos, inadvertidamente, incluir no prompt de sistema informações sensíveis sobre o funcionamento do sistema, expondo funcionalidades críticas. Nunca devemos incluir no prompt de sistema detalhes que devem ser mantidos em sigilo, como a arquitetura do sistema, chaves de API, acesso a bancos de dados ou tipos de bancos de dados. Qualquer descrição adicional sobre o sistema pode ajudar usuários mal-intencionados a entender como ele funciona e obter acesso.

Isso é o que chamamos de reconhecimento. Nunca devemos facilitar o reconhecimento do nosso próprio sistema, pois isso constitui uma falha de segurança. Outro exemplo de práticas a serem evitadas no prompt de sistema é a exposição de regras internas e o funcionamento do sistema.

Dividindo o sistema em módulos para segurança

Se nosso sistema depende exclusivamente de um LLM (Large Language Model), e temos uma transação muito grande para automatizar, é importante entender como ele funciona como um todo. Devemos tentar dividir o sistema em módulos separados, colocando cada LLM em um local específico com um guardrail (barreira de segurança). É essencial dividir as regras de negócio que estamos terceirizando para LLMs em partes separadas, de modo que, se uma informação específica vazar, ela não terá necessariamente o contexto de todo o sistema, minimizando o impacto do vazamento.

Idealmente, não devemos incluir regras internas de funcionamento do sistema no prompt de sistema da LLM. Caso não haja alternativa, é importante tentar separar o máximo possível, mantendo o escopo o menor possível. Um exemplo do que não fazer nos prompts de sistema é revelar critérios de filtragem. Por exemplo, se no prompt de sistema mencionarmos algo como "se eu pedir informação sobre certo usuário, responda com um lamento, não posso ajudar", isso pode dar um insight para um usuário mal-intencionado. Ele poderia tentar burlar o sistema perguntando de forma que não pareça uma solicitação de informações.

Considerando a perspectiva de usuários mal-intencionados

Devemos sempre considerar a perspectiva de um usuário mal-intencionado e avaliar que informações estamos fornecendo, caso o prompt vaze. Outro exemplo do que não fazer é divulgar permissões e funções de usuário. Questões de controle de acesso e segurança devem ser sempre geridas por aplicações determinísticas. A função do usuário deve ser verificada antes de conceder acesso ao LLM com uma ferramenta específica. Nunca devemos dar todas as funções e ferramentas a um LLM e depois verificar se o usuário é administrador antes de liberar tudo. Devemos verificar quem é o usuário, suas permissões, e somente depois colocá-lo em uma sessão onde o LLM tem acesso apenas às ferramentas que aquele usuário tem permissão para modificar ou visualizar.

Implementando guardrails para segurança

Para prevenir e mitigar o vazamento de prompts de sistema, devemos remover todos os dados sensíveis do prompt de sistema. Não queremos que o LLM seja responsável pelo controle rigoroso do comportamento do sistema. Devemos sempre implementar guardrails como uma camada de segurança, tanto antes da entrada do que o usuário vai falar para o LLM, verificando se é seguro, quanto na saída do modelo, para garantir que não está passando informações indevidas. Isso protege também o usuário bem-intencionado de possíveis problemas.

Por exemplo, o prompt guard pode ser utilizado como um exemplo de guardrail. Queremos garantir que os controles de segurança não dependam da decisão do LLM, mas sim de sistemas externos, determinísticos, projetados para garantir nossa segurança de forma testável e verificável. Assim, apenas usuários com acesso autorizado chegarão a determinados pontos do sistema.

Esses são os principais pontos que devemos considerar para impedir o vazamento de prompts de sistema e mitigar essa vulnerabilidade.

Sobre o curso OWASP Top 10 para LLMs: protegendo aplicações e agentes inteligentes

O curso OWASP Top 10 para LLMs: protegendo aplicações e agentes inteligentes possui 167 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos da OWASP e manipulação de entrada
• Integridade de dados e supply chain
• Riscos de saída, vetores e privacidade
• Agentes autônomos e disponibilidade
• Ferramentas e estratégias de teste