Los sistemas agentic son aplicaciones en las que agentes autónomos planifican, razonan y actúan en múltiples servicios. Estas aplicaciones están diseñadas para ir más allá de las simples interacciones de solicitud/respuesta.
A diferencia de los microservicios tradicionales basados en API, que dependen del esquema de la carga útil de la solicitud e interpretan las solicitudes sintácticamente, las aplicaciones de agentes utilizan modelos de lenguaje grande (LLM) para interpretar las solicitudes semánticamente. Esto les permite planificar tareas de varios pasos, encadenar acciones e invocar múltiples servicios de forma autónoma en nombre de un usuario.
A medida que estos sistemas maduran, se asemejan cada vez más a aplicaciones distribuidas compuestas por agentes, servicios y API externas débilmente acoplados que trabajan en conjunto. Con esta flexibilidad añadida, surge una mayor complejidad y la necesidad de un enfoque coherente y seguro de la identidad.
Problemas de seguridad que plantean los sistemas agentic
Un desafío central en estos entornos es la propagación de la identidad, asegurando que la identidad y la intención de un usuario puedan ser transportadas de forma segura a través de agentes, servicios y herramientas. Sin una autenticación y autorización sólidas, un agente podría invocar un servicio sin el contexto correcto, extralimitarse en sus privilegios o eludir las políticas empresariales.
Okta Cross-App Access proporciona una forma basada en estándares para intercambiar tokens de identidad entre aplicaciones. Combinado con el Model Context Protocol (MCP), que brinda a los agentes una forma consistente de descubrir y llamar a las herramientas, estas capacidades crean una estructura confiable que une a los usuarios, agentes y servicios.
Las siguientes secciones ilustran una arquitectura de muestra para integrar Okta Cross-App Access con agentes de IA que se ejecutan en servicios sin servidor de Amazon Web Services (AWS), como AWS Lambda o Amazon Elastic Container Service, para resolver estos desafíos. Verá cómo un usuario se autentica con Okta, cómo su identidad se propaga a través de los agentes mediante el intercambio de tokens y cómo los servicios downstream validan y aplican el acceso.
Al combinar la plataforma de identidad empresarial de Okta con los servicios de AWS sin servidor y de contenedores, las organizaciones pueden permitir una colaboración segura de agente a agente y de agente a servicio a escala.
Arquitectura de la solución
Esta sección describe un diseño integral de muestra que vincula la identidad de Okta a las llamadas de agente a servicio en AWS, con MCP proporcionando un protocolo consistente para que los agentes descubran e invoquen herramientas. Verá los componentes principales, el flujo de tokens y cómo la identidad se propaga y se aplica en cada salto.
Flujos de autenticación y autorización
La arquitectura de muestra comienza con un usuario que interactúa con una aplicación cliente agentic, como una interfaz web o de escritorio. El cliente se integra con Okta utilizando OpenID Connect (OIDC) para gestionar la autenticación. Una vez que ha iniciado sesión, el cliente recibe un token de ID que representa la identidad del usuario. En lugar de usar ese token directamente para las llamadas descendentes, el cliente aprovecha el SDK de Cross-App Access (XAA) para intercambiarlo por una Identity Assertion Grant (ID-JAG), que está vinculada a una audiencia descendente específica. Esto establece la base para la propagación segura de la identidad a través de las aplicaciones.
El ID-JAG se presenta a un servicio de autorización que se ejecuta en AWS, como se ilustra en el diagrama anterior. Este servicio verifica la aserción y emite un token de acceso de corta duración y restringido a la audiencia. Ese token está específicamente dentro del alcance del recurso al que el agente necesita llamar. Al introducir este paso, puedes aplicar límites de confianza claros y asegurar el acceso con privilegios mínimos a los servicios downstream.
Con el token de acceso en la mano, el agente puede llamar a herramientas y recursos alojados en los servidores MCP. Cada servidor MCP valida el token entrante antes de realizar cualquier acción. Estas herramientas y recursos pueden, a su vez, llamar a recursos protegidos posteriores, como las API de servicio. En caso de que estos servicios se ejecuten en AWS, pueden hacer cumplir sus propias políticas, basándose en los roles IAM y validando las reclamaciones de tokens, como la identidad del usuario, el alcance y el inquilino. Esta aplicación en capas asegura que la identidad, la intención y la autorización se transmitan de manera consistente desde el usuario hasta los sistemas de backend.
Consideraciones y mejores prácticas
Al crear aplicaciones de agentes seguros, los equipos de ingeniería deben adoptar controles de seguridad estrictos y las mejores prácticas comprobadas. Los siguientes principios proporcionan una base sólida para construir de forma segura sistemas de agentes y servidores MCP.
Validación de identidad
Valide la identidad en cada límite. Cada agente de IA y servidor MCP debe verificar de forma independiente los tokens de acceso, comprobando el emisor, la audiencia, el alcance, la firma y el vencimiento. Nunca confíe únicamente en la validación ascendente; esto asegura que los agentes no puedan eludir la aplicación encadenando llamadas.
Gestión de tokens
Utilice tokens de alcance limitado y de corta duración. Siempre siga el principio de acceso con privilegios mínimos y limite los tokens a los permisos mínimos requeridos. Los tokens de acceso emitidos para los agentes deben ser válidos solo por un corto período (minutos, no horas) y estar vinculados a herramientas MCP específicas (por ejemplo, documents.read vs. documents.write). Si un agente necesita invocar otra herramienta, realice un intercambio de tokens para emitir un nuevo token con un alcance más limitado.
Propagación de contexto
Propagar el contexto del usuario de forma segura. Utilice Okta Cross‑App Access para transportar la identidad a través de los servicios. Cuando los agentes invocan servidores MCP, incluya reclamaciones como el sujeto, el usuario final (sub), la parte autorizada (azp), la audiencia (aud) y el acto para rastrear la ejecución en nombre de. Esto garantiza que los servicios descendentes puedan aplicar políticas sabiendo tanto quién inició la solicitud como por qué se hizo.
Observabilidad y auditoría
Audite y rastree las cadenas de agentes de extremo a extremo. Registre eventos estructurados y decisiones de autenticación en cada segmento, mostrando el seguimiento completo del actor (por ejemplo: usuario → agente → herramienta MCP), los alcances utilizados y las decisiones tomadas. Utilice servicios de observabilidad como Amazon CloudWatch y AWS X-Ray para rastrear solicitudes a través de múltiples agentes y herramientas, para responder preguntas como: "¿Quién le pidió al agente que actuara?" ¿Qué herramienta se invocó? ¿A qué datos se accedió?
Prácticas recomendadas específicas de AWS
- Roles de IAM: use los permisos mínimos requeridos para los roles de ejecución de la función Lambda. Evite reutilizar los roles de ejecución en varias funciones.
- Puerta de enlace API: Use autorizadores Lambda para proteger sus API. Habilite CORS, la limitación de velocidad y WAF. Considere mTLS cuando se comunique entre los componentes del sistema.
- CloudWatch: Utilizar para el registro centralizado con políticas de retención, métricas operativas y de negocio, y rastreo de extremo a extremo.
- Configuración de VPC: Considere usar VPC para aislamiento de red adicional si es necesario.
Las aplicaciones agentic abren la puerta a nuevas formas de automatizar tareas y conectar servicios, pero también introducen nuevas consideraciones de seguridad. Cada agente y servidor MCP debe operar con el contexto de usuario correcto, aplicar el mínimo privilegio y dejar un registro de auditoría claro. Sin bases sólidas en la autenticación, la autorización y la propagación de la identidad, estos sistemas pueden volverse rápidamente inmanejables o inseguros.
Al combinar las soluciones de acceso entre aplicaciones y de identidad de Okta con los servicios "serverless" y de contenedores de AWS, las organizaciones pueden crear sistemas "agentic" que se escalan de forma segura. El enfoque descrito en esta publicación demuestra cómo autenticar usuarios, propagar su identidad a través de agentes, emitir "scoped tokens" para las herramientas MCP y hacer cumplir la política en cada límite.
Implementar sus agentes de IA utilizando las tecnologías sin servidor de AWS ofrece varias ventajas:
- Escalabilidad y confiabilidad: Sus cargas de trabajo se distribuyen automáticamente en varias zonas de disponibilidad y se escalan de forma autónoma según los patrones de tráfico.
- Optimización de costos: Modelo de precios de pago por uso; solo paga por lo que usa.
- Infraestructura administrada: AWS maneja completamente la administración de la infraestructura por usted, incluidas las operaciones, la seguridad y la resiliencia.
- Integración: Integraciones nativas con una multitud de servicios de AWS.
- Observabilidad incorporada: Monitoreo integral con CloudWatch y X-Ray.
Para obtener más información, explore la documentación de Okta Cross-App Access y los servicios AWS serverless.
Recursos
- Okta Cross-App Access
- Especificación MCP
- Documentación de AWS Lambda
- Documentación de AWS SAM
- Documentación de API Gateway
