Vulnerabilidades de injeção rápida podem nunca ser totalmente mitigadas como categoria, e os defensores da rede deveriam focar em formas de reduzir seu impacto, alertaram especialistas em segurança governamental.
O então diretor técnico de pesquisa de plataformas do National Cyber Security Centre (NCSC), David C, alertou os profissionais de segurança para não tratarem a injeção rápida como injeção SQL.
“A injeção SQL é … ilustrativa de um problema recorrente em cibersegurança; ou seja, ‘dados’ e ‘instruções’ sendo tratados incorretamente”, explicou.
“Isso permite que um atacante forneça ‘dados’ que são executados pelo sistema como uma instrução. É o mesmo problema subjacente para muitos outros tipos críticos de vulnerabilidades que incluem scripts cross-site e exploração de overflows de buffer.”
No entanto, as mesmas regras não se aplicam à injeção de prompts, porque grandes modelos de linguagem (LLMs) não distinguem entre dados e instruções.
“Quando você fornece um prompt para LLM, ele não entende o texto do jeito que uma pessoa entende. Ele está simplesmente prevendo o próximo token mais provável do texto até agora”, continuou o blog.
“Como não há distinção inerente entre ‘dados’ e ‘instrução’, é muito possível que ataques de injeção prompt nunca sejam totalmente mitigados da mesma forma que os ataques de injeção SQL podem ser.”
É por isso que mitigações como detectar tentativas de injeção rápida, treinar modelos para priorizar “instruções” em vez de “dados” e explicar a um modelo o que são “dados” estão fadadas ao fracasso, argumentou David C.
Uma forma melhor de abordar o desafio é enxergar a injeção rápida não como injeção de código, mas como exploração de um “delegado inerentemente confuso”.
David C argumentou que os LLMs são “inerentemente confusos” porque o risco não pode ser totalmente mitigado.
“Em vez de esperar que possamos aplicar uma mitigação que corrija a injeção rápida, precisamos abordá-la buscando reduzir o risco e o impacto. Se a segurança do sistema não tolerar o risco restante, pode não ser um bom caso de uso para LLMs”, explicou.
Reduzindo os Riscos de Injeção Rápida
O NCSC sugeriu as seguintes medidas para reduzir o risco de injeção rápida, todas alinhadas ao ETSI (TS 104 223) sobre os Requisitos Básicos de Cibersegurança para Modelos e Sistemas de IA.
- Desenvolvedor/equipe de segurança/consciência organizacional dessa classe de vulnerabilidades e de que sempre haverá um risco residual que não pode ser totalmente mitigado com um produto ou appliance
- Projeto seguro de LLM, especialmente se o LLM chama ferramentas ou usa APIs baseadas em sua saída. As proteções devem focar em salvaguardas não relacionadas a LLMs que limitam as ações do sistema, como impedir que um modelo que processa e-mails de indivíduos externos tenham acesso a ferramentas privilegiadas
- Dificultar a injeção de prompts maliciosos, como marcar seções de “dados” como separadas das “instruções”
- Monitoramento das informações de registro para identificar atividades suspeitas, como falhas em chamadas de ferramentas/API
A falha em resolver o desafio logo no início pode levar a uma situação semelhante aos bugs de injeção de SQL, que só recentemente se tornaram muito mais raros.
“Corremos o risco de ver esse padrão se repetir com injeção rápida, já que estamos no caminho para incorporar a genAI na maioria das aplicações”, concluiu David C.
“Se essas aplicações não forem projetadas pensando em injeção rápida, uma onda semelhante de violações pode seguir.”
Steve Wilson, diretor de IA da Exabeam, concordou que as abordagens atuais para combater a injeção rápida estão falhando.
“CISOs precisam mudar sua mentalidade. Defender agentes de IA é menos como proteger softwares tradicionais e muito mais como defender os humanos dentro de uma organização. Agentes, assim como as pessoas, são bagunçados, adaptáveis e propensos a serem manipulados, coercidos e confundidos”, acrescentou.
“Isso os torna mais análogos a ameaças internas do que a componentes clássicos de aplicação. Seja lidando com um prompt malicioso, dados upstream comprometidos ou caminhos de raciocínio não intencionais, é necessária vigilância constante. A segurança eficaz da IA não virá de camadas mágicas de proteção, mas sim da disciplina operacional, monitoramento, contenção e da expectativa de que esses sistemas continuarão a se comportar de forma imprevisível por muitos anos.”