Gestion des sorties AI dangereuses

Qu'est-ce que Gestion des sorties AI dangereuses?

La sortie du modèle est une entrée non fiable pour tout ce qui la consomme. Une fois qu’une application exécute, restitue ou transmet une réponse de l’IA, le modèle fait partie de la surface d’attaque et la validation habituelle des entrées se trouve au mauvais endroit. Vous travaillerez sur un point de terminaison de langage naturel vers SQL, enverrez un paramètre spécialement conçu et regarderez la requête générée se transformer en une injection qui renvoie des enregistrements que l'appelant ne devrait jamais voir. Aucun contrôle n’a été contourné. Vous lirez le chemin vulnérable et approuverez le correctif paramétré.

Ce que vous apprendrez dans Gestion des sorties AI dangereuses

• Identifiez la surface d'attaque créée lorsque le contenu généré par l'IA passe sans être nettoyé dans des bases de données, des pages Web, des API et des commandes système.
• Tracez une chaîne d'attaque de bout en bout dans laquelle une entrée d'IA spécialement conçue produit une sortie malveillante qui exploite un système en aval.
• Appliquer des contrôles de validation et de nettoyage des sorties à la frontière entre les composants d'IA et les systèmes connectés
• Évaluez les modèles architecturaux, notamment les requêtes paramétrées, l'encodage des sorties et l'accès API avec le moindre privilège qui empêchent l'exploitation des sorties de l'IA.
• Faites la distinction entre les scénarios dans lesquels la sortie de l'IA peut être fiable pour l'affichage et les scénarios dans lesquels elle doit être traitée comme une entrée non fiable dans un autre système.

Gestion des sorties AI dangereuses — Étapes de la formation

1. Une nouvelle fonctionnalité d'IA à tester

   Aujourd'hui, la fonctionnalité de l'API Natural Language Query (NLQ) est prête à être testée en interne avant d'être envoyée en production. L'API NLQ utilise un modèle d'IA pour convertir des questions en anglais simple en requêtes SQL : les utilisateurs professionnels saisissent une question, l'IA écrit le code SQL et l'API renvoie les résultats.

2. E-mail du responsable technique

   Alice reçoit un e-mail de son responsable technique James Park, l'informant que le point de terminaison de l'API NLQ est déployé dans l'environnement de test et prêt à être testé.

3. Ouverture du testeur API

   Alice ouvre l'outil API Tester pour commencer à envoyer des requêtes au point de terminaison NLQ. Il s'agit d'une partie standard de son flux de travail pour tester les nouvelles fonctionnalités de l'API avant leur mise en ligne.

4. Une requête de test simple

   Alice commence par une requête simple pour s'assurer que l'API fonctionne. Le point de terminaison NLQ accepte les requêtes GET avec un paramètre de requête contenant la question en langage naturel.

5. La réponse de l'API

   L'API a répondu avec cinq enregistrements client correspondant à la requête. La réponse semble normale.

6. Le SQL généré

   Le panneau Analyse des requêtes SQL montre exactement ce que l'IA a généré à partir de l'entrée en langage naturel. Il s'agit de la requête qui a été exécutée sur la base de données.

7. Le flux de données

   La visualisation en chaîne montre comment les données circulent depuis la question en langage naturel de l'utilisateur jusqu'au résultat de la base de données.

8. Test avec une entrée malveillante

   Alice décide de tester la résilience de l'API. Que se passe-t-il si un utilisateur inclut la syntaxe d'injection SQL dans sa requête en langage naturel ? Un système bien construit doit soit rejeter l’entrée, soit la nettoyer. Elle crée un paramètre de requête qui intègre une commande DROP TABLE dans l'invite en langage naturel.

9. Les dégâts dans la réponse

   La réponse est revenue, mais quelque chose ne va vraiment pas. Regardez attentivement le corps de la réponse.

10. Le SQL injecté

    Le panneau SQL révèle exactement ce que l'IA a généré. La charge utile d’injection a été fidèlement traduite en SQL exécutable.