Identidad del llamador en el tráfico de agentes y herramientas

La identidad del llamador es el origen de la llamada, y no la credencial que la transportó. Cuando dos equipos comparten el mismo agente, el gateway reconoce la credencial y no reconoce a la persona: cuota, traza y autorización se vuelven una sola cosa. El NIST publicó la SP 800-63-4 en julio de 2025 para separar autenticar una credencial de afirmar la identidad.

Las tres fronteras que la empresa cree tener desaparecen juntas. La factura llega después.

Qué se pierde exactamente cuando la credencial es compartida

Un gateway que solo ve la credencial pierde tres cosas al mismo tiempo, y la empresa trata cada una como un problema separado. Pierde la cuota, porque el techo pasa a valer para el grupo entero. Pierde la traza, porque la traza registra la clave y no el equipo. Y pierde la autorización, porque el alcance concedido al vecino vale para quien esté cerca.

Las tres vienen de la misma causa. La credencial es un objeto compartido, y un objeto compartido no tiene dueño. El equipo de ingeniería abre una clave para un agente de clasificación, el equipo de soporte descubre que funciona, el equipo de ingresos conecta el mismo agente a su propio flujo. Nadie hizo nada mal y nadie decidió nada. La frontera simplemente desapareció, y el primer lugar donde eso duele no es la factura.

La factura es un documento agregado. No es falsa, es insuficiente para responder la pregunta que hace finanzas. Quién gastó. En qué. Con autorización de quién. Una factura que suma cuatro equipos en una línea responde "la empresa gastó", y esa respuesta ya se conocía antes de que la factura llegara.

Por qué el techo por clave no es un techo por unidad de negocio

El presupuesto de IA por equipo parte de una premisa explícita: la clave es el equipo. El techo por clave, la alerta al 80% y la traza por llamada funcionan cuando esa premisa es verdadera. El problema es que deja de ser verdadera en el momento en que el segundo equipo usa el mismo agente, y nada en el sistema avisa que eso ocurrió.

Es un asunto de modelado, no de configuración. Un techo por clave responde a la pregunta "cuánto consumió esta credencial". Un techo por unidad de negocio responde "cuánto consumió el equipo de ingresos, en qué modelo, y quién responde por eso". Son preguntas distintas, y la segunda no se obtiene dividiendo la primera.

La quinta fila es la que decide el valor del modelado. Un techo por clave no falla de forma visible cuando la premisa se rompe. Sigue funcionando exactamente como fue diseñado, sumando lo que alcanza a ver, y lo que no ve es la diferencia entre el consumo real del área y el consumo que aparece en su cuenta. El error no produce alarma, produce número.

Identidad del llamador: la cadena completa, y dónde se rompe

La identidad del llamador es el atributo que responde quién originó la llamada, y tiene que sobrevivir desde el usuario final hasta el servidor de herramienta. La cadena completa tiene cinco eslabones: el usuario final, el agente, la credencial que el agente usa, el gateway por donde pasa la llamada y el servidor de herramienta que la ejecuta. La identidad muere cuando uno de esos eslabones carga solo la credencial y no el origen. El primer eslabón es el que no tiene mecanismo por defecto, y no un salto garantizado. La identidad del usuario solo entra en la cadena si el host del agente la autenticó y la reenvió hacia adelante. La clave estática no la transporta, y por eso la ruptura de entrada es la más común.

Hay tres puntos de ruptura, y ninguno es exótico. El primero es la entrada: el agente se autentica con una clave estática y el humano detrás de él nunca llega al gateway. El segundo es la delegación: un agente llama a otro agente, o a un subagente, o a un servidor de herramienta que dispara una llamada nueva, y el origen no se propaga en la segunda pierna. Lo que se pierde ahí no es solo la propagación, es la reautorización. Un sujeto que llega a la segunda pierna sin alcance reducido carga la identidad sin reducir la autoridad, y ese es un modo de falla peor que perder simplemente el origen, porque la traza apunta a la persona correcta con el permiso equivocado. El tercero es la salida: la herramienta recibe la llamada sin saber en nombre de quién se está ejecutando, así que aplica el permiso de la credencial.

Leyenda: la identidad del llamador tiene que sobrevivir desde el origen hasta la herramienta; tres puntos de ruptura colapsan cuota, traza y permiso.

El segundo punto merece atención porque es el menos visible. La capa de control del tráfico de herramientas estableció el gateway como punto único de inspección y nombró la autenticación y la auditoría como funciones suyas. Reconocer la credencial, sin embargo, no es reconocer al llamador, y la diferencia aparece justamente en la delegación. Un flujo que llama tres herramientas en secuencia registra tres líneas de log con el mismo identificador de credencial. La pregunta que hace la auditoría, qué usuario activó esta cadena, no tiene respuesta en ninguna de las tres.

El log muestra la clave. No muestra a la persona.

El costo y el acceso se rompen en la misma causa

Llamar a esto un problema de costo es subestimar el defecto. La credencial compartida es un vector de autorización, y el exceso de permiso que produce es estructural, no accidental. Un equipo que solo necesitaba leer pasa a poder escribir porque la credencial del vecino lo permite, y nadie concedió ese permiso por decisión, se heredó por el uso compartido.

El modo de falla es siempre el mismo. El agente pertenece a un área, la herramienta pertenece a otra, y el alcance es el más amplio de los dos porque nadie declaró el menor. El equipo de soporte gana escritura en el sistema financiero porque el agente de clasificación fue autorizado a registrar una nota y la clave es la misma. El primer indicio no es el techo reventado: es un registro alterado que nadie reconoce como propio.

Una cuenta responde por dos áreas.

La especificación de autorización del Model Context Protocol trata este punto de forma directa. Exige que el cliente incluya el parámetro de recurso en la solicitud y que el servidor valide que el token fue emitido específicamente para él, rechazando los tokens que no lo nombran como destinatario. La vinculación por audiencia solo se sostiene cuando el servidor de autorización honra ese parámetro, así que es una pregunta que se le hace al proveedor, no un estándar que se asume. La misma sección prohíbe que el servidor reenvíe a la API aguas abajo el token que recibió del cliente, que es el token passthrough. El motivo es el confused deputy, un patrón antiguo de falla de autorización: un intermediario con credencial amplia actúa por quien no la tiene, y el sistema aguas abajo confía en él. El passthrough es una de las rutas hacia ese estado.

El gateway de LLM es la única posición de la arquitectura que ve los dos lados de ese flujo. Por eso la corrección queda ahí y no en cada aplicación.

Qué tiene que cargar el gateway para que la identidad sobreviva

Un gateway resuelve el problema cuando carga siete cosas, y ninguna es opcional. La lista de abajo no es una configuración, es el contrato mínimo entre la identidad que el sistema afirma tener y la identidad que logra probar por llamada.

1. Sujeto de origen. El identificador del usuario final viaja en la llamada, y la sesión del navegador no basta. Sin él, el gateway autentica la máquina e ignora a la persona.
2. Contexto de autorización por llamada. La decisión de permitir se recalcula en cada ejecución, con alcance declarado por herramienta, en vez de concederse una sola vez al crear la credencial.
3. Atribución por unidad de negocio. Cuota, política y traza apuntan al área responsable, y el área es un atributo de primera clase, no una etiqueta aplicada después.
4. Propagación en la delegación. Cuando un agente llama a otro, o a un subagente, o a un servidor de herramienta que dispara una llamada nueva, la identidad de origen sobrevive a la segunda pierna.
5. Traza completa por llamada. Cada ejecución registra sujeto, área, clave, herramienta, modelo, tokens y costo, y la auditoría de la llamada de LLM logra reconstruir la cadena entera desde cualquier punto de ella.
6. Menor privilegio efectivo. El alcance de la llamada es la intersección entre lo que el área puede y lo que la herramienta exige, y el exceso se niega por defecto en vez de tolerarse.
7. Techo en la dimensión correcta. El límite de gasto por clave de API sigue vigente como protección de caja, y el techo que responde al área es un segundo control, aplicado sobre la misma llamada.

El orden importa poco. La ausencia de cualquiera de ellos, sin embargo, reabre el defecto. Los siete no están en el mismo estadio de madurez: el sujeto de origen en la llamada es entrega corriente, y la propagación en la delegación todavía es rara en el herramental de producción. Del lado del proveedor, la pregunta práctica es cuál de esas siete propiedades el gateway ya entrega hoy, y es en el gateway de LLM en la empresa donde se revisa la lista.

Cuatro arreglos de uso compartido: qué se pierde en cada uno

La tabla de abajo cruza cuatro arreglos reales de uso compartido con las tres fronteras, y muestra dónde cae cada una. La columna de la cuota colapsa primero en todos ellos, y por eso el problema se diagnostica como costo cuando la causa es identidad.

La primera fila es la configuración que funciona, y no es la más común. La segunda es la que aparece con más frecuencia en las empresas que crecieron rápido, porque compartir el agente es la decisión barata y nadie mide su costo el día en que se toma.

La cuarta fila explica un síntoma específico: un gasto en producción que nadie logra reproducir en prueba, porque la prueba usa la clave de producción y el consumo de ambos cae en la misma línea. Cuando el equipo finalmente separa las claves, el gasto de producción parece bajar, y en realidad solo se volvió visible.

Prueba y producción no se separan solas.

Dónde duele primero, y por qué no es la factura del mes

El primer lugar donde la ausencia de identidad del llamador causa daño real no es el cierre mensual. Es la renovación del contrato de software, cuando alguien tiene que justificar lo que se compró y no logra atribuir consumo a ningún área. La factura del mes es un problema de caja. La caja se resuelve. La renovación sin atribución es un problema de crédito interno, y ese no se resuelve con pago.

Existe además la lectura regulatoria, y tiene plazo. El NIST publicó la revisión final de las Digital Identity Guidelines en julio de 2025, sustituyendo la SP 800-63-3, y la serie trata justamente la diferencia entre autenticar una credencial y afirmar la identidad de un sujeto ante un servicio.

Ninguna de ellas obliga a una empresa privada a nada. El NIST no regula al comprador, regula el vocabulario. El estándar que se cobra en contrato, en cuestionario de proveedor y en auditoría interna pregunta quién, nunca solo si. La lectura es esta, y no un dato medido. La SP 800-63C, el volumen de federación, exige que la aserción se restrinja a un destinatario específico a partir del FAL2, que es la misma propiedad que la prueba de abajo busca en el gateway. La empresa que solo logra responder "la credencial" queda con una laguna que nadie firma.

El argumento contrario, en su versión más fuerte

La objeción seria no es que la identidad del llamador sea irrelevante. Es que gestionar identidad por llamada cuesta caro y agrega un punto de falla en el camino crítico. El gateway pasa a depender de un servicio de identidad, el servicio cae, el tráfico se detiene. La simplicidad operativa tiene valor, y la clave única es simple.

La respuesta es que la objeción describe el costo de hacerlo e ignora el costo de no hacerlo, que ya se está pagando. Cada incidente que exige reconstruir quién alteró un registro en el sistema financiero consume días de ingeniería, y un puñado de ellos en el año ya supera una semana de trabajo detenido. Cada renovación sin atribución consume una renegociación. El costo no lo crea la identidad del llamador, se vuelve visible.

Y hay una razón de arquitectura para que el servicio de identidad sea menos frágil de lo que la objeción supone. La especificación del MCP recomienda el token de corta duración, y vuelve obligatorios el parámetro de recurso del lado del cliente y la validación de audiencia del lado del servidor. También obliga la rotación del refresh token para clientes públicos, que es lo que cierra la ventana de una filtración. El gateway que respeta ese contrato depende de tokens que expiran y no de sesiones largas, lo que reduce el impacto de una filtración en vez de ampliarlo.

Cómo probar si el gateway reconoce al llamador antes de firmar

La prueba cabe en una tarde. No exige tráfico de producción ni un agente sofisticado, y la respuesta que importa aparece en la primera pregunta dentro de la primera hora.

1. Registre dos claves distintas y asigne cada una a un área diferente, con el mismo agente corriendo en las dos.
2. Dispare la misma cadena de llamadas de herramienta por las dos claves, incluyendo un flujo de dos piernas en el que un agente llama a una herramienta que dispara otra llamada.
3. Lea la traza como la leería finanzas. ¿La llamada de cada área aparece separada, con el identificador del usuario de origen y el costo por modelo?
4. Verifique la segunda pierna de la delegación. ¿El origen sobrevive cuando la llamada se reenvía, o el log de la segunda herramienta solo muestra la credencial?
5. Intente negar con la clave del vecino. Dé a un área una clave con el alcance más amplio del vecino y dispare, como usuario de esa área, una herramienta que su propio alcance no cubre. El rechazo tiene que venir del llamador, no de la clave. Si la solicitud pasa porque la credencial autoriza, el gateway aplica política en la clave y todavía no conoce al llamador.

La quinta pregunta separa la aplicación de política en el llamador de la aplicación de política en la credencial. Un sistema que niega solo lo que la clave no permite está registrando tráfico con alcance, y no gobernando quién llamó. Vale decir lo que la prueba no demuestra por sí sola: un rechazo aislado es compatible con un gateway que solo mira la clave, y por eso la variación de arriba invierte la pregunta en vez de repetirla.

FAQ

¿Qué es la identidad del llamador en un gateway de LLM? Es el conjunto de atributos que responde quién originó una llamada, y la credencial que la transportó es solo uno de ellos. Tiene que sobrevivir desde el usuario final hasta el servidor de herramienta, y cubre al menos el sujeto de origen, la unidad de negocio responsable y el contexto de autorización de esa ejecución específica.

¿Por qué un techo por clave no resuelve el presupuesto por unidad de negocio? Porque el techo por clave mide lo que consumió la credencial, y la credencial deja de representar un área cuando dos equipos pasan a usar el mismo agente. El número sigue siendo correcto. E inútil. El techo por unidad de negocio exige que el área sea un atributo de la llamada, no una inferencia hecha a partir de la clave.

¿Compartir la credencial del agente entre equipos es siempre un error? No siempre, pero siempre es una decisión que necesita quedar registrada. En entorno de prueba, con dato sintético y techo bajo, compartir es aceptable y económico. En producción, con dato de cliente y herramienta transaccional, mezcla cuota, acceso y traza en una sola línea que nadie logra separar después.

¿Cómo sobrevive la identidad cuando un agente llama a otro agente? Sobrevive cuando la identidad de origen se propaga como parte de la llamada delegada, y no se sustituye por la credencial del segundo agente. En la práctica, eso significa que el gateway tiene que emitir un contexto de autorización para la ejecución encadenada que preserve el sujeto original y restrinja el alcance a la herramienta de destino.

¿La identidad del llamador es lo mismo que la autenticación de la clave de API? No. La autenticación de la clave responde si quien llamó puede llamar. La identidad del llamador responde quién es, en nombre de qué área y con qué autorización. Un gateway puede autenticar todas las llamadas con éxito y aun así no saber responder quién alteró un registro específico.

¿Cuánto de esto ya cubre el Nexforce Router? El Router gobierna el presupuesto por clave, por agente y por proyecto, con consumo en tiempo real de tokens por sesión y por agente, reglas de enrutamiento por clave y la traza completa de cada llamada. Es la capa donde cuota, política y traza viven en el mismo punto de control, y por eso el modelado por unidad de negocio empieza ahí. Quien está eligiendo la herramienta puede partir de los criterios de evaluación de un gateway de LLM y aplicar las preguntas de la prueba de arriba a cada candidato.

Referencias y Lectura Complementaria

• MCP gateway: la capa de control para el tráfico de herramientas de agentes de IA
• Presupuesto de IA por equipo: gobernanza con rastreabilidad
• Rastreo de la llamada de LLM: cómo auditar solicitud y token
• Cómo evaluar y elegir un gateway de LLM
• Model Context Protocol, especificación de autorización y buenas prácticas de seguridad: modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• NIST, Digital Identity Guidelines, SP 800-63-4, publicada en julio de 2025: pages.nist.gov/800-63-4

Quién responde por la llamada es una decisión de arquitectura

La identidad del llamador no es un recurso de observabilidad que se enciende después. Es una decisión sobre quién responde por lo que hizo la IA, tomada en el momento en que el primer agente empieza a compartirse, y revertida en silencio cada vez que una clave se copia al equipo de al lado.

La prueba cuesta una tarde. La respuesta es binaria. O el gateway logra nombrar el área y el usuario de origen por llamada, o la empresa opera con tres fronteras que solo existen en el organigrama. La cuota, el acceso y la traza caen juntos, y vuelven juntos cuando la identidad vuelve a sobrevivir hasta el servidor de herramienta.

Es en esa capa donde opera el Nexforce Router. Una API única, una clave, 300 o más modelos, con presupuesto por clave, por agente y por proyecto, consumo en tiempo real de tokens por sesión y por agente, reglas de enrutamiento por clave, guardrails de seguridad y la traza completa de cada llamada en observabilidad centralizada. La cuota, la política y la traza quedan en el mismo punto de control, en el lugar por donde la llamada ya pasa.