Garde-fous LLM : caviardage, listes autorisées et régions

Un garde-fou est une politique nommée que vous attribuez à une clé ou à un membre de votre organisation. Il peut restreindre les modèles, les fournisseurs et les régions de données qu’une requête peut utiliser, plafonner les dépenses et filtrer le contenu des requêtes. La politique se combine dans l’ordre organisation, espace de travail, puis clé, et chaque niveau ne peut que restreindre ce que permet le niveau au-dessus. Les budgets des différents niveaux sont vérifiés séparément, jamais additionnés.

Ce que comprend chaque forfait

• Tous les forfaits, Solo compris : le caviardage des renseignements personnels par les détecteurs intégrés, pour toute l’organisation, en mode caviardage (ci-dessous).
• Équipe et Entreprise : les garde-fous eux-mêmes — motifs personnalisés, mode blocage, liste d’exceptions des filtres, budgets, listes de modèles, de fournisseurs et de régions autorisés, et politiques par espace de travail, par clé et par membre. Sans le forfait, en créer ou en attribuer un renvoie 402 subscription_required; ce qui était déjà configuré continue de fonctionner.

Caviardage des renseignements personnels pour toute l’organisation

Les détecteurs intégrés énumérés plus bas, appliqués à chaque requête de chaque clé de l’organisation, sans garde-fou à attribuer. Les correspondances sont toujours caviardées, jamais bloquées. Les propriétaires et les administrateurs le configurent; [] le désactive. Il se combine avec tout garde-fou de la clé : un garde-fou peut ajouter des détecteurs, des motifs ou le mode blocage, jamais retirer ceux-ci. Demander à ce point d’accès un motif personnalisé, le mode blocage ou une portée par espace de travail ou par clé renvoie 402 sur Solo et 400 sur Équipe, avec un renvoi vers les garde-fous.

curl -X PUT https://autonomousrelay.com/v1/guardrails/redaction \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY" \
  -H 'content-type: application/json' \
  -d '{"builtins": ["email", "phone", "credit-card", "secrets"]}'

builtins accepte email, phone, ssn, credit-card, ip-address, secrets et prompt-injection.

Champs

• name : obligatoire.
• allowed_models, allowed_providers : des listes. Vide signifie sans restriction.
• allowed_data_regions : un point d’accès doit fonctionner dans l’une de ces régions. Un point d’accès sans région enregistrée est exclu : le filtre échoue fermé.
• limit_usd, reset_interval (daily, weekly, monthly, lifetime) et include_byok_in_budgets : un plafond de dépenses pour ce à quoi le garde-fou est attribué. Il compte les dépenses faites avec vos propres clés au prix catalogue, sauf si include_byok_in_budgets vaut false ; voir ce que compte un plafond.
• content_filter_builtins, content_filters, filter_allowlist : voir ci-dessous.

Filtrage et caviardage du contenu

Les filtres s’appliquent aux messages de la requête après les vérifications de dépenses et avant l’acheminement : c’est donc la requête caviardée qui parvient au fournisseur. La réponse du modèle n’est pas filtrée.

Les détecteurs intégrés, nommés dans content_filter_builtins, caviardent toujours :

• email, phone, ssn, ip-address, person-name, address.
• credit-card : vérifié par l’algorithme de Luhn, pour qu’un numéro de commande à 16 chiffres ne soit pas pris pour une carte.
• secrets : 36 formats d’identifiants, dont des clés d’infonuagique, de fournisseurs d’IA, d’hébergement de code, de paiement et de messagerie, des jetons de registres de paquets, des JWT et des clés privées. Chacun est étiqueté par format, par exemple SECRET:github-pat.
• prompt-injection : des instructions qui tentent de remplacer l’invite système.

content_filters ajoute jusqu’à 100 filtres à vous, chacun {"pattern", "action", "label"}. Le motif est une expression régulière, appliquée sans tenir compte de la casse. Un motif qui pourrait revenir en arrière sans limite (quantificateurs imbriqués, références arrière, assertions) est refusé à l’enregistrement. L’action est flag (enregistrer seulement), redact ou block.

Si une correspondance bloque, la requête est refusée avec 403 guardrail_blocked, en nommant les étiquettes trouvées et jamais le texte correspondant. Sinon, chaque passage caviardé est remplacé par son étiquette entre crochets, comme [email] ou [SECRET:github-pat] ; des correspondances qui se chevauchent affichent toutes leurs étiquettes, comme dans [email|customer-id]. Un signalement ne change rien à la requête.

filter_allowlist liste des expressions, de 200 caractères au plus chacune, qu’aucun filtre ne touche, sans tenir compte de la casse. Votre propre adresse de soutien est l’exemple habituel, pour qu’elle ne soit pas caviardée de chaque requête qui la mentionne.

Chaque requête enregistre l’action et les étiquettes du filtre dans l’activité : vous voyez ce qui a été caviardé ou bloqué sans que le contenu soit conservé.

curl -X POST https://autonomousrelay.com/v1/guardrails \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY" \
  -H 'content-type: application/json' \
  -d '{"name": "client-acme",
       "allowed_providers": ["anthropic", "openai"],
       "content_filter_builtins": ["email", "secrets"],
       "content_filters": [{"pattern": "ACME-\\d{6}", "action": "block", "label": "acme-id"}],
       "filter_allowlist": ["support@acme.example"]}'

curl -X POST https://autonomousrelay.com/v1/guardrails/$GUARDRAIL_ID/assign \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY" \
  -H 'content-type: application/json' \
  -d '{"subject_type": "key", "subject_id": "'$KEY_HASH'"}'

subject_type vaut key (avec l’empreinte de la clé tirée de GET /v1/keys) ou member (avec l’identifiant d’utilisateur de la personne, tiré de GET /v1/members).

Injection de requête

Le détecteur prompt-injection recherche six types d’attaque : les instructions d’ignorer ou de remplacer le message système, les demandes de « mode développeur », les tentatives d’extraire la requête, les jetons de contrôle du modèle, la réattribution de rôle et les instructions d’envoyer des données ailleurs. Il déjoue aussi trois déguisements courants — lettres espacées, lettres mélangées à l’intérieur d’un mot, et texte caché en base64 ou en hexadécimal, qu’il décode puis analyse de nouveau — et signale la correspondance sur le passage que la requête contient réellement.

Il repose sur des motifs : rapide, prévisible et identique d’une requête à l’autre, il peut manquer une formulation nouvelle. Utilisez block pour refuser une correspondance, ou flag pour l’enregistrer le temps de voir ce qu’il détecte dans votre trafic. C’est une couche de protection, pas un substitut à la limitation de ce que les outils d’un modèle peuvent faire.

Régions de données : vérifiez avant de les exiger

allowed_data_regions échoue fermé. Un point d’accès ne convient que s’il déclare une région de déploiement de votre liste ; un point d’accès qui n’en déclare aucune est exclu, pas présumé conforme. Une politique qu’aucun point d’accès d’un modèle ne satisfait refuse toutes les requêtes vers ce modèle.

Avant d’en attribuer une, lisez deployment_region dans GET /v1/models/:author/:slug/endpoints et envoyez un vrai corps de requête à POST /v1/route/preview avec la clé à laquelle le garde-fou sera attribué : il indique quels points d’accès seraient essayés, ou pourquoi aucun ne le serait, sans contacter de fournisseur.

La conservation et l’entraînement ne sont pas des garde-fous

Un garde-fou ne peut pas exiger l’absence de conservation ni d’entraînement sur les invites, et un enforce_zdr contenant un true donne un 400. La conservation de vos invites par un fournisseur, et leur usage pour l’entraînement, relèvent de votre propre entente avec lui, et nous ne les consignons pas. Pour qu’un fournisseur avec qui vous n’avez pas une telle entente ne voie pas vos invites, laissez-le hors de allowed_providers. Voir Ce que nous conservons.

Pour l’authentification unique avec SCIM, un niveau d’acheminement privé, la conservation du grand livre pendant sept ans ou un SLA : voir Enterprise.