Sécurité LLM et attaques de robots : un plan de test pratique

Quel genre d’attaque essayez-vous d’arrêter ?

La sécurité LLM couvre l'application autour du modèle ainsi que ses réponses. L'injection rapide tente de faire en sorte que les entrées non fiables agissent comme une instruction. L'abus de robots utilise l'automatisation pour abuser d'un flux de travail, potentiellement sans aucune invite particulière. La même application peut rencontrer les deux, mais un contrôle qui détecte le langage suspect n’arrêtera pas nécessairement les demandes répétées d’apparence légitime.

Le projet de menaces automatisées de l’OWASP inclut explicitement une utilisation abusive des fonctionnalités d’application valides. Ses directives sur les risques LLM décrivent une inférence excessive comme une voie menant à la dégradation du service et à une perte économique. Utilisez ces distinctions lors du tri d'un incident : identifiez l'actif affecté et le résultat avant de décider si le problème appartient au comportement du modèle, à l'accès au compte, à l'autorisation ou à la gestion des ressources.

Preuve : Menaces automatisées OWASP contre les applications Web [1]LLM10 : 2025 Consommation illimitée [2]

Écrivez la limite de test avant de choisir un scanner

Pour le flux de travail d'évaluation proposé par Rubrex, nommez la version de l'application, l'environnement, les points d'entrée, la configuration du modèle, les sources de récupération et les outils activés. Identifiez le propriétaire de chaque ressource protégée. Écrivez une phrase pour le résultat qui ne doit jamais se produire, comme un utilisateur du support voyant le ticket d’un autre locataire ou un assistant en lecture seule envoyant un message.

Utilisez un environnement de test avec des comptes synthétiques, des documents et des destinations d'outils. Convenez du plafond de demande, du plafond de dépenses, de la fenêtre d'exécution et des conditions d'arrêt avec le propriétaire du système. Un quota configuré faible peut exercer une application sans produire une inondation de trafic. Conservez un petit ensemble de tâches client ordinaires comme contrôles et enregistrez l'état des données de départ afin que les essais ultérieurs puissent être réinitialisés. Il s'agit d'un plan de test d'application et non d'une autorisation d'analyser des services non liés.

Testez l'injection d'invite par rapport aux autorisations réelles de l'outil

L'OWASP recommande de traiter les garde-corps basés sur un modèle comme une seule couche aux côtés des outils contraints, de la validation et du moindre privilège. Ses directives excessives placent l'autorisation dans les systèmes en aval plutôt que de laisser le modèle décider si une action est autorisée. Une instruction forte constitue un contexte utile, mais elle ne peut pas remplacer une vérification d’autorisation.

Dans un test de support illustratif, une note synthétique récupérée demande à l’assistant de changer le propriétaire d’un ticket même si l’utilisateur n’a demandé qu’un résumé. Remplacez l'outil d'écriture en direct par une implémentation de test instrumentée. Enregistrez si le modèle a demandé l'écriture, si les limites de l'outil l'ont autorisé et si un enregistrement a été modifié. Un refus de modèle et une demande d'outil rejetée sont des observations différentes ; préserver les deux.

Soumettez ensuite une mise à jour légitime via un compte de test autorisé. Si le correctif proposé bloque chaque mise à jour, il a modifié le contrat du produit plutôt que de démontrer une protection utilisable. Pour les actions nécessitant une approbation, vérifiez que la cible et les arguments approuvés sont ceux exécutés et que leur modification nécessite une nouvelle décision.

Preuve : Aide-mémoire pour la prévention des injections rapides LLM [3]LLM06 : 2025 Agence excessive [4]

Contrôlez les abus des robots avant qu'ils ne créent des coûts de modèle ou d'outil

Les directives de consommation des ressources API de l’OWASP appellent à des limites explicites sur la charge de travail et les dépenses de tiers. Pour une application LLM, évaluez le coût d'une tâche complète, y compris la récupération, les appels de modèle, les opérations d'outil et les nouvelles tentatives. Limiter le nombre de requêtes entrantes ne suffit pas si une requête acceptée peut déclencher un travail illimité en aval.

Rubrex recommande de documenter des limites d'admission et des limites d'exécution distinctes. A l'admission, associez la demande à un compte ou un locataire vérifié et vérifiez son allocation. Pendant l'exécution, taille d'entrée liée, budget de sortie, travail simultané, étapes de l'outil et nouvelles tentatives. Appliquez un délai et définissez ce que signifie l'annulation pour le travail déjà en attente ou envoyé à un fournisseur. Utiliser les contrôles des dépenses des prestataires lorsqu'ils sont disponibles ; une alerte de facturation à elle seule n’arrête pas la consommation.

À titre d'exemple de vérification arithmétique, si une stratégie de test autorise trois appels de modèle par tâche et au plus deux tentatives par appel, le budget doit autoriser jusqu'à neuf tentatives d'appels de modèle. Il ne s’agit pas d’un paramètre de production recommandé ni d’une estimation des coûts. C'est un moyen de découvrir une inadéquation entre un quota par demande et le travail que l'application peut réellement planifier. Incluez séparément les budgets de récupération et d’outils externes.

Preuve : API4 : 2023 Consommation de ressources sans restriction [5]LLM10 : 2025 Consommation illimitée [2]

Exemple exécuté : une course aux quotas, une correction et un nouveau test

Nous avons exécuté le luminaire Node.js sans modèle lié le 3 octobre 2026. Il utilise deux requêtes simultanées et une allocation d'une unité synthétique. Dans le scénario vulnérable, une barrière force les deux demandes à atteindre la même pause avant que l'une ou l'autre ne continue. Il n'y a pas de demandes sortantes, d'enregistrements d'utilisateurs réels, d'appels de modèles payants ou de cibles de sites en direct ; les appels du fournisseur sont comptés par un stub en mémoire.

Dans la version vulnérable, chaque requête vérifie l'allocation restante, attend la barrière, puis décrémente. Tous deux réussissent le contrôle : deux sont admis, deux appels de talon ont lieu et l'allocation restante devient -1. Dans la version fixe, la requête réserve son unité de manière synchrone avant la première attente. Une seule demande est admise et l'autre est refusée avant le talon ; l'allocation restante est nulle.

Téléchargez le script et exécutez node quota-race-demo.mjs avec Node.js 22. Il imprime quatre scénarios ; l'enregistrement de résultat contient la sortie observée, le temps d'exécution, la date et le hachage SHA-256 du script exact. Le contrôle du budget zéro refuse les deux demandes ; le contrôle du budget suffisant admet les deux. Ces contrôles vérifient que le correctif ne bloque pas simplement chaque demande.

Cela démontre un défaut de planification et un correctif d’un seul processus. Il ne s'agit pas d'une implémentation de quota distribué : le JavaScript synchrone ne peut pas sérialiser les requêtes entre les nœuds de calcul ou les réplicas. L'admission en production nécessite une réservation atomique dans le stockage partagé, une idempotence pour les tentatives et un rapprochement explicite à la fin ou à l'annulation. Les demandes de modèles à coûts variables nécessitent également une réservation prudente et un ajustement d'utilisation final. Vérifiez ces comportements séparément ; cet appareil ne teste pas l'isolement des locataires, l'injection rapide ou l'infrastructure de production Rubrex.

• Téléchargez le programme de course aux quotas exécutables (Node.js)
• Téléchargez l'exécution enregistrée et le hachage du script (JSON)

Un petit ensemble de tests avec des conditions de réussite observables

Les cas suivants sont une proposition de feuille de travail de départ, et non les résultats d'un client Rubrex ou une réclamation de couverture complète. Remplacez les exemples de limites par le contrat écrit du produit. Enregistrez le résultat attendu avant d’examiner chaque cas et incluez ensuite une référence aux preuves.

Pour les tests de quota, configurez une allocation volontairement faible dans un environnement isolé et maintenez un volume de demandes faible. Pour les tests d’autorisation, utilisez deux locataires synthétiques et des marqueurs uniques non sensibles. Pour un nouveau test, simulez un échec d’acquittement après qu’un faux outil a terminé son opération. Ces appareils permettent d'inspecter les limites sans s'appuyer sur une panne réelle, des données client réelles ou un effet secondaire destructeur.

Gardez l’accès aux données séparé du jugement du modèle

Les directives d’autorisation au niveau objet de l’OWASP nécessitent de vérifier les enregistrements auxquels un appelant authentifié accède. Appliquez ce principe aux sources de données utilisées par un assistant : une connexion valide n'implique pas l'autorisation d'accéder à chaque document, réponse mise en cache ou résultat de l'outil. La récupération doit utiliser la portée autorisée de l’appelant, et les opérations en aval doivent à nouveau valider cette portée lorsqu’elles accèdent aux objets protégés.

Pour l’exemple de deux locataires, placez un marqueur inoffensif différent dans le matériel de test de chaque locataire. Testez les chemins de documents et de conversations pris en charge par l’application, puis inspectez le contenu renvoyé et les décisions d’accès associées. Répétez une fois que le cache a été rempli par l’autre locataire. Enregistrez quels chemins ont été testés ; une vérification d'isolement réussie ne permet pas d'établir que chaque chemin de récupération ou de stockage est isolé.

Preuve : API1 : 2023 Autorisation au niveau de l'objet brisé [6]

Transformez une découverte en un correctif que quelqu'un peut vérifier

Une constatation utile explique ce qui était attendu, ce qui s’est produit, pourquoi c’est important et quelles preuves étayent la conclusion. Conservez ensemble la version du système, le scénario de test, le rôle du compte, la configuration, l'état observé et l'identifiant d'exécution. Séparez une suspicion générée par le modèle d’un échec de limite reproduit. Décrivez l'impact en utilisant les données ou l'action accessibles, plutôt que la formulation dramatique de l'invite.

Pour un résultat de quota illustratif, le résultat attendu est un rejet avant un appel du fournisseur. L'échec observé peut être un appel du fournisseur enregistré après l'épuisement des crédits du compte. Un candidat fixe pourrait réserver l'allocation avant l'admission. Le nouveau test doit inclure le cas d'origine, une concurrence contrôlée autour de l'allocation finale et une demande légitime avec un quota suffisant. Enregistrez si le résultat est corrigé, partiellement corrigé, non reproduit ou non testé ; ces étiquettes ne sont pas interchangeables.

Mesurer ensemble la protection et la facilité d'utilisation du produit

Pour la lecture de l'évaluation, signalez les violations de limites, les demandes refusées, les tâches incomplètes, les faux blocages sur les cas légitimes et l'utilisation des ressources. Indiquez le nombre et le type de cas derrière chaque taux. Préservez les différences de configuration entre la ligne de base et le candidat. Un score global peut masquer la seule action non autorisée que le test était censé empêcher.

Pour les opérations en cours, décidez qui reçoit une alerte et ce qu'il peut modifier. Une réponse utile peut consister à suspendre un outil coûteux, à réduire l’allocation d’un locataire ou à exiger temporairement une révision sur un chemin sensible. Contrôlez l’accès aux enregistrements d’enquête et évitez de copier l’intégralité des conversations des clients dans un canal d’alerte général. Après un incident confirmé, ajoutez un cas de régression nettoyé et vérifiez à nouveau la limite pertinente après des modifications de modèle, d'invite, de récupération ou d'outil.

Questions courantes