El futuro de la seguridad de la IA

En septiembre de 2025, Anthropic detectó e interrumpió el primer ciberataque a gran escala ejecutado mayormente por un agente de IA del que se tiene noción. Un grupo patrocinado por el estado chino (GTG-1002) manipuló Claude Code para atacar a aproximadamente 30 organizaciones en los sectores de servicios financieros, tecnología, fabricación y gobierno (informe de Anthropic). La IA ejecutó de forma autónoma entre el 80 y el 90 % de las operaciones tácticas: reconocimiento, detección de vulnerabilidades, ataque, recolección de credenciales, movimiento lateral y exfiltración de datos. Las personas intervinieron solo en momentos estratégicos críticos, y dedicaron aproximadamente 20 minutos de dirección práctica por etapa. Un puñado de objetivos fueron atacados con éxito.

Esto no fue una prueba de concepto. Fue una campaña operativa que explotó las mismas brechas en la arquitectura que la mayoría de las empresas tienen hoy en día: ninguna revisión en la capa de modelo detectó las solicitudes manipuladas, ningún marco de identidad del agente detectó operaciones autónomas no autorizadas, y ningún intermediario de agente aplicó controles a nivel de herramienta en tiempo de ejecución. La Lista de OWASP de las 10 principales amenazas para aplicaciones con agentes, publicada en diciembre 2025 y con la colaboración de más de 100 expertos del sector, enumera como los tres riesgos principales exactamente a estos errores: secuestro de objetivos del agente (ASI01), uso indebido de herramientas (ASI02) y uso indebido de identidades y privilegios (ASI03).

Esto no es un evento aislado. El 88 % de las organizaciones informaron incidentes de seguridad confirmados o sospechosos relacionados con agentes de IA en el último año (encuesta de Gravitee) y, entre las organizaciones que experimentaron filtraciones relacionadas con la IA, el 97 % carecía de controles de acceso adecuados para sus sistemas de IA (IBM/Ponemon). Solo el 22 % trata a los agentes de IA como entidades independientes con identidad propia (Gravitee).

Dicho de otra manera: si tiene agentes en producción y no tuvo incidentes todavía, seguramente es porque no los encontraron.

La arquitectura correcta

Las empresas están implementando agentes en tres límites de confianza distintos. Los agentes internos (bots de la mesa de ayuda de TI, agentes de RR. HH., bots de finanzas que extraen informes de ERP) operan dentro del perímetro empresarial. Los agentes orientados al cliente (asistentes de soporte, IA de autoservicio que consulta bases de conocimiento internas en nombre de los usuarios finales) conectan los recursos internos con los consumidores externos. Los agentes de socios (integraciones de la cadena de suministro, prestación de servicios entre organizaciones) operan cruzando los límites de la organización en su totalidad. Los requisitos de seguridad aumentan con cada patrón. Los agentes internos requieren una gobernanza adecuada de identidad y ciclo de vida. Si agrega un agente orientado al cliente, necesitará delegación de autorización y consentimiento. Y si lo extiende a los socios, deberá gestionar la confianza entre dominios y los controles de flujo de datos. Los tres requieren la misma arquitectura fundamental.

AWS, Google, Anthropic y Microsoft implementan controles de seguridad de agentes dentro de sus propias plataformas que se corresponden con estas mismas tres capas. Eso valida la arquitectura. Sin embargo, las empresas no utilizan agentes en una sola plataforma. Necesitan identidades y autorizaciones que funcionen en todas ellas. Gartner predice que, para 2028, el 25 % de las filtraciones empresariales se originarán por uso indebido de agentes de IA. McKinsey llama a los agentes de IA “infiltrados digitales” que requieren la misma gobernanza que los empleados. La arquitectura se está unificando. La pregunta es si su organización la adoptará de manera proactiva o reactiva.

Capa 1: seguridad del modelo para proteger la inteligencia

En la campaña de septiembre de 2025, los atacantes eludieron las medidas de seguridad con el engaño mediante juegos de roles y la descomposición de tareas: lo que hicieron fue dividir los ataques de varias etapas en solicitudes discretas que parecían legítimas de forma aislada (Anthropic). Ningún humano revisa miles de solicitudes por minuto. La seguridad en la capa del modelo es lo que separa una solicitud manipulada de una red en riesgo.

La evaluación de modelos y el red-teaming de adversarios revelan vulnerabilidades antes de la etapa de producción. La defensa contra la inyección de comandos detecta instrucciones maliciosas ocultas en documentos, correos electrónicos o respuestas de herramientas, mientras que las protecciones de salida y la prevención de pérdida de datos (DLP) evitan la filtración de datos confidenciales. La supervisión continua de entrada y salida lo une todo, y señala el comportamiento anómalo en tiempo real. Estos no son riesgos teóricos. Los investigadores han detectado vulnerabilidades reales de MCP en el mundo real: envenenamiento de herramientas a través de servidores MCP maliciosos, inyección de comandos mediante respuestas de herramientas y ataques a la cadena de suministro en paquetes de MCP (OWASP). Tanto AWS Bedrock Guardrails como Google Cloud Model Armor ofrecen un filtrado en tiempo de ejecución configurable y apto para todos los modelos. Si el modelo está en riesgo, nada de lo demás importa.

Capa 2: identidad del agente para proteger al actor

Una vez que el modelo es confiable, el agente necesita una identidad. No se trata de una cuenta de servicio compartida ni de una clave de API estática. Estamos hablando de una identidad real, con un propietario que responde cuando algo sale mal, permisos de ámbito limitado que caducan y un ciclo de vida que termina cuando debe.

Antes de la IA, todo era código y podíamos determinar lo que iba a pasar. Ahora, a los agentes de IA les damos una instrucción y no hay garantía de a qué sistemas va a acceder para responder. No sabemos si usará un nivel más alto de acceso para acceder a un sistema que ni siquiera tenías en cuenta. 

Harish Peri, VP sénior y gerente general, Okta

La identidad del agente comienza con la detección: ¿cuántos agentes operan, quién los desarrolló y qué credenciales tienen? La encuesta AI at Work de Okta reveló que el 91 % de las organizaciones ya implementan agentes; sin embargo, solo el 10 % cuenta con una estrategia de gobernanza eficaz. En cada taller para clientes que realizamos, la primera pregunta siempre es la misma: ¿cuántos agentes tienen en realidad? La respuesta también es casi siempre la misma: “no lo sabemos”. Cada agente obtiene una identidad de duración limitada, un propietario y una clasificación. La autorización es posterior a la delegación: el agente actúa en nombre de un usuario específico, con un conjunto específico de permisos para una tarea específica. Cross App Access (XAA) de Okta, un protocolo abierto que extiende OAuth y que ahora se adoptó en MCP como autorización gestionada por la empresa, permite auditar estas cadenas de delegación. Cuando la cadena se rompe, el acceso se detiene. La gestión del ciclo de vida mediante la SCIM proporciona la misma gobernanza que las identidades humanas: revisiones de acceso, desaprovisionamiento automatizado y responsabilidad del propietario. Cuando se desvincula al usuario que delega o cambia una política, la revocación se propaga por todos los sistemas relacionados.

Sin embargo, la identidad por sí sola no cierra la brecha. Saber que un agente está autorizado no es lo mismo que saber si debería transferir 50 000 dólares de una cuenta, ahora mismo, durante la madrugada, a un destinatario con el que nunca antes interactuó.

Capa 3: autorización de los datos para proteger las acciones

Las políticas de OAuth revisan el token. Controlan si el ámbito es válido, si el público es válido y si el token no caducó. Esto es necesario, pero no suficiente. El token indica que el agente puede realizar transferencias. No dice nada sobre si una transferencia, a un destinatario específico y por una cantidad determinada tiene algún sentido.

La identidad y los perímetros solo brindan controles básicos sobre las acciones del agente. Las protecciones en el uso de herramientas ofrecen más poder para controlar con precisión qué acciones permitir.

Documentación de seguridad del Kit de desarrollo de agentes de Google Cloud

El comportamiento del agente no es determinista. El LLM selecciona herramientas al momento de la ejecución, rellena los parámetros según el razonamiento que realice y encadena operaciones en secuencias que nadie anticipó cuando se redactó la política. Aquí es donde reside el intermediario del agente: el punto en el que se requiere el cumplimiento entre el agente y las herramientas que invoca. El intermediario de agentes de Okta aplica controles detallados en el tiempo de ejecución: acceso a nivel de herramienta (¿qué herramientas puede invocar este agente?); restricciones de parámetros (¿está el importe dentro de los límites?); intervención humana mediante la autenticación de canal secundario iniciada por el cliente (CIBA) para operaciones de alto riesgo; gobernanza del flujo de datos entre aplicaciones (¿está autorizada la salida de la herramienta A como entrada de la herramienta B?) y un registro completo de auditoría de invocaciones.

El intermediario del agente no reemplaza la identidad. Comienza donde termina la identidad. La identidad decide qué se incluye en el token. El intermediario del agente decide qué ocurre en el momento de la ejecución, con base en lo que contiene el token. Las afirmaciones llevan el contexto de una capa a la siguiente. No existe una brecha entre quién es el agente y lo que se le permite hacer.

¿Qué se rompe sin cada capa?

Un estudio de Kiteworks de 225 líderes de seguridad reveló que el 100 % tiene a la IA con agentes en su hoja de ruta, pero el 63 % no puede aplicar limitaciones de propósito y el 60 % no puede desactivar un agente que se comporta indebidamente. Los controles que faltan son los que más importan.

¿Hacia dónde se dirige la arquitectura?

La arquitectura de tres capas cierra las brechas estructurales que la mayoría de las empresas tienen hoy en día. Hay tres áreas que están evolucionando rápidamente y definirán la próxima etapa:

• Delegación recursiva. El agente A delega en el agente B, quien delega en el agente C. ¿Hasta dónde se propaga la autoridad? ¿Quién revoca a nivel profundo? Cross App Access (XAA) de Okta con ID-JAG mantiene la cadena de custodia al integrar la identidad del usuario y la del agente en cada intercambio de tokens, con un alcance que se reduce con cada nueva delegación. La gestión del ciclo de vida de SCIM ayuda a garantizar que se propague la revocación de un usuario que delega cuando se lo desvincula. El desafío restante es la estandarización de los límites de profundidad de delegación y la señalización de revocación de múltiples delegaciones, un trabajo que la especificación OAuth Identity and Authorization Chaining está abordando activamente.
• Deriva de la autorización. Se autoriza a un agente al momento de invocarlo, pero los permisos del usuario cambian a mitad del proceso. ¿Cómo llega la revocación a una operación que ya está en curso? Los tokens de corta duración con períodos de caducidad estrictos limitan el radio de explosión. La autenticación escalonada basada en CIBA puede revalidar la autorización en puntos de decisión de alto riesgo. Las políticas de acceso de Okta aplican concesiones de ámbitos según la pertenencia a un grupo, por lo que un cambio de permiso a nivel del directorio se activa en el siguiente intercambio de tokens. El horizonte es la señalización de la revocación en tiempo real a través de cadenas de ejecución activas sin interrumpir las operaciones legítimas.
• Límites de confianza entre dominios. Un agente conecta herramientas entre dos aplicaciones SaaS con diferentes modelos de confianza y esquemas de clasificación de datos. ¿Cuál gobierna el límite? Dentro de un único dominio de confianza, XAA de Okta y los servidores de autorización personalizados por recurso ya exigen un acceso con ámbito definido en cada cruce de límites. Auth0 Token Vault amplía esta funcionalidad a recursos OAuth de terceros (como Google, GitHub o Salesforce) mediante el consentimiento gestionado y la traducción de tokens. El desafío de los límites entre organizaciones, en el que dos IdP independientes deben entablar una relación de mutua confianza para la delegación de agentes, es el horizonte al que aspiramos. La especificación OAuth Identity Chaining proporciona la base de la arquitectura, y Okta contribuye activamente a su desarrollo.

Estos son problemas difíciles, pero está claro cómo debemos avanzar en términos de arquitectura. La Iniciativa de seguridad de agentes de OWASP y OpenID Foundation están desarrollando marcos de trabajo. Las organizaciones que establezcan hoy su base de tres capas estarán preparadas para adoptar estos controles a medida que evolucionen.

¿Cuál es la situación actual?

Evalúe su organización en función de cada capa. La mayoría de las empresas se encuentran en postura reactiva en, al menos, dos de ellas.

Okta y Auth0 proporcionan la infraestructura de identidad y autorización para pasar de la postura reactiva a la adaptativa en las capas 2 y 3. Como la única plataforma de identidad independiente diseñada específicamente para la identidad de la fuerza laboral y de los clientes, Okta trata la identidad de los agentes como una prioridad con la misma gobernanza que la identidad humana, y se basa en estándares abiertos (como XAA y SCIM) en lugar de herramientas exclusivas.

Si considera que su postura es gestionada en las tres capas, probablemente sea un resultado muy generoso.

El camino de los 90 días

Conclusión

El ataque de septiembre de 2025 demostró que las amenazas de la IA con agentes son operativas. Los datos del sector confirman que la mayoría de las empresas no están preparadas. La arquitectura de tres capas no es un concepto nuevo. Es lo que las empresas de plataformas más importantes del mundo desarrollaron de forma independiente, lo que los organismos de estandarización están recopilando y lo que exigen los datos sobre incidentes. La única pregunta por responder tiene que ver con la velocidad.

El contexto es la nueva credencial. La intención es el nuevo perímetro. El futuro de la seguridad de la IA se construye conectando la seguridad del modelo, la identidad de los agentes y la autorización de datos en una sola cadena de confianza.

La tecnología para resolver esto ya existe. Descubra cómo Okta y Auth0 protegen a los agentes de IA en okta.com/ai y auth0.com/ai. Podemos ayudarle con todo esto. Colabore con nosotros.

A continuación, podrás obtener más información sobre la seguridad de la IA.

• Seguridad de agentes de IA: desarrolle confianza autónoma a la velocidad de las máquinas. Una serie de siete episodios de Liderazgo de opinión creada por Okta. 
• Los agentes de IA nos imponen una elección fundamental que, en realidad, es una falsa disyuntiva: los agentes son útiles o son seguros. La identidad es la clave para rechazar este dilema.