IDENTIFICATION DES APPELANTS MCP

Découvrez qui appelle votre MCP server

Votre MCP server expose des outils à des clients IA que vous ne contrôlez pas. Proof of Actor vous indique ce qui se trouve derrière chaque appel, quelles preuves l'étayent, et vous permet de définir des politiques par outil.

Obtenir un accès anticipé Découvrir le fonctionnement

Par Toshendra SharmaFondateur et CEO, AgentCredia · Updated November 13, 2026

Vos outils sont ouverts à des appelants que vous ne pouvez pas voir

Un MCP server rend votre produit utilisable par des clients IA. Il expose des outils, des ressources et des prompts que des assistants et des agents peuvent découvrir et appeler, en utilisant des messages JSON-RPC 2.0 entre hôtes, clients et serveurs, comme décrit dans la spécification Model Context Protocol. C'est précisément pour cela que les équipes les construisent: ils placent votre produit dans les workflows où les agents IA travaillent déjà.

Cela signifie aussi que votre server reçoit des appels de clients que vous n'avez pas créés et que vous ne pouvez pas observer directement. Un seul outil peut être invoqué par un développeur en test local, par un assistant de bureau agissant pour une personne connectée, par un agent autonome exécutant une longue tâche pendant la nuit, ou par quelque chose qui sonde votre server à la recherche de faiblesses. Le protocole vous indique quel outil a été appelé et avec quels arguments. À lui seul, il ne vous dit pas quel type d'acteur se trouve derrière l'appel ni quel niveau de confiance lui accorder.

L'identification de l'appelant d'un MCP server comble cette lacune. Proof of Actor ajoute à chaque appel d'outil un résultat d'acteur étayé par des preuves, afin que votre server puisse prendre des décisions éclairées sur qui obtient quoi. Pour aller plus loin sur le problème, lisez who is calling your MCP server, et consultez le cas d'usage MCP servers use case pour voir comment les équipes l'appliquent.

Note sur les termes. "Caller identity" a aussi un sens bien connu dans l'infrastructure cloud. AWS STS GetCallerIdentity, par exemple, renvoie des détails sur l'utilisateur ou le rôle IAM dont les informations d'identification sont utilisées pour appeler l'opération. Cela répond à la question de savoir quelle information d'identification cloud a effectué un appel. L'identification de l'appelant d'un MCP server sur cette page répond à une question différente: quel type d'acteur, Human, Human + AI, Agent ou Unknown, se trouve derrière un appel d'outil vers votre MCP server, et quelles preuves étayent cette réponse.

Ce qui rend les appelants MCP différents

Les appelants MCP diffèrent des visiteurs d'un navigateur et des clients API traditionnels d'une manière qui compte pour les politiques.

Ils sont presque toujours automatisés. La question est moins "humain ou bot ?" que "quel agent, agissant comment, avec quelles preuves ?"
Ils agissent souvent pour une personne. Un assistant peut appeler votre outil parce qu'un utilisateur le lui a demandé, ou bien agir de manière autonome. Ces cas méritent un traitement différent.
Ils se décrivent eux-mêmes. La spécification de cycle de vie MCP prévoit que le client envoie un objet clientInfo avec un nom et une version dans sa requête initialize. Cette déclaration est un contexte utile, mais une déclaration n'est pas une preuve.
Les outils varient énormément en impact. Un outil de recherche et un outil qui supprime des enregistrements ne devraient pas partager une seule politique.

Une bonne identification des appelants MCP doit respecter ces quatre points.

Comment Proof of Actor identifie les appelants MCP

Signaux provenant de votre server

Votre intégration MCP transmet à Proof of Actor le contexte disponible pour chaque appel: les détails déclarés par le client, le contexte de transport et de requête, toutes les signatures cryptographiques de requête fournies par le client, comme les HTTP Message Signatures définies dans RFC 9421, ainsi que l'outil appelé. Chaque signal est étiqueté avec son origine.

Classification avec une base

Proof of Actor renvoie l'une des quatre classes, Human, Human + AI, Agent ou Unknown, ainsi que la base du résultat:

verified lorsqu'une vérification cryptographique, comme une signature de requête vérifiée par rapport à une clé publiée, a réussi;
declared lorsque le client ou votre application l'a indiqué, comme le nom du client dans la session;
inferred lorsque le résultat repose sur des schémas observés dans les appels;
unknown lorsque les preuves ne permettent pas d'établir une détermination.

Un nom de client déclaré n'est jamais présenté comme une vérification. Lorsque les preuves sont faibles, le résultat est Unknown plutôt qu'une supposition trop assurée, et votre server sait exactement avec quoi il travaille.

Un résultat que vos outils peuvent utiliser

Le résultat d'acteur arrive avec l'appel d'outil, prêt à être utilisé par la logique de votre server. En mode observation, vous l'enregistrez. Quand vous êtes prêt, vos politiques au niveau de l'outil s'appliquent.

Ce que votre équipe obtient: Detect, Understand, Route

Detect

Capturez les preuves d'appel disponibles sur chaque appel d'outil et conservez séparées les preuves verified, declared et inferred.

Understand

Voyez quels clients appellent quels outils, à quelle fréquence, avec quelles preuves, et comment cela évolue dans le temps. Repérez les outils qui attirent surtout des appelants Unknown, les clients qui changent de comportement et la part des appels portant une identité vérifiable.

Route

Écrivez des politiques par outil et par niveau de risque. Schémas courants:

Outils à faible impact comme la recherche ou les consultations en lecture seule: autorisez largement, avec une limite de débit standard.
Outils à impact modéré comme la création de brouillons: autorisez les appelants verified et declared, limitez le débit des Unknown.
Outils à fort impact comme la suppression de données, la modification de paramètres ou l'envoi de messages au nom d'un utilisateur: exigez votre autorisation la plus forte, et ajoutez une confirmation ou une revue lorsque l'appelant est Unknown ou agit de manière autonome.

Le guide sur protecting sensitive actions without blocking agents montre comment concevoir ces niveaux.

Les preuves d'identité, les informations d'identification et l'autorisation sont distinctes

La sécurité MCP fonctionne mieux lorsque trois questions restent séparées:

Preuve d'identité: quel type de client appelle, et qu'est-ce qui le prouve ? Proof of Actor fournit cela.
Informations d'identification: avec quel compte ou quel token cet appel est-il effectué ? L'authentification de votre MCP server fournit cela. La spécification d'autorisation MCP rend l'autorisation facultative et, pour les transports basés sur HTTP, la fonde sur OAuth 2.1, le MCP server agissant comme un resource server qui valide les access tokens.
Autorisation: cet appelant peut-il utiliser cet outil, avec ces arguments, pour ce compte ? Votre modèle d'autorisations fournit cela.

Un client reconnu n'est pas automatiquement un client autorisé. Une signature valide ne montre pas que la personne derrière la session a délégué l'autorité pour cette action précise. Lisez-en plus sur delegated authority et agent authorization. Proof of Actor donne à votre server un meilleur contexte pour la première question afin que vos réponses aux deuxième et troisième soient mieux informées.

Pourquoi ne pas simplement faire confiance au nom du client ?

Parce que n'importe quel client peut envoyer n'importe quel nom. Traiter un nom déclaré comme une preuve ouvre la porte à l'imitation: un client malveillant n'a qu'à copier le nom d'un assistant populaire. Proof of Actor enregistre le nom comme preuve déclarée, le combine avec toute preuve plus solide disponible et vous indique la base utilisée. Votre politique peut alors accorder plus de marge aux appelants vérifiés qu'aux appelants qui se sont seulement déclarés, et appliquer votre solution de repli Unknown lorsque ni l'un ni l'autre ne s'applique.

Commencez en mode observation

L'installation de Proof of Actor dans votre MCP server ne change pas la manière dont les outils répondent. Les résultats sont enregistrés afin que vous puissiez voir qui appelle vos outils, quelle est la force des preuves, et où des politiques seraient utiles. Quand vous êtes sûr de vous, activez une politique sur un seul outil à fort impact, observez les résultats, puis élargissez. How It Works couvre le flux complet, et Detection & Limitations explique ce que chaque type de preuve peut et ne peut pas établir.

Conçu pour les équipes qui exploitent des MCP servers et des APIs

Proof of Actor s'intègre à votre server à côté de votre authentification, de votre limitation de débit et de votre journalisation existantes. Les intégrations sont réalisées de façon pratique avec chaque équipe fondatrice, afin que la configuration corresponde à votre transport, votre hébergement et votre conception d'outil. Les cas d'usage MCP Servers et APIs montrent comment la même approche s'applique à travers vos outils et votre API.

Questions à poser pour chaque outil que vous exposez

Avant d'écrire des politiques au niveau de l'outil, il est utile de passer en revue chaque outil exposé par votre MCP server à l'aide d'une courte liste de contrôle:

Que peut modifier cet outil ? Les outils en lecture seule et les outils qui modifient des données, envoient des messages ou ont un impact sur la facturation méritent un traitement différent.
À qui est-il destiné ? Certains outils existent pour des assistants agissant au nom d'une personne connectée; d'autres pour des workflows autonomes. L'appelant attendu façonne la bonne politique.
Quel serait le coût d'une erreur ? Un mauvais résultat de recherche coûte peu. Une mauvaise suppression, non. Associez chaque outil à un niveau de risque.
Quelle preuve devrait être exigée ? Décidez si un client déclaré suffit, ou si l'outil doit nécessiter une identité vérifiée plus votre autorisation la plus forte.
Que se passe-t-il en cas de Unknown ? Choisissez une solution de repli explicite pour chaque outil: autoriser, limiter le débit, demander à l'utilisateur de confirmer, ou orienter vers une revue.
Comment saurez-vous que cela fonctionne ? Décidez quels résultats vous surveillerez en mode observation avant d'appliquer quoi que ce soit.

Répondre à ces questions une fois par outil transforme l'identification de l'appelant en règles claires et testables, et facilite l'explication du comportement de votre server aux clients qui s'y intègrent.

Rejoignez le programme fondateur pour développeurs

Proof of Actor est en private beta. Les équipes fondatrices sélectionnées peuvent recevoir jusqu'à 12 mois d'accès gratuit, dans les limites d'utilisation convenues, avec l'aide directe de nos ingénieurs pendant que vous concevez des politiques au niveau de l'outil.

Si vous exploitez un MCP server et souhaitez savoir qui l'appelle, demandez un accès anticipé. Parlez-nous de votre server, des outils que vous exposez et des appels qui comptent le plus pour vous.

Sources

Spécification Model Context Protocol (2025-06-18), modelcontextprotocol.io.
MCP lifecycle: initialization and clientInfo, modelcontextprotocol.io.
MCP authorization, modelcontextprotocol.io.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
AWS STS GetCallerIdentity API reference, Amazon Web Services.

POUR LES DÉVELOPPEURS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent ou Unknown.
basis: Niveau de solidité des preuves : Verified, Declared, Inferred ou Unknown.
evidence: Les signaux derrière le résultat, pour que votre équipe puisse voir pourquoi.

Commencez en mode observation : enregistrez les résultats à côté de vos logs et ne changez rien tant que vous n'avez pas choisi une politique. Lire le guide d'intégration Node.js

Questions fréquentes

Pourquoi un MCP server a-t-il besoin d'une identification de l'appelant ?

Les MCP servers exposent des outils à des clients IA qui agissent au nom de personnes ou fonctionnent de manière autonome. Savoir quel type d'appelant se trouve derrière un appel d'outil vous permet d'autoriser librement les outils à faible impact et d'exiger davantage pour les outils à fort impact.

Le nom du client dans une session MCP est-il une vérification ?

Non. Un nom de client est une déclaration faite par le client. Proof of Actor l'enregistre comme preuve déclarée et la distingue de l'identité vérifiée cryptographiquement.

L'identification de l'appelant remplace-t-elle l'autorisation MCP ?

Non. Les preuves d'identité de l'appelant, les informations d'identification utilisées et ce que l'appelant est autorisé à faire sont des questions distinctes. Proof of Actor ajoute du contexte à la première et laisse l'autorisation à votre server.

Proof of Actor bloquera-t-il les appels d'outil ?

Seulement si vos politiques le prévoient. Chaque intégration commence en mode observation, puis vous activez les politiques au niveau de l'outil lorsque vous êtes prêt.

Comment puis-je l'essayer ?

Demandez un accès anticipé. Les équipes fondatrices sélectionnées peuvent bénéficier de jusqu'à 12 mois gratuits dans les limites d'utilisation convenues, avec un accompagnement pratique à l'intégration.

Savoir qui utilise votre app.

Private beta pour un petit groupe de développeurs fondateurs.

Obtenir un accès anticipé Voir les prix

Vous préférez en parler d'abord ? Parler aux fondateurs