Anthropic Intègre la Prévention des Pertes de Données en Ligne dans Claude Enterprise

Anthropic a lancé des hooks d’inférence le 5 août 2026, une fonctionnalité bêta pour Claude Enterprise qui route chaque invite de l’employé via le serveur de sécurité de l’organisation pour un verdict d’autorisation ou de refus avant que le modèle ne le voie. Le système, décrit dans l’annonce d’Anthropic, étend le type de prévention des pertes de données en ligne que les équipes de sécurité exécutent déjà sur les e-mails et le trafic Web aux sessions de chat, de Claude Code et de Claude Cowork, avec une configuration unique au niveau de l’organisation.

Jusqu’à présent, la seule mise en œuvre native d’Anthropic vivait dans les hooks client-side de Claude Code, qui s’exécutent sur la machine de l’utilisateur. Les hooks d’inférence déplacent le point de contrôle sur les serveurs d’Anthropic, après qu’une demande quitte le client et avant que l’inférence ne s’exécute, de sorte qu’un seul contrôle couvre toutes les surfaces réglementées sans rien installer sur les appareils des utilisateurs.

Comment fonctionne le chemin d’exécution

Lorsqu’un utilisateur sur une surface réglementée soumet une invite, Anthropic envoie la transcription de la conversation au serveur de sécurité de l’organisation via une connexion signée et attend un verdict. En cas d’autorisation, l’inférence se poursuit. En cas de refus, la demande n’atteint jamais le modèle, et l’utilisateur voit un message bloqué par la stratégie construit à partir de la raison pour laquelle le serveur de sécurité a retourné un refus, ainsi qu’un avis permanent que les administrateurs de l’organisation configurent, comme l’endroit où demander une exception. Chaque refus atterrit dans le fil d’activité de l’organisation.

La même inspection s’exécute sur les appels d’outils. Lorsque Claude invoque un outil, y compris les outils connectés via des connecteurs MCP, des compétences et des plugins, la réponse de l’outil est vérifiée avant de retourner au modèle. Cela ferme l’autre moitié du problème de déplacement de données : le matériel sensible qui entre dans une conversation à partir d’un système connecté, et non seulement ce que l’employé colle. Les réponses des outils sont devenues une surface d’attaque surveillée pour cette raison exacte, puisque elles transportent des données dans le contexte du modèle à partir de l’extérieur du périmètre de l’organisation, comme la recherche récente sur les échappatoires de sandbox d’agent l’a souligné.

Le verdict lui-même est un petit objet JSON, et le serveur doit répondre dans un délai d’attente configurable, de cinq secondes par défaut, selon la documentation du produit. Les demandes sont signées sous la spécification Standard Webhooks une fois que l’organisation génère un secret de signature, de sorte que le serveur de sécurité puisse vérifier que le trafic provient réellement d’Anthropic.

Le serveur de sécurité voit le texte de la transcription, les appels d’outils et leurs résultats, ainsi que le texte extrait des pièces jointes. Il n’a jamais reçu de fichiers ou d’octets d’images bruts, de invites de système, ou de définitions d’outils. Les demandes annexes comme la génération de titres de conversation sautent la fin de l’endpoint, et le mode vocal n’est pas couvert.

Conçu pour s’intégrer à la pile DLP existante

Anthropic ne vend pas le moteur de scan. Le protocole est basé sur les webhooks avec un schéma publié, et l’annonce nomme Netskope, Palo Alto Networks (PANW ), Proofpoint et Zscaler comme destinations que les organisations peuvent pointer l’hook, aux côtés des serveurs internes. Les fournisseurs de sécurité peuvent construire des intégrations contre le schéma documenté et ont des clients mutuels qui routent les verdicts vers leurs plateformes. L’architecture inverse le déploiement DLP habituel : au lieu que l’appliance du fournisseur poursuive le trafic AI sur le réseau, le fournisseur d’AI appelle l’API de verdict du fournisseur sur chaque demande. Check Point a pris l’approche miroir quelques jours plus tôt, en déplaçant l’inspection des invites d’IA dans ses pare-feu de sorte que la couche réseau intercepte le trafic lié au modèle.

Les contrôles de déploiement reconnaissent que le blocage des employés le premier jour est la façon dont les programmes DLP meurent. Le mode d’ombre observe les verdicts sur le trafic en direct sans bloquer quoi que ce soit, un pourcentage de déploiement inspecte une fraction choisie de demandes, et les exclusions exemptent les membres de rôles choisis entièrement. Si le serveur de sécurité est injoignable, se produit une erreur, ou dépasse le délai d’attente, l’organisation choisit la posture de défaillance : bloquer la demande ou la laisser passer sans inspection.

La documentation liste la DLP comme le déploiement le plus courant, mais décrit trois autres : l’archivage de transcript en temps réel comme alternative push pour l’API de conformité d’Anthropic, la télémétrie d’invite capturée au moment de l’utilisation, et les moteurs de stratégie personnalisés qui mettent en œuvre des règles comme des listes d’autorisation de modèle ou des restrictions à portée de projet avant l’inférence.

Ce que la bêta ne couvre pas

Les limites énoncées dans la documentation définissent l’enveloppe actuelle. Les verdicts sont binaires : le serveur peut autoriser ou refuser une invite, mais ne peut pas la réécrire ou la réviser. Les pièces jointes arrivent sous forme de métadonnées et de texte extrait, de sorte que le contenu d’image uniquement, par exemple une capture d’écran d’un document, n’est pas inspecté. L’événement de hook unique au lancement se déclenche sur l’invite avant l’inférence ; la mise en œuvre de l’inspection du côté de la réponse, qui vérifie ce que le modèle retourne, est prévue comme un événement ultérieur. Et la fonctionnalité ne régit que les surfaces de Claude Enterprise : l’accès à l’API via la plateforme Claude est hors de portée, et les organisations qui exécutent Claude sur Amazon Bedrock ou Google Cloud n’obtiennent rien.

Cela laisse le concours d’inspection de points avec deux modèles en direct. Les contrôles de la couche réseau voient tout ce qui traverse le fil, mais sont tendus contre le trafic AI chiffré et dispersé ; les hooks du côté du fournisseur comme celui-ci voient exactement ce que le modèle verrait, mais uniquement à l’intérieur du périmètre d’un seul fournisseur. La documentation limite les hooks aux surfaces de Claude Enterprise et exclut Bedrock et Google Cloud, tandis que l’approche de pare-feu de Check Point inspecte le trafic à la couche réseau.

Les hooks d’inférence sont disponibles en bêta pour les organisations Claude Enterprise, avec une configuration verrouillée derrière les rôles d’administration de l’organisation. L’événement d’invite est actif sur les sessions claude.ai, Cowork et Claude Code sur le Web, le bureau et la CLI, et la documentation d’Anthropic présente la mise en œuvre de l’inspection du côté de la réponse comme le prochain point de contrôle à arriver.