Segurança LLM e ataques de bot: um plano de teste prático

Que tipo de ataque você está tentando impedir?

A segurança LLM cobre a aplicação em torno do modelo, bem como suas respostas. A injeção de prompt tenta fazer com que entradas não confiáveis ​​atuem como uma instrução. O abuso de bot usa automação para fazer mau uso de um fluxo de trabalho, potencialmente sem qualquer aviso especial. O mesmo aplicativo pode experimentar ambos, mas um controle que detecta linguagem suspeita não interromperá necessariamente solicitações repetidas que parecem legítimas.

O projeto de ameaças automatizadas do OWASP inclui explicitamente o uso indevido de funcionalidades válidas do aplicativo. A sua orientação sobre riscos LLM descreve a inferência excessiva como um caminho para a degradação do serviço e perdas económicas. Use essas distinções ao fazer a triagem de um incidente: identifique o ativo afetado e o resultado antes de decidir se o problema pertence ao comportamento do modelo, ao acesso à conta, à autorização ou ao gerenciamento de recursos.

Evidência: Ameaças automatizadas OWASP a aplicativos da Web [1]LLM10:2025 Consumo ilimitado [2]

Escreva o limite do teste antes de escolher um scanner

Para o fluxo de trabalho de avaliação proposto pela Rubrex, nomeie a versão do aplicativo, o ambiente, os pontos de entrada, a configuração do modelo, as fontes de recuperação e as ferramentas habilitadas. Identifique o proprietário de cada recurso protegido. Escreva uma frase para o resultado que nunca deve ocorrer, como um usuário de suporte vendo o ticket de outro inquilino ou um assistente somente leitura enviando uma mensagem.

Use um ambiente de teste com contas sintéticas, documentos e destinos de ferramentas. Combine o teto de solicitação, o teto de gastos, a janela de execução e as condições de parada com o proprietário do sistema. Uma cota configurada baixa pode exercer a fiscalização sem produzir uma inundação de tráfego. Mantenha um pequeno conjunto de tarefas comuns do cliente como controle e registre o estado inicial dos dados para que os testes posteriores possam ser redefinidos. Este é um plano de teste de aplicativo, não uma permissão para verificar serviços não relacionados.

Teste a injeção de prompt em relação às permissões reais da ferramenta

OWASP recomenda tratar as proteções baseadas em modelo como uma camada ao lado de ferramentas restritas, validação e privilégio mínimo. A sua orientação excessiva da agência coloca a autorização em sistemas a jusante, em vez de deixar que o modelo decida se uma acção é permitida. Uma instrução forte é um contexto útil, mas não pode substituir uma verificação de permissão.

Em um teste de suporte ilustrativo, uma nota sintética recuperada solicita ao assistente que altere o proprietário de um ticket, mesmo que o usuário tenha solicitado apenas um resumo. Substitua a ferramenta de gravação ao vivo por uma implementação de teste instrumentada. Registre se o modelo solicitou a gravação, se o limite da ferramenta permitiu isso e se algum registro foi alterado. Uma recusa de modelo e uma solicitação de ferramenta rejeitada são observações diferentes; preservar ambos.

Em seguida, envie uma atualização legítima por meio de uma conta de teste autorizada. Se a correção proposta bloquear todas as atualizações, ela alterou o contrato do produto em vez de demonstrar uma proteção utilizável. Para ações que requerem aprovação, verifique se o alvo e os argumentos aprovados são os executados e se alterá-los requer uma nova decisão.

Evidência: Folha de dicas sobre prevenção de injeção LLM Prompt [3]LLM06:2025 Agência Excessiva [4]

Controle o abuso de bot antes que ele crie custos de modelo ou ferramenta

A orientação de consumo de recursos de API da OWASP exige limites explícitos na carga de trabalho e nos gastos de terceiros. Para uma aplicação LLM, avalie o custo de uma tarefa completa, incluindo recuperação, chamadas de modelo, operações de ferramentas e novas tentativas. Limitar o número de solicitações recebidas é insuficiente se uma solicitação aceita puder acionar trabalho downstream ilimitado.

Rubrex recomenda documentar limites de admissão e limites de execução separados. Na admissão, associe o pedido a uma conta verificada ou inquilino e verifique o seu subsídio. Durante a execução, limite o tamanho da entrada, o orçamento de saída, o trabalho simultâneo, as etapas da ferramenta e as novas tentativas. Aplique um prazo e defina o que significa cancelamento para trabalhos já enfileirados ou enviados a um fornecedor. Use controles de gastos do fornecedor, quando disponíveis; um alerta de cobrança por si só não interrompe o consumo.

Como verificação aritmética ilustrativa, se uma política de teste permitir três chamadas de modelo por tarefa e no máximo duas novas tentativas por chamada, o orçamento deverá permitir até nove tentativas de chamadas de modelo. Essa não é uma configuração de produção recomendada ou uma estimativa de custo. É uma forma de descobrir uma incompatibilidade entre uma cota por solicitação e o trabalho que o aplicativo pode realmente agendar. Inclua orçamentos de recuperação e de ferramentas externas separadamente.

Evidência: API4:2023 Consumo irrestrito de recursos [5]LLM10:2025 Consumo ilimitado [2]

Exemplo executado: corrida de cota, correção e novo teste

Executamos o acessório Node.js sem modelo vinculado em 3 de outubro de 2026. Ele usa duas solicitações simultâneas e uma permissão de uma unidade sintética. No cenário vulnerável, uma barreira força ambas as solicitações a atingirem a mesma pausa antes de qualquer uma continuar. Não há solicitações de saída, registros reais de usuários, chamadas de modelo pagas ou alvos de sites ativos; as chamadas do provedor são contadas por um stub na memória.

Na versão vulnerável, cada solicitação verifica a margem restante, aguarda a barreira e depois decrementa. Ambos passam na verificação: dois são admitidos, ocorrem duas chamadas stub e o subsídio restante torna-se -1. Na versão fixa, a solicitação reserva sua unidade de forma síncrona antes da primeira espera. Apenas um pedido é admitido e o outro é negado antes do stub; o subsídio restante é zero.

Baixe o script e execute node quota-race-demo.mjs com Node.js 22. Ele imprime quatro cenários; o registro de resultado contém a saída observada, o tempo de execução, a data e o hash SHA-256 do script exato. O controle de orçamento zero nega ambos os pedidos; o controle orçamentário suficiente admite ambos. Esses controles verificam se a correção não está simplesmente bloqueando todas as solicitações.

Isso demonstra um defeito de agendamento e uma correção de processo único. Não é uma implementação de cota distribuída: o JavaScript síncrono não pode serializar solicitações entre trabalhadores ou réplicas. A admissão de produção precisa de uma reserva atômica no armazenamento compartilhado, idempotência para novas tentativas e reconciliação explícita na conclusão ou cancelamento. As solicitações do modelo de custo variável também necessitam de uma reserva conservadora e de um ajuste final de uso. Verifique esses comportamentos separadamente; este acessório não testa o isolamento do locatário, a injeção imediata ou a infraestrutura de produção Rubrex.

• Baixe o dispositivo de corrida de cota executável (Node.js)
• Baixe a execução gravada e o hash do script (JSON)

Um pequeno conjunto de testes com condições de aprovação observáveis

Os casos a seguir são uma planilha inicial proposta, não resultados de um cliente Rubrex ou de uma reivindicação de cobertura completa. Substitua os limites do exemplo pelo contrato escrito do produto. Registre o resultado esperado antes de executar cada caso e inclua uma referência às evidências posteriormente.

Para testes de cota, configure uma permissão deliberadamente pequena em um ambiente isolado e mantenha o volume de solicitações baixo. Para testes de permissão, use dois locatários sintéticos e marcadores exclusivos não sensíveis. Para um teste de repetição, simule uma falha de confirmação após uma ferramenta falsa ter concluído sua operação. Esses acessórios tornam possível inspecionar o limite sem depender de uma interrupção real, de dados reais do cliente ou de um efeito colateral destrutivo.

Mantenha o acesso aos dados separado do julgamento do modelo

A orientação de autorização em nível de objeto do OWASP exige verificações dos registros acessados ​​por um chamador autenticado. Aplique esse princípio às fontes de dados que um assistente usa: um login válido não implica permissão para todos os documentos, respostas em cache ou resultados de ferramentas. A recuperação deve usar o escopo permitido do chamador, e as operações downstream devem validar esse escopo novamente quando acessam objetos protegidos.

Para o exemplo de dois inquilinos, coloque um marcador inofensivo diferente no material de teste de cada inquilino. Exercite os documentos e caminhos de conversa suportados pelo aplicativo e, em seguida, inspecione o conteúdo retornado e as decisões de acesso associadas. Repita depois que o cache tiver sido preenchido pelo outro locatário. Registre quais caminhos foram testados; uma verificação de isolamento bem-sucedida não estabelece que todos os caminhos de recuperação ou armazenamento estejam isolados.

Evidência: API1:2023 Autorização em nível de objeto quebrado [6]

Transforme uma descoberta em uma solução que alguém possa verificar

Uma descoberta útil explica o que era esperado, o que ocorreu, por que é importante e quais evidências apoiam a conclusão. Mantenha a versão do sistema, o caso de teste, a função da conta, a configuração, o estado observado e o identificador de execução juntos. Separe uma suspeita gerada pelo modelo de uma falha de limite reproduzida. Descreva o impacto usando os dados ou ações acessíveis, em vez do texto dramático da solicitação.

Para uma descoberta de cota ilustrativa, o resultado esperado é a rejeição antes de uma chamada do provedor. A falha observada pode ser uma ligação do provedor registrada após o esgotamento do limite da conta. Uma correção de candidato poderia reservar o subsídio antes da admissão. O novo teste deve incluir o caso original, a simultaneidade controlada em torno da permissão final e uma solicitação legítima com cota suficiente. Registre se o resultado foi corrigido, parcialmente corrigido, não reproduzido ou não testado; esses rótulos não são intercambiáveis.

Meça a proteção e a usabilidade do produto juntas

Para a leitura da avaliação, relate violações de limites, solicitações negadas, tarefas incompletas, bloqueios falsos em casos legítimos e uso de recursos. Indique o número e o tipo de casos por trás de cada taxa. Preserve as diferenças de configuração entre a linha de base e o candidato. Uma pontuação agregada pode ocultar a ação não autorizada que o teste pretendia evitar.

Para operações em andamento, decida quem recebe um alerta e o que pode ser alterado. Uma resposta útil pode ser pausar uma ferramenta dispendiosa, reduzir o subsídio de um inquilino ou exigir temporariamente a revisão de um caminho sensível. Mantenha o acesso aos registros de investigação controlado e evite copiar conversas completas dos clientes em um canal de alerta geral. Após um incidente confirmado, adicione um caso de regressão higienizado e verifique novamente o limite relevante após alterações de modelo, prompt, recuperação ou ferramenta.

Perguntas comuns