Skip to main content

Activer la protection Safe House

Ce démarrage rapide vous guide pour activer Safe House sur un agent existant, observer de vraies détections de menaces, passer en mode enforce et gérer les messages mis en quarantaine. Vous aurez besoin d’un agent Mnemom déjà enregistré — si vous n’en avez pas, consultez d’abord la Vue d’ensemble de la Mnemom Gateway.

Prérequis

  • Un token API Mnemom dans $MNEMOM_TOKEN
  • Un ID d’agent dans $AGENT_ID (ex. mnm-550e8400-e29b-41d4-a716-446655440000)

Étape 1 — Activer Safe House en mode observe

Commencez par le mode observe. Il exécute une analyse complète des menaces sans aucun impact sur la latence, vous permettant de voir ce que Safe House détecterait avant de vous engager dans le blocage. La configuration de Safe House se trouve sur la carte de protection de l’agent — mode est l’interrupteur principal de premier niveau ; screen_surfaces décide quelles surfaces le pipeline de détection inspecte. Les surfaces sont des unités de filtrage, pas un budget par tour : la porte d’entrée s’exécute une fois par surface activée que la requête transporte. La carte ci-dessous ne commence qu’avec incoming, vous verrez donc une évaluation de porte d’entrée par requête. Activer tool_responses (Étape 7) ajoute une évaluation supplémentaire pour chaque résultat d’outil que la requête renvoie au modèle — à l’intérieur de cette même requête, avant que le modèle ne le lise.
La grammaire complète de la carte de protection est sur /specifications/protection-card-schema ; la carte canonique que le composeur renvoie inclut également card_id, _composition et tous les défauts plateforme / organisation qui se propagent dans la carte effective de l’agent. Alternative CLI. Enregistrez la carte sous protection.card.yaml et publiez-la avec une seule commande — pas de curl requis :

Étape 2 — Envoyer un message de menace de test

Envoyez un message de type BEC (compromission de messagerie d’entreprise) via la passerelle et vérifiez les en-têtes de réponse. Cela ne bloquera rien en mode observe — mais cela enregistrera une détection.
Recherchez l’état de Safe House dans la réponse. Les anciens en-têtes X-Safe-House-* ont été retirés au profit de la structure unifiée à quatre points de contrôle X-Mnemom-Verdict (voir la référence des en-têtes) :
En mode observe, X-Mnemom-Verdict.front indique observed afin que vous puissiez suivre ce qui se serait passé en mode enforce — le message atteint quand même l’agent dans tous les cas. L’en-tête X-Mnemom-Advisory porte les résultats du détecteur sous forme de tableau JSON ; voir /api-reference/headers#x-mnemom-advisory.

Étape 3 — Examiner les détections dans l’observatoire

Ouvrez l’Observatoire pour voir les détections Safe House enregistrées à partir de votre test :
  1. Allez sur mnemom.ai/observatory
  2. Sélectionnez votre agent dans la barre latérale
  3. Cliquez sur Security dans la barre de navigation supérieure
Vous verrez une timeline Safe House Events avec chaque détection, sa catégorie de menace, les scores L1/L2 et le verdict. Le message de test devrait apparaître quelques secondes après la fin de la requête. Vous pouvez également extraire les statistiques de détection directement via l’API. Les statistiques Safe House sont à portée organisation (un nombre agrégé sur chaque agent de l’organisation) ; filtrez par agent_id pour cibler un agent spécifique :

Étape 4 — Passer en mode enforce

Une fois à l’aise avec ce que Safe House détecte, passez en mode enforce. À partir de ce moment, les messages dont le score dépasse le seuil quarantine sont retenus pour examen, et les messages au-dessus du seuil block sont supprimés.
Le mode enforce renvoie HTTP 422 pour les messages mis en quarantaine et HTTP 403 pour les messages bloqués selon la référence des erreurs. L’énumération à 4 modes n’a aucun simulate — commencez par observe (pas de blocage) et progressez par nudge (injection d’avis, pas de blocage) avant d’activer enforce. Consultez le concept Safe House pour la sémantique complète des modes.

Étape 5 — Voir un message mis en quarantaine

Envoyez à nouveau le même message BEC, cette fois en mode enforce :
Cette fois, la réponse est un 422 avec un ID de quarantaine (le contrat canonique des erreurs) :
Le message a été retenu avant d’atteindre l’agent. Votre application doit le présenter à la personne responsable de l’examen de sécurité.

Étape 6 — Examiner et libérer de la quarantaine

Inspectez le message mis en quarantaine et décidez de le libérer ou de le rejeter. Les points de terminaison de quarantaine sont à portée organisation (une file de quarantaine par organisation) ; le quarantine_id transporté dans le corps de la réponse 422 est la clé de recherche :
Si le message est légitime (un faux positif), libérez-le. Cela transmet le message original à l’agent et marque l’entrée de quarantaine comme libérée :
Pour rejeter le message sans le libérer (confirmer qu’il s’agissait d’une vraie menace) — DELETE sur la ressource de quarantaine :
Libérer un message mis en quarantaine l’enregistre également comme faux positif, ce qui alimente la calibration des seuils. Après plus de 10 faux positifs confirmés dans une catégorie, l’Observatoire suggérera des ajustements de seuil pour votre agent.

Étape 7 — Filtrer les résultats d’outils

Les étapes 1 à 6 n’ont filtré que incoming — le message de l’utilisateur. Si votre agent utilise des outils, la voie d’injection la plus courante est le résultat d’outil : un résultat de recherche, un corps d’e-mail, une réponse d’API contenant des instructions dissimulées. Activez la surface tool_responses :
À partir de là, une requête qui renvoie des résultats d’outils au modèle est filtrée à nouveau à l’intérieur de cette même requête — une fois par résultat d’outil, sur sa propre surface, avant que le corps ne soit transmis au fournisseur. C’est une vérification de porte d’entrée ; rien n’attend le tour suivant de l’agent. La couverture n’est toutefois pas inconditionnelle : une requête qui se ramifie vers de nombreux appels d’outils au sein d’un même tour n’a pas de couverture complète garantie. La forme de l’application diffère de celle de l’étape 5. Un message signalé fait échouer la requête avec un 422 ou un 403. Un résultat d’outil signalé ne fait pas échouer la requête — il est retiré du corps :
N’interprétez pas un 200 comme « la porte d’entrée n’a rien fait ce tour-ci ». Analysez X-Mnemom-Verdictfront=enforced sur un 200 signifie qu’un résultat d’outil a été retenu ou annoté à l’intérieur de la requête.

Prochaines étapes

Ajouter des identifiants canari

Plantez de fausses clés API dans le contexte de l’agent. Toute tentative de les utiliser est un indicateur sans faux positif d’une exfiltration réussie.

Configurer la confiance des sources

Mettez en liste blanche les sources amont de confiance dans trusted_sources.{domains, agent_ids, ip_ranges} pour court-circuiter la détection sur les appelants connus comme sûrs (chaque saut reste journalisé pour audit).

Activer le DLP sortant

Analysez les réponses de l’agent à la recherche de PII et de secrets avant qu’elles ne soient renvoyées aux appelants.

Consulter l'Observatoire

Vue d’ensemble de sécurité, tendances du risque de session et ventilation des détections par catégorie pour tous vos agents.

Voir aussi

  • Concept Safe House — Explication complète des modes, catégories de menaces et couches de détection
  • Quand la porte d’entrée s’exécute — Pourquoi la porte d’entrée se déclenche une fois par surface entrante, et non une fois par tour
  • Intégration Safe House Gateway — Comment Safe House s’intègre dans le pipeline de requêtes de la passerelle Mnemom
  • Modes d’application — Comment la passerelle gère les violations après qu’elles atteignent l’agent