AdministrationHooks d'inférence

Hooks d'inférence

Envoyez chaque prompt gouverné au serveur de sécurité IA de votre organisation pour obtenir un verdict d'autorisation ou de refus avant que l'inférence ne se poursuive.

Les « Inference hooks » (hooks d'inférence) permettent à une organisation Claude Enterprise d'acheminer chaque prompt gouverné via un « AI security server » (serveur de sécurité IA), un service HTTPS exploité par l'organisation ou son fournisseur de sécurité, avant l'exécution de l'inférence. Lorsqu'un utilisateur soumet un prompt, Anthropic envoie la transcription de la conversation à votre serveur de sécurité IA et attend un verdict d'autorisation ou de refus ; une requête refusée n'atteint jamais le modèle. Les équipes de sécurité et de conformité utilisent les hooks d'inférence pour appliquer des politiques de données en ligne, et les développeurs construisent le serveur de sécurité IA qui évalue chaque requête.

Comme le hook s'exécute sur les serveurs d'Anthropic, après que la requête a quitté le client et avant que le modèle ne s'exécute, il s'applique uniformément à chaque requête gouvernée, sans rien à installer ni à déployer sur les appareils des utilisateurs.

Aujourd'hui, le seul événement de hook est prompt, qui se déclenche une fois par requête d'inférence gouvernée, avant le début de l'inférence. L'application côté réponse est prévue comme événement ultérieur.

Fonctionnement des hooks d'inférence

Un utilisateur soumet un prompt sur une surface gouvernée.
Anthropic envoie une requête HTTPS POST au point de terminaison du serveur de sécurité IA configuré par votre organisation. Le corps de la requête contient la transcription de la conversation. Une fois que votre organisation a généré son secret de signature, chaque requête est signée conformément à la spécification Standard Webhooks, afin que votre serveur puisse vérifier qu'elle provient d'Anthropic.
Votre serveur de sécurité IA évalue le contenu et répond par un verdict dans le délai de verdict configuré par votre organisation (5 secondes par défaut).
En cas de allow, l'inférence se déroule normalement. En cas de deny, la requête est rejetée et l'utilisateur voit un message de blocage par politique composé de deux parties. La première est le motif propre à la requête, fourni par votre serveur de sécurité IA dans le champ deny_reason du verdict. La seconde est un message permanent configuré par vos administrateurs (par exemple, qui contacter ou où demander une exception). Si vos administrateurs n'en ont pas configuré, un message par défaut intégré invite l'utilisateur à les contacter. Chaque refus est également enregistré dans l'Activity Feed (fil d'activité) de votre organisation.

Le diagramme suivant retrace un exemple : une requête Cowork dans laquelle Claude appelle également un outil O365. Il illustre les parties du flux qui sont interceptées par un hook. Les points interceptés correspondent aux étapes 1 et 6 du diagramme, où le prompt arrive et où le résultat de l'outil revient. Chacun donne lieu à l'échange de validation avec votre serveur de sécurité IA, illustré aux étapes 2–3 et 7–8.

Diagramme de flux : le « AI security server » (serveur de sécurité IA) valide à la fois le prompt et le résultat de l'outil avant que l'inférence ne se poursuive

Un verdict est un petit objet JSON : {"action": "allow"} laisse la requête se poursuivre, et un refus contient le motif destiné à l'utilisateur. Pour le schéma complet du verdict, consultez Renvoyer un verdict.

Votre serveur de sécurité IA voit ce que voit l'utilisateur : le texte de la transcription, les appels d'outils et leurs résultats, ainsi que le texte extrait des pièces jointes. Il ne reçoit jamais les octets bruts des fichiers ou des images, les invites système ni le contexte interne d'Anthropic.

Le système des hooks d'inférence ne conserve pas sa propre copie du contenu des prompts ou des réponses. Il stocke uniquement la configuration de votre hook et des métadonnées sur l'activité du hook, telles que les verdicts, les horodatages et les identifiants de requête. Le produit Claude que vous utilisez stocke les prompts et les réponses selon ses propres règles de conservation des données, que les hooks soient activés ou non. Par exemple, un message bloqué par un hook sur claude.ai reste dans la conversation.

Votre serveur de sécurité IA peut être injoignable, renvoyer une erreur ou ne pas répondre dans le délai imparti. Dans ces cas, le paramètre de gestion des défaillances de votre organisation détermine le résultat : bloquer la requête, ou la laisser se poursuivre sans inspection. Des défaillances persistantes imputables à votre serveur déclenchent un « circuit breaker » (disjoncteur). Anthropic cesse alors de contacter votre serveur et applique votre paramètre de gestion des défaillances à chaque requête. Le disjoncteur se réinitialise automatiquement dès qu'Anthropic détecte que votre serveur renvoie de nouveau des verdicts ; consultez Disjoncteur.

Vous pouvez déployer le contrôle à votre rythme, afin que personne ne soit bloqué dès le premier jour. Trois mécanismes sont disponibles :

Le « shadow mode » (mode fantôme) observe les verdicts sur le trafic réel sans rien bloquer.
Un « rollout percentage » (pourcentage de déploiement) inspecte une fraction choisie des requêtes.
Les exclusions exemptent entièrement les membres des rôles choisis.

Consultez Configurer les Inference hooks.

Pour les schémas complets des requêtes et des réponses, la vérification des signatures et les détails opérationnels, consultez Développer une intégration.

Poursuivre une conversation après une requête refusée

Chaque requête inclut l'intégralité de la conversation, de sorte qu'un message refusé est renvoyé avec chaque message ultérieur. Si votre serveur de sécurité IA évalue l'intégralité de la transcription, il refuse également ces requêtes. Pour poursuivre, l'utilisateur retire le contenu refusé de ce que l'application envoie ensuite, y compris tout fichier que Claude relirait.

Les étapes dépendent de l'application :

claude.ai, y compris Claude Desktop et les applications mobiles. L'utilisateur modifie le message refusé, ou un message antérieur, plutôt que d'envoyer une copie corrigée sous forme de nouveau message. Sur le web et dans Claude Desktop, la modification renvoie les pièces jointes du message, sauf si l'utilisateur les supprime. Une nouvelle conversation fonctionne également.
Claude Code. L'utilisateur exécute /rewind et sélectionne le prompt qui a introduit le contenu en premier. Si cela lui est demandé, il sélectionne Restore conversation, puis modifie ou efface le prompt qui revient dans le champ de saisie. /clear permet de recommencer à zéro. Consultez Checkpointing.
Cowork. L'utilisateur modifie le message refusé s'il s'agit de son dernier message. La modification renvoie les fichiers joints, et Restart from here renvoie l'intégralité du message sans modification. Si le contenu se trouve dans un fichier ou dans un message antérieur, l'utilisateur sélectionne New task.
Claude Tag. Dans Slack, l'utilisateur modifie d'abord le message refusé, ou le supprime s'il s'agit d'une réponse. Il envoie ensuite @Claude !restart seul à l'endroit où Claude répondait : dans ce fil, ou au niveau principal du canal. La nouvelle session relit les messages encore présents dans Slack, c'est pourquoi la modification ou la suppression doit intervenir en premier. Consultez la commande !restart.

Cas d'utilisation

« Data loss prevention » (prévention des pertes de données), ou DLP. Transmettez la transcription à votre scanner DLP et refusez les prompts contenant des informations réglementées ou classifiées. Il s'agit du déploiement le plus courant.
Archivage des transcriptions en temps réel. Archivez chaque transcription à son arrivée et renvoyez toujours allow, comme alternative en mode push à l'interrogation de la Compliance API.
Télémétrie des prompts. Mesurez la façon dont votre organisation utilise Claude, au moment même de l'utilisation.
Moteurs de politiques. Appliquez vos propres règles avant l'inférence : listes d'autorisation de modèles, restrictions limitées à un projet ou contrôles des heures de travail.

Limitations actuelles

Les pièces jointes sont représentées par des métadonnées et du texte extrait. Les octets bruts des fichiers et des images ne sont jamais envoyés, de sorte que le contenu uniquement sous forme d'image (par exemple, une capture d'écran d'un document) n'est pas inspecté.
Les verdicts sont soit une autorisation, soit un refus. La réécriture ou la rédaction d'un prompt n'est pas prise en charge.
Les organisations de plateforme (accès API via la Claude Platform) sont hors du périmètre.

Disponibilité

Les Inference hooks sont disponibles pour les organisations Claude Enterprise. Leur configuration nécessite l'autorisation organization:manage, que seuls les rôles Owner et Primary owner détiennent.

Un seul hook gouverne les conversations dans les sessions claude.ai, Cowork, Claude Code et Claude Tag de votre organisation Claude Enterprise, qu'elles s'exécutent sur le web, dans les applications de bureau ou mobiles, dans la CLI ou dans Slack. Les Inference hooks ne sont pas disponibles sur Amazon Bedrock ni sur Google Cloud.

Les requêtes gouvernées sont les requêtes d'inférence qui sous-tendent la conversation de l'utilisateur. Les requêtes annexes, telles que la génération du titre de la conversation, ne sont pas envoyées à votre point de terminaison, et les invites système ainsi que les définitions d'outils ne sont jamais incluses dans ce qui est envoyé. Le mode vocal n'est pas couvert.