Nota del editor: Descubre cómo desbloquear esto en el último episodio de Streamcast, “El plan maestro para la empresa segura y autónoma”, donde pasamos de la teoría a la demostración. Aprenderás exactamente cómo el plan de la empresa agencial segura se convierte en controles prácticos para herramientas como Claude Code y Cursor.
Sus equipos de IA no pueden permitirse que las brechas en la gobernanza ralenticen el despliegue. Necesitan poner a los agentes de IA a trabajar ahora.
Según una encuesta de 2026 entre líderes tecnológicos sénior, el 90 % de las organizaciones no tienen forma de gobernar lo que los agentes en producción están haciendo realmente. Alrededor del 54 % ya ha sufrido un incidente de seguridad relacionado con un agente que actuó de manera inesperada.
Estos agentes llaman a APIs, leen registros sensibles, delegan tareas a otros agentes y toman decisiones sin esperar la intervención humana. La pregunta no es si su organización tiene agentes que operen de esta manera; es si tiene algún control significativo sobre lo que hacen cuando lo hacen. Para la mayoría de las empresas hoy en día, la respuesta honesta es no.
La razón por la que la respuesta es no es casi siempre un problema de gobernanza de identidad. Todo agente de IA en producción opera o bien a través de una capa de identidad regulada o la elude. La mayoría está corriendo alrededor de uno.
Donde la gobernanza de la identidad ahora llega más lejos.
Para ser una empresa autónoma y segura, necesitas un plan maestro que te ayude a responder tres preguntas críticas:
- ¿Dónde están mis agentes?
- ¿Con qué se pueden conectar?
- ¿Qué pueden hacer?
Las capacidades cubiertas en este blog son nuevas mejoras que avanzan aún más el plan maestro para la empresa agentiva segura en exactamente las dos últimas preguntas. Ayudan a los equipos de IA a lanzar más rápido, y los equipos de seguridad obtienen la aplicación de políticas en tiempo real, los controles de respuesta y la auditabilidad que necesitan para dar el visto bueno.
¿Con qué se pueden conectar?
En algún lugar de su organización, en este momento, un agente de IA podría estar transfiriendo discretamente tareas a otro agente.
Aquí está el problema: cada una de esas transferencias es un evento de acceso que la empresa necesita gobernar. Y sin una capa de identidad, la mayoría de los equipos de seguridad no tienen visibilidad sobre ellos.
La mayoría de las empresas están creando flujos de trabajo con múltiples agentes de dos formas:
- Flujos de trabajo iniciados por el usuario: Un empleado pide a un agente asistente ejecutivo que prepare una presentación de revisión trimestral del negocio. El agente orquesta un enjambre de agentes, cada uno actuando en nombre del usuario y limitado a lo que el usuario tiene permitido acceder. El ser humano es el ancla, mientras la identidad fluye en cada transferencia.
- Flujos de trabajo iniciados por la máquina: Un servicio de monitoreo detecta una anomalía y activa un agente de diagnóstico, que delega en un agente de análisis de registros para investigar más a fondo. Sin sesión de usuario ni supervisión humana. La autoridad del servicio fluye hacia abajo a través de cada agente de la cadena.
Ambos patrones comparten la misma necesidad de gobernanza: cada cesión es un evento de acceso que debe ser autorizado, acotado y registrado. Cuando los agentes de IA se comunican sin una capa de identidad dedicada, las organizaciones corren el riesgo de perder la capacidad de verificar la identidad del actor detrás de cada solicitud, hacer cumplir las políticas de manera consistente o rastrear las acciones hasta su origen.
Agent-to-Agent Connections: asegure los flujos de trabajo de múltiples agentes
Agent-to-Agent Connections, una nueva capacidad dentro de Okta para agentes de IA, cierra esa brecha. Te permite definir políticas de conexión por agente: qué servicios y agentes upstream pueden invocar a este agente, su alcance y la duración del permiso. La identidad se conserva en cada transferencia, por lo que cada conexión permanece verificable a lo largo de todo el flujo de trabajo.
Tres principios hacen que esto funcione:
- Listas blancas explícitas definen qué agentes pueden llamar a qué otros agentes.
- Permisos delimitados otorgan a cada agente aguas abajo solo lo que necesita para su tarea.
- Una cadena verificable viaja con cada token, por lo que el registro de auditoría captura quién autorizó qué.
Esto es lo que significa gobernar a qué agentes se pueden conectar en la capa de agente a agente: qué agentes pueden invocar a qué otros agentes, bajo qué condiciones, con qué alcance y con pruebas que puedan presentarse ante cualquier auditor o equipo de respuesta a incidentes que lo solicite.
Disponibilidad: el acceso anticipado a Agent-to-Agent Connections ya está disponible. Lea más sobre cómo asegurar sus flujos de trabajo multiagente con Agent-to-Agent Connections.
Asistentes de codificación de IA seguros como Claude Code, Microsoft 365 Copilot y Cursor
Las conexiones de agente a agente son un aspecto del problema de conectividad. Otra brecha importante son las herramientas de IA no reguladas que sus desarrolladores ya están usando para conectarse a sus sistemas. Estos incluyen asistentes de codificación con IA como Claude Code, Cursor, Microsoft 365 Copilot, GitHub Copilot y Glean.
Estas herramientas están integradas en los flujos de trabajo diarios y conectadas a sistemas internos como Jira, ServiceNow, GitHub y sus API internas.
El problema es cómo están entrando. La mayoría de estas herramientas no fueron diseñadas para autenticarse mediante un proveedor de identidad. Obtienen acceso a través de tokens codificados de forma fija, credenciales ad hoc y claves de API almacenadas en archivos de configuración. No hay autorización centralizada. No hay registro de auditoría. Los equipos de seguridad a menudo no tienen visibilidad de qué agentes accedieron a qué sistemas, en nombre de quién o qué hicieron al llegar.
El MCP Bridge aborda esto sin necesidad de realizar cambios en los propios agentes. Un proxy autoalojado y consciente de la identidad se sitúa entre sus agentes y las herramientas del Protocolo de Contexto de Modelo (MCP) a las que se conectan. Cada llamada pasa por el puente. Cada agente se autentica a través de su proveedor de identidad. Cada acción queda registrada en su registro de auditoría. El agente no necesita ser reescrito. El desarrollador tampoco necesita cambiar su flujo de trabajo.
El puente se ejecuta en el entorno del cliente, por lo que los datos permanecen dentro del perímetro. Ningún servicio externo ve lo que pasa por él. El cliente controla el despliegue, la configuración y los datos.
Disponibilidad: El MCP Bridge es una oferta de servicios profesionales y requiere una Declaración de Trabajo (SOW).
¿Qué pueden hacer?
Regular lo que los agentes pueden hacer requiere que la capa de identidad vaya más allá del acceso inicial. Un token de acceso permite que un agente pase por la puerta; no regula lo que hace una vez allí.
Autorización de agentes de IA: hacer cumplir la autorización en tiempo de ejecución para cada acción de un agente de IA.
Los permisos de un usuario pueden cambiar después de que se emita un token. Un contratista puede abandonar un proyecto. Un paciente puede retirar su consentimiento. Un gerente puede irse de vacaciones. Los roles estáticos y los tokens de acceso no pueden mantenerse al día con esos cambios. En lugar de preguntar: «¿Este usuario o agente tiene acceso al sistema?» La autorización del agente de IA plantea una pregunta más precisa: “¿Puede este agente, actuando en nombre de este usuario, realizar esta acción sobre este recurso en este momento?”
Esa distinción importa porque las condiciones de autorización cambian constantemente. La autorización de grano fino (FGA) es una autorización que considera el contexto en lugar de basarse únicamente en el rol. Comprueba si, en tiempo de ejecución, el usuario en cuyo nombre actúa un agente cuenta con la relación requerida, los atributos actuales y las condiciones de la política para llevar a cabo una acción específica sobre un recurso determinado.
Esto incluye relaciones directas y heredadas, atributos dinámicos como el nivel de autorización o el estado de servicio, y umbrales de política, tales como límites de cantidad, montos en dólares o reglas de clasificación de datos.
Por ejemplo, un agente de adquisiciones puede aprobar facturas de hasta $10 000 para el usuario en cuyo nombre actúa, pero no por encima de ese umbral. FGA verifica el límite de aprobación del usuario en tiempo de ejecución, no solo su rol.
Gobernar lo que los agentes pueden hacer requiere algo más que permisos estáticos establecidos durante el despliegue. Requiere la evaluación continua de todas las acciones, de todos los agentes, en tiempo real. Así es como controla lo que un agente realmente hace.
Disponibilidad: esta es una implementación de un caso de uso de FGA y Okta for AI Agents.
Interruptor de emergencia: apague un agente que actúa por su cuenta justo cuando lo necesite.
La gobernanza incorporada desde el inicio reduce la probabilidad de que algo salga mal, pero no significa que no vaya a ocurrir. Los agentes son impredecibles por diseño. Ellos toman decisiones, se desplazan a través de sistemas y pueden realizar acciones que nadie anticipó. Cuando eso ocurra, los equipos de seguridad deben responder de inmediato.
Muchas implementaciones de agentes de IA hoy en día no tienen forma de apagar a un agente cuando se comporta de manera inesperada. Cuando el consejo de administración pregunta cuál es el plan de respuesta si un agente actúa de forma maliciosa, la mayoría de los CISOs no tienen una respuesta.
Eso cambia con un interruptor de emergencia. Para los agentes que se conectan a través de Okta, revocar el acceso bloquea el acceso a los recursos conectados con una sola acción desde la Consola de administración de Okta. No necesitas confirmar que un agente esté comprometido para usarlo. Una configuración errónea, una acción fuera del alcance o un comportamiento que plantee dudas. Cualquiera de estas razones es motivo suficiente para desactivar al agente de inmediato, mientras investigas más a fondo lo sucedido.
¿El resultado? Los equipos de IA pueden lanzar sus productos sabiendo que cuentan con una red de seguridad. Los equipos de seguridad pueden aprobar los despliegues sabiendo que podrán responder si algo sale mal. Cuando sepas que puedes detenerlo, puedes aprobarlo.
Disponibilidad: la función de corte de emergencia está generalmente disponible y está incluida en Okta para agentes de IA. Próximamente: detección que lee señales de riesgo de todo el ecosistema de Okta, aumenta la puntuación de riesgo del agente y activa automáticamente el interruptor de emergencia.
Todo agente necesita una capa de identidad.
Estas capacidades abordan diferentes partes del problema de gobernanza de agentes, pero comparten una premisa común. Las primitivas de identidad que protegen a su personal y a sus aplicaciones también deben extenderse a los agentes. Esto incluye gobernar las conexiones entre ellos, las acciones que realizan, las herramientas que utilizan y su capacidad para detenerlos cuando algo sale mal.
Gobernar a los agentes de esta manera requiere una capa de identidad autorizada y en tiempo real que ya abarque su fuerza laboral y sus aplicaciones. Okta se encuentra en esa capa.
Las empresas que lo hagan bien desde el principio no solo reducirán los incidentes. Se moverán más rápido. El descubrimiento, la seguridad y la gobernanza incorporados desde el principio no ralentizan el despliegue de la IA. Son los que hacen posible la escalabilidad. Establece la base ahora y tu equipo de seguridad dejará de ser el cuello de botella en los despliegues de agentes, convirtiéndose en la razón de su éxito.
Para obtener más información sobre estas actualizaciones, incluidas las demostraciones, vea el seminario web de Streamcast.
Estos materiales se ofrecen únicamente con fines informativos generales y no constituyen asesoramiento legal, de privacidad, de seguridad, de cumplimiento ni empresarial. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales. Cualquier mención de productos, funciones, funcionalidades o certificaciones futuras en este blog es únicamente con fines informativos. Estos elementos no son compromisos de entrega y no deben considerarse como base para tomar decisiones de compra. © Okta, Inc. y sus filiales, 2026.
