Coneix el teu agent: com vincular un humà a un agent d'IA (CA)

Aspectes clau

• El Know Your Agent (KYA) no es resol donant un nom a un agent. El control durador és una cadena de delegació que enllaça una persona autenticada, un client registrat, àmbits concedits, un context d'organització i cada acció resultant.
• L'endpoint MCP (Model Context Protocol) allotjat de Didit exposa 115 eines en 19 dominis i utilitza Open Authorization (OAuth) 2.1 amb Proof Key for Code Exchange (PKCE) i registre dinàmic de clients.
• L'MCP actua com l'usuari de Didit que ha iniciat sessió. Hereda el rol d'organització d'aquest usuari, de manera que un agent connectat no pot obtenir permisos que la persona ja no tingués.
• Una clau d'aplicació emmagatzemada en un fitxer de configuració prova la possessió d'una credencial, no quina persona va delegar una acció concreta. Les claus compartides fusionen múltiples operadors i agents en una única identitat d'aplicació.
• La responsabilitat requereix tant aplicació com evidència: tokens amb àmbit i comprovacions de rol abans d'una acció, i després registres d'auditoria que mostrin qui va canviar què.

Didit ja ha implementat el mecanisme. El seu servidor MCP allotjat connecta un client d'IA a les operacions d'identitat i frau mitjançant un usuari que ha iniciat sessió, en lloc de tractar l'agent com un titular anònim d'un secret d'aplicació. L'endpoint és gratuït, utilitza HTTP transmissible sense estat i exposa 115 eines. La implementació també està disponible al repositori públic de GitHub amb llicència MIT.

Aquest artefacte canvia la pregunta útil. En lloc de demanar una altra definició de KYA, pregunta: quan un agent crea una sessió de verificació, llegeix una decisió o canvia dades de l'espai de treball, què demostra quina persona la va autoritzar, què va permetre aquesta persona i quina organització va acceptar l'acció?

La vinculació humana és una cadena de delegació

Un nom d'agent, un identificador de model, una clau pública o una atestació de programari poden ajudar a identificar l'actor de la màquina. Cap d'ells, per si sol, estableix qui és responsable del que fa l'agent. La vinculació humana necessita una cadena amb enllaços distints:

• Principal: l'usuari autenticat o el propietari del servei en nom del qual actua l'agent.
• Client: l'aplicació d'IA que va sol·licitar l'accés.
• Delegació: els àmbits i el consentiment concedits a aquest client.
• Context d'autorització: el rol d'organització i el límit d'aplicació aplicats a la sol·licitud.
• Evidència: un registre revisable de l'acció i el seu resultat.

Cada enllaç respon a una pregunta diferent. L'autenticació diu qui ha iniciat sessió. OAuth diu quin client va rebre accés delegat. Els àmbits diuen quines classes d'operació es van aprovar. Els rols diuen què pot fer l'usuari dins de l'organització. Els registres d'auditoria diuen què va passar realment. Col·lapsar aquests controls en una única insígnia d'“agent verificat” amaga la part més important: l'autoritat és contextual i revocable.

Un agent de confiança no és només identificable. Ha de poder mostrar un camí ininterromput des d'un principal responsable fins a una acció específica i permesa.

Per què una clau en un fitxer de configuració no supera la prova de responsabilitat

Una clau API d'aplicació pot ser adequada per a una integració controlada de servidor a servidor. No és, per si mateixa, un mecanisme de vinculació d'humà a agent. Una clau copiada normalment respon a una pregunta: “Aquest sol·licitant posseeix una credencial acceptada per a aquesta aplicació?” No respon qui va iniciar l'agent, qui va aprovar la tasca actual o si dues trucades utilitzant la mateixa clau provenien de persones diferents.

Els modes de fallada són predictibles. Els equips comparteixen una clau entre entorns locals. Un procés d'agent l'hereta d'un fitxer de configuració. Un segon agent rep una còpia. Els registres llavors atribueixen cada trucada a la mateixa credencial d'aplicació. Revocar aquesta credencial interromp cada càrrega de treball que la utilitza, mentre que l'esdeveniment de delegació individual queda poc clar.

Didit deliberadament no ofereix un camí de clau d'aplicació per al seu endpoint MCP allotjat. Les integracions de backend encara poden utilitzar les API REST de Didit amb credencials d'aplicació, però l'accés remot a l'MCP requereix un flux d'usuari OAuth. Aquesta separació és important: la credencial REST representa una integració d'aplicació; el token MCP representa l'accés delegat d'un usuari que ha iniciat sessió.

OAuth 2.1, PKCE i registre dinàmic de clients

OAuth és la primitiva de delegació en aquest disseny. El flux no lliura la contrasenya de l'usuari a l'agent, i no col·loca un secret de plataforma reutilitzable a la configuració de l'MCP. En canvi, el client d'IA obté un token d'accés limitat després que l'usuari s'autentiqui amb Didit i aprovi l'accés.

1. Registra el client

El registre dinàmic de clients permet a un client MCP compatible registrar-se al servidor d'autorització de Didit sense un identificador de client pre-aprovisionat manualment. Això dóna al servidor d'autorització un registre de client distint al qual pot emetre accés. El registre identifica el client OAuth; no certifica, per si mateix, que el programari del client sigui de confiança.

2. Vincula la resposta d'autorització al client

PKCE crea un verificador i un desafiament d'un sol ús per a l'intent d'autorització. El client que inicia el flux ha de presentar el verificador en intercanviar el codi d'autorització. Això limita el valor d'un codi interceptat perquè un altre procés no el pot bescanviar sense el verificador.

3. Autentica i dóna el consentiment

L'usuari inicia sessió a la consola de negocis de Didit, que actua com a servidor d'autorització, i aprova els àmbits sol·licitats. Didit anuncia didit:verification per a operacions de verificació i didit:management per a la gestió de l'espai de treball. Un client només ha de sol·licitar l'àmbit requerit per a la tasca.

4. Valida cada trucada

El servidor de recursos MCP allotjat valida el token de portador abans de despatxar una trucada d'eina. El token d'usuari validat i el context d'organització viatgen amb la sol·licitud a Didit. El servei posterior avalua el rol i els permisos existents per a aquest usuari. El resultat són semàntiques d'actuar com a usuari, no una nova identitat de superusuari creada per a l'agent.

La guia d'autenticació de l'MCP documenta el flux, mentre que la visió general de l'MCP explica l'endpoint allotjat i el model de client.

Actuar com a usuari fa que l'autoritat sigui llegible

Suposem que un operador de compliment connecta un client d'IA a Didit. El client primer crida didit_context_get, que retorna les organitzacions i aplicacions a les quals pot accedir l'usuari que ha iniciat sessió. Si l'usuari té una organització i una aplicació inequívoques, el context es pot resoldre automàticament. Si n'hi ha diverses disponibles, l'operació es pot restringir a una organització i una aplicació explícites.

L'agent pot llavors cridar didit_session_create per crear una sessió de verificació i didit_session_get_decision per recuperar el seu resultat. Aquests són noms d'eines reals de primer domini en el catàleg actual de l'MCP. Un usuari que no té el permís requerit no l'obté connectant un agent; el mateix límit d'autorització de l'organització encara s'aplica.

Aquesta és la diferència central d'una credencial d'aplicació compartida. En el model OAuth, la sol·licitud arriba com un usuari conegut que opera a través d'un client registrat amb àmbits declarats. En el model de clau compartida, el sistema posterior veu la credencial de l'aplicació, mentre que l'humà i l'agent darrere d'una trucada particular romanen indistingibles tret que un pla de control separat proporcioni aquest context.

Auditabilitat: de “qui pot actuar?” a “qui va fer què?”

L'autorització impedeix una acció fora de l'àmbit. L'auditabilitat explica una acció després que s'hagi produït. Didit exposa didit_audit_log_list perquè un usuari autoritzat pugui inspeccionar les entrades d'auditoria de l'aplicació que descriuen qui va canviar què. Com que cada sol·licitud MCP allotjada porta el token de portador de l'usuari que ha iniciat sessió i el context d'organització resolt, l'acció és atribuïble a aquest sol·licitant en lloc d'un procés d'agent anònim.

Un registre forense complet també ha de conservar les proves del costat de l'agent. Per a fluxos de treball d'alt impacte, registreu l'identificador d'execució de l'agent, el registre del client, l'àmbit sol·licitat, l'organització i l'aplicació de destinació, el nom de l'eina, la marca de temps, l'estat d'aprovació i una representació segura de les entrades i sortides. No registreu tokens d'accés ni càrregues útils d'identitat sensibles. La pista d'auditoria de la plataforma i el registre d'execució de l'agent han de poder correlacionar-se sense duplicar secrets o dades personals regulades.

L'atribució no és el mateix que la no repudiació, i un registre d'auditoria no és un substitut del privilegi mínim. Els controls es reforcen mútuament:

• Utilitzeu accés de curta durada i actualització controlada en lloc de credencials compartides permanents.
• Concediu l'àmbit OAuth més estret i el rol d'organització amb menys privilegis.
• Requeriu confirmació humana per a operacions destructives o d'impacte inusualment alt.
• Mantingueu el context d'organització i aplicació explícit quan hi hagi més d'un objectiu disponible.
• Revoqueu la sessió d'usuari o la concessió del client quan la delegació hagi d'acabar.
• Monitoritzeu els registres d'auditoria per a actors, eines, objectius o temps inesperats.

Què prova la vinculació — i què no

Aquest patró prova que un compte autenticat de Didit va delegar accés amb àmbit a un client OAuth i que cada sol·licitud s'avalua amb els permisos d'organització d'aquest usuari. Crea una responsabilitat pràctica davant un compte i una cadena revisable per a les accions de la plataforma.

No prova automàticament que el titular del compte tingui una identitat civil verificada, que el binari del client aprovat no hagi estat modificat o que l'humà estigui vigilant activament cada pas. Aquests requereixen una garantia addicional. Si és necessària una garantia d'identitat legal, verifiqueu el principal durant l'incorporació amb controls Know Your Customer (KYC) i vinculeu aquest resultat al compte. Si la procedència del programari importa, afegiu atestació del client i versions signades. Si la presència importa, requeriu una aprovació per augment de nivell en el moment de l'acció sensible.

Aquesta visió per capes manté l'honestedat del KYA. La identitat de l'agent, la identitat humana, l'autorització delegada, la política en temps d'execució i les proves d'auditoria són controls relacionats, no etiquetes intercanviables.

Una implementació funcional que podeu inspeccionar

La implementació de Didit proporciona una referència concreta per als equips que dissenyen el mateix límit de responsabilitat. El servidor allotjat s'autentica com l'usuari de Didit que ha iniciat sessió, hereta el rol d'organització d'aquest usuari i aplica aquesta identitat a cada trucada d'eina. Les seves 115 eines allotjades abasten 19 dominis, des de sessions de context i verificació fins a fluxos de treball, organitzacions, analítiques i registres d'auditoria. El catàleg d'eines actual enumera la superfície exacta.

Per al context del producte, el paquet KYC complet costa 0,33 $ i combina la verificació d'identitat, la prova de vida passiva, la concordança facial i l'anàlisi d'IP. Didit inclou 500 verificacions gratuïtes al mes i és utilitzat per més de 2.000 empreses en producció. El servidor MCP en si és gratuït, de manera que els equips poden avaluar el model de delegació i permisos sense afegir una tarifa de connector separada.

Per veure com aquest mecanisme encaixa en fluxos de treball d'agent més amplis, llegiu com funciona l'MCP d'identitat i frau per als agents d'IA i la referència d'eines de l'MCP de Didit.

Vincula l'agent abans de confiar en l'acció

El problema difícil en la identitat de l'agent no és inventar un nom durador per al programari. És preservar la responsabilitat humana a mesura que el programari travessa interfícies i actua a la velocitat de la màquina. OAuth 2.1 proporciona accés delegat. PKCE protegeix l'intercanvi d'autorització. El registre dinàmic de clients identifica el client que es connecta. Els àmbits i els rols d'organització restringeixen l'autoritat. Els registres d'auditoria fan que el resultat sigui revisable.

Podeu inspeccionar l'arquitectura al repositori MCP de Didit, revisar la documentació d'autenticació, o connectar Didit a Claude. La prova útil és senzilla: per a qualsevol acció d'agent proposada, podeu identificar l'usuari responsable, el client, l'àmbit concedit, el límit de l'organització i l'evidència d'auditoria resultant? Si falta algun enllaç, l'agent no està completament vinculat.