Saltar al contenido principal
IDENTIFICACIÓN DE LLAMANTES EN MCP

Sabe quién está llamando a tu MCP server

Tu MCP server expone herramientas a clientes de IA que no controlas. Proof of Actor te dice qué hay detrás de cada llamada, qué evidencia respalda ese resultado y te permite definir políticas por herramienta.

Obtener acceso anticipadoExplorar cómo funciona
Toshendra Sharma

Por Toshendra SharmaFundador y CEO, AgentCredia · Updated November 13, 2026

Tus herramientas están abiertas a llamantes que no puedes ver

Un MCP server hace que tu producto sea utilizable por clientes de IA. Expone herramientas, recursos y prompts que los assistants y agents pueden descubrir y llamar, usando mensajes JSON-RPC 2.0 entre hosts, clients y servers, como se describe en la especificación de Model Context Protocol. Precisamente por eso los equipos los construyen: colocan tu producto dentro de los flujos de trabajo en los que ya están operando los agentes de IA.

También significa que tu server recibe llamadas de clientes que no construiste y que no puedes observar directamente. Una sola herramienta puede ser invocada por un developer que prueba en local, por un assistant de escritorio que actúa para una persona autenticada, por un agent autónomo que ejecuta una tarea larga durante la noche o por algo que explora tu server en busca de debilidades. El protocolo te dice qué herramienta se llamó y con qué argumentos. Por sí solo no te dice qué tipo de actor está detrás de la llamada ni cuánto deberías confiar en ella.

La identificación de llamantes en MCP server cubre esa brecha. Proof of Actor añade un resultado de actor respaldado por evidencia a cada llamada a herramienta, para que tu server pueda tomar decisiones informadas sobre quién obtiene qué. Para una mirada más profunda al problema, lee quién está llamando a tu MCP server y consulta el caso de uso MCP servers para ver cómo lo aplican los equipos.

Nota sobre los términos. "Caller identity" también tiene un significado bien conocido en la infraestructura cloud. AWS STS GetCallerIdentity, por ejemplo, devuelve detalles sobre el usuario o rol de IAM cuyas credenciales se usan para invocar la operación. Eso responde qué credencial cloud hizo una llamada. La identificación de llamantes en MCP server de esta página responde a otra pregunta: qué tipo de actor, Human, Human + AI, Agent o Unknown, está detrás de una llamada a herramienta a tu MCP server, y qué evidencia respalda esa respuesta.

Qué hace distintos a los llamantes de MCP

Los llamantes de MCP son distintos de los visitantes del navegador y de los clientes API tradicionales en aspectos que importan para la política.

  • Casi siempre son automatizados. La pregunta es menos "¿humano o bot?" y más "¿qué agent, actuando cómo y con qué evidencia?"
  • A menudo actúan por una persona. Un assistant puede estar llamando a tu herramienta porque un usuario se lo pidió, o puede estar actuando de forma autónoma. Esos casos merecen un tratamiento distinto.
  • Se describen a sí mismos. La especificación de lifecycle de MCP hace que el client envíe un objeto clientInfo con un nombre y una versión en su solicitud initialize. Esa declaración es un contexto útil, pero es una declaración, no una prueba.
  • Las herramientas varían enormemente en impacto. Una herramienta de búsqueda y una herramienta que elimina registros no deberían compartir una sola política.

Una buena identificación de llamantes en MCP debe respetar las cuatro.

Cómo Proof of Actor identifica a los llamantes de MCP

Señales de tu server

Tu integración MCP pasa a Proof of Actor el contexto disponible para cada llamada: los detalles declarados del client, el contexto de transporte y de la solicitud, las firmas criptográficas de la solicitud que el client proporcione, como HTTP Message Signatures definidas en RFC 9421, y la herramienta que se está llamando. Cada señal se etiqueta con su origen.

Clasificación con una base

Proof of Actor devuelve una de cuatro clases, Human, Human + AI, Agent o Unknown, junto con la base del resultado:

  • verified cuando pasó una verificación criptográfica, como una firma de solicitud contra una clave publicada;
  • declared cuando el client o tu aplicación lo indicó, como el nombre del client en la sesión;
  • inferred cuando el resultado se basa en patrones de las llamadas;
  • unknown cuando la evidencia no respalda una determinación.

Un nombre de client declarado nunca se presenta como verificación. Cuando la evidencia es escasa, el resultado es Unknown en lugar de una suposición confiada, y tu server sabe exactamente con qué está trabajando.

Un resultado que tus herramientas pueden usar

El resultado del actor llega junto con la llamada a herramienta, listo para la lógica de tu server. En modo de observación lo registras. Cuando estés listo, tus políticas a nivel de herramienta actúan sobre él.

Qué obtiene tu equipo: Detect, Understand, Route

Detect

Captura la evidencia del llamante disponible en cada llamada a herramienta y mantiene separadas la evidencia verificada, declarada e inferida.

Understand

Ve qué clients llaman a qué herramientas, con qué frecuencia, con qué evidencia y cómo cambia eso con el tiempo. Detecta herramientas que atraen sobre todo llamantes Unknown, clients que cambian de comportamiento y la proporción de llamadas que llevan identidad verificable.

Route

Escribe políticas por herramienta y por nivel de riesgo. Patrones típicos:

  • Herramientas de bajo impacto como búsquedas o consultas de solo lectura: permitir de forma amplia, con un límite de tasa estándar.
  • Herramientas de impacto moderado como crear borradores: permitir llamantes verified y declared, limitar la tasa de Unknown.
  • Herramientas de alto impacto como eliminar datos, cambiar configuraciones o enviar mensajes en nombre de un usuario: exigir tu autorización más fuerte y añadir confirmación o revisión cuando el llamante sea Unknown o actúe de forma autónoma.

La guía sobre proteger acciones sensibles sin bloquear agents muestra cómo diseñar estos niveles.

La evidencia de identidad, las credenciales y la autorización son separadas

La seguridad MCP funciona mejor cuando tres preguntas permanecen distintas:

  1. Evidencia de identidad: qué tipo de client está llamando y qué lo prueba. Proof of Actor proporciona esto.
  2. Credenciales: con qué cuenta o token se hace esta llamada. La autenticación de tu MCP server proporciona esto. La especificación de autorización de MCP hace que la autorización sea opcional y, para transportes basados en HTTP, la base en OAuth 2.1, con el MCP server actuando como un resource server que valida access tokens.
  3. Autorización: puede este llamante usar esta herramienta, con estos argumentos, para esta cuenta. Tu modelo de permisos proporciona esto.

Un client reconocido no es automáticamente uno autorizado. Una firma válida no muestra que la persona detrás de la sesión haya delegado autoridad para esta acción específica. Lee más sobre autoridad delegada y autorización de agent. Proof of Actor ofrece a tu server mejor contexto para la primera pregunta, de modo que tus respuestas a la segunda y la tercera estén mejor informadas.

¿Por qué no confiar simplemente en el nombre del client?

Porque cualquier client puede enviar cualquier nombre. Tratar un nombre declarado como prueba invita a la imitación: un client hostil solo tiene que copiar el nombre de un assistant popular. Proof of Actor registra el nombre como evidencia declarada, lo combina con cualquier evidencia más fuerte que exista y te indica la base. Tu policy puede entonces dar más margen a los llamantes verified que a los llamantes que solo se declararon, y aplicar tu fallback de Unknown cuando no aplique ninguno de los dos.

Empieza en modo de observación

Instalar Proof of Actor en tu MCP server no cambia cómo responde ninguna herramienta. Los resultados se registran para que puedas ver quién llama a tus herramientas, cuán fuerte es la evidencia y dónde ayudarían las políticas. Cuando tengas confianza, habilita una policy en una sola herramienta de alto impacto, observa los resultados y luego amplía. How It Works cubre el flujo completo, y Detection & Limitations explica qué puede y qué no puede establecer cada tipo de evidencia.

Diseñado para equipos que operan MCP servers y APIs

Proof of Actor se integra en tu server junto con tu autenticación, limitación de tasa y registro existentes. Las integraciones se entregan de forma práctica con cada founding team, para que la configuración se adapte a tu transporte, hosting y diseño de herramientas. Los casos de uso MCP Servers y APIs muestran cómo el mismo enfoque se aplica a todas tus herramientas y a tu API.

Preguntas que hacer sobre cada herramienta que expones

Antes de escribir políticas a nivel de herramienta, conviene revisar cada herramienta que expone tu MCP server con una breve lista de verificación:

  • ¿Qué puede cambiar esta herramienta? Las herramientas de solo lectura y las que modifican datos, envían mensajes o afectan la facturación merecen un tratamiento distinto.
  • ¿Para quién es? Algunas herramientas existen para assistants que actúan en nombre de una persona autenticada; otras para flujos de trabajo autónomos. El llamante esperado define la política adecuada.
  • ¿Cuánto costaría un error? Un resultado de búsqueda incorrecto es barato. Una eliminación incorrecta no lo es. Asigna cada herramienta a un nivel de riesgo.
  • ¿Qué evidencia debería exigirse? Decide si un client declarado basta o si la herramienta debería necesitar identidad verified más tu autorización más fuerte.
  • ¿Qué ocurre con Unknown? Elige un fallback explícito para cada herramienta: permitir, limitar la tasa, pedir al usuario que confirme o enviar a revisión.
  • ¿Cómo sabrás que funciona? Decide qué resultados vigilarás en modo de observación antes de aplicar cualquier enforcement.

Responder esto una vez por herramienta convierte la identificación de llamantes en reglas claras y comprobables, y facilita explicar el comportamiento de tu server a los clients que se integran con él.

Únete al programa fundacional de developers

Proof of Actor está en beta privada. Los equipos fundadores de desarrollo seleccionados pueden recibir hasta 12 meses de acceso gratuito, dentro de los límites de uso acordados, con apoyo directo de nuestros engineers mientras diseñas políticas a nivel de herramienta.

Si operas un MCP server y quieres saber quién lo llama, solicita acceso anticipado. Cuéntanos sobre tu server, las herramientas que expones y las llamadas que más te importan.

Fuentes

PARA DESARROLLADORES

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 o Unknown.
basis
Qué tan sólida es la evidencia: Verified, Declared, Inferred o Unknown.
evidence
Las señales detrás del resultado, para que tu equipo vea por qué.

Empieza en modo de observación: registra los resultados junto a tus logs y no cambies nada hasta que elijas una política. Lee la guía de integración de Node.js

Preguntas frecuentes

¿Por qué un MCP server necesita identificación de llamantes?

Los MCP servers exponen herramientas a clientes de IA que actúan en nombre de personas o funcionan de forma autónoma. Saber qué tipo de llamante está detrás de una llamada a herramienta te permite permitir libremente las herramientas de bajo impacto y exigir más para las de alto impacto.

¿El nombre del cliente en una sesión MCP es una verificación?

No. Un nombre de cliente es una declaración hecha por el cliente. Proof of Actor lo registra como evidencia declarada y lo mantiene separado de la identidad verificada criptográficamente.

¿La identificación del llamante reemplaza la autorización MCP?

No. La evidencia de identidad del llamante, la credencial utilizada y lo que el llamante está autorizado a hacer son cuestiones separadas. Proof of Actor añade contexto a la primera y deja la autorización a tu server.

¿Proof of Actor bloqueará llamadas a herramientas?

Solo si tus políticas lo indican. Cada integración comienza en modo de observación y habilitas políticas a nivel de herramienta cuando estés listo.

¿Cómo puedo probarlo?

Solicita acceso anticipado. Los equipos fundadores seleccionados pueden recibir hasta 12 meses gratis dentro de los límites de uso acordados, con apoyo práctico de integración.

Sabe quién usa tu app.

Beta privada para un pequeño grupo de desarrolladores fundadores.

Obtener acceso anticipadoVer precios

¿Prefieres hablar primero? Habla con los fundadores