Votre première détection : un guide pas à pas

Un exercice de dix minutes : installez Zeuslock, collez une clé AWS de test sûre dans ChatGPT et regardez l'incident apparaître en temps réel dans la Console Opérateur.

Ce que vous allez faire dans les dix prochaines minutes

À la fin de ce guide, vous aurez déclenché une véritable détection Zeuslock, vu l'incident remonter dans la Console Opérateur, puis rejoué la même détection sous les trois modes de politique : Surveillance, Anonymisation et Blocage. Aucun secret réel n'est utilisé à aucun moment.

Prérequis

  • L'extension navigateur Zeuslock installée sur Chrome, Edge, Firefox ou Safari, et appairée à votre organisation.
  • Un compte avec le rôle Opérateur sur la Console Opérateur (app.zeuslock.ai).
  • Une session ChatGPT déjà connectée dans le même profil de navigateur.

La valeur de test utilisée, AKIAIOSFODNN7EXAMPLE, est l'identifiant de clé d'accès AWS publié dans la documentation officielle d'Amazon comme exemple. Ce n'est pas une vraie clé, elle ne donne accès à rien, et elle peut être collée sans risque dans une fenêtre de chat. Le moteur regex de Zeuslock la détecte tout de même, parce que sa structure correspond à celle d'une vraie clé AWS.

Étape par étape

  1. Passez votre organisation en mode Surveillance. Dans la Console Opérateur, allez dans Paramètres → Politique de détection → Profil par défaut et choisissez Mode : Surveillance. Enregistrez. Le mode Surveillance laisse passer les prompts inchangés mais enregistre chaque détection — c'est par là que doit toujours commencer un déploiement.
  2. Ouvrez ChatGPT. Chargez chat.openai.com dans un nouvel onglet et vérifiez que l'icône Zeuslock dans la barre d'outils est verte. Le vert indique que l'extension est appairée, que la politique est chargée et que la page est dans le périmètre.
  3. Collez la clé de test. Dans une nouvelle conversation, tapez la phrase Voici ma clé AWS pour le script de déploiement : AKIAIOSFODNN7EXAMPLE et envoyez.
  4. Observez l'indicateur dans le navigateur. Juste au-dessus de la zone de saisie, Zeuslock affiche un petit bandeau : 1 détection : clé d'accès AWS (mode surveillance — envoyée telle quelle). Le prompt part vers OpenAI sans modification, conformément à la politique.
  5. Basculez dans la Console Opérateur. Ouvrez l'onglet Incidents. En trois secondes environ, le nouvel incident apparaît en haut de la liste, avec la sévérité, le type de détection (api_key:aws), un aperçu anonymisé du prompt, l'utilisateur, le navigateur et l'URL source (chat.openai.com).
  6. Ouvrez l'incident. Cliquez dessus pour voir la chronologie complète. Vous verrez la correspondance regex de la première couche de détection, le score de confirmation du modèle ML hébergé dans l'UE, les heuristiques de contexte locales et l'action recommandée. Le secret brut n'est jamais stocké dans la console — seuls un hash salé et un aperçu masqué sont conservés.

Rejouez le même test en modes plus stricts

Tout l'intérêt du déploiement progressif de Zeuslock est de pouvoir valider chaque mode sur du trafic réel avant de serrer les vis. Retournez dans Paramètres → Politique de détection → Profil par défaut et passez Mode à Anonymisation. Enregistrez, rechargez l'onglet ChatGPT et renvoyez la même phrase.

Cette fois, le prompt qui arrive réellement à ChatGPT est Voici ma clé AWS pour le script de déploiement : AKIAIO********7EXAMPLE. Le modèle reçoit un token qui reste structurellement crédible — le raisonnement aval autour de « une clé a été fournie » continue de fonctionner — mais la vraie valeur n'a jamais quitté le navigateur. La Console Opérateur enregistre un deuxième incident avec l'étiquette anonymisé.

Passez ensuite le même profil en Blocage, enregistrez et faites un troisième essai. Le prompt est intercepté avant l'envoi. ChatGPT ne voit absolument rien. L'utilisateur final reçoit une fenêtre modale claire qui explique ce qui a été bloqué et pourquoi, avec un lien vers votre politique interne si vous l'avez configurée. La Console Opérateur enregistre un troisième incident, étiqueté bloqué, avec une attribution complète.

Comparer les trois résultats côte à côte

Ouvrez l'onglet Incidents et filtrez sur votre propre compte. Vous devez voir trois lignes pour le même prompt, une par mode. Comparez :

  • Surveillance — le prompt est parti, le secret a quitté le navigateur, vous avez de la visibilité mais aucune protection.
  • Anonymisation — le prompt est parti sous forme masquée, le modèle fonctionne toujours, le secret est resté local.
  • Blocage — rien n'est sorti du navigateur ; l'utilisateur a été sensibilisé sur le moment.

C'est exactement le déploiement progressif que nous recommandons : Surveillance pendant les deux premières semaines pour cartographier votre exposition réelle, Anonymisation pendant les trois suivantes, puis Blocage à partir de la semaine six pour les types de détection à très faible taux de faux positifs (clés AWS, clés Stripe, IBAN et autres motifs très fiables).

Prochaines étapes

  1. Invitez votre équipe. Console Opérateur → Paramètres → Équipe, envoyez les invitations et attribuez le rôle Opérateur ou Lecteur. Le SSO via Okta, Azure AD ou Google Workspace s'active depuis le même écran.
  2. Connectez Slack. Paramètres → Intégrations → Slack, collez votre URL de webhook et routez les incidents de sévérité élevée vers votre canal sécurité. Les signatures HMAC sont activées par défaut.
  3. Créez un détecteur personnalisé. Si votre organisation utilise ses propres identifiants internes (matricules, codes projet, numéros de référence client), ouvrez Détecteurs → Personnalisés → Nouveau, fournissez une regex avec quelques exemples positifs et négatifs, puis lancez le backtest sur les 30 derniers jours d'incidents avant de passer en Blocage.

Vous disposez maintenant d'une détection qui fonctionne, d'un incident réel et d'une idée claire du comportement de chaque mode. Vous pouvez passer à la définition de votre premier profil de production.