Connaître votre agent IA : lier un humain à une action d'IA

Points clés à retenir

• Le concept "Know Your Agent" (KYA) ne se résout pas en nommant un agent. Le contrôle durable est une chaîne de délégation qui relie une personne authentifiée, un client enregistré, des portées accordées, un contexte organisationnel et chaque action qui en résulte.
• Le point de terminaison du protocole de contexte de modèle (MCP) hébergé de Didit expose 115 outils dans 19 domaines et utilise Open Authorization (OAuth) 2.1 avec Proof Key for Code Exchange (PKCE) et l'enregistrement dynamique de clients.
• Le MCP agit en tant qu'utilisateur Didit connecté. Il hérite du rôle organisationnel de cet utilisateur, de sorte qu'un agent connecté ne peut pas obtenir des permissions que la personne n'avait pas déjà.
• Une clé d'application stockée dans un fichier de configuration prouve la possession d'une accréditation, et non quel humain a délégué une action particulière. Les clés partagées fusionnent plusieurs opérateurs et agents en une seule identité d'application.
• La responsabilité exige à la fois l'application et la preuve : des jetons délimités et des vérifications de rôle avant une action, puis des enregistrements d'audit qui montrent qui a modifié quoi.

Didit a déjà mis en œuvre le mécanisme. Son serveur MCP hébergé connecte un client IA aux opérations d'identité et de fraude via un utilisateur connecté, plutôt que de traiter l'agent comme un détenteur anonyme d'un secret d'application. Le point de terminaison est gratuit, utilise le HTTP "Streamable" sans état et expose 115 outils. L'implémentation est également disponible dans le répertoire GitHub public sous licence MIT.

Cet artefact modifie la question utile. Au lieu de demander une autre définition de KYA, demandez : lorsqu'un agent crée une session de vérification, lit une décision ou modifie des données d'espace de travail, qu'est-ce qui prouve quelle personne l'a autorisé, ce que cette personne a permis et quelle organisation a accepté l'action ?

La liaison humaine est une chaîne de délégation

Un nom d'agent, un identifiant de modèle, une clé publique ou une attestation logicielle peuvent aider à identifier l'acteur machine. Aucun d'entre eux, à lui seul, n'établit qui est responsable de ce que l'agent fait. La liaison humaine nécessite une chaîne avec des maillons distincts :

• Principal : l'utilisateur authentifié ou le propriétaire du service pour le compte duquel l'agent agit.
• Client : l'application IA qui a demandé l'accès.
• Délégation : les portées et le consentement accordés à ce client.
• Contexte d'autorisation : le rôle organisationnel et la limite d'application appliqués à la requête.
• Preuve : un enregistrement vérifiable de l'action et de son résultat.

Chaque maillon répond à une question différente. L'authentification indique qui s'est connecté. OAuth indique quel client a reçu un accès délégué. Les portées indiquent quelles classes d'opérations ont été approuvées. Les rôles indiquent ce que l'utilisateur peut faire au sein de l'organisation. Les enregistrements d'audit indiquent ce qui s'est réellement passé. Regrouper ces contrôles en un seul badge "agent vérifié" masque la partie la plus importante : l'autorité est contextuelle et révocable.

Un agent digne de confiance n'est pas seulement identifiable. Il doit être capable de montrer un chemin ininterrompu d'un mandant responsable à une action spécifique et autorisée.

Pourquoi une clé dans un fichier de configuration échoue au test de responsabilité

Une clé API d'application peut être appropriée pour une intégration "serveur à serveur" contrôlée. Ce n'est pas, en soi, un mécanisme de liaison humain-agent. Une clé copiée répond normalement à une question : "Cet appelant possède-t-il une accréditation acceptée pour cette application ?" Elle ne répond pas à qui a lancé l'agent, qui a approuvé la tâche actuelle, ou si deux appels utilisant la même clé proviennent de personnes différentes.

Les modes de défaillance sont prévisibles. Les équipes partagent une clé entre les environnements locaux. Un processus d'agent l'hérite d'un fichier de configuration. Un deuxième agent reçoit une copie. Les journaux attribuent alors chaque appel à la même accréditation d'application. Révoquer cette accréditation interrompt chaque charge de travail qui l'utilise, tout en laissant l'événement de délégation individuelle peu clair.

Didit n'offre délibérément pas de chemin d'accès par clé d'application pour son point de terminaison MCP hébergé. Les intégrations backend peuvent toujours utiliser les API REST de Didit avec des accréditations d'application, mais l'accès MCP à distance nécessite un flux OAuth utilisateur. Cette séparation est importante : l'accréditation REST représente une intégration d'application ; le jeton MCP représente un accès délégué d'un utilisateur connecté.

OAuth 2.1, PKCE et enregistrement dynamique de clients

OAuth est la primitive de délégation dans cette conception. Le flux ne transmet pas le mot de passe de l'utilisateur à l'agent, et il ne place pas de secret de plateforme réutilisable dans la configuration MCP. Au lieu de cela, le client IA obtient un jeton d'accès limité après que l'utilisateur s'est authentifié auprès de Didit et a approuvé l'accès.

1. Enregistrer le client

L'enregistrement dynamique de clients permet à un client MCP compatible de s'enregistrer auprès du serveur d'autorisation Didit sans identifiant client pré-provisionné manuellement. Cela donne au serveur d'autorisation un enregistrement client distinct auquel il peut émettre un accès. L'enregistrement identifie le client OAuth ; il ne certifie pas, en soi, que le logiciel du client est digne de confiance.

2. Lier la réponse d'autorisation au client

PKCE crée un vérificateur et un défi uniques pour la tentative d'autorisation. Le client qui démarre le flux doit présenter le vérificateur lors de l'échange du code d'autorisation. Cela limite la valeur d'un code intercepté car un autre processus ne peut pas le racheter sans le vérificateur.

3. Authentification et consentement

L'utilisateur se connecte à la console Didit Business, qui agit comme serveur d'autorisation, et approuve les portées demandées. Didit annonce didit:verification pour les opérations de vérification et didit:management pour la gestion de l'espace de travail. Un client ne doit demander que la portée requise pour la tâche.

4. Valider chaque appel

Le serveur de ressources MCP hébergé valide le jeton "bearer" avant de "dispatcher" un appel d'outil. Le jeton utilisateur validé et le contexte organisationnel voyagent avec la requête vers Didit. Le service en aval évalue ensuite le rôle et les permissions existants pour cet utilisateur. Le résultat est une sémantique d'action en tant qu'utilisateur, et non une nouvelle identité de super-utilisateur créée pour l'agent.

Le guide d'authentification MCP documente le flux, tandis que la présentation du MCP explique le point de terminaison hébergé et le modèle client.

Agir en tant qu'utilisateur rend l'autorité lisible

Supposons qu'un opérateur de conformité connecte un client IA à Didit. Le client appelle d'abord didit_context_get, qui renvoie les organisations et les applications auxquelles l'utilisateur connecté peut accéder. Si l'utilisateur a une organisation et une application non ambiguës, le contexte peut se résoudre automatiquement. Si plusieurs sont disponibles, l'opération peut être restreinte à une organisation et une application explicites.

L'agent peut ensuite appeler didit_session_create pour créer une session de vérification et didit_session_get_decision pour récupérer son résultat. Ce sont des noms d'outils réels "domain-first" dans le catalogue MCP actuel. Un utilisateur qui n'a pas la permission requise ne l'obtient pas en connectant un agent ; la même limite d'autorisation organisationnelle s'applique toujours.

C'est la différence essentielle avec une accréditation d'application partagée. Dans le modèle OAuth, la requête arrive comme un utilisateur connu opérant via un client enregistré avec des portées déclarées. Dans le modèle à clé partagée, le système en aval voit l'accréditation de l'application, tandis que l'humain et l'agent derrière un appel particulier restent indiscernables à moins qu'un plan de contrôle distinct ne fournisse ce contexte.

Auditabilité : de "qui peut agir ?" à "qui a fait quoi ?"

L'autorisation empêche une action hors de portée. L'auditabilité explique une action après qu'elle se soit produite. Didit expose didit_audit_log_list afin qu'un utilisateur autorisé puisse inspecter les entrées d'audit d'application décrivant qui a modifié quoi. Parce que chaque requête MCP hébergée contient le jeton "bearer" de l'utilisateur connecté et le contexte organisationnel résolu, l'action est attribuable à cet appelant plutôt qu'à un processus d'agent anonyme.

Un enregistrement forensique complet doit également préserver les preuves côté agent. Pour les flux de travail à fort impact, enregistrez l'identifiant d'exécution de l'agent, l'enregistrement du client, la portée demandée, l'organisation et l'application cibles, le nom de l'outil, l'horodatage, l'état d'approbation et une représentation sécurisée des entrées et des sorties. Ne journalisez pas les jetons d'accès ou les charges utiles d'identité sensibles. La piste d'audit de la plateforme et le journal d'exécution de l'agent doivent être corrélables sans dupliquer les secrets ou les données personnelles réglementées.

L'attribution n'est pas la même chose que la non-répudiation, et un journal d'audit ne remplace pas le principe du moindre privilège. Les contrôles se renforcent mutuellement :

• Utilisez des accès de courte durée et un rafraîchissement contrôlé plutôt que des accréditations partagées permanentes.
• Accordez la portée OAuth la plus étroite et le rôle organisationnel le moins privilégié.
• Exigez une confirmation humaine pour les opérations destructrices ou à impact inhabituellement élevé.
• Gardez le contexte de l'organisation et de l'application explicite lorsqu'il y a plus d'une cible disponible.
• Révoquez la session utilisateur ou l'octroi client lorsque la délégation doit prendre fin.
• Surveillez les enregistrements d'audit pour détecter les acteurs, outils, cibles ou synchronisations inattendus.

Ce que la liaison prouve – et ce qu'elle ne prouve pas

Ce modèle prouve qu'un compte Didit authentifié a délégué un accès délimité à un client OAuth et que chaque requête est évaluée avec les permissions organisationnelles de cet utilisateur. Il crée une responsabilité pratique envers un compte et une chaîne vérifiable pour les actions de la plateforme.

Il ne prouve pas automatiquement que le titulaire du compte a une identité civile vérifiée, que le binaire client approuvé n'a pas été modifié, ou que l'humain surveille activement chaque étape. Cela nécessite une assurance supplémentaire. Si une assurance d'identité légale est nécessaire, vérifiez le principal lors de l'intégration avec les contrôles "Know Your Customer" (KYC) et liez ce résultat au compte. Si la provenance du logiciel est importante, ajoutez l'attestation client et les versions signées. Si la présence est importante, exigez une approbation renforcée au moment de l'action sensible.

Cette approche par couches maintient l'honnêteté du KYA. L'identité de l'agent, l'identité humaine, l'autorisation déléguée, la politique d'exécution et les preuves d'audit sont des contrôles liés, et non des étiquettes interchangeables.

Une implémentation fonctionnelle que vous pouvez inspecter

L'implémentation de Didit fournit une référence concrète pour les équipes qui conçoivent la même limite de responsabilité. Le serveur hébergé s'authentifie en tant qu'utilisateur Didit connecté, hérite du rôle organisationnel de cet utilisateur et applique cette identité à chaque appel d'outil. Ses 115 outils hébergés couvrent 19 domaines, des sessions de contexte et de vérification aux flux de travail, organisations, analyses et journaux d'audit. Le catalogue d'outils actuel liste la surface exacte.

Pour le contexte produit, le pack KYC complet coûte 0,33 $ et combine la vérification d'identité, la "Liveness" passive, la "Face Match" et l'analyse IP. Didit inclut 500 vérifications gratuites par mois et est utilisé par plus de 2 000 entreprises en production. Le serveur MCP lui-même est gratuit, de sorte que les équipes peuvent évaluer le modèle de délégation et de permission sans ajouter de frais de connecteur séparés.

Pour voir comment ce mécanisme s'intègre dans des flux de travail d'agents plus larges, lisez comment le MCP d'identité et de fraude fonctionne pour les agents IA et la référence des outils Didit MCP.

Liez l'agent avant de faire confiance à l'action

Le problème difficile de l'identité des agents n'est pas d'inventer un nom durable pour un logiciel. Il s'agit de préserver la responsabilité humaine lorsque le logiciel franchit les interfaces et agit à la vitesse de la machine. OAuth 2.1 fournit un accès délégué. PKCE protège l'échange d'autorisation. L'enregistrement dynamique de clients identifie le client connecteur. Les portées et les rôles organisationnels limitent l'autorité. Les enregistrements d'audit rendent le résultat vérifiable.

Vous pouvez inspecter l'architecture dans le répertoire MCP de Didit, consulter la documentation d'authentification, ou connecter Didit à Claude. Le test utile est simple : pour toute action d'agent proposée, pouvez-vous identifier l'utilisateur responsable, le client, la portée accordée, la limite organisationnelle et les preuves d'audit résultantes ? Si un maillon est manquant, l'agent n'est pas entièrement lié.