Aller au contenu principal
Avancé•10–16 heures

Exercice de confinement d’incident de sécurité IA

Exercez un incident spécifique à l’IA où une prompt injection ou un tool compromis a déjà affecté un workflow de production. Construisez un confinement préservant les preuves, une réconciliation, un rollback ciblé et une clôture de régression.

réponse à incidentconfinementforensiqueréconciliationrollbackrégression de sécurité

Scénario

Tâche

Après une prompt injection indirecte, un agent de production a appelé un write tool et un timeout a laissé l’état final inconnu. Ne vous contentez pas de désactiver le modèle : préservez les preuves, délimitez le blast radius, vérifiez le système de référence autoritatif, révoquez la capacité compromise et restaurez le service en sécurité.

Exécution pas à pas

1. Classez l’incident et figez les preuves

Résultat: L’équipe sait ce qui s’est produit et quel runtime envelope était actif.

Tâches

  • →Enregistrer les versions du modèle, prompt, retrieval et tools
  • →Préserver les traces sans secrets inutiles
  • →Identifier les identités utilisateur, session et tool
  • →Séparer les effets confirmés des effets suspectés

Vérifications

  • ✓L’audit trail n’est pas réécrit rétrospectivement
  • ✓Les preuves sensibles ont un contrôle d’accès

2. Confinez uniquement le blast radius nécessaire

Résultat: La capacité dangereuse est arrêtée sans coupure totale inutile.

Tâches

  • →Désactiver le write tool ou scope affecté
  • →Révoquer le credential compromis
  • →Passer le workflow en mode dégradé ou lecture seule
  • →Bloquer la source malveillante connue

Vérifications

  • ✓Le confinement ne dépend pas du comportement du modèle
  • ✓Le chemin d’action critique n’est plus disponible

3. Réconciliez avant tout retry

Résultat: Les effets de bord inconnus sont vérifiés contre la source autoritative avant toute nouvelle exécution.

Tâches

  • →Vérifier le system of record
  • →Rapprocher les idempotency keys
  • →Détecter les écritures partielles ou dupliquées
  • →Marquer les réparations manuelles en attente

Vérifications

  • ✓Aucun blind retry après timeout
  • ✓Chaque action incertaine a un état final confirmé ou un owner manuel explicite

4. Restaurez known-good et fermez la régression

Résultat: Le service revient de façon contrôlée et la cause de l’incident ne peut pas se reproduire silencieusement.

Tâches

  • →Rollback du behavior envelope affecté
  • →Exécuter le security replay
  • →Effectuer canary et failback
  • →Minimiser l’exploit
  • →Ajouter un cas de régression permanent

Vérifications

  • ✓La récupération est vérifiée par des postconditions
  • ✓La régression bloque la répétition du chemin d’attaque critique

Critères d’acceptation

  • La chronologie contient un runtime fingerprint
  • Le confinement est ciblé et indépendant de la conformité du modèle
  • La réconciliation des effets inconnus est terminée avant retry
  • La récupération known-good est confirmée par des postconditions autoritatives
  • L’exploit de production devient un test de régression permanent