¿Quién es su agente realmente? La crisis de identidad que nadie resuelve

Tiempo estimado de lectura: 7 min

Su agente acaba de enviar un correo desde su cuenta. Revisó su calendario, leyó su bandeja de entrada, reservó una reunión. Más tarde ese mismo día ejecutó una transacción de $50,000 contra su base de datos de producción. Ambas acciones usaron el mismo token OAuth, la misma credencial digital, porque sus herramientas autenticaron al agente de la misma manera que autenticarían una aplicación web. El agente es usted, hasta donde el sistema sabe. Todo usted. El usted del calendario, el usted del correo, el usted de los pagos, el usted de la base de datos de producción.

Este es el problema de identidad que nadie que construya sistemas de agentes ha resuelto. Y es la razón por la que los agentes con poder real (del tipo que mueve dinero, modifica registros o asume compromisos) permanecen bloqueados detrás de puertas de aprobación humana que anulan todo el sentido de tener agentes en primer lugar.

El problema de la delegación

La autenticación para agentes hoy funciona de una sola manera: el agente hereda los permisos completos del humano que lo configuró. Una sola clave API. Un solo token OAuth. Una credencial que dice "este agente puede hacer todo lo que el humano puede hacer".

Eso está bien cuando el alcance del agente es limitado. Un agente de soporte al cliente que solo lee de una base de datos de tickets. Es un desastre cuando la misma arquitectura se aplica a un agente que necesita acceso al calendario, correo, una pasarela de pago y datos de producción. El problema no es que el agente vaya a abusar necesariamente de esos permisos. El problema es que cuando lo hace, cuando una instrucción malinterpretada desencadena una transferencia bancaria en lugar de una consulta al calendario, no hay nada en la capa de autorización que lo detenga.

El problema de la delegación se descompone en tres preguntas difíciles.

La granularidad del alcance es la primera. ¿Puedo darle al agente lectura del calendario pero no escritura? ¿Puedo darle acceso a pagos solo para montos inferiores a $100? ¿Puedo decir "lee la base de datos de producción pero solo la tabla de pedidos, y solo las filas actualizadas en las últimas 24 horas"?

Los límites contextuales vienen después. El mismo agente que debería poder leer su calendario a las 9 AM un martes no debería poder leer su calendario a las 3 AM cuando nadie está mirando. Un agente que se ejecuta en un pipeline de CI/CD debería tener permisos diferentes a uno invocado de forma interactiva. Los sistemas de autenticación actuales no distinguen entre estos contextos.

Luego están las cadenas de delegación. Cuando un agente genera un subagente, ¿hereda el subagente los mismos permisos? ¿Debería hacerlo? Si el Agente A tiene acceso al calendario y genera el Agente B para cruzar su calendario con su correo, ¿debería el Agente B también tener lectura del calendario, o solo debería recibir los datos que el Agente A le pasó?

Cada despliegue de agentes en producción que he visto cubre estas preguntas con una sola autorización amplia, y cada uno de ellos eventualmente tendrá que enfrentar las consecuencias.

La cadena de identidad

La identidad de un agente no es una sola cosa. Es una cadena con al menos cinco eslabones:

Humano → Agente → Subagente → Herramienta → Servicio externo

En cada salto, la identidad se vuelve más borrosa.

El humano es el principal, la persona de cuya autoridad se deriva en última instancia la cadena. La mayoría de los sistemas autentican al humano una vez y se olvidan de él.

El agente es el delegado. Posee el token del humano y actúa en su nombre. Pero el agente podría tener intenciones diferentes a las del humano, no de forma maliciosa, sino porque las instrucciones son imprecisas y las interpretaciones varían.

El subagente es el delegado del agente. Si el agente puede crear subagentes, esos subagentes heredan los permisos del agente. El humano que autorizó al agente original puede no tener idea de que existe un subagente, y mucho menos de lo que está haciendo.

La herramienta es el siguiente salto: un conector de base de datos, un cliente API, un accesor del sistema de archivos. Las herramientas no se autentican como agentes. Se autentican como cuentas de servicio o usuarios a nivel de aplicación. Para cuando una llamada a herramienta llega a un servicio externo, la identidad del humano original es invisible.

El servicio externo (Salesforce, Gmail, Stripe, Snowflake) ve una llamada API desde una aplicación. No tiene idea de que un humano autorizó esta acción específica a través de una cadena de delegación. No sabe si el agente está actuando en nombre de un VP de Ingeniería o de un pasante con acceso accidental.

La cadena de responsabilidad se rompe a escala porque la identidad se estrecha en cada salto. El humano autoriza de manera amplia. El agente interpreta de manera flexible. El subagente actúa sin supervisión. La herramienta registra una cuenta de servicio. El servicio externo registra una clave API.

Cuando algo sale mal, y algo saldrá mal, usted puede reconstruir la cadena si su registro de auditoría es suficientemente bueno. Pero no puede prevenir la falla porque ningún eslabón de la cadena tiene suficiente información para aplicar una autorización granular.

Lo que existe hoy (y por qué no es suficiente)

El conjunto actual de herramientas para la identidad de agentes es como intentar meter una clavija cuadrada en un agujero redondo.

Comencemos con las claves API. Una clave desbloquea todo a lo que la clave tiene acceso. Está bien para un script sin estado, es terrible para un agente que necesita acceso diferenciado a múltiples sistemas. No hay alcance, no hay contexto, no hay forma de limitar lo que el agente puede hacer con la clave.

OAuth con ámbitos es un paso adelante. OAuth le permite solicitar ámbitos de permisos específicos (leer calendario, enviar correo) y el usuario los concede. Pero los ámbitos OAuth fueron diseñados para aplicaciones, no para agentes. Una aplicación pide permisos una vez y el usuario aprueba o rechaza todo el conjunto. No hay forma de decir "este agente puede leer mi calendario pero solo entre las 9 AM y las 5 PM" o "este agente puede enviar correo pero solo a contactos a los que ya he enviado correo". OAuth define categorías amplias, no políticas granulares.

Las cuentas de servicio resuelven el problema de identidad eliminando al humano por completo: el agente se autentica como sí mismo. Pero esto rompe la cadena de delegación. Si la cuenta de servicio tiene acceso de lectura a la base de datos, cada agente que use esa cuenta de servicio tiene acceso de lectura a la base de datos. Ha intercambiado granularidad por simplicidad y ha perdido en ambas dimensiones.

Las aprobaciones con humano en el circuito son la opción nuclear: cada acción relevante requiere un clic humano. Esto funciona para acciones de alto riesgo como una ejecución de operación bursátil, una firma de contrato o un pago por encima de un umbral. No escala a las miles de acciones rutinarias que los agentes deberían manejar de forma autónoma. Si cada llamada a herramienta requiere aprobación humana, el agente no es un agente. Es un autocompletado lento.

Nada en el conjunto actual de herramientas está diseñado específicamente para el problema de identidad de agentes. Cada equipo de producción con el que he hablado está uniendo alguna combinación de estos enfoques y esperando que se mantenga.

Lo que se requiere realmente para resolver esto

El problema de identidad de agentes tiene cuatro requisitos que la mayoría de los sistemas solo abordan parcialmente.

La autorización delegada con reducción de alcance es el primero. Un agente debería recibir un subconjunto de sus permisos, no todos. Si usted tiene acceso para leer y escribir en la base de datos de producción, su agente debería poder configurarse para solo leer, o para leer tablas específicas, o para leer filas modificadas después de una cierta marca de tiempo. El principio de mínimo privilegio se aplica a los agentes de la misma manera que se aplica a los empleados humanos, y no lo estamos aplicando para agentes más de lo que lo aplicamos para humanos, es decir, apenas.

Esto existe en teoría. Los ámbitos OAuth de Google incluyen permisos granulares de calendario (solo lectura, escritura, lectura de disponibilidad). Los tokens de acceso personal de GitHub de granularidad fina permiten limitar el alcance por repositorio y tipo de permiso. El problema es que estos sistemas de ámbitos están diseñados cada uno para su propia plataforma. No existe un estándar de autorización de agentes multiplataforma. Un agente que necesita leer su Google Calendar y enviar correo a través de Outlook y consultar su base de datos Snowflake necesitaría tres mecanismos de autorización separados, cada uno con diferentes lenguajes de alcance, diferentes comportamientos de renovación de tokens y diferentes formatos de auditoría.

El encadenamiento de identidad viene después. Cuando un agente llama a una herramienta que llama a un servicio externo, ese servicio debería conocer al humano original, no solo a la cuenta de servicio intermediaria. La cadena de identidad debería preservarse de extremo a extremo, con cada salto transmitiendo información sobre el autorizador original y el alcance de la delegación.

Esto es técnicamente factible hoy usando claims JWT, estándares de intercambio de tokens o metadatos estructurados en llamadas API. No está sucediendo porque los organismos de estándares y los proveedores de plataformas no lo han priorizado. MCP está explorando esto: el borrador del protocolo tiene espacio para metadatos de identidad en contextos de llamadas a herramientas, pero aún no está definido.

El tercer requisito son los tokens con límite de tiempo y contexto. Un agente debería poder poseer un token que expire no solo después de una duración sino después de que se cumpla una condición. "Este token otorga acceso de lectura a la base de datos por hasta 24 horas o hasta que la tarea de análisis actual se complete, lo que ocurra primero". Los sistemas de tokens modernos (autenticación escalonada OAuth 2.0, tokens basados en claims) pueden expresar técnicamente algunas de estas restricciones, pero no están diseñados para el ciclo de vida en tiempo real y vinculado a tareas del trabajo de agentes.

Finalmente, pistas de auditoría que mapeen las decisiones del agente a los autorizadores humanos. Cada acción del agente debería ser rastreable hasta un evento de autorización humana, no solo "quién configuró el agente" sino "bajo qué autoridad ocurrió esta acción específica". Este es el beneficio práctico del encadenamiento de identidad. Cuando la pista de auditoría muestra "Agente Alice (autorizado por Bob el 6 de mayo) llamó a la herramienta PaymentGateway.send con parámetros {monto: 50000, destino: AcmeCorp}", usted tiene la información que necesita para cumplimiento, análisis forense y determinación de responsabilidad (Artículo 005).

La Ley de IA de Colorado, vigente a partir del 30 de junio de 2026, exige que los desarrolladores de sistemas de IA de alto riesgo documenten los procesos de toma de decisiones y mantengan registros de las operaciones del sistema. La Ley de IA de la UE tiene obligaciones de transparencia similares. Las cadenas de identidad difusas dificultan el cumplimiento de ambas leyes más de lo necesario. Si no puede mapear la acción de un agente a un autorizador humano específico, no puede decir quién tomó la decisión, que es exactamente lo que los reguladores preguntarán en la primera auditoría.

La dimensión regulatoria

La regulación es la fuerza que eventualmente empujará a que se resuelva el problema de identidad de agentes, esté la industria lista o no.

Las regulaciones de servicios financieros ya exigen "conozca a su cliente" y documentación de pistas de auditoría. Si un agente procesa una operación, un oficial de cumplimiento necesita saber quién autorizó al agente, bajo qué parámetros y con qué supervisión. El enfoque actual, un token OAuth con permisos completos y sin cadena, no satisface estos requisitos. Los bancos que ejecutan despliegues de agentes están siendo creativos con soluciones alternativas: cuentas de servicio de propósito limitado, puertas de aprobación manual, registros extensivos que compensan la falta de infraestructura de identidad. Esto funciona a escala de prueba de concepto. No funciona para el despliegue de 50 agentes planificado para el próximo año.

La Ley de IA de la UE clasifica los sistemas de IA por nivel de riesgo. Los sistemas de alto riesgo requieren transparencia en la toma de decisiones y supervisión humana. Para sistemas de agentes, la "supervisión humana" necesariamente incluye saber qué humano autorizó qué acción. Un agente que no puede demostrar que actuaba bajo autoridad delegada específica crea una brecha de cumplimiento para cada organización que lo utiliza.

El sector salud añade otra capa. HIPAA exige controles de acceso que limiten quién, o qué, puede ver información de salud protegida. Un agente que procesa registros de pacientes necesita autenticarse no solo como "una aplicación con acceso API" sino como una entidad específica que actúa en nombre de una entidad cubierta específica para un propósito específico. El conjunto actual de herramientas no admite este nivel de granularidad, lo cual es una razón por la que los despliegues de agentes en salud (Artículo 006) permanecen en gran medida limitados a flujos de trabajo estructurados que no enfrentan al paciente, como autorización previa y sugerencia de códigos de facturación.

La ventaja competitiva

Las empresas que resuelvan la identidad de agentes desbloquearán los casos de uso que el resto del mercado no puede tocar. Finanzas, salud, derecho, seguros: los sectores verticales de alto valor requieren autorización granular, encadenamiento de identidad y delegación auditable. Cada organización en estas industrias tiene el mismo problema, y ninguna tiene una buena solución.

Los problemas de infraestructura como este se convierten en fosos competitivos. La primera plataforma que ofrezca IAM para agentes diseñado específicamente (autorización delegada con reducción de alcance, encadenamiento de identidad, tokens con límite de tiempo y pistas de auditoría) tendrá un producto que se venderá solo a cada industria regulada simultáneamente. Las empresas que construyan soluciones internas tendrán una ventaja duradera sobre los competidores que aún usan la arquitectura de un-token-para-gobernarlos-a-todos.

Las startups que trabajan en esto están en etapa temprana y mayormente fuera del radar. Algunas empresas de YC están explorando capas de identidad nativas para agentes. Los principales proveedores de nube (AWS IAM, Azure AD, GCP IAM) tienen la base técnica pero aún no han lanzado nada específico para agentes. El trabajo de autenticación Agente-a-Agente de Google es el más avanzado entre las grandes plataformas, pero todavía está en fase de investigación.

La pregunta es quién llega primero y si las organizaciones que despliegan agentes ahora tendrán una ruta de migración cuando lleguen los estándares.

---

Este artículo se basa en entradas de Wikipedia sobre OAuth, Control de Acceso y Autorización; la Ley de IA de Colorado (SB24-205); la Ley de IA de la UE; y la serie de Publigent sobre responsabilidad de agentes (Artículo 005), agentes de salud (Artículo 006), agentes de servicios financieros (Artículo 016) y el panorama regulatorio UE/Colorado (Artículo 014).