¿Cuál es el problema de la última milla en la IA?
El problema de la identidad en la última milla de la IA se produce cuando el contexto de identidad establecido en la puerta de entrada se degrada antes de llegar al sistema que realmente realiza el trabajo. El recurso termina autorizándose mediante una credencial, como una clave virtual, una cuenta de servicio o un cliente compartido, en lugar de una cadena verificable que muestre qué agente está actuando, en nombre de quién y bajo qué restricciones. El principio de privilegio mínimo se vuelve inaplicable en el único lugar donde importa, y todas las acciones de etapa final se ven iguales en el registro de auditoría.
He tenido alguna versión de esta conversación muchas veces, con diferentes equipos en diferentes industrias, y generalmente comienza de la misma manera. En un banco, una aseguradora o cualquier empresa regulada, los desarrolladores quieren utilizar un asistente de codificación con IA (como Claude Code o Codex), y el equipo de la plataforma hace lo más inteligente y obvio: coloca una puerta de enlace de IA delante de todos sus recursos. Esta puerta de enlace proporciona un lugar para enrutar a los modelos, aplicar límites de presupuesto y frecuencia, y gestionar el acceso a herramientas internas a través del Model Context Protocol (MCP). Comprendo la lógica que hay detrás de esto, pero no puedo evitar sentir que es similar al “modelo de cuenta de servicio” para agentes de IA, y las cosas tienden a ponerse un poco interesantes en la práctica.
Fundamentalmente, una puerta de enlace autentica una clave. No puede autenticar a una persona, y para cuando una solicitud llega al recurso real —la herramienta interna, la fuente de datos o lo que sea que esté en el otro extremo—, nadie en la etapa final puede notar la diferencia. Solucionar eso no es cuestión de ajustar la configuración de la puerta de enlace. Significa poner una identidad real por debajo: el agente obtiene sus propias credenciales, cada llamada lleva la identidad de la persona detrás de ella, y el propio recurso verifica esas credenciales con respecto a lo que le corresponde a esa persona específica. El mismo agente, la misma puerta de enlace y el mismo código ahora dan una respuesta diferente según quién haga la pregunta.
¿Por qué fallan las puertas de enlace de IA en la aplicación de la identidad en la etapa final?
La forma en que funcionan la mayoría de estas puertas de enlace hoy en día es que el agente (un asistente de codificación) termina teniendo la clave. El agente se autentica en la puerta de enlace utilizando esa clave virtual; a continuación, la puerta de enlace enruta la solicitud a un modelo o a un servidor MCP.
El problema surge justo al final de esa cadena. Una vez que una solicitud supera la puerta de enlace, no hay forma real de que el recurso en el otro extremo sepa quién está realmente detrás de ella. Lo único que ve es la llave. No es una persona. Ni siquiera se puede determinar con certeza un agente específico. Simplemente una credencial que cualquiera que tuviera acceso a ella podría haber utilizado ese día.
El patrón con el que suelen empezar la mayoría de los equipos es el siguiente: un Developer, un asistente personal de IA que posee una clave virtual, una puerta de enlace y todo lo que venga después. Nada en esta cadena transmite la identidad del desarrollador más allá de la puerta de enlace.
He visto varios nombres para este problema en los foros, y el que he elegido es “el problema de la última milla”. La puerta de enlace facilita gran parte del proceso: autentica algo (por ejemplo, una clave virtual) y, en definitiva, redirige al recurso correcto. Lo que no hace es contener información relativa a la identidad, los derechos o la autorización. Para cuando la solicitud llega al servidor MCP o al modelo, el sistema normalmente no sabe nada sobre la identidad que realiza la solicitud.
Vulnerabilidades de seguridad fundamentales de las puertas de enlace de IA basadas en claves
- Credenciales estáticas como identidad: Una clave estática representa la identidad, no una afirmación dinámica y revocable de quién está detrás de una solicitud (similar a un modelo de cuenta de servicio).
- Configuración predeterminada de acceso con privilegios excesivos: El acceso suele estar abierto por defecto hasta que alguien lo cierra deliberadamente.
- Aplicación: El recurso no tiene límite de aplicación, incluso cuando la puerta de enlace registra "esta clave llamó a esta herramienta", porque nadie en la cadena preguntó nunca: "¿Esta persona específica tiene derecho a estos datos específicos?".
Esto se nota mucho en una auditoría. Si le pregunta a un equipo especializado en IA quién accedió a un registro o a un servidor MCP, y por qué motivo, la respuesta será el silencio.
El fallo con la puerta de enlace como punto de aplicación
No creo que se trate de una brecha de configuración que se pueda solucionar escribiendo más reglas en la puerta de enlace. Para tomar una decisión real se necesitan tres cosas en el momento de la llamada:
- Lo que el agente puede hacer
- A qué tiene derecho el ser humano específico
- Lo que permite la política del recurso
Por diseño, una puerta de enlace solo tiene visibilidad de la primera de ellas, y a menudo ni siquiera de eso, solo de “alguien presentó una clave válida”.
¿Por qué falla “acoplar” un proveedor de identidad?
Un siguiente paso habitual es añadir un proveedor de identidad (IdP) y realizar un intercambio de tokens en nombre del usuario (siempre que esto sea compatible), de modo que el agente herede el token de acceso del usuario en lugar de mantener su propia clave estática.
El siguiente paso es añadir un proveedor de identidad (IdP).
Este patrón supone un paso en la dirección correcta, porque ahora al menos se sabe qué persona inició sesión. Pero al final se encuentra con el mismo problema de última milla, solo que una capa más abajo: “¿Qué agente invocó esta solicitud?” El recurso no tiene forma de verificar que el agente X esté actuando legítimamente en nombre del usuario Y, ni tampoco un mecanismo de desactivación para detenerlo. No hay intervención humana, no hay forma de bloquear a ese agente específico ni de revocar su acceso. El agente sigue sin ser un ciudadano de primera clase en ese flujo; simplemente está apropiándose de la identidad del usuario por completo. Si ha visto alguno de los incidentes de tipo “diputado confuso” que han circulado, esto debería sonar más como un riesgo y no como una solución.
Pero, ¿cómo sería una solución? Ya hemos establecido que añadir un IdP a nivel de puerta de enlace le da una dirección y no lo lleva a su destino de saber qué usuario solicitó a qué agente que realizara qué acción.
¿Cuál es la solución para la Identity Governance?
La solución reside en tratar a los agentes de IA como identidades de primera clase dentro de su marco de gestión de identidades y accesos, y en vincular las comprobaciones de autorización de usuarios y agentes a nivel de solicitud, y no a nivel de recurso. En Okta, ofrecemos esta funcionalidad con Okta for IA agentes, tal como se muestra en la siguiente figura.
La solución: El asistente obtiene una identidad propia controlada. El usuario inicia sesión una sola vez; el adaptador realiza un intercambio de tokens con la capa de identidad; solo un token aprobado y con el alcance especificado llega a la herramienta.
Con esta configuración, los usuarios pueden autenticarse antes de realizar una solicitud y, lo que es más importante, vincular sus autorizaciones a nivel de usuario (que establecen un límite a lo que pueden acceder) a cada solicitud que realicen a través de ese agente. Por supuesto, los usuarios pueden operar por debajo del límite, pero nunca podrán superarlo. Con este modelo, proporcionado a través de la especificación Cross App Access, finalmente podemos superar los problemas de última milla que encontramos al implementar y poner en funcionamiento los agentes de IA.
Cómo funciona la autorización dinámica a nivel de solicitud
Autenticación: El usuario humano se autentica mediante OpenID Connect (OIDC).
Definición de ámbito de derechos: La capa de identidad evalúa tres políticas distintas antes de emitir un token:
Autorización del agente: ¿Está autorizado este agente a actuar en nombre de este usuario?
Accesibilidad del objetivo: ¿Está este agente autorizado a acceder a este recurso específico?
Límite de permisos del usuario: ¿Qué acciones específicas tiene permitido realizar este usuario con ese recurso (leer/escribir/acceder)?
Emisión de tokens: el sistema genera un token de portador vinculado, de corta duración y de un solo uso, que contiene la intersección explícita de los permisos del agente y del usuario.
La intersección no se produce en un solo lugar. Como muestra la siguiente figura, dos puntos de autorización evalúan la política real sobre a qué pueden acceder el usuario y el agente. La primera llamada a una herramienta por parte del agente de IA llega al adaptador Okta MCP Bridge, que es responsable de algunas interacciones. En primer lugar, gestiona el inicio de sesión humano mediante un patrón estándar de OpenID Connect (OIDC). A continuación, coordina el protocolo de enlace de acceso entre aplicaciones entre el servidor de autorización de la organización Okta (que evalúa los permisos del agente y emite el token ID-JAG) y el servidor de autorización del recurso para emitir un token de portador vinculado (que incluye tanto los permisos del agente como los del usuario). Solo el token que contiene el veredicto de las comprobaciones tanto humanas como del agente llega al servidor MCP.
Los mecanismos de Cross Aplicaciones Access a través de Okta para agentes de IA. El usuario se autentica una sola vez; el agente solicita una aserción de corta duración y de un solo uso vinculada a ese usuario; servidores de autorización independientes la evalúan según la política establecida antes de emitir un token de portador con ámbito definido en el que el recurso puede confiar realmente.
La capa de identidad calcula esa intersección antes de que la solicitud llegue al recurso y devuelve un token que ya contiene el veredicto. En la práctica, eso significa que debemos hacernos tres preguntas: primero, ¿este agente está autorizado a actuar en nombre de este usuario? En segundo lugar, ¿tiene este agente permiso para acceder a este recurso? Finalmente, una vez que llega al recurso, ¿qué puede hacer realmente: leer un registro, leerlos todos o escribir en ellos?
En este modelo, los dos servidores de autorización independientes formulan estas preguntas. El servidor de autorización de la organización Okta responde a la pregunta del agente: “¿Tiene este agente permiso para actuar en nombre de este usuario y para acceder a este recurso?”. El servidor de autorización del propio recurso (que puede ser Okta o el propio recurso) responde a la pregunta humana: “Dado quién es esta persona, ¿a qué tiene derecho en este momento?”. Ninguna de las comprobaciones por sí sola constituye la intersección; la intersección es el token portador con ámbito que sale por el otro extremo de ambas. El recurso no tiene que volver a implementar estas comprobaciones para cada llamada a la herramienta. Simplemente valida un token y comprueba un ámbito.
Puerta de enlace de IA frente a identidad de agente gobernado: comparación de características
| Seguridad y capacidad operativa | Puerta de enlace de IA independiente | Puerta de enlace de IA + identidad de agente gobernada |
|---|---|---|
| Enrutamiento de modelos, control de costos y límites de frecuencia | Sí, su fuerza principal | Sí, sin cambios |
| Definición de ámbito de las herramientas y las fuentes de datos | Por clave o por equipo, sin contexto de usuario | Por usuario, gobernado centralmente |
| Identidad de agente gobernada y de primera clase | No, la identidad es una clave estática. | Sí, una identidad registrada y propia |
| Delegación verificable (agente que actúa en nombre de un usuario específico) | No, la solicitud tiene una clave, no un actor | Sí, cada llamada lleva a la persona que la autorizó |
| Ciclo de vida de las credenciales | Claves compartidas de larga duración | Tokens de corta duración por agente |
| Postura de acceso predeterminada | Abierto por defecto hasta que alguien configure de otra manera | Denegar por defecto (privilegio mínimo) |
| Gobernanza del ciclo de vida del agente | Hágalo usted mismo | Gestionado como cualquier otra identidad |
Si bien la puerta de enlace es una sólida puerta de entrada en cuanto a costos y enrutamiento, no se puede negar que tiene (con toda la intención del juego de palabras) una crisis de identidad. La decisión sobre quién tiene permiso para ver qué corresponde a una capa inferior y debe viajar con la solicitud hasta el recurso, sin terminar en la puerta de enlace.
Ejemplo práctico: aplicación de límites máximos de derechos
Imagina que tienes un bot interno que puede buscar información salarial. Tres personas distintas interactúan con este mismo bot: Charlie, un empleado normal que solo debería ver su propio salario; alguien del departamento de cumplimiento normativo que tiene permiso para ver el salario de todos (pero no para modificarlo); y un director financiero que puede ver y actualizar el salario de todos. El mismo bot, la misma acción (más o menos), pero personas diferentes con límites diferentes.
Charlie le pregunta al bot, a través de la puerta de enlace: "¿Cuál es mi salario?". El bot devuelve la respuesta correcta, supongamos que son $70 000. El problema surge de la pregunta de seguimiento. Charlie introduce "¿Cuál es el salario de Alice?" y el bot vuelve a dar la respuesta.
Ni el usuario, ni el agente, ni la puerta de enlace de IA, ni el servidor MCP comprobaron jamás la diferencia entre “como Charlie” y “como cualquier persona que tenga esta clave”. La puerta de enlace funcionó exactamente como la configuró el equipo de la plataforma; simplemente nunca la configuraron para que distinguiera entre ellas porque no puede ver la diferencia.
Ahora vamos a añadir una capa de identidad debajo de esa misma puerta de enlace. Charlie se identifica como él mismo. Cada llamada ahora es la intersección de tres cosas: lo que el agente puede solicitar, a qué tiene derecho personalmente Charlie y lo que permite la política de acceso al recurso.
Cuando Charlie pide su propio salario, se cumplen los tres requisitos. Cuando solicita el de Alice, el sistema rechaza su solicitud porque el término intermedio en esa intersección falla, incluso si el agente o la puerta de enlace lo permitieran en otras circunstancias. Si cambiamos el perfil al del director financiero, utilizando el mismo agente, el sistema permite la solicitud porque el director financiero tiene un límite de permisos diferente. El límite de privilegios viaja con la persona, no con una clave que cualquier miembro del equipo pueda usar para hacer la misma pregunta.
Preguntas frecuentes
Siempre me preguntan algo parecido a “¿Acaso nuestra puerta de enlace no se encarga ya de esto?”.
Recuerde que una clave identifica una categoría de quien realiza la llamada, no a quien realiza la llamada. No conlleva un derecho de acceso activo y vinculado a una persona que se pueda consultar en el recurso o revocar en el momento en que alguien cambie de rol. Dos personas que comparten una clave se ven idénticas para todo lo que está en la etapa final.
Todo el intercambio de información se produce en el backend. El Developer sigue comunicándose con su asistente de programación de la misma manera que lo hizo ayer; la autenticación y el intercambio de token se producen en segundo plano y no forman parte de su flujo de trabajo. Si cambia la forma en que los Developer trabajan día a día, entonces se construyó incorrectamente.
Desaconsejo esto. En la práctica, se crea un sistema de gobernanza propio para cada herramienta, a cargo del equipo que sea propietario de cada una de ellas, para siempre. No le proporciona una identidad única, duradera y gobernada centralmente que pueda auditar o revocar. En cambio, le ofrece varias versiones ligeramente diferentes y elaboradas manualmente de la misma comprobación, sin una fuente de verdad común entre ellas.
¿Debería reemplazar su puerta de enlace de IA con una capa de identidad?
El argumento aquí no es “arrancar su puerta de enlace”. Una puerta de enlace de agente tiene su lugar en el entorno de TI por la función para la que fue diseñada, como el enrutamiento, el control de costos, los límites de frecuencia o la detección de herramientas. No fue diseñada para transmitir un contexto de usuario específico. Esa es una capa diferente, que se sitúa aparte y evalúa cada solicitud individualmente.
¿Eso significa que todo lo que ya ha construido debe desaparecer? No. Esto significa que la puerta de enlace y la capa de identidad realizan dos funciones diferentes, y la mayoría de las arquitecturas actuales solo pagan por una de ellas.
Tome el control de su arquitectura de identidad de IA
Para resolver el problema de la última milla, se necesita una capa de identidad dedicada que funcione junto con la puerta de enlace, evaluando cada solicitud según sus propios criterios.
Con Okta para agentes de IA, puede establecer un límite de autorización a nivel de solicitud que acompañe al usuario humano en lugar de depender de una clave estática de acceso permanente. Al proteger los Workflows de su personal y Developer sin generar fricciones para estos últimos, Okta le ayuda a escalar las capacidades autónomas con confianza.
¿Listo para eliminar la crisis de identidad de su puerta de enlace?
Descargue el plan maestro para la empresa con agentes seguros para evaluar la arquitectura de seguridad de sus agentes y descubrir cómo Okta puede ayudarle a controlar sus agentes de IA empresariales tratándolos como identidades de primera clase.
