Claude Enterprise : contrôler un export client avec Inference hooks

Un analyste demande à Claude de résumer un export client. La demande peut être légitime, alors que le fichier contient des coordonnées inutiles au résumé. Dans une autre conversation, le modèle peut recevoir un extrait autorisé et proposer de le transmettre à un outil externe. L’équipe sécurité doit pouvoir distinguer ces deux décisions.

Le point sécurité Claude Enterprise du 5 novembre présente les deux contrôles d’inférence comme disponibles en général. L’annonce initiale des Inference hooks, en août, décrivait notamment un contrôle des résultats d’outils avant leur retour au modèle. Les notes du 20 octobre actent la sortie de bêta des hooks. Le contrôle avant exécution est explicitement présenté comme disponible dans le billet du 5 novembre. Sa première date de disponibilité n’est pas précisée.

Deux décisions sur le même export

Le hook est une requête HTTPS envoyée par Anthropic au service de sécurité que votre organisation configure. Ce service applique vos règles de prévention des fuites de données, ou DLP. Pour une requête couverte, Anthropic transmet les éléments à contrôler avant de poursuivre. Le serveur répond allow ou deny.

Avant le modèle, l’événement prompt transmet la conversation jusqu’à la demande d’inférence. Il peut inclure les tours précédents, le texte extrait des pièces jointes et des résultats d’outils textuels déjà présents. Pour l’export client, une règle peut refuser une demande dont le texte transmis contient un marqueur réservé aux exports nominatifs. Après un refus appliqué à ce stade, la demande n’est pas soumise au modèle. Le client a déjà envoyé la demande à Anthropic. Sur claude.ai, le message bloqué reste dans la conversation selon les règles de conservation du produit. Périmètre du hook · Contenu de l’événement.

Avant l’outil, l’événement tool_call intervient lorsque la réponse contient des appels couverts et que la validation des appels est activée. Le serveur reçoit le dernier message assistant et les arguments des appels concernés. Dans le pilote, le premier contrôle accepte une synthèse fictive autorisée. Le second refuse une destination extérieure non approuvée si elle apparaît dans les arguments du connecteur de test. Un seul verdict s’applique au lot d’appels de l’événement. Un refus arrête leur exécution et met fin à la réponse, sans reprendre le texte déjà affiché. Certaines actions intégrées peuvent être omises. Vérifiez que l’outil choisi produit bien cet événement dans votre environnement. Contrat de l’événement outil.

Dans les deux cas, le serveur rend un verdict. Le hook ne réécrit pas la demande. Si le besoin consiste à enlever les coordonnées, préparez un export agrégé ou expurgé à la source. Si le même export existe en capture d’écran, le serveur reçoit au mieux des métadonnées et le texte extrait quand il existe. Les pixels et les octets originaux restent hors de ce contrôle. Une politique sur le texte peut donc refuser les exports marqués et manquer la capture du même fichier. Limites documentées.

Refus de politique et panne du service

Pour refuser une opération, le service répond HTTP 200 avec un verdict deny. Un HTTP 403, un délai dépassé ou une réponse illisible déclenchent le comportement de panne configuré. Si l’organisation autorise la poursuite sur erreur, une requête peut passer sans inspection. Si elle choisit le blocage sur erreur, la panne peut empêcher des demandes légitimes. Anthropic documente un délai par défaut de cinq secondes qui couvre l’échange complet, ainsi qu’un coupe-circuit en cas de défaillances persistantes attribuées au serveur. Configuration · Comportement du serveur.

Le contrôle ajoute un aller-retour. La requête peut aussi grossir avec le fil et les pièces jointes. Un proxy qui refuse un corps trop volumineux déclenche une panne du contrôle. Relevez séparément les verdicts, les erreurs de transport, les délais et les requêtes hors périmètre. Un faible nombre de refus peut refléter une couverture partielle ou un endpoint indisponible. Taille des requêtes · Suivi du service.

Une recette sur un connecteur de test

Le pilote est documentaire. Préparez dans un environnement de test une demande neutre, un export textuel fictif avec un marqueur de refus et une destination de test sans envoi réel. Le connecteur doit uniquement journaliser les appels reçus. Donnez à chaque tentative un identifiant de test à transmettre en argument de l’outil. Rejouez chaque cas dans une nouvelle conversation. Le texte marqué d’un tour précédent pourrait sinon provoquer un refus avant même le contrôle que vous cherchez à exercer.

1. Cadrez le périmètre. Un Owner ou Primary Owner configure l’endpoint HTTPS public sur le port 443, génère le secret, puis vérifie l’authenticité des requêtes signées côté serveur. Testez la connexion avec la demande synthétique de la console. Le test ne vérifie ni la règle métier ni le déclenchement sur l’outil choisi.
2. Observez les décisions. En mode shadow, avec validation des outils activée, cherchez les événements attendus sur le rôle de test. Les verdicts ne bloquent rien. Avec une inspection limitée à certains rôles, utilisez un membre configuré en rôle personnalisé sélectionné. Un compte Owner qui administre le pilote reste hors de cette sélection.
3. Validez l’effet en environnement de test. Passez en application des verdicts sur le périmètre de recette, inspectez 100 % des demandes éligibles de ce périmètre et attendez la propagation du réglage. Pour le texte marqué, attendez un refus avant génération. Pour la destination non approuvée, rapprochez le même identifiant de test dans les arguments de l’événement outil, le verdict HTTP 200 avec deny, le blocage de politique affiché dans Claude et l’absence d’appel reçu par le connecteur pour cet identifiant. Les événements prompt et outil ont des identifiants de requête distincts. Faites un essai témoin avec la destination approuvée et vérifiez un appel journalisé pour son identifiant, après confirmation dans Claude si elle est demandée. Si le modèle ne propose aucun appel, marquez le cas comme non exercé.
4. Provoquez une erreur contrôlée. Faites répondre HTTP 503 une seule fois par mode pour un prompt neutre identifié. Vérifiez le mode actif, la trace HTTP côté serveur et le résultat dans Claude. Un blocage sur panne est distinct d’un verdict de politique. Restaurez une réponse valide et rejouez un témoin autorisé pour vérifier la reprise.

Grille de recette à renseigner · Configuration Anthropic.

Où placer la règle

Inference hooks s’adresse aux organisations Claude Enterprise. La documentation couvre notamment claude.ai, Cowork et Claude Code sur les surfaces gouvernées. Les organisations Claude Platform qui utilisent l’API, Amazon Bedrock et Google Cloud sont hors périmètre. Pour une application qui appelle directement l’API, placez les règles dans son propre chemin de requête et dans les autorisations des outils. Une règle de destination au niveau du connecteur reste utile dans tous les cas où une action sort de votre environnement. Disponibilité et limites.

La page de prix affiche 20 USD par siège et par mois, facturés à l’année, avec un minimum de 20 sièges. Ce tarif affiché représente 4 800 USD par an avant usage et taxes. L’usage est facturé aux tarifs API et les devis peuvent varier. Chiffrez aussi votre service de verdict et l’éventuelle licence DLP. L’hébergement de cet endpoint est une décision distincte de la localisation du traitement Claude. Vérifiez le contrat et les journaux du fournisseur de sécurité avant de transférer des conversations réelles. Tarifs Anthropic.

Pour décider du déploiement, partez d’un flux que vous pouvez observer aux deux points de contrôle. Mesurez la part des événements attendus réellement reçus, la latence et les refus justifiés sur la recette. Si votre exigence principale est de ne jamais transmettre le fichier original à Anthropic, filtrez ce fichier avant l’envoi, dans la source ou dans l’application.