Prévention des fuites de données (DLP)

La couche DLP est une porte de workflow configurable. Elle s'exécute chaque fois qu'un workflow souhaite valider le contenu en entrée ou en sortie par rapport à une politique définie — détection des données personnelles gérée par l'organisation, scoring d'hallucination, validation JSON ou correspondance regex.

Cette page documente le bloc Guardrails et les quatre types de validation qu'il prend en charge.

Quand l'utiliser

Emplacements typiques :

• Porte d'entrée — analyser un message utilisateur à la recherche de données personnelles avant qu'il n'atteigne un LLM.
• Porte de sortie — analyser une réponse LLM à la recherche de données personnelles avant de la renvoyer à l'utilisateur.
• Porte d'hallucination — scorer une réponse par rapport à une base de connaissances avant de l'exposer.
• Porte de format — vérifier qu'un LLM a produit du JSON valide / correspond à une regex avant de le transmettre en aval.

Le bloc Guardrails fait partie du produit scrydon:guardrails — voir Vendeurs → Scrydon.

Quatre types de validation

Détection des données personnelles

L'opération PII Guardrails gouvernée utilise l'ensemble de règles maintenu par les administrateurs de l'organisation dans Paramètres → Gouvernance → DLP. Un workflow ne peut pas choisir une autre liste d'entités, une autre méthode de détection ni une autre action d'application. L'analyse des capacités et la validation des workflows partagent ainsi une seule politique.

Lorsqu'une règle correspond, la validation Guardrails échoue et le workflow suit sa branche d'échec. Le résultat contient les métadonnées de la règle et les positions de caractères nécessaires au routage et au diagnostic, mais jamais le texte brut correspondant :

{
  "passed": false,
  "evaluated": true,
  "validationType": "pii",
  "policyMode": "enforce",
  "findings": [
    {
      "ruleId": "email-address",
      "entityType": "EMAIL",
      "detector": "builtin",
      "confidence": "HIGH",
      "channel": "tool_call",
      "start": 8,
      "end": 21
    }
  ]
}

La politique doit être disponible, activée et inclure le canal tool_call. L'exécution directe en dehors de l'hôte gouverné de Scrydon est refusée, car elle ne peut pas charger la politique d'organisation de confiance.

Détection des hallucinations

Valide une sortie LLM par rapport à une base de connaissances en utilisant RAG et le scoring LLM :

Échelle de confiance :

Exemple de sortie

{
  "passed": false,
  "score": 2,
  "reasoning": "The claim about Q4 revenue is not mentioned in any knowledge base document",
  "error": "Low confidence: score 2/10 is below threshold 3"
}

Configuration

Le bloc Guardrails expose ces champs dans l'éditeur de workflow :

Le choix des règles PII, la configuration des détecteurs et le mode de la politique sont des paramètres de l'organisation, et non des entrées du bloc Guardrails.

L'intégration Guardrails sous-jacente expose également l'outil de vérification des hallucinations avec des paramètres de modèle et de base de connaissances. Il ne figure pas actuellement dans la liste déroulante des types de validation du bloc de workflow.

Association avec le bloc Evaluator

Le bloc Guardrails est fail-closed (fermé en cas d'échec) — en cas d'échec, le workflow suit la branche d'échec. Le bloc Evaluator est scoring — il renvoie un score sur lequel le workflow peut brancher comme il le souhaite. Utilisez Guardrails pour des portes strictes, Evaluator pour des vérifications de qualité qui pilotent des tentatives de reprise ou des chemins de secours.

Comment nous mesurons le moteur DLP de la plateforme

Au-delà du bloc Guardrails, Scrydon applique la politique DLP de l'organisation aux appels de capacité couverts, notamment les complétions LLM, la transcription et les embeddings. L'exécution gouvernée des outils applique séparément la classification de confiance des destinations et bloque les violations de non-écriture vers un niveau inférieur lorsque le mode de classification est Enforce. Les affirmations sur la qualité de détection sont faciles à formuler et difficiles à vérifier, c'est pourquoi nous mesurons le moteur partagé de la même manière que nous mesurons la qualité de la récupération : sur un benchmark public tiers, avec le harnais en CI comme porte de publication — une version qui régresserait en dessous des seuils ne sera pas livrée.

Mesurée sur une tranche anglophone de 2 661 prompts de ai4privacy/pii-masking-300k (révision de dataset épinglée, évaluée au moment du build — le dataset lui-même n'est jamais redistribué) plus une banque d'escalade de classification interne :

Par type d'entité gradué : email 99,6 %, adresse IP 99,5 %, numéro de téléphone 86,1 % de rappel.

Ce que nous ne prétendons pas. Le rapport comporte une section obligatoire hors périmètre listant les catégories de détection que le moteur ne couvre pas, avec des preuves mesurées plutôt que le silence : noms de personnes en texte libre (domaine NER — l'heuristique regex mesurée à 14 % de rappel, nous ne le notons donc pas), formats libres de date de naissance (3 % — le moteur revendique ISO 8601 uniquement), et identifiants nationaux génériques (27 % — le moteur revendique des formats juridictionnels spécifiques tels que US_SSN ou BE_NRN, pas des suites de chiffres arbitraires). Chacun est documenté dans l'artefact de rapport signé afin que les auditeurs voient le périmètre, et non un chiffre marketing.

Politique DLP de l'organisation et appels LLM bloqués

L'opération Guardrails des workflows et les appels LLM de la plateforme utilisent la même politique DLP de l'organisation (Paramètres → Gouvernance → DLP). Lorsque cette politique est en mode Enforce et que l'analyse d'une entrée LLM produit une détection — correspondance d'un motif PII/secret ou classification d'injection de prompt — l'appel est bloqué avant d'atteindre le fournisseur de modèle :

HTTP 422 Unprocessable Entity

{
  "error": "llm_blocked_by_dlp",
  "detail": "Your input contained content that could not be processed.",
  "dlpReason": "input_blocked"
}

• detail est le message d'entrée bloquée configuré par l'administrateur dans l'éditeur de politique DLP.
• dlpReason distingue un blocage d'entrée (input_blocked) d'un refus fail-closed du classificateur ou du chargement de politique (classifier_unavailable, policy_not_loaded).
• Les étapes d'agent de workflow échouent avec Blocked by DLP policy: <message> ; les appels SDK et API reçoivent le refus de politique typé sur les opérations Base Platform unaires et streaming.
• Un 422 signifie que le blocage est déterministe — réessayer la même entrée re-bloque. Examinez la règle concernée dans Paramètres → Gouvernance → DLP → Hits ou ajustez le mode de la politique.
• La colonne Triggered by de Hits indique à qui une détection est attribuée : l'utilisateur connecté ; la personne qui a délégué l'exécution d'un workflow, même exécuté sous un compte de service ; ou le compte de service lui-même lorsqu'il appelle directement la plateforme. Une détection levée par un service de la plateforme n'agissant pour personne n'affiche personne.

Le classificateur sémantique d'injection de prompt est activé lorsqu'une organisation ne s'en est pas explicitement désinscrite. Dans Paramètres avancés, les administrateurs peuvent également configurer la politique pré-action canonique : une liste d'autorisation ou de refus des destinations externes et des rangs maximaux de classification des données par catégorie d'outil.

Ce que couvre l'analyse d'un appel LLM

En entrée, l'analyse lit le texte de chaque message, l'entrée de chaque appel d'outil émis par le modèle, chaque résultat d'outil (y compris les résultats imbriqués dans un autre contenu), les arguments des appels d'outils au format OpenAI et les documents texte. En sortie, elle lit le texte de la réponse, les blocs de contenu ordonnés qui l'accompagnent et les appels d'outils demandés par le modèle. Les noms d'outils, les identifiants d'appels d'outils et les images sont des données de protocole, pas du contenu, et restent intacts. Les versions précédentes ne lisaient en entrée que le texte de premier niveau des messages et ne lisaient pas les blocs de contenu renvoyés : une donnée sensible dans une entrée d'outil, un résultat d'outil ou un bloc de contenu passait sans analyse.

Motifs personnalisés et entrées longues

Chaque règle est analysée sur le champ entier, quelle que soit la longueur de l'invite, de la réponse, du fichier ou de la requête sortante.

• Vos propres motifs et exceptions s'exécutent sur un moteur en temps linéaire. Son temps d'exécution ne croît qu'en proportion du texte, quel que soit le motif : une règle personnalisée ne peut ni ralentir la plateforme, ni abandonner sans signaler de correspondance. Écrivez les motifs dans la syntaxe habituelle des expressions régulières JavaScript. \w+, .* et les autres répétitions non bornées sont acceptés.
• Certaines syntaxes ne sont pas prises en charge, et un tel motif ne peut pas être enregistré. L'éditeur de règles en indique la raison :
  • les assertions : (?=…), (?!…), (?<=…), (?<!…). Faites plutôt correspondre le texte environnant, ou utilisez une exception de règle ;
  • les références arrière : \1, \k<nom> ;
  • les échappements JavaScript hérités, comme \c sans lettre, ou les échappements octaux ;
  • un nombre de répétitions supérieur à 1 000, ou un motif trop complexe pour le moteur (les grandes répétitions comptées en sont la cause habituelle : donnez à une répétition un minimum sans maximum plutôt qu'un large intervalle) ;
  • un groupe répété dont le contenu peut être vide, comme (a|)* ou (,?\s*)* (rendez le contenu obligatoire, par exemple (?:,\s+)*) ;
  • avec les options i et u à la fois : une propriété Unicode négative (\P{…}) ou \B ;
  • une classe de caractères qui ne correspond à rien, comme [] ou [^\W\w], lorsqu'elle est répétée ou facultative ;
  • sans l'option u, un emoji écrit en échappements (\uD83D\uDE00) suivi d'une répétition ou placé dans une classe de caractères (ajoutez l'option u, ou écrivez-le hors de la classe, sous forme de groupe) ;
  • avec l'option u, une moitié d'emoji seule (un demi-codet isolé), saisie telle quelle ou échappée ;
  • avec l'option i, des classes de caractères qui énumèrent trop de caractères, comme deux [\S] ou plusieurs intervalles aussi larges que [\u0100-\uffff] (utilisez \S hors des crochets, réduisez les intervalles ou retirez i) ;
  • un motif de plus de 512 caractères.
• Quelques motifs correspondraient légèrement différemment de JavaScript sur certains caractères : sur un champ qui en contient un, la règle échoue de manière sûre (voir ci-dessous), et elle s'exécute exactement comme JavaScript sur tous les autres champs. L'éditeur affiche une remarque : sans l'option u, ., les classes négatives et les larges intervalles de caractères pourraient correspondre à la moitié d'un emoji, donc un champ qui contient un emoji, ou la moitié d'un emoji, échoue de manière sûre (ajoutez l'option u pour l'éviter) ; et sans distinction de casse et sans u, quelques caractères comme le signe Kelvin (K), le s long (ſ) ou ẞ sont comparés différemment, donc un champ qui en contient un échoue de manière sûre.
• Chaque règle personnalisée a une limite de champ, affichée dans l'éditeur de règles : un motif plus grand coûte davantage par caractère, donc une règle s'exécute sur les champs jusqu'à une limite (environ 8,9 millions de caractères pour un motif court comme secret-[0-9]{6}, environ 330 000 pour password\s*[:=]\s*\S{8,200}). Un champ plus long échoue de manière sûre pour cette règle. Les exceptions d'une règle comptent dans la même limite : lorsque le motif de la règle et ses exceptions ne tiennent pas ensemble sur un champ, les exceptions ne s'y exécutent pas et toutes les correspondances sont maintenues.
• Les règles personnalisées et toutes les exceptions partagent un budget de temps par champ : 100 ms, ou 1 seconde par Mo de texte. Les exceptions ne s'exécutent que lorsque leur règle a trouvé une correspondance. Les détecteurs intégrés s'exécutent toujours. Une fois le budget épuisé, chaque règle personnalisée restante échoue de manière sûre pour ce champ, et les exceptions d'une règle cessent d'excuser ses correspondances, règles intégrées comprises : les correspondances sont maintenues. L'analyse enregistre les règles ignorées. La compilation des motifs d'une politique et la construction de ses dictionnaires ne sont pas imputées à ce budget : elles ont lieu au plus une fois par requête, et une requête peut y consacrer au plus 1 seconde (une politique à toutes les limites prend environ 0,15 s). Au-delà, les règles pas encore compilées échouent de manière sûre pour le reste de la requête : en mode Enforce, la requête est bloquée. Cela n'arrive que sur un serveur plusieurs fois plus lent que d'habitude, ou qui garde les règles compilées d'un très grand nombre de requêtes à la fois.
• Une politique compte au plus 100 règles, et une règle au plus 16 exceptions. L'éditeur refuse davantage. Une politique enregistrée auparavant avec davantage continue d'exécuter toutes ses règles, mais seules les 16 premières exceptions d'une règle s'appliquent.
• Les dictionnaires (une règle de dictionnaire, ou une exception de dictionnaire) font correspondre leurs termes comme mots entiers, sans tenir compte de la casse (le ς final et le σ grecs se correspondent, et les ı et İ turcs correspondent à i et I : kırmızı correspond à KIRMIZI), et contiennent au plus 1 000 termes et 32 768 caractères au total. Chaque occurrence est trouvée, y compris celles qui se chevauchent. Tous les termes sont recherchés en une seule passe : une liste plus longue ne ralentit pas l'analyse terme par terme. Un dictionnaire compte dans la limite de champ de sa règle comme un motif. L'éditeur refuse un dictionnaire plus grand. Un dictionnaire enregistré auparavant qui dépasse ces limites échoue de manière sûre comme règle, et est ignoré comme exception : sa règle correspond alors davantage, jamais moins.
• Une politique dans son ensemble peut contenir au plus 262 144 caractères de termes de dictionnaire, et ses motifs personnalisés, ensemble, doivent rester assez petits pour que le moteur les garde compilés ; l'éditeur indique quelle limite un enregistrement dépasse. Une politique enregistrée auparavant au-delà de ces limites continue de se charger : les exceptions au-delà sont ignorées (leurs règles correspondent davantage, jamais moins) et signalées.
• Ce que le journal d'audit enregistre lorsque le budget ou une limite arrête une exception. La ligne de l'analyse nomme les règles dont les exceptions ne se sont pas toutes exécutées (jusqu'à 20 identifiants de règle, plus le nombre total), et chacune de ces règles reçoit une ligne Exception ignorée avec la raison budget_exhausted. Une exception qui dépasse une limite reçoit une ligne Exception ignorée avec la raison over_cap au chargement de la politique. Ces lignes nomment la règle et la position de l'exception, jamais le motif ni le texte correspondant ; les répétitions au sein d'une même requête sont écrites une seule fois, avec un compte.
• Lignes d'audit par requête. Une requête écrit une ligne par fait distinct : une ligne d'analyse par canal avec les totaux, une ligne de violation par règle, type de détection et canal, une ligne d'action par règle, action et direction, chacune avec le nombre d'occurrences. Le nombre de lignes croît donc avec les règles qui ont trouvé une correspondance, et non avec la longueur de la réponse. Une réponse diffusée avec une détection dans chaque phrase écrit quelques lignes, et non une par phrase ; la position de chaque détection n'est pas conservée. Si le client annule une réponse diffusée en cours de route, les lignes correspondant à ce qu'il a déjà reçu sont tout de même écrites.
• Échouer de manière sûre signifie que le champ entier est traité comme une correspondance de cette règle, sans exécuter le motif. En mode Enforce, l'appel est bloqué. Avec une action de masquage, de caviardage ou de hachage, le champ entier est réécrit. Avec une action d'audit, la détection est seulement signalée. Elle est enregistrée sans extrait de contenu.
• Règles enregistrées auparavant. Une règle enregistrée avant ces vérifications qui utilise une syntaxe non prise en charge échoue de manière sûre sur chaque champ, et les détections de la politique affichent un avertissement nommant la règle. Une règle qui peut correspondre différemment sur certains caractères continue de s'exécuter, n'échoue de manière sûre que sur les champs qui en contiennent, et affiche un avertissement vous invitant à la vérifier et à l'enregistrer. Une exception enregistrée auparavant avec une syntaxe non prise en charge est ignorée : sa règle correspond alors davantage, jamais moins. Dans tous les cas, modifiez la règle et enregistrez-la.
• Les détecteurs intégrés ont une longueur de correspondance maximale. Par exemple, une adresse e-mail correspond à au plus 64 caractères avant le @, et un JWT à environ 16 000 caractères au plus. Une clé d'API ou un JWT plus long que sa limite est tout de même caviardé en entier. Si vous utilisez le catalogue @scrydon/sdk-authoring pour caviarder du texte vous-même, passez chaque correspondance de clé d'API et de JWT par extendPastBound pour obtenir le même résultat.
• Les règles et préréglages fournis par Scrydon (signatures d'attaque, préréglages de l'éditeur de politique) sont mesurés et bornés, et les copies enregistrées auparavant ont été mises à jour. Ajouter des espaces à une attaque déclenche ces règles au lieu de les contourner.
• Les exceptions excusent exactement les correspondances qu'elles contiennent sur le champ entier.

Pas d'écriture vers le bas : un workflow qui lit des données classifiées

Indépendamment de la DLP, l'exécution d'un workflow porte une marque de niveau maximal de classification — l'habilitation la plus élevée de tout ce qu'elle a lu. Lorsque le mode de classification de votre organisation est Enforce (Paramètres → Gouvernance → Classification), un appel d'outil qui enverrait ces données vers un point de terminaison moins bien noté est refusé :

HTTP 422 Unprocessable Entity

{
  "code": "POLICY_BLOCKED",
  "details": { "policyCode": "EGRESS_BLOCKED_BY_CLEARANCE" }
}

Un bloc de workflow affiche le refus sous la forme CLEARANCE_EGRESS_VIOLATION.

La marque est une propriété de l'exécution, et non d'une connexion entre deux blocs : dès que l'exécution a lu du contenu CONFIDENTIAL, tout ce qu'elle envoie ensuite est considéré comme le portant. Elle monte lorsqu'une recherche dans une base de connaissances ou la lecture d'un document renvoie du contenu classifié, elle est héritée par un workflow enfant, et elle s'applique aux outils qu'un bloc Agent choisit d'appeler.

Trois éléments déterminent si vous rencontrez ce refus :

• Un contenu que personne n'a classifié ne fait pas monter la marque. Une base de connaissances dont les documents ne portent aucune étiquette d'habilitation laisse la marque vide, et rien n'est refusé.
• Un point de terminaison que personne n'a noté compte comme le niveau choisi par votre organisation. C'est le réglage Les points de terminaison non évalués comptent comme de l'onglet Habilitation. Il vaut INTERNAL par défaut, y compris pour une organisation qui existait avant ce réglage et qui était encore à PUBLIC sur le schéma par défaut, passée à INTERNAL lors de la mise à jour (voir Classification et habilitation). Il couvre les comptes, les serveurs MCP et les connexions non évalués. Notez les comptes, connexions et serveurs MCP vers lesquels vos workflows envoient des données dans Paramètres → Gouvernance → Identité → Endpoints, sinon une exécution qui a lu du contenu classifié au-dessus de ce niveau ne peut pas leur envoyer de données. Une connexion sans compte (connexions par clé d'API, authentification basique, jeton de bot ou sans authentification) se note dans le groupe Connections. Cette note couvre aussi chaque compte de la connexion qui n'a pas de note propre, et la note propre d'un compte l'emporte toujours. Les destinations des requêtes HTTP et des webhooks ne suivent pas ce réglage : elles ne peuvent pas être évaluées, gardent le rang 0 (le plus bas de tout schéma) et se voient refuser toute donnée classifiée au-dessus du rang 0.
• Les serveurs MCP se notent comme les comptes d'extension. Le même contrôle d'écriture vers le bas s'applique à chaque appel d'outil MCP, depuis un bloc Agent ou un bloc MCP autonome. Notez chaque serveur MCP dans le groupe MCP servers de la même page Endpoints. Un serveur MCP que personne n'a noté compte comme ce même niveau choisi par l'organisation, tout comme un serveur noté selon un schéma de classification que votre organisation n'utilise plus : une exécution qui a lu du contenu classifié au-dessus de ce niveau ne peut pas appeler ses outils. Les versions précédentes ne contrôlaient pas les appels MCP : si votre organisation est en mode Enforce, notez vos serveurs MCP avant la mise à niveau, ou passez en mode Audit jusqu'à ce qu'ils soient notés.

Passez le mode de classification sur Audit pour enregistrer chaque refus potentiel comme preuve sans bloquer, le temps de noter vos points de terminaison.

Voir aussi

• Architecture → Cortex — où Cortex peut appliquer des garde-fous sur chaque appel LLM en tant que couche indépendante du workflow.
• Habilitation de la base de connaissances — l'habilitation est un axe distinct de la DLP, et non un remplacement.
• Conformité — comment la DLP se mappe aux contrôles des référentiels (RGPD, EU AI Act, ISO 42001).