Exemple de mise en œuvre des gardes pour un chatbot

Sécuriser les Applications IA avec les Gardiens Cato (Configuration d'Exemple)

Aperçu

Ce guide vous guide à travers le processus de bout en bout de sécurisation d'une application IA personnalisée en utilisant les Gardiens de Sécurité IA de Cato. Il est structuré en un flux en trois étapes, chaque étape étant basée sur la précédente, vous permettant ainsi de voir exactement ce qui change à chaque étape et pourquoi.

L'application utilisée tout au long de ce guide est TravelBot — un simple chatbot assistant de voyage alimenté par l'IA. Bien que l'exemple soit spécifique, les concepts et les étapes s'appliquent à n'importe quelle application IA personnalisée que vous construisez et souhaitez protéger.

Le guide couvre trois étapes :

• Étape 1 établit la base : une application IA fonctionnelle communiquant directement avec un LLM, sans contrôles de sécurité en place. Cette étape vous aide à comprendre le point de départ et les risques qu'il introduit.
• Étape 2 présente le gardien : un Gardien Proxy Cato est créé et inséré entre l'application et le LLM. Le trafic est redirigé via le gardien, qui commence à journaliser toutes les interactions. Aucune règle de politique n'est configurée pour l'instant — l'objectif à ce stade est simplement de vérifier que le flux fonctionne toujours avec le gardien en place.
• Étape 3 active l'application : des règles de politique d'interaction sont configurées et publiées, instruisant le gardien de bloquer les tentatives de jailbreak et de surveiller le contenu lié à la santé. L'application est maintenant entièrement protégée.
  À la fin de ce guide, vous aurez une image claire de la façon dont une application IA personnalisée peut être sécurisée avec les Gardiens Cato — d'une connexion totalement ouverte à un flux de travail IA activement appliqué, surveillé et gouverné.

Étape 1 — La Base : Votre Application IA Sans Gardien

Ce que couvre cette étape

Avant d'introduire des contrôles de sécurité, il est important de comprendre comment l'application fonctionne par elle-même. Cette étape vous guide à travers la configuration de base — une application chat IA fonctionnant qui communique directement avec un modèle de langue étendue (LLM). Considérez cela comme la photo "avant" : l'application est fonctionnelle, mais il n'y a encore rien entre l'utilisateur et le modèle.

Comment fonctionne l'application

L'application est un simple chatbot assistant de voyage appelé TravelBot. Elle se compose de trois composants qui travaillent ensemble :

1. L'interface utilisateur
C'est ce que l'utilisateur voit et avec quoi il interagit — une interface de chat dans le navigateur où il peut taper des questions et recevoir des réponses.

2. Le Backend
C'est le moteur qui fonctionne en coulisses. Il reçoit le message de l'utilisateur, suit l'historique de la conversation et transmet le message au LLM. Il gère également les erreurs et retourne la réponse du modèle à l'utilisateur. Le backend est construit avec Flask, un framework web léger.

3. La Connexion LLM
C'est là que réside l'intelligence. Le backend envoie le message de l'utilisateur (avec l'historique de la conversation) à un large modèle de langage, qui génère une réponse. À ce stade, le backend communique directement avec le LLM — il n'y a rien entre les deux.

Le flux ressemble à ceci :

Utilisateur (navigateur) → Backend (Flask) → LLM → Réponse à l'utilisateur

Une note sur le langage et le framework

L'application exemple dans ce guide est construite avec Python, utilisant un framework web léger appelé Flask. Python est un choix populaire pour le développement d'applications IA, mais cela n'est pas l'unique option. Les mêmes concepts et flux s'appliquent, que votre application soit construite en Node.js, Java, Go, ou tout autre langage. Les valeurs de configuration, la structure de la requête et l'intégration du gardien suivent tous la même logique — seule la syntaxe change.

Le Fichier de Configuration

La connexion entre le backend et le LLM est contrôlée par un fichier appelé config.py. Ce fichier contient trois valeurs critiques :

OPENAI_API_KEY = "sk-proj-xK92mLqP3nVwTz8YdR5eN1uJbF7cQm4HsAo6WpGi0XvCl"
BASE_URL = "https://bedrock-mantle.eu-north-1.api.aws/v1"
MODEL_ID = "amazon.nova-pro-v1:0"

• OPENAI_API_KEY — Ceci est la crédential qui prouve au fournisseur LLM que votre application est autorisée à effectuer des requêtes.
• BASE_URL — C'est l'adresse à laquelle le backend envoie les requêtes. Pour l'instant, il pointe directement vers le fournisseur du LLM.
• MODEL_ID — Cela indique au fournisseur de LLM quel modèle spécifique utiliser lors de la génération des réponses.

Pour faire fonctionner l'application à ce stade, vous (ou votre développeur) devrez remplir ces trois valeurs avec les identifiants fournis par votre fournisseur de LLM.

Ce que l'application fait avec votre message

Lorsqu'un utilisateur envoie un message, voici ce qui se passe étape par étape :

1. L'utilisateur tape un message dans l'interface de chat et appuie sur envoyer.
2. Le navigateur envoie le message au backend Flask, avec un ID de session qui identifie la conversation.
3. Le backend ajoute le message à l'historique de conversation et transmet tout au LLM, en ajoutant une instruction système disant au modèle de se comporter comme TravelBot.
4. Le LLM traite la conversation complète et génère une réponse.
5. La réponse est renvoyée au backend, ajoutée à l'historique de la conversation, et retournée au navigateur de l'utilisateur.
6. L'utilisateur voit la réponse dans l'interface de chat.

Ce qui ne se passe pas encore

À ce stade, l'application est pleinement fonctionnelle mais complètement non protégée. Ceci signifie :

• Il n'y a aucune inspection de ce que l'utilisateur envoie au modèle.
• Il n'y a aucune inspection des appels et des réponses de l'outil.
• Il n'y a aucune application de politique — tout message, y compris ceux malveillants, atteint le LLM.
• Il n'y a aucune visibilité sur la façon dont l'application est utilisée.

Un utilisateur pourrait, par exemple, tenter de manipuler le modèle pour ignorer ses instructions, extraire des informations sensibles, ou utiliser l'application d'une manière qui viole les politiques de votre organisation — et rien de tout cela ne serait détecté ni stoppé.

C'est exactement l'écart que la prochaine étape aborde.

Résumé

Étape 2 — Présentation du Gardien

Ce que couvre cette étape

À l'étape 1, nous avons établi une application IA fonctionnelle qui communique directement avec un LLM. L'application fonctionne, mais il n'y a rien entre l'utilisateur et le modèle. À cette étape, nous introduisons un Gardien de Sécurité IA Cato — la couche applicative qui se situe entre votre application et le LLM, inspectant le trafic en temps réel avant qu'il n'atteigne le modèle et avant que les réponses ne soient retournées à l'utilisateur.

À la fin de cette étape, tout le trafic LLM, les messages des utilisateurs, les définitions des outils, l'utilisation des outils, etc. passent par Cato. L'expérience utilisateur reste identique — mais maintenant chaque interaction est inspectée et peut être contrôlée.

Le flux mis à jour ressemble à ceci :

{hauteur="" largeur=""}

Qu'est-ce qu'un Gardien ?

Un gardien est le point d'application pour la Sécurité IA. Dans cet exemple, dans lequel nous utilisons le Mode Proxy, il agit comme un intermédiaire — entre votre application et le LLM — et évalue chaque invite et réponse par rapport aux politiques que vous définissez. Basé sur ces politiques, le gardien peut autoriser, bloquer ou journaliser une interaction.

Il y a trois types de gardiens. Pour ce guide, nous utilisons un Gardien Proxy. En mode proxy, le gardien est entièrement en ligne dans le chemin du trafic. Votre application envoie ses requêtes au point d'accès du gardien au lieu de directement au LLM, et le gardien les transmet après inspection. Aucun changement à la logique de votre application n'est requis — seule l'adresse de destination change.

Étape 1 — Créez le Gardien dans l'Application de Gestion Cato

La première étape est de créer le gardien en tant qu'entité logique dans l'Application de Gestion Cato. Cela se fait dans l'interface utilisateur — aucun code n'est requis à ce stade.

1. Dans le menu de navigation, sélectionnez Sécurité IA > Gardiens, puis cliquez sur Nouveau.
2. Entrez un Nom de Gardien descriptif. Dans notre exemple, nous utilisons E2E Exemple d'Utilisation.
3. Sous Sélectionner le Type de Gardien, choisissez Proxy.
4. Sous Sélectionner un Service IA, choisissez Point de Terminaison Personnalisé depuis le menu déroulant. Cette option fonctionne avec n'importe quel point de terminaison compatible OpenAI, ce que notre application utilise.
5. Dans le champ URL du Point de Terminaison, entrez l'URL de votre fournisseur de LLM. Dans notre exemple, il s'agit de https://bedrock-mantle.eu-north-1.api.aws/v1. C'est la même URL qui était précédemment définie comme BASE_URL dans config.py — vous la transmettez maintenant au gardien au lieu de l'utiliser directement dans votre application.
   Remarque : L'URL doit inclure le chemin jusqu'à et y compris le /v1.
6. Sous Configurer les Paramètres du Gardien, laissez Hôte du Gardien réglé sur Cloud de Cato. Cela signifie que le gardien est géré et hébergé par Cato — vous n'avez pas besoin de déployer ou maintenir une infrastructure supplémentaire.
7. Cliquez sur Enregistrer.

Que s'est-il passé ? Vous avez créé un gardien qui sait où réside votre LLM. Cato agit désormais comme l'intermédiaire pour tout le trafic entre votre application et ce LLM. Le gardien n'a pas encore de règles de politique - nous les ajouterons à l'étape 3. Pour l'instant, nous établissons simplement la connexion et vérifions que le flux fonctionne toujours.

Étape 2 — Récupérer les Détails de Connexion du Gardien

Une fois le gardien enregistré, ouvrez-le depuis la page des Gardiens et naviguez vers la page Docs du gardien, qui fournit tout ce dont votre application a besoin pour se connecter au gardien au lieu de se connecter directement au LLM.

Vous trouverez ici deux éléments d'information clés :

• Le Point de Terminaison du Gardien (votre nouveau BASE_URL) - C'est l'adresse à laquelle votre application enverra désormais des requêtes : https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • Cela remplace l'URL du point de terminaison du LLM dans votre configuration. À partir de ce point, votre application parle à Cato, et Cato parle au LLM en votre nom.

• La Clé API du Gardien (votre nouveau OPENAI_API_KEY)

  • La page Docs fournit également une Clé API du Gardien — l'identifiant que votre application utilise pour s'authentifier auprès du gardien. Cela remplace la clé API du LLM qui se trouve auparavant dans votre configuration. Elle ressemble à ceci : cato-1234-abcde

Remarque: Cato fournit deux Clés API du Gardien. Vous n'en avez besoin que d'une pour faire des requêtes. La deuxième clé existe pour que vous puissiez faire tourner les identifiants en toute sécurité — vous pouvez mettre à jour votre application pour utiliser la nouvelle clé tandis que l'ancienne est encore active, évitant ainsi tout temps d'arrêt.

La Clé API du LLM

Auparavant, la clé API du LLM vivait dans la configuration de votre application. Avec le gardien en place, cette clé est déplacée dans les en-têtes de requête que votre application envoie au gardien — spécifiquement dans un en-tête appelé x-cato-provider-api-key. Le gardien utilise cela pour s'authentifier avec le LLM au nom de votre application.

C'est en fait une amélioration de la sécurité : la clé API du LLM n'est plus codée en dur dans un fichier de configuration, et le gardien agit comme le relais contrôlé pour cet identifiant.

Étape 3 — Mettre à Jour la Configuration de l'Application

Maintenant que le gardien est créé et que vous avez ses détails de connexion, il est temps de mettre à jour l'application. Pour garder l'étape 1 et l'étape 2 clairement séparées, nous créons un nouvel ensemble de fichiers de configuration plutôt que de réécrire les originaux. De cette façon, les deux étapes restent intactes pour référence.

Le nouveau fichier de configuration, config_stage2.py, reflète les détails de connexion mis à jour :

# Configuration étape 2 — routage via le Gardien Proxy Cato

GUARD_API_KEY = "cato-xxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
BASE_URL = "https://api.aisec.catonetworks.com/fw/v1/proxy/openai"
MODEL_ID = "amazon.nova-pro-v1:0"
LLM_PROVIDER_API_KEY = "[SECRET_1]" # Votre clé API fournisseur LLM — transmise au gardien, pas directement au LLM

SYSTEM_PROMPT = (
 "Vous êtes TravelBot, un assistant de voyage sympathique et bien informé. "
 "Aidez les utilisateurs à découvrir des destinations, planifier des itinéraires, recommander des hôtels, "
 "et partager des conseils de voyage pratiques. Gardez les réponses concises et enthousiastes. "
 "Si une question n'est pas liée au voyage, redirigez poliment la conversation."
)

MAX_TOKENS = 1024

Les principales différences par rapport à l'étape 1 :

Étape 4 — Mettre à Jour le Code Client

Le code client obtient également une version correspondante Étape 2 — bedrock_client_stage2.py. La logique est en grande partie la même que l'étape 1, avec deux ajouts :

1. La Clé API du Gardien est utilisée pour s'authentifier avec le gardien (dans l'en-tête Authorization).
2. La clé API du LLM est passée comme un en-tête supplémentaire (x-cato-provider-api-key) afin que le gardien puisse la transmettre au LLM.
3. L'ID de session est passé en tant qu'en-tête (x-cato-session-id) afin que le gardien puisse regrouper les requêtes de la même conversation ensemble — cela se mappe directement à l'id_session qui existe déjà dans la logique de l'application.

# bedrock_client_stage2.py

de **openai** import **OpenAI**
de **config_stage2** import **GUARD_API_KEY**, **BASE_URL**, **MODEL_ID**, **LLM_PROVIDER_API_KEY**, **SYSTEM_PROMPT**, **MAX_TOKENS**


classe **BedrockClient**:
    def __init__(self):
        self._client = **Aucun**

    def _get_client(self) -> OpenAI:
        si self._client est **Aucun**:
            self._client = OpenAI(
                api_key=GUARD_API_KEY,
                base_url=BASE_URL,
                default_headers={
                    "x-cato-provider-api-key": LLM_PROVIDER_API_KEY,
                }
            )
        renvoie self._client

    def invoke(self, messages: liste[dict], session_id: str = "") -> str:
        all_messages = [{"Rôle": "système", "content": SYSTEM_PROMPT}] + messages

        réponse = self._get_client().chat.completions.create(
            modèle=MODEL_ID,
            messages=all_messages,
            max_tokens=MAX_TOKENS,
            extra_headers={
                "x-cato-session-id": session_id,
            }
        )

        renvoyer response.choices[0].message.content

Vérification du Flux

Une fois que les fichiers de configuration et de client mis à jour sont en place, l'application devrait se comporter exactement comme elle le faisait à l'étape 1 du point de vue de l'utilisateur. TravelBot répond aux questions de voyage de la même manière — mais maintenant chaque interaction passe par le protecteur.

À ce stade, le protecteur n'a aucune règle de politique configurée, donc il ne bloque ni ne modifie aucun trafic. Cependant, il consigne chaque interaction. Vous pouvez le vérifier en ouvrant le protecteur dans l'Application de gestion Cato et en consultant la page Enregistrement du protecteur, où vous devriez voir apparaître des sessions au fur et à mesure que l'application est utilisée.

Cela confirme que l'intégration fonctionne correctement et que le protecteur reçoit du trafic.

Résumé des Modifications de l'Étape 1 à l'Étape 2

Étape 3 — Configuration des Règles de Politique

Ce Que Couvre Cette Étape

À l'Étape 2, nous avons introduit le garde et vérifié que le trafic y circule correctement. Le protecteur est actif, mais il n'applique encore aucune règle — il observe le trafic sans agir dessus. À cette étape, nous configurons la Politique d'Interaction des Gardes : l'ensemble des règles qui indiquent au gardien quoi faire lorsqu'il détecte des types de contenu spécifiques.

À la fin de cette étape, le garde appliquera activement deux règles contre le trafic en direct :

• Bloquer et anonymiser toute interaction qui inclut des informations telles que PII ou mots de passe
• Surveiller toute interaction impliquant des conseils médicaux ou des données liées à la santé

Remarque : Nous vous recommandons de d'abord tester vos règles en les réglant sur Surveiller et de les déplacer sur Bloquer après avoir validé que les détections fonctionnent comme prévu.

Qu'est-ce que la Politique d'Interaction des Gardes?

La Politique d'Interaction des Gardes est la base de règles pour vos gardes de sécurité AI. Considérez-la comme un pare-feu pour le trafic AI — au lieu d'inspecter les paquets réseau, elle inspecte le contenu des interactions AI et applique l'action que vous définissez lorsqu'une correspondance est trouvée.

Chaque règle de la politique précise :

• Quel garde la règle s'applique-t-elle
• Que rechercher — défini par un Profil de Moteur, qui est la catégorie de détection (par exemple, tentatives de jailbreak, PII ou données médicales)
• Ce qu'il faut faire lorsqu'une correspondance est trouvée — Bloquer, Surveiller, Anonymiser & Bloquer ou Anonymiser & Surveiller
• Quelle direction de trafic inspecter — messages entrants de l'utilisateur, réponses de l'assistant, entrées d'outils ou sorties d'outils

Un comportement important à connaître : les règles de la Politique d'Interaction des Gardes sont évaluées indépendamment de leur position dans la base règle. Si plus d'une règle s'applique à une interaction, l'action la plus stricte prévaut. Par exemple, si une règle dit de Surveiller et une autre dit de Bloquer, l'action Bloquer est appliquée.

Étape 1 — Créez la Règle 1 : Bloquez les Tentatives de Jailbreak

La première règle que nous créons cible les tentatives de jailbreak — des efforts délibérés des utilisateurs pour manipuler le modèle afin qu'il ignore ses instructions ou contourne ses protections. Pour une application orientée utilisateur comme TravelBot, cela constitue un risque significatif : un utilisateur pourrait tenter de forcer le modèle à se comporter en dehors de son rôle défini ou d'exposer des informations qu'il ne devrait pas.

Pour commencer, accédez à la page de la Politique des Gardes. Vous pouvez le faire soit depuis le menu de navigation principal en sélectionnant Sécurité AI > Politique d'Interaction des Gardes, soit directement depuis la page Vue d'ensemble du garde en cliquant sur Gérer la Politique sous la section Règles Actives.

Depuis la page de la Politique des Gardes, cliquez sur Nouveau pour ouvrir l'éditeur de règles, puis configurez ce qui suit :

Général

• Nom : Bloquer Certain Trafic
• Description : Cela bloque le trafic de jailbreak de notre bot voyage
• Laisser l'interrupteur Activé allumé

Gardes

• Sélectionner Cas d'Utilisation Exemple E2E — cela limite la règle à notre garde spécifique et n'affecte aucun autre garde dans le compte

Profil de Moteur

• Sélectionnez Identifiants Sensibles — c'est la catégorie de détection qui identifie des tentatives d'injections, des modèles de jailbreak et des tentatives d'extraction de secrets ou de crédentials à partir du modèle

Action

• Sélectionnez Anonymiser & Bloquer — lorsque le protecteur détecte une correspondance, il anonymisera toute donnée sensible présente dans l'interaction et bloquera l'invite de parvenir entièrement au LLM

Direction

• Vérifier Utilisateur et Entrée d'Outil — la règle s'applique au contenu provenant de l'utilisateur et de toute entrée d'outil. Les réponses de l'assistant et les sorties d'outils ne sont pas concernées par cette règle.

Cliquez sur Enregistrer. La règle est enregistrée dans une révision non publiée et n'affectera pas encore le trafic en direct.

Étape 2 — Créez la Règle 2 : Surveiller le Contenu Médical

La deuxième règle adopte une approche différente. Plutôt que de bloquer le trafic, elle permet aux interactions de se poursuivre tout en les signalant pour révision. Ceci est approprié pour le contenu qui n'est pas nécessairement malveillant mais peut justifier une visibilité — dans ce cas, des interactions impliquant des conseils médicaux ou des données liées à la santé.

Pour TravelBot, un utilisateur demandant des conseils médicaux pour un voyage (comme les exigences de vaccination ou les précautions sanitaires pour une destination) n'est pas intrinsèquement nuisible, mais c'est le type de contenu que votre organisation peut vouloir suivre pour des raisons de conformité ou de qualité.

Depuis la page de la Politique des Gardes, cliquez Nouveau à nouveau et configurez ce qui suit :

• Général
  • Nom : Surveiller les Données Potentiellement Nuisibles
  • Description : Cela permet à la communication de passer, mais surveille les interactions
    Laisser l'interrupteur Activé allumé

Gardes

• Sélectionnez Cas d'Utilisation Exemple E2E

Profil de Moteur

• Sélectionnez Exposition des Données de Santé — cela détecte les interactions qui impliquent des conseils médicaux, des données de santé ou des informations cliniques

Action

• Sélectionnez Anonymiser & Surveiller — l'interaction est autorisée à passer au LLM et la réponse est renvoyée à l'utilisateur normalement. Toute information personnalisée est anonymisée pour protéger les détails personnels. L'interaction est consignée dans Cato pour révision.

Direction

• Vérifiez les quatre directions : Utilisateur, Assistant, Entrée d'Outil et Sortie d'Outil — cette règle surveille le trafic dans chaque direction, vous donnant une visibilité complète sur les deux côtés de la conversation.

Cliquez sur Enregistrer.

Étape 3 — Publier la Politique

Après avoir enregistré les deux règles, la page de la Politique des Gardes affichera un statut Révision Non Publiée et un bouton Publier (2) dans le coin supérieur droit, indiquant que deux règles sont prêtes à entrer en vigueur.

Important : Jusqu'à ce que vous publiiez, la politique active reste inchangée. Vos règles existent dans un état de brouillon et ne sont pas appliquées au trafic en direct. Cela vous donne l'occasion de réviser vos modifications avant qu'elles ne prennent effet.

Quand vous êtes prêt, cliquez sur Publier (2). Les deux règles deviennent immédiatement actives et le protecteur commence à les appliquer à tout le trafic entrant.

{hauteur="" largeur=""}

Ce que le Protecteur Fait Maintenant

Avec les deux règles publiées, chaque interaction qui passe par le garde Cas d'Utilisation Exemple E2E est maintenant évaluée par rapport à la politique. Voici à quoi cela ressemble en pratique :

Un utilisateur envoie un message à TravelBot. Avant que le message n'atteigne le LLM, le protecteur l'inspecte selon les deux règles :

• Si le message contient un modèle de jailbreak ou une tentative d'extraction de secrets, le protecteur l'anonymise et le bloque. Le LLM ne voit jamais le message, et l'utilisateur reçoit une réponse bloquée.
• Si le message contient des conseils médicaux ou des contenus liés à la santé, le protecteur le permet mais enregistre l'interaction pour révision.
• Si le message ne correspond à aucune des règles, il passe au LLM sans être affecté.

La même évaluation s'applique aux réponses de l'assistant, aux entrées d'outils et aux sorties d'outils, en fonction des directions configurées pour chaque règle.

Vérification que les Règles Sont Actives

Pour confirmer que les règles sont actives et appliquées à votre protecteur, accédez à la page Vue d'ensemble du protecteur. Sous Règles Actives, vous devriez maintenant voir les deux règles listées. Le graphique Interactions dans le Temps et le panneau de Répartition des Violations commenceront à se remplir à mesure que le trafic passe par le protecteur et que des détections se produisent.

Vous pouvez également vous rendre dans Enregistrement du Protecteur pour examiner les sessions individuelles, voir quelles règles ont été déclenchées et inspecter les détails des interactions signalées — à condition que vous ayez les autorisations nécessaires pour visualiser le contenu sensible.

Résumé

Avec ces deux règles en place, l'application dispose maintenant d'une application de sécurité active. Les tentatives de prompt malveillantes sont bloquées avant de parvenir au modèle, et les interactions sensibles d'ordre médical sont visibles pour votre équipe de sécurité — le tout sans aucune modification du code de l'application ni impact sur l'expérience utilisateur finale pour les interactions légitimes.

Ceci termine le guide de bout en bout pour sécuriser une application AI personnalisée avec les Garde Sécurité AI de Cato.