Aller au contenu principal
Avancé•10–16 heures

Laboratoire Source-Sink de Prompt Injection

Construisez un laboratoire de red team pour la prompt injection directe et indirecte où le risque est mesuré par le chemin réel entre des sources contrôlées par un attaquant, des sinks sensibles et des effets de bord, pas seulement par le contournement des instructions.

prompt injectionanalyse source-sinkexfiltration de donnéesautorisation des toolsévaluation de sécurité

Scénario

Tâche

Un assistant IA lit des pages web, des documents et du contexte RAG et peut appeler des tools. Vérifiez si un contenu contrôlé par un attaquant peut amener le système à divulguer des données, appeler un tool dangereux ou modifier un état métier même lorsque le modèle ne viole pas formellement son instruction système.

Exécution pas à pas

1. Construisez le modèle source-sink

Résultat: Chaque entrée contrôlée par un attaquant et chaque sink conséquent possède une frontière de confiance explicite.

Tâches

  • →Inventorier les sources utilisateur, web, RAG, tools et mémoire
  • →Marquer les secrets, write tools et sinks de sortie externe
  • →Relier les chemins source → interpreter → sink
  • →Définir où une politique déterministe doit stopper une action

Vérifications

  • ✓Aucune source sans classification de confiance
  • ✓Un sink write ou egress ne dépend pas uniquement du system prompt

2. Construisez un corpus d’attaques adaptatif

Résultat: Les tests couvrent des familles d’attaques réalistes plutôt qu’un seul jailbreak prompt.

Tâches

  • →Ajouter la prompt injection directe
  • →Ajouter la prompt injection indirecte web et document
  • →Ajouter le RAG poisoning
  • →Ajouter la tool-result et persistent-memory injection
  • →Ajouter obfuscation et escalade multi-étapes

Vérifications

  • ✓Chaque cas possède un objectif d’attaque et un résultat sûr attendu
  • ✓Le corpus est versionné et reproductible

3. Testez le confinement, pas seulement le refus

Résultat: Même un raisonnement manipulé du modèle ne peut pas provoquer un effet dangereux.

Tâches

  • →Désactiver un contrôle à la fois
  • →Tester allowlists, denylists et validation de schéma
  • →Tester approval de l’action exacte
  • →Tester les limites egress réseau et URL
  • →Tester isolation des secrets

Vérifications

  • ✓Un raisonnement compromis n’hérite pas de l’autorité métier
  • ✓Chaque sink sensible possède un contrôle indépendant

4. Introduisez un release gate

Résultat: Une régression critique source-to-sink bloque automatiquement la release.

Tâches

  • →Séparer les évaluations par sévérité
  • →Définir des hard blockers pour exfiltration de données et écritures non autorisées
  • →Conserver les reproductions minimisées
  • →Ajouter les incidents à la suite de régression permanente

Vérifications

  • ✓Aucun score agrégé ne masque une défaillance critique
  • ✓Chaque incident de production peut devenir un cas de test reproductible

Critères d’acceptation

  • Une carte source-sink complète existe
  • Le corpus inclut injection directe et indirecte
  • Les sinks sensibles ont des contrôles déterministes
  • Écriture ou egress non autorisé est un hard blocker
  • Des cas de régression minimisés et un owner du risque résiduel existent