Conclusiones clave:
La IA encubierta en los extremos se produce cuando los empleados instalan agentes de IA y conectan servidores MCP sin la aprobación ni el control del administrador de TI.
La detección de extremos ya está disponible en acceso anticipado a través de la integración de CrowdStrike Falcon Endpoint Detection and Response (EDR).
Los agentes no administrados ejecutan llamadas a la API en segundo plano, eluden los controles de identidad y conllevan el riesgo de filtración de datos.
Con esta nueva funcionalidad, Okta para agentes de IA ofrece visibilidad de los extremos, asignando las identidades de los agentes directamente a sus propietarios humanos y estableciendo una gobernanza centralizada del ciclo de vida.
¿Qué es la IA en la sombra en el extremo?
La IA en la sombra en el extremo se refiere a las integraciones de software de IA local, LLM y servidores de Model Context Protocol (MCP) implementadas directamente en el hardware del empleado sin adquisición, revisión de seguridad ni Identity Governance. Si bien la IA basada en navegador plantea riesgos de fuga de datos, los agentes de IA de extremo interactúan directamente con los sistemas de archivos locales y los sistemas SaaS a través de servidores MCP en segundo plano.
El riesgo ya no se limita a que los agentes se conecten a través de navegadores. Ahora, cada empleado puede ejecutar varios agentes de IA en su computadora portátil. Es tan fácil que ya no es solo para puestos técnicos. Cualquiera puede hacerlo.
Estos agentes aumentan la velocidad, pero crean un problema de identidad complejo: no hay una aplicación centralizada de la identidad, ni ámbitos definidos, ni registro de auditoría, ni revisión de accesos.
Cómo los servidores MCP amplían la superficie de ataque de los extremos
Los agentes de IA no actúan solos. Para poder realizar cualquier tarea útil, un agente necesita una forma de acceder a diferentes sistemas, y hoy en día eso casi siempre significa el servidor MCP. Es el tejido conectivo entre un agente y todo lo que puede tocar.
Conectar estos agentes a las aplicaciones más sensibles de su organización a través de un servidor MCP solo requiere unos pocos clics. El agente reside en el dispositivo, pero realiza llamadas que llegan directamente a su CRM, aplicaciones SaaS, infraestructura en la nube y más.
La Fundación OWASP documenta el "envenenamiento de herramientas MCP" como un vector de ataque crítico, señalando que, dado que las descripciones de las herramientas normalmente solo se revisan en la conexión inicial, un servidor MCP controlado por un atacante o comprometido puede alterar los metadatos de la herramienta en tiempo de ejecución. Una vez conectadas, las definiciones de herramientas modificadas se cargan en la ventana de contexto del modelo para secuestrar la ejecución y extraer datos.
En caso de incidente, ¿puede su equipo de seguridad identificar a estos agentes, quién es su propietario y a qué aplicaciones y datos pueden acceder? Muchos no pueden.
Y si no puede responder a eso, tampoco puede responder a la primera pregunta del plan maestro para la Enterprise con agentes seguros: ¿Dónde están mis agentes?
Si multiplicamos eso por todos los dispositivos, la exposición se acumula rápidamente.
¿Cómo logran los agentes de IA no supervisados eludir los controles de seguridad empresariales?
Los agentes de IA locales eluden los controles de seguridad empresariales mediante el uso de conexiones MCP no revisadas, heredando permisos de usuario humano sin identidades de agente discretas, manteniendo un acceso permanente y ejecutando modificaciones de herramientas en tiempo de ejecución, todo ello sin generar registros de auditoría de TI centrales.
Detrás de estas vulnerabilidades se esconde una sola causa raíz: la falta de visibilidad de los extremos. Cuando los equipos de seguridad no pueden ver los agentes de IA o los servidores MCP a los que se conectan, los marcos estándar de gestión de identidades y accesos fallan.
Estas son las cinco formas principales en que los agentes pueden eludir sus controles.
1. Los servidores MCP conectan a los agentes con los sistemas empresariales sin su conocimiento.
Crear y conectar servidores MCP que accedan a sistemas sensibles es bastante sencillo, y utilizarlos consiste en ejecutar un único comando en la terminal. Conectar un agente de extremo no autorizado a sus aplicaciones, por ejemplo, a su inquilino de Snowflake, lleva solo unos minutos. Ese agente de IA ahora reside en su sistema más sensible y puede consultar todas las tablas que ve sin su aprobación ni conocimiento.
La promesa de productividad impulsa a sus empleados a conectar estos servidores a agentes de IA sin pensar en las implicaciones de seguridad.
Cuando las medidas de seguridad no dan abasto, las conexiones críticas quedan sin supervisión ni revisión. Eso significa que una conexión a sus datos más confidenciales puede permanecer ahí indefinidamente, sin que nadie sea responsable de lo que toca y sin ningún registro que consultar cuando algo salga mal. Eso es una filtración en potencia.
2. Los datos se transfieren entre sistemas que nunca fueron revisados centralmente.
Un agente mueve datos basándose en su propio criterio sobre lo que resulta útil para la tarea en cuestión. Ese criterio no tiene en cuenta la clasificación de sus datos, las normas de residencia ni quién tiene permiso para ver qué. Nadie aprobó esa decisión. No existe ninguna política que regule a qué puede acceder el agente, por lo que termina conectado a múltiples sistemas a la vez, y esa combinación es la que crea el riesgo.
Por ejemplo, el mismo agente que puede leer los datos de los clientes también puede enviar correos electrónicos a cualquier persona. Así es como se ven los permisos amplios, que otorgan a sus agentes la capacidad de ver más datos de los que necesitan para completar una sola acción. El resultado: basta con una sola solicitud de acceso comprometida para desencadenar una filtración importante.
3. Los agentes actúan a través del acceso de otra persona, sin tener una identidad propia
Los agentes suelen autenticarse en los sistemas mediante una concesión de OAuth o una clave de API almacenada en el archivo de configuración del servidor MCP. Una vez que está ahí, no hay forma confiable de determinar si una acción provino de la persona o del agente que actúa en su nombre. Están unidos bajo la misma identidad. Entonces, cuando algo sale mal, no puede responder a la primera pregunta que cualquiera le hará: ¿fue la persona o el agente?
Por ejemplo, un agente de un empleado de contabilidad actualiza el registro de pagos a proveedores durante la noche. El registro muestra que el cambio provino de las credenciales del empleado, pero no hay forma de saber si lo hizo el empleado o su agente, ni si fue revisado.
Para responder a la pregunta de quién actuó, es necesario extraer los registros de cada sistema con el que interactuó el agente y cotejar manualmente las marcas de tiempo en formatos que nunca fueron diseñados para comunicarse entre sí. Lo que debería llevar minutos se convierte en días dedicados a reconstruir una sola acción a través de sistemas desconectados.
4. Los agentes solicitan permiso solo una vez y obtienen acceso permanente
Hasta hace unos meses, la mayoría de nosotros seguíamos desconfiando de lo que hacían los agentes de IA. Nos deteníamos a comprobarlo siempre que un agente necesitaba permisos adicionales o quería llamar a una API del sistema. Ahora, les permitimos funcionar de forma autónoma. Las herramientas de agentes incluyen modos automáticos en los que el agente sigue funcionando mediante llamadas a herramientas por sí solo, con reglas de permiso y denegación que se configuran una sola vez.
Tomemos este ejemplo: un empleado asigna a su agente una tarea compleja y de larga duración y la configura para que se ejecute automáticamente. En algún punto del proceso, el agente decide por sí mismo que modificar los registros en Salesforce o Snowflake es la forma correcta de completar la tarea, y así lo hace. El empleado nunca aprobó esa acción en concreto y puede que ni siquiera se haya dado cuenta de que ocurrió. Nadie revisa el cambio hasta que algo se rompe o parece estar mal.
5. El servidor MCP otorga a los agentes acceso que no controla
Un servidor MCP proporciona a su agente una lista de herramientas, cada una con una descripción que explica cuándo y cómo utilizarla. Quienquiera que haya escrito ese servidor escribió esas descripciones, no sus equipos de TI y seguridad. Su usuario vio un nombre en un menú e hizo clic en “Aprobar”, sin verificar quién construyó el servidor ni qué ejecuta.
Y las descripciones no son fijas. Si el propietario del servidor MCP edita una descripción, cambia un permiso o agrega una herramienta, su agente lo obtiene automáticamente, sin reaprobación ni revisión. Lo que se ejecutó el lunes no es necesariamente lo que se ejecuta el viernes.
He aquí un ejemplo: un empleado añade una herramienta para su agente. El propietario del servidor MCP implementa una actualización que modifica su comportamiento. La próxima vez que el agente se conecte, heredará la nueva funcionalidad sin necesidad de alerta ni de una segunda aprobación.
Cómo los equipos de seguridad pueden descubrir y proteger la IA en la sombra de los extremos con Okta para agentes de IA
No se puede definir el ámbito, revisar ni revocar un agente que nunca se ha visto, y no se puede confiar plenamente en uno que no se ha sometido a la Identity Governance.
Okta for AI Agents está diseñado para cerrar esta brecha.
1. Detección de extremos: vea cada agente y servidor MCP que se ejecuta en el extremo
Okta se integra con los sensores de extremo existentes, ahora disponibles con CrowdStrike Falcon EDR, para descubrir agentes de IA y servidores MCP conectados. No se requieren agentes adicionales en los extremos. Esto amplía la cobertura de detección de Okta a los agentes que se ejecutan fuera del navegador y que, de otro modo, no aparecerían a través de los permisos de OAuth. Okta Verify es la próxima fuente que incorporaremos, por lo que la detección de extremos no dependerá de ningún EDR en particular, y posteriormente se prevé añadir soporte con plataformas EDR adicionales.
2. Registrarse como identidades de primera clase: inscripción en el directorio centralizado
Los agentes se registran en Universal Directory junto con sus otras identidades no humanas, agentes de IA e incluso identidades humanas. A cada agente se le asigna una identidad única. Con esta herramienta, puede definir a qué puede acceder ese agente y obtener un registro de auditoría completo.
3. Mapeo de identidad y correlación: vinculación de agentes con propietarios humanos
Los agentes detectados están vinculados a la cuenta humana autenticada específica, lo que proporciona a los equipos de seguridad una visibilidad completa de las entidades humanas y no humanas en un solo lugar. Ese mapeo se mantiene incluso ante los cambios: a medida que los propietarios cambian de rol o se marchan, y a medida que se crean subagentes en una cadena de delegación, el contexto de propiedad permanece correlacionado en lugar de perderse.
4. Autorización en tiempo de ejecución: aplicación de políticas en el punto de acción
Aplique la política de acceso cada vez que se ejecute una llamada a una herramienta, no solo una vez durante la configuración, con Agent Gateway. Los agentes solo disponen de tokens de corta duración en lugar de credenciales permanentes, y el acceso puede revocarse instantáneamente en la puerta de enlace, sin tener que esperar a la siguiente revisión de acceso para detectar cambios.
5. Gobernanza continua del acceso: revisiones de acceso y revocación del acceso
Realice revisiones periódicas de acceso que incluyan a los agentes junto con las identidades humanas, para que los equipos de seguridad puedan demostrar a los auditores que el acceso de cada agente fue revisado y aprobado. Y cuando un agente se desvía o se ve comprometido, un interruptor de seguridad lo desactiva y finaliza cualquier nuevo acceso a través de todos los sistemas conectados con los que haya interactuado.
Tome el control de la IA de su empresa.
Obtenga el plan maestro para la Enterprise con agentes seguros para obtener más información sobre cómo escalar de forma segura la IA de su Enterprise.
Disponibilidad: La función destacada Shadow IA agente detección para extremos ya está disponible en acceso anticipado para los clientes de Identity Security Posture Management y Okta for IA agentes a través de la integración de CrowdStrike Falcon EDR. Si ya utiliza CrowdStrike, el sensor que tiene es la fuente y no se envía nada nuevo al extremo.
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. Estas menciones no son compromisos de entrega y no deben considerarse como base para tomar decisiones de compra. © Okta, Inc. o sus filiales 2026.
