Resumen ejecutivo
Al ritmo actual de aceleración de la IA agentic, ya no parece profético decir que, en poco tiempo, habrá más agentes de IA conectados a aplicaciones y datos de producción que usuarios humanos.
Habrá profundas implicaciones para el lugar de trabajo, con algunas estimaciones de que la mitad de la fuerza laboral de cuello blanco podría no estar empleada en un plazo de cinco años. También existen profundas implicaciones para la ciberseguridad.
La IA agentic presenta riesgos novedosos, como los ataques de inyección de prompts, en los que los agentes de IA son efectivamente “víctimas de ingeniería social” para que actúen en nombre de un atacante tras haber sido expuestos a entradas no confiables.
Como empresa de identidad, la preocupación más grande e inmediata de Okta es cómo la IA agentic aumenta la superficie de ataque de cada organización desde una perspectiva de autenticación y autorización. Podemos esperar de manera confiable que los atacantes descubran y abusen de las innumerables contraseñas de cuentas de servicio y las claves de API estáticas que los desarrolladores están generando para otorgar a los agentes de IA acceso a los recursos corporativos. También podemos esperar de manera confiable que la amplia autorización otorgada a los agentes de IA exacerbe la posible pérdida de datos por el compromiso de cualquier cuenta dada.
Este documento está destinado a servir como guía para proveedores de servicios, Organizations y Developers que experimentan con la IA agentic con el fin de crear aplicaciones de producción.
El papel que juega la IA en la deuda de identidad
La deuda de identidad se acumula cuando se permite que secretos compartidos y estáticos se acumulen con el tiempo en un sistema. Un secreto se comparte cuando es conocido o almacenado por más de un usuario o en más de un lugar. Un secreto es estático cuando es de larga duración y pasa largos períodos de tiempo sin ser rotado.
Nuestra investigación descubrió que la IA Agentic está contribuyendo a una aceleración en esta acumulación de deuda de identidad. Las organizaciones deben confiar en métodos de nivel empresarial para autorizar a un cliente (aplicación de IA) a actuar en nombre de un usuario en un recurso protegido (aplicaciones y datos).
Nuestra investigación encontró lo contrario. Los métodos más utilizados para autorizar el acceso de un agente de IA a funciones y datos en aplicaciones SaaS, repositorios de código, bases de datos y otros recursos resultan en la exposición de secretos altamente privilegiados.
La tabla en la página siguiente evalúa las propiedades de seguridad de varios enfoques de autorización.
Complementos agénticos: los precursores de MCP
Un estudio de los complementos de Copilot
Nuestra investigación encontró que la mayoría de los métodos de autenticación de máquina a máquina utilizados para conectar agentes de IA a recursos protegidos (aplicaciones y datos Enterprise) utilizan formas de autenticación que no son aptas para su propósito en entornos de producción, con poco o ningún control sobre la autorización.
Para ilustrar, evaluamos los métodos de autenticación disponibles para permitir que los agentes de Microsoft Copilot Al accedan a algunos de los datos más confidenciales de la Enterprise: las aplicaciones de seguridad.
Copilot se encuentra entre los asistentes de IA de propósito general dominantes del mundo. Microsoft ofrece la capacidad de crear "complementos" para Microsoft Copilot con el fin de exponer las características de aplicaciones de seguridad de terceros a las aplicaciones de Microsoft (bajo la marca "Microsoft Security Copilot"). Cada complemento de Microsoft Security Copilot se configura en un archivo YAML o JSON (un manifiesto de complemento) que describe qué herramientas en el servicio externo están disponibles para el agente de Copilot.
Usando estos servicios:
- Microsoft Copilot actúa como la aplicación anfitriona
- Las herramientas y los datos de las aplicaciones de seguridad, como Splunk, SentinelOne, Forescout o Cyberark, son recursos protegidos.
Un cliente mutuo (de ambos servicios) primero debe autorizar a Copilot para acceder a los recursos protegidos en su nombre. Esto requiere que el cliente proporcione a Copilot credenciales (contraseñas, claves de API o el ID de cliente y el secreto de cliente en un flujo de OAuth), que se almacenan en reposo en los servidores de Microsoft. Los esquemas disponibles se enumeran en la siguiente tabla.
Security Copilot admite varios esquemas para autenticar complementos:
Figura 2: Opciones de autenticación para Microsoft Security Copilot. Fuente: Microsoft
Cuando un usuario indica a Copilot que utilice un recurso protegido, Copilot Al analiza la solicitud y determina qué complemento anuncia la "habilidad" relevante (tal como se define en el manifiesto del complemento) de la que se va a extraer. A continuación, Copilot utiliza las credenciales almacenadas para realizar una llamada API autenticada a la aplicación de terceros, que recupera los datos o realiza una acción y devuelve un resultado a Copilot. Buscamos comprender qué métodos de autenticación se utilizaban para conectar estos recursos protegidos (aplicaciones de seguridad) a Microsoft Copilot. 5
De nuestro análisis de los manifiestos de complementos de terceros publicados en GitHub, encontramos:
- El 20 % admite la Autenticación Básica
- El 75% apoya el método ApiKey
- El 5% da soporte a un flujo OAuth2
Los riesgos asociados con el uso de un complemento Copilot IA dependen en gran medida de (a) esta elección del método de autenticación y (b) el alcance del acceso proporcionado al agente.
autenticación básica
Usando la Autenticación Básica, los administradores deben crear una cuenta de servicio en la aplicación de terceros y cargar el nombre de usuario y la contraseña a los servidores de Microsoft. Copilot luego envía el nombre de usuario y la contraseña en el encabezado de cada solicitud a la aplicación de seguridad (siempre que Copilot seleccione esa herramienta basándose en una indicación del usuario).
Figuras 3 y 4: Capturas de pantalla de la documentación de ayuda del complemento de seguridad de Microsoft
Por definición, las cuentas de usuario o de servicio configuradas para permitir que un agente de IA acceda a los recursos mediante el esquema http:basic (autenticación básica) no pueden admitir la autenticación multifactor.
Los clientes que utilizan este esquema deben, por consiguiente, exponer cuentas de usuario o de servicio (que a menudo tienen un amplio acceso a datos confidenciales) a ataques de relleno de credenciales y spray de contraseñas.
APIKey
Tres de cada cuatro complementos de Microsoft Security Copilot se pueden autorizar utilizando el método APIKey.
Durante la configuración, los administradores crean un token de API de larga duración en el recurso protegido, que normalmente se crea en el contexto de una cuenta de usuario o de servicio, y cargan manualmente el token de API a los servidores de Microsoft. Copilot envía el token de API en el encabezado de cada solicitud HTTP que realiza al recurso protegido (es decir, cada vez que Copilot selecciona esa herramienta de seguridad basándose en una solicitud del usuario).
Las claves de API estáticas ofrecen varias ventajas sobre la autenticación básica:
- Las claves de API se adaptan mejor a los flujos de máquina a máquina. Cada token de API único a menudo se puede configurar para que caduque después de la inactividad o una duración establecida. La revocación de la clave no tiene ningún impacto en el usuario o la cuenta de servicio que la creó.
- Ahora se puede proteger el acceso a la cuenta de servicio utilizada para crear el token de API mediante la Autenticación Multifactor (MFA).
- Es más probable que los administradores limiten el "alcance" de lo que un token de API se puede usar para leer o modificar, en comparación con los permisos de una cuenta de servicio utilizada para la autenticación básica.
Los riesgos residuales son que estos tokens de API suelen ser de larga duración. Las claves de API se registran rutinariamente en los sistemas de control de código fuente. Las claves de API se almacenan rutinariamente en los registros cuando se establecen como parámetros de consulta. Ocasionalmente, las claves de API se guardan en archivos de texto en la estación de trabajo del desarrollador, listas para ser recopiladas por el próximo ladrón de información genérico que infecte el dispositivo.
Figura 5: El acceso al token al que se hace referencia en este complemento de Copilot proporciona acceso a datos sobre todos los dispositivos de una organización.
Los tokens de API estáticos son muy valorados por los atacantes, y lo primero que muchos atacantes buscan después de comprometer un sistema. Una vez interceptados, estos tokens suelen ser válidos durante largos períodos de tiempo, lo que los convierte en candidatos ideales para su reventa en mercados en línea.
Los tokens de API estáticos también presentan riesgos de disponibilidad, al menos en comparación con los tokens temporales creados en los flujos de OAuth, ya que los tokens estáticos tienden a crearse en el contexto de un usuario en lugar de una aplicación.
En muchos casos, si el usuario o la cuenta de servicio que creó el token se elimina o se desaprovisiona, el token se elimina con él y rompe cualquier integración M2M que haya unido.
OAuth2
El pequeño resto de los complementos de Microsoft Security Copilot parece utilizar flujos OAuth2 de nivel empresarial.
En estos esquemas, un ID de cliente y un secreto de cliente (compartido con Microsoft) se intercambian con un servidor de autorización para obtener un token de acceso de corta duración, que es validado independientemente por el servidor de recursos.
Si estos flujos se crearon en Okta, los tokens de acceso resultantes pueden tener restricción de IP (solo válidos desde un rango de IP configurado) y restricción de cliente (solo válidos desde el cliente que lo solicitó). Los alcances se establecen a nivel de la aplicación de servicio, no a nivel del usuario, lo que significa que los administradores no desactivan accidentalmente las integraciones de máquina a máquina cuando se desaprovisiona una cuenta administrativa o una cuenta de servicio.
Si bien es decepcionante observar que tan pocos agentes de Copilot están diseñados para la autenticación de nivel empresarial, en muchos aspectos estas elecciones son un reflejo de los métodos de autenticación existentes disponibles por las aplicaciones de seguridad. En el contexto de la integración con una sola herramienta de IA propietaria, estos proveedores de seguridad evidentemente no estaban preparados para invertir en la actualización de sus métodos de autenticación disponibles.
Pero, ¿qué pasaría si, en lugar de escribir manifiestos de complementos para cada aplicación de Al, los Developers pudieran construir un único servidor con un estándar de la industria compatible con todos los tipos de aplicación de Al?
Ingrese el Protocolo de Contexto de Modelo.
Modelado de amenazas al Protocolo de Contexto de Modelo
Si eres un Developer de aplicaciones Enterprise, la economía de tener que escribir un nuevo conector personalizado (como un complemento de Microsoft Copilot) para cada variante de modelo de IA está lejos de ser deseable.
Los proveedores de servicios preferirían declarar desde el principio qué datos y herramientas está dispuesta a compartir la empresa con cualquier modelo de IA, definir las condiciones bajo las cuales se exponen estos recursos, definir cómo deben los clientes autorizar el acceso y crear una lista de permitidos de las aplicaciones de IA que pueden acceder a estos recursos.
Por esta razón, el impulso en la IA agentic ahora se está construyendo alrededor del Protocolo de Contexto del Modelo (MCP). MCP es una interfaz estandarizada para conectar aplicaciones de IA (hosts) a servicios empresariales tan diversos como plataformas en la nube, aplicaciones SaaS, repositorios de código, bases de datos e incluso servicios de pago. La arquitectura cliente-servidor de MCP permite el "plug and play" de aplicaciones de IA a las fuentes de datos y herramientas que les proporcionan contexto.
En la Enterprise, MCP promete la capacidad de:
- Determinar qué fuentes de datos y herramientas propiedad de Enterprise están disponibles,
- Permitir que las aplicaciones de IA agentic accedan a fuentes de datos y herramientas de múltiples aplicaciones, sin contaminación cruzada de datos,
- Reduzca el costo de experimentar con diferentes aplicaciones de IA que acceden a esas fuentes de datos y herramientas.
Figura 6: Una descripción visual del Protocolo de Contexto del Modelo (Model Context Protocol o MCP). Fuente: modelcontextprotocol.io
Los servidores MCP se pueden implementar localmente o de forma remota. Esta elección de modelo de implementación para cualquier caso de uso tiene un impacto significativo en el modelo de amenazas resultante.
El alcance de nuestra investigación se limitó a comprender cómo las aplicaciones de Al (hosts), los clientes de MCP y los servidores de MCP gestionan las credenciales. Los componentes centrales que evaluamos fueron:
- Hosts MCP: Todas las aplicaciones, incluidos los entornos de desarrollo integrados (IDE) como Cursor, VS Code o Claude, que requieren acceso a las herramientas anunciadas por los servidores MCP.
- Clientes MCP: Los múltiples clientes que un host MCP utiliza para comunicarse con un servidor MCP emparejado.
- Servidores MCP: Los servidores MCP anuncian las herramientas y los recursos disponibles en un servicio externo y realizan llamadas API a estos servicios.
Servidores MCP locales
El modelo MCP es especialmente atractivo para los casos de uso de desarrollo de software.
Los ingenieros de software que utilizan IDE habilitados para IA, como Cursor y VS Code, pueden crear código localmente mientras aprovechan la asistencia de modelos de IA remotos para hacer sugerencias a medida que el Developer escribe el código.
Anthropic pone su agente Claude Al a disposición para su implementación local como "Claude Desktop". Claude Desktop es un cliente de MacOS y Windows implementado localmente y una alternativa para acceder a los modelos Al de Anthropic a través del navegador. Una ventaja de los servidores MCP locales es que los clientes pueden interactuar tanto con un modelo Al remoto como con archivos locales (documentos, imágenes, etc.).
Estas aplicaciones de escritorio a menudo necesitan autenticarse tanto en el LLM (esto generalmente requiere una clave de API) como en fuentes de datos remotas (como repositorios de código, que requieren un Token de Acceso Personal).
Cuando un usuario lanza la aplicación host, como Claude o Cursor, el cliente MCP genera un servidor MCP y le pasa al servidor cualquier credencial (claves de API, credenciales de base de datos, contraseñas, secretos de cliente de OAuth, etc.) requerida para la operación desde un archivo de configuración local, incluidas las credenciales que el servidor MCP necesita para acceder a los servicios remotos.
Si el servidor MCP está diseñado para acceder a los recursos de Github, por ejemplo, el host requiere que un Token de Acceso Personal (PAT) de Github esté disponible en el archivo de configuración local. El servidor mostrará un error si no se proporciona el PAT de Github.
Figura 7: Un servidor MCP utilizado para acceder a los recursos de GitHub genera un error si no se proporciona un PAT en el archivo de configuración.
A continuación, se proporciona la ubicación de los archivos de configuración para tres de las aplicaciones de desarrollo más populares que utilizan IA:
| aplicación | Archivo de configuración local | Ubicaciones predeterminadas |
|---|---|---|
| Claude Desktop | claude_desktop_config.json | Ubicación predeterminada en MacOS: ~/Library/aplicación soporte/Claude/ Ubicación predeterminada en Windows: ~/AppData/Roaming/Claude |
| Cursor | mcp.json | Ubicación predeterminada cuando se usa globalmente (todos los sistemas operativos): ~/.cursor/mcp.json Si un servidor MCP solo está disponible para un proyecto específico, el archivo de configuración se coloca en el directorio del proyecto. |
| VS Code | settings.json | Ubicación predeterminada en MacOS: ~/Library/soporte de la aplicación/Code/usuario/ Ubicación predeterminada en Windows: ~/AppData/Roaming/Code/usuario |
La investigación de Keith Hoodlet en Trail of Bits señaló los riesgos de almacenar claves API estáticas en texto plano en estos archivos, y citó ejemplos de dónde estos archivos eran legibles por todo el mundo (es decir, al que puede acceder cualquier usuario del sistema).
Ampliando esta investigación, evaluamos los archivos de configuración predeterminados para Claude Desktop, Cursor y VS Code, y observamos los mismos permisos.
Figura 8: Permisos predeterminados para los archivos de configuración de Claude, Cursor y vs code.
Los mismos permisos parecen aplicarse a los archivos de configuración incluidos en numerosas implementaciones oficiales del servidor MCP que se describen como "listas para producción", y para casi todas las integraciones comunitarias desarrolladas por terceros, que no están respaldadas por los proveedores de servicios en cuestión.
Figuras 9 y 10: Una "integración comunitaria" no oficial les pide a los clientes de Okta que carguen un token SSWS a un archivo de configuración local.
Cualquier modelado de amenazas debe anticipar que la gran mayoría de los servidores MCP compartidos hasta la fecha no están aprobados, lo que conlleva mayores riesgos en torno al uso por parte de los Developers de servidores MCP no autorizados.
Un análisis preliminar de VirusTotal de los servidores MCP subidos a GitHub [2] descubrió que el 8% de ellos eran sospechosos. Un número no revelado de ellos incluía código que intenta identificar secretos (claves, contraseñas, etc.) en los mensajes y los publica en extremos externos.
El almacenamiento inseguro de las claves de API presenta una variedad de riesgos, cada uno de los cuales se explora a continuación.
Riesgos asociados con el almacenamiento inseguro de claves API. Claves subidas a repositorios de software
Claves subidas a repositorios de software
La mayoría de la documentación para las implementaciones locales del servidor MCP no advierte a los desarrolladores u otros usuarios sobre los riesgos de almacenar credenciales en texto plano para los recursos de producción en los archivos de configuración. Se supone que los desarrolladores guardarán de forma segura las credenciales, de modo que el archivo de configuración solo haga referencia a una credencial almacenada en una ubicación segura.
Observamos algunos escenarios en los que la configuración de MCP no podía obtener la credencial en tiempo de ejecución a menos que se almacenara en texto plano en el archivo de configuración.
- Una investigación de Gaetan Ferry en GitGuardian de repositorios clonados del registro no oficial del servidor MCP de Smithery.IA encontró 202 ejemplos que contenían al menos un secreto (5.2% de todos los repositorios escaneados). Los tokens de API estáticos (ver "x-api-key") figuraban prominentemente[3].
Fuente: “Una mirada a los secretos de MCP”, GitGuardian, abril de 2025
Las claves están expuestas en los metadatos del contenedor
Ejecutar servidores MCP en contenedores traslada el problema en lugar de mitigarlo. El secreto debe pasarse al contenedor en un formato que admita el servidor MCP.
La revisión de la configuración del contenedor proporciona una referencia directa a un secreto en texto plano, ya sea en forma de un archivo en el host, o por ser capaz de identificar las variables de entorno relevantes en un contenedor que puede ser expuesto ejecutando `docker inspect`, una herramienta de línea de comandos que permite la inspección de recursos de docker.
Figura 11: Un token de acceso personal de GitHub expuesto en los metadatos del contenedor.
Claves accedidas por malware
El malware de robo de información estándar está diseñado para localizar rutas y tipos de archivos específicos donde se almacenan las credenciales.
Por ejemplo:
- Los ladrones de información de Windows, como Vidar Stealer, buscarán secretos almacenados en ~\AppData\Roaming
- Los ladrones de información de MacOS, como Atomic Stealer, buscan secretos almacenados en ~/Library/aplicación y soporte
Es muy probable que el almacenamiento inseguro de tokens de API estáticos en estas ubicaciones provoque eventos impactantes. Mientras que un token de sesión almacenado en esta ubicación proporciona una breve ventana de tiempo en la que un atacante puede obtener acceso a un recurso a nivel de usuario, un API Token estático proporciona acceso persistente a los recursos de toda la organización.
Claves respaldadas en sistemas externos
Las claves quedan expuestas en los volúmenes de copia de seguridad si los administradores no excluyen las carpetas confidenciales (como ~\AppData\Roaming en Windows o ~/Library/aplicación de soporte en MacOS).
Estaciones de trabajo compartidas entre varios usuarios
Dado que se descubrió que los archivos de configuración eran legibles por todo el mundo, las claves almacenadas por un usuario en un dispositivo compartido también son accesibles para otros usuarios que inician sesión en el mismo dispositivo.
Alternativas seguras para el almacenamiento local de credenciales
La sección de recomendaciones de este documento describe soluciones tácticas que minimizan estos riesgos de almacenamiento de credenciales.
Alternativamente, las organizaciones que experimentan con MCP pueden adoptar un enfoque de "seguro por diseño" y utilizar soluciones desarrolladas teniendo en cuenta estas amenazas.
Tomemos el servidor Auth0 MCP, por ejemplo [4]. El servidor Autho MCP ofrece a los administradores la capacidad de autorizar el acceso a los recursos de Autho desde aplicaciones locales Claude Desktop, Cursor o Windsurf utilizando el flujo de Autorización de Código de Dispositivo OAuth 2.0.
Figura 12: Flujo de autenticación utilizando el servidor Autho MCP.
De forma predeterminada, las credenciales se almacenan en el llavero de MacOS después de la autenticación y se eliminan del llavero cada vez que el administrador cierra la sesión del servidor MCP.
Además, no se seleccionan alcances por defecto: se solicita a un usuario administrativo que los seleccione.
Servidores MCP remotos
Un servidor MCP remoto funciona como un servicio web. Si la especificación MCP se implementa fielmente, un cliente MCP establece una conexión HTTP de larga duración con el servidor, con la gestión de sesiones manejada por la autenticación basada en tokens.
La versión del 26 de marzo de 2025 de la especificación del Protocolo de Contexto del Modelo estipuló que, cuando se requiere autorización, OAuth 2.1 es el método apropiado:
Las implementaciones de autenticación de MCP DEBEN implementar OAuth 2.1 con las medidas de seguridad adecuadas tanto para clientes confidenciales como públicos.
Atlassian fue uno de los primeros proveedores de software empresarial en ofrecer unservidor MCP remoto para los clientes. Esto ofrece una alternativa simple, habilitada para OAuth, a un servidor de Comunidad que lo precedió por varios meses.
Una comparación entre el servidor MCP remoto oficial y el servidor local "de la Comunidad" desarrollado localmente es instructiva.
Cuando el servidor Comunidad descubre los métodos de autenticación disponibles en un archivo .env local (de configuración), cualquier contraseña configurada para la autenticación básica tiene prioridad sobre cualquier Token de acceso personal configurado, que a su vez tiene prioridad sobre las credenciales de OAuth.
Figura 13: Instrucciones del servidor de la comunidad de Atlassian
Los autores de este complemento afirman claramente que han optimizado la conveniencia del Developer por encima de la seguridad.
Figura 14: Instrucciones del servidor de la comunidad de Atlassian
El servidor MCP remoto oficial de Atlassian, por el contrario, incluye soporte de localhost para ofrecer inicio de sesión y consentimiento basados en OAuth para todos los usuarios, incluidos los que se conectan desde IDE locales como Cursor.
Esto elimina de manera efectiva la necesidad de que los Developer copien y peguen secretos en los archivos de configuración locales. El archivo de configuración simplemente hace referencia al servicio remoto y se le pide al usuario que complete un consentimiento de OAuth después de una autenticación exitosa.
Y a diferencia de Microsoft Copilot, que optimizó la elección de los métodos de autenticación en lugar de un resultado de seguridad específico, OAuth es el único método de autenticación disponible en el servidor MCP remoto de Atlassian. Atlassian también está creando una lista de permitidos de qué hosts (aplicaciones de IA) pueden conectarse a este servidor MCP remoto.
Figura 15: Fuente: Atlassian
Protección de la IA agentic
¡La única pregunta es qué flujo de OAuth utilizar!
Si bien los servidores MCP remotos basados en OAuth proporcionan un enfoque más seguro y estandarizado que los complementos propietarios, el camino a seguir está lejos de estar resuelto. 20 Algunos de los desafíos de seguridad restantes son:
- ¿Cómo podemos autorizar a los agentes de Al para que accedan a los recursos protegidos, manteniendo siempre al usuario interactivo (humano) en el circuito?
- ¿Cómo podemos reducir la carga de gestión de la escritura de reglas de autorización para cada recurso individual en el nivel del proveedor de servicios?
- ¿Cómo podemos proporcionar políticas centralizadas y auditoría de las concesiones de autorización?
En los servidores MCP remotos que evaluamos, los agentes de Al estaban autorizados con el mismo nivel de acceso a los servicios que el usuario que los autorizó. Están actuando "en nombre de" un usuario en la máxima medida de lo que el usuario está autorizado a hacer.
Esto podría no cumplir con las expectativas de los CISOs preocupados por los riesgos de conectar agentes de IA a los datos que están obligados a proteger. Los administradores Enterprise no se conformarán con que los proveedores de servicios sean la autoridad final sobre qué herramientas proporciona el servidor MCP.
Un administrador centralizado no puede, en el ejemplo de Atlassian, escribir políticas que permitan a los usuarios autorizar a los agentes de IA para leer y escribir páginas wiki de Confluence, pero denegar la capacidad de modificar tickets de Jira. Los administradores no pueden elegir proyectos específicos a los que no quieren que accedan los agentes de IA. Si el usuario puede acceder a él, también puede hacerlo el agente.
El borrador de la IETF OAuth Grant de afirmación de identidad, escrito por arquitectos actuales y anteriores de Okta, tiene como objetivo resolver este problema. Esta concesión combina dos estándares existentes: el OAuth 2.0 token Exchange y el JWT Profile for OAuth 2.0 Authorization Grants en una concesión que proporciona control y visibilidad empresarial.
Usando este enfoque, los administradores pueden configurar políticas centralizadas que aseguren que un usuario protegido por SSO pueda autorizar a un agente de IA para acceder a datos en múltiples aplicaciones donde ya se ha establecido una relación de confianza.
El CISO podría nuevamente limitar el alcance de a lo que los clientes (en este caso, los agentes de Al) pueden acceder en un recurso protegido. Okta está trabajando con proveedores de software independientes (ISV) para brindar estas capacidades a los clientes bajo el Acceso entre aplicaciones recientemente anunciado.
Conclusiones
Como industria, ahora tenemos algunas decisiones importantes que tomar para disfrutar de manera segura de los beneficios de conectar recursos protegidos a la IA agentic.
Debemos resistir la tentación de reutilizar los métodos de autenticación que ya eran inadecuados para conectar sistemas a través de la internet pública, y mucho menos los sistemas que pueden actuar con autonomía. A medida que los agentes de IA buscan y se les otorgan conjuntos de permisos más amplios, el "radio de explosión" de cualquier compromiso único se ampliará enormemente. Una sola filtración podría exponer significativamente más datos y sistemas críticos que antes.
En cambio, debemos adoptar flujos que estén diseñados para la era de la IA: flujos de acceso de alcance limitado y delegados por el usuario que utilicen tokens efímeros y auditables, proporcionando al CISO un control y una visibilidad largamente esperados.
Apéndice: controles de protección
Recomendaciones para proveedores de servicios
- Adopte OAuth 2.1 como el modelo de autorización mínimo viable para los servidores del Protocolo de Contexto del Modelo (MCP).
- Suscríbase a las actualizaciones de MCP para mantenerse al tanto de las novedades.
Recomendaciones para desarrolladores
- Restrinja el uso de tokens API estáticos solo a entornos de desarrollo y prueba (sin datos de producción) y aplique los alcances mínimos requeridos.
- Cuando desarrolle localmente, utilice bóvedas de secretos a nivel de sistema operativo (llavero de MacOS, Administrador de credenciales de Windows) para obtener secretos dinámicamente en tiempo de ejecución.
- Modifique los permisos de .env y otros archivos de configuración, así como los archivos de registro locales de las aplicaciones de IA, de modo que solo su cuenta de usuario pueda leerlos o modificarlos.
- Enumere todos los archivos de configuración y registro en .gitignore para evitar la confirmación accidental en los sistemas de control de versiones.
Recomendaciones para los equipos de seguridad
- Restrinja las actividades de desarrollo a estaciones de trabajo corporativas protegidas.
- Requerir autenticación resistente al phishing para el acceso a los recursos corporativos.
- Utilice soluciones de administración de secretos dedicadas para las credenciales de producción.
- Administre y controle la membresía de los grupos con acceso a los recursos del contenedor, y asegúrese de que el demonio (proceso) de Docker esté configurado para evitar la exposición.
- Requerir flujos de OAuth 2.1 para autorizar el acceso del cliente a los recursos corporativos.
- Para los casos de uso en los que se aceptan los riesgos de utilizar tokens API estáticos:
- Eduque a los developers sobre los riesgos de usar con tokens de larga duración.
- Permitir solicitudes utilizando el token al rango de IP conocido del servidor MCP correspondiente.
- Deniegue el acceso interactivo a las aplicaciones utilizando la cuenta de servicio vinculada al token de API, o al menos exija desafíos de autenticación multifactor de alta seguridad para acceder a él.
- Busque proactivamente tokens almacenados en texto plano en servidores, en archivos, en repositorios de código, en registros y en aplicaciones de mensajería y colaboración.
- Supervise el uso indebido de los tokens.
