Router — Guard anti-exfiltration

Guard est le filtre qui retire les informations sensibles avant qu'elles ne quittent votre serveur pour rejoindre un modèle IA externe. C'est le différenciateur opérationnel de Router : vos données sensibles (NAS, cartes, clés API, courriels, adresses) ne voyagent jamais en clair.

Guard est actif par défaut sur toute requête POST /chat/completions et POST /embeddings. Aucune configuration initiale requise — la politique par défaut est créée à la première requête et filtre tout ce qui est critique.

Ce que Guard filtre

🔒 Détecteurs intégrés (15 regex + 4 entités)

Renseignements personnels canadiens (PII)

Détails des patterns :

• regex:nas — NAS 9 chiffres validé Luhn (évite les faux positifs sur les numéros de téléphone à 9 chiffres).
• regex:ramq — Carte d'assurance maladie Québec: 4 lettres suivies de 8 chiffres.
• regex:postal_code_ca — Code postal canadien au format H2X 1Y4.
• entity:email — RFC 5322 simplifié.
• entity:phone_na — Formats nord-américains: (XXX) XXX-XXXX, XXX-XXX-XXXX, +1 XXX XXX XXXX, 1-XXX-XXX-XXXX. Validation 10-11 chiffres.
• entity:person_name — Titres M., Mme, Mlle, Me., Dr., Pr., Prof., Mr., Mrs., Ms., Mx. + 1-2 mots capitalisés. Supporte accents français et noms composés (M. Léon-Étienne Côté).
• entity:address_ca — Adresse complète avec numéro + rue + ville + province + code postal, FR (100 rue Saint-Denis, Montréal, QC H2X 1Y4) et EN (100 Yonge Street, Toronto, ON M5C 2W1).

Identifiants et clés API

Note sur regex:aws_secret_key — Les 40-char base64 sont ubiquitaires (hashes, IDs opaques). Le détecteur défère actuellement à env_var_secret + custom patterns pour éviter les faux positifs massifs. Si vous voulez une détection stricte AWS, ajoutez un custom pattern contextuel (AWS_SECRET_ACCESS_KEY=[A-Za-z0-9/+=]{40}).

Secrets et infrastructure

Sur env_var_secret, la valeur est redactée (API_KEY=[REDACTED:ENV_VAR]) mais le nom de la variable est préservé — utile pour comprendre quel type de secret a été filtré sans exposer le contenu.

Le validateur Luhn

NAS et numéros de carte passent tous par l'algorithme Luhn après le match regex. Ça évite les faux positifs sur les téléphones (qui ressemblent à des NAS) et les numéros de commande (qui ressemblent à des cartes). Les candidats qui échouent Luhn sont ignorés.

Personnalisation par organisation

Tout se configure dans Paramètres → IA & Système → Guard (Sécurité IA) à /settings/guard.

Toggle des détecteurs

Chaque détecteur peut être activé ou désactivé indépendamment. Par défaut tous sont actifs (opt-out). Useful pour :

• Désactiver entity:email si votre workflow doit envoyer des courriels au modèle pour triage
• Garder seulement les critiques en mode bas-bruit

Custom patterns

Ajoutez vos propres regex pour les identifiants spécifiques à votre domaine :

• Matricules employés (EMP-\d{6})
• Codes client (CLT-[A-Z]{3}-\d{4})
• Identifiants fournisseurs, contrats, etc.

Chaque custom pattern a son propre label, catégorie et sévérité. La regex est validée à la sauvegarde — une expression invalide refuse le formulaire.

Allowlist (exclusions)

Patterns de contenu à laisser passer même s'il matche un détecteur. Cas d'usage typique :

• Vos propres adresses courriel ([A-Za-z0-9._%+\-]+@votredomaine\.ca) — vous voulez que l'IA puisse y répondre sans redaction
• Identifiants publics non-sensibles qui matchent un pattern de clé API par coïncidence

Un hit est exclu quand il est entièrement contenu dans un range matché par l'allowlist.

Mode strict — halt vs redact

• Par défaut (strict_mode: false) : Guard redacte le contenu et la requête continue vers le modèle avec le contenu filtré.
• Mode strict (strict_mode: true) : toute détection critical ou high bloque la requête (HTTP 412 guard_halt) sans appel upstream. La requête échoue proprement avec la liste des détections — aucun token consommé, aucun coût facturé.

Recommandé pour les environnements réglementés où accidentellement redacter du contenu est moins coûteux qu'envoyer quoi que ce soit de sensible.

Tester votre politique en direct

Sur /settings/guard, section Tester la politique :

1. Collez du texte dans la textarea
2. Guard exécute Pipeline.apply/2 en live côté serveur
3. L'UI affiche le texte redacté exact qui serait envoyé au modèle, plus la liste des détections (original → label de redaction)

Aucun appel n'est fait à un modèle. C'est un aperçu pur de la politique.

Audit — voir ce que Guard a redacté

Chaque requête génère une entrée audit encrypted-at-rest (Cloak AES-256-GCM), rétention 90 jours.

Via l'API

# Récupérer un audit par request_id
curl https://router.signalorange.ca/api/v1/router/audit/chatcmpl-abc123 \
  -H "Authorization: Bearer $ROUTER_API_KEY"

# Lister les audits récents (avec filtres)
curl "https://router.signalorange.ca/api/v1/router/audit?limit=50&min_severity=high&halted_only=true" \
  -H "Authorization: Bearer $ROUTER_API_KEY"

Réponse :

{
  "request_id": "chatcmpl-abc",
  "policy_id": 42,
  "detections_count": 2,
  "halted": false,
  "inserted_at": "2026-04-21T12:34:56Z",
  "detections": [
    {
      "detector": "regex:nas",
      "category": "pii",
      "severity": "critical",
      "redacted_snippet": "[REDACTED:NAS]",
      "position_start": 23,
      "position_end": 34
    }
  ]
}

Privacy-by-design : l'API ne retourne jamais original_snippet (le contenu sensible pré-redaction). Seuls le label redacté, les positions, la catégorie et la sévérité sont exposés. Les originaux restent derrière l'UI /settings/guard avec ACLs.

Voir Router — API d'audit pour les détails.

Via l'UI

/settings/guard affiche les 10 derniers audits : request_id, nombre de détections, flag HALTED, timestamp relatif. Pour voir les originaux, cliquer sur un audit ouvre la vue détaillée avec décryption Cloak (admin uniquement).

Réagir en temps réel — webhook guard.halt

Quand une requête est bloquée en mode strict, Guard peut déclencher un webhook vers votre URL :

POST https://votre-app.com/hooks/meridian
X-Meridian-Event: guard.halt
X-Meridian-Delivery-Id: 1234
X-Meridian-Signature: sha256=<hex>

{
  "event": "guard.halt",
  "organization_id": 42,
  "policy_id": 1,
  "request_id": "halt-uuid",
  "halted_at": "2026-04-21T12:34:56Z",
  "detections_count": 2,
  "detections": [
    {"detector": "regex:nas", "category": "pii", "severity": "critical", "redacted": "[REDACTED:NAS]"}
  ]
}

Cas d'usage : pager le SOC, mettre à jour un dashboard de compliance, envoyer une alerte Slack. Voir Router — Webhooks pour la configuration + la vérification HMAC.

Ententes zéro rétention chez les fournisseurs

En complément de Guard, Router a négocié avec les fournisseurs principaux :

• Anthropic — entente zéro rétention : aucun stockage des prompts/réponses, aucun usage pour l'entraînement
• OpenAI — entente zéro rétention équivalente
• Google Gemini — opt-out automatique de l'entraînement selon les modèles

Les logs Router (côté Meridian) restent hébergés à Montréal (OVH ca-east-1).

Ce que Guard ne fait pas

• Contenu métier légitime — noms de clients, montants, descriptions de projets : intentionnellement laissés intacts (sinon Router serait inutile)
• Prompt système — vos instructions ne sont jamais altérées, seulement le contenu utilisateur
• Données déjà publiques — adresses postales d'entreprise, numéros de TPS publiés, etc.

C'est un compromis conscient : Guard empêche les fuites accidentelles de secrets et de PII forte, pas la divulgation volontaire de données métier.

Conformité

Guard + zéro rétention positionne Meridian comme :

• Conforme LPRPDE (PIPEDA)
• Conforme Loi 25 du Québec — incluant les exigences de transferts hors Québec (la PII forte est filtrée avant tout transfert)
• Compatible avec les politiques RGPD côté client

Voir aussi : Politique de confidentialité, Pratiques de sécurité, DPA.

Et après ?

• Router — API d'audit — inspection programmatique des détections
• Router — Webhooks — alertes sur guard.halt
• Router — Démarrage rapide — premier appel
• Router — Codes d'erreur — gestion du 412 guard_halt