Anthropic distingue les clients dans son API. Les alertes automatiques ne sont pas encore actives
Un identifiant rattache une requête au client final d’une plateforme. L’attribution et les alertes gardent des conditions différentes selon l’intégration.
Une plateforme peut envoyer les demandes de nombreux clients à Claude sous une même organisation. Une mesure de sécurité liée à un client risque alors d’avoir une portée plus large. Anthropic a annoncé le 20 octobre des profils pour rattacher chaque requête à son client final. L’objectif est de mieux cibler les restrictions. Les alertes automatiques associées gardent toutefois une limite importante. Leur livraison n’est pas encore active selon la documentation consultée.
À quel problème répond un profil client
Les notes de version de Claude Platform présentent les user profiles comme un mécanisme d’attribution des requêtes. Le public concerné est celui des plateformes et des passerelles qui utilisent l’API pour leurs propres clients.
Le guide des profils explique qu’une restriction ou un bannissement peut alors viser un client final. Sans profil associé à la requête, une mesure peut s’appliquer à l’organisation qui envoie le trafic. Le mécanisme ne constitue donc pas un réglage de personnalisation dans l’application grand public Claude.
La plateforme crée un profil puis conserve l’identifiant renvoyé. Elle joint cet identifiant aux requêtes effectuées pour ce client. Un nom enregistré une seule fois ne suffit pas si les appels suivants ne portent pas la bonne attribution.
Une personne et une société ne sont pas le même périmètre
Le guide distingue deux cas. Une application peut créer un profil pour chacun de ses utilisateurs inscrits. Une entreprise qui revend un accès à l’API peut créer un profil pour chaque société cliente. Dans ce second cas, le profil désigne la société et non chaque personne qui y travaille.
Anthropic précise que ces profils ne sont pas facturés et ne changent pas les prix de l’API. Ils contiennent les informations fournies par la plateforme et certains statuts attribués par Anthropic. Ils ne contiennent pas le texte des conversations.
Les champs descriptifs restent facultatifs. Anthropic ne vérifie pas lui-même les informations fournies. L’existence d’un identifiant ne doit donc pas être présentée comme une certification d’identité du client.
Les intégrations ne vérifient pas toutes la même chose
La documentation différencie les plateformes capables de créer les profils et celles qui peuvent seulement joindre un identifiant à l’inférence. Elle distingue notamment les déploiements Microsoft Foundry hébergés par Anthropic de ceux hébergés sur Azure.
Autre nuance utile, Claude dans Amazon Bedrock et Google Cloud vérifient le format de l’identifiant sans rechercher le profil de la même manière que les plateformes décrites comme le vérifiant à chaque requête. Une réponse réussie ne confirme donc pas à elle seule que l’identifiant correspond au bon profil. Les conditions de liaison des comptes restent à examiner pour l’intégration retenue.
Les points d’entrée des alertes existent avant leur livraison
Anthropic annonce aussi des webhooks d’organisation en bêta. Ce sont des points d’entrée qui doivent recevoir un événement lorsqu’un profil est restreint ou banni. Un second événement doit signaler la fin de la mesure.
Mais le guide des webhooks d’organisation précise que la livraison des événements n’est pas active. Il est possible d’enregistrer des points d’entrée et de préparer le traitement du format annoncé. Il ne faut pas en déduire que des alertes arrivent déjà.
L’accès à cette bêta doit être activé pour l’organisation. Des conditions d’éligibilité et de droits d’administration s’appliquent. Le guide explique aussi que les futurs événements pourront arriver en retard ou dans un ordre différent. Le statut courant du profil devra rester la référence pour interpréter la situation.
Attribuer une requête ne remplace pas les autres contrôles
Cette nouveauté porte sur le rattachement du trafic à un client et les mesures de sécurité du fournisseur. Elle ne remplace pas les autorisations des outils auxquels un agent accède. Notre article sur les workflows de Claude Managed Agents explique une autre partie de cette organisation.
Je retiens surtout la précision du périmètre. Savoir quel client a envoyé une demande peut éviter de traiter toute une plateforme comme un seul utilisateur. Mais une supervision utile doit aussi distinguer les fonctions disponibles des alertes qu’on peut seulement préparer aujourd’hui.