Identidad de agentes de IA: la pregunta que todas las empresas se saltaron

La respuesta corta: cuando pones en marcha un agente de IA dentro de tu empresa, necesita una identidad propia, exactamente igual que un empleado necesita una cuenta. La práctica habitual hoy —incrustar una clave de API estática dentro del agente para que pueda acceder a tus sistemas— es lo más peligroso que puedes hacer, porque esa clave nunca caduca, nadie sabe quién la está usando y no se puede revocar rápidamente cuando lo necesitas. El enfoque correcto es dar a cada agente una identidad registrada, permisos acotados y tokens de corta duración que caducan automáticamente.

Eso es precisamente lo que Okta, uno de los mayores proveedores de gestión de identidades del mundo, anunció el 24 de agosto de 2026 con una nueva capacidad llamada Agent SSO. La idea parece sencilla en la superficie y tiene consecuencias profundas: registrar al agente de IA como una identidad de primera clase dentro del directorio de la empresa, junto a los empleados humanos, de modo que quede sujeto a las mismas herramientas para conceder, supervisar y revocar accesos.

Por qué esta pregunta se ha vuelto urgente ahora

En los últimos dos años, la IA empresarial ha pasado de ser «un bot que responde preguntas» a «un agente que hace el trabajo». El agente actual abre tu CRM, lee pedidos, actualiza un registro de inventario, envía un mensaje a un cliente e incluso puede preparar una factura. Cada uno de esos pasos implica iniciar sesión en un sistema real que contiene datos reales.

El problema es que las herramientas de seguridad de la mayoría de las empresas se construyeron sobre un único supuesto: que quien inicia sesión en los sistemas es un ser humano. Una cifra llamativa que Okta citó en su anuncio refleja la brecha: solo el 34 % de las organizaciones aplica a los agentes de IA los mismos controles de seguridad que aplica a los trabajadores humanos. Dicho de otro modo, aproximadamente dos tercios de las empresas tienen entidades automatizadas operando dentro de sus sistemas sin el mismo nivel de gobernanza.

Cuando un agente no tiene una identidad clara, los problemas se acumulan y todos son del mismo tipo: no sabes cuántos agentes operan dentro de tu negocio, no sabes quién autorizó a cada uno, no puedes responder a la pregunta sencilla de un auditor —«¿quién realizó esta acción?»— y no tienes un único botón que pulsar para detener a un agente que se ha desviado.

Qué hace realmente Agent SSO

El servicio funciona sobre un protocolo abierto llamado Cross App Access (XAA), una extensión del conocido estándar OAuth, que ha sido adoptado como la extensión oficial de autorización gestionada por la empresa para MCP, el protocolo que se ha convertido en el idioma común entre agentes y sistemas. En resumen, cuando un agente de IA compatible con este protocolo intenta conectarse a una de tus aplicaciones de negocio, ocurre lo siguiente:

  • Registro: el agente queda registrado como una identidad con nombre en el directorio de la empresa, no como una clave anónima.
  • Autorización: recibe un token de acceso de corta duración que caduca automáticamente, en lugar de una clave estática guardada en un archivo de configuración.
  • Gobernanza: un administrador gestiona los permisos del agente desde la misma consola que usa para los permisos de los empleados.
  • Revocación instantánea: el acceso del agente puede cortarse con una sola acción en el momento en que su comportamiento parezca incorrecto.

Cabe destacar que Okta ha incluido Agent SSO en su oferta principal de inicio de sesión único sin coste adicional, una señal de que quiere que este patrón se extienda como estándar en lugar de venderlo como una función premium. Su anuncio también mencionó a empresas que trabajan con ella en este enfoque, entre ellas Anthropic, Atlassian, Slack, Notion, Datadog y Figma.

La nueva regla: todo agente de IA que funcione dentro de tu empresa debe tener un nombre, un responsable humano que responda por él, permisos acotados y una fecha de caducidad. Exactamente igual que un empleado.

Qué significa esto para un empresario en Arabia Saudí

En un año que el Reino ha declarado Año de la Inteligencia Artificial, las empresas avanzan rápido para incorporar agentes de IA a la atención al cliente, las ventas y las operaciones. Y el paso del piloto a la producción real es exactamente el punto en el que la identidad y los permisos dejan de ser un detalle técnico y se convierten en una preocupación central.

También hay una dimensión regulatoria. La Ley de Protección de Datos Personales (PDPL) exige a una organización controlar quién accede a los datos personales y con qué fin, y ser capaz de demostrarlo en una auditoría. Si tu agente de IA lee datos de clientes mediante una clave compartida que no pertenece a nadie en particular, en la práctica no puedes responder a la pregunta «¿quién accedió a estos datos?», y eso no es solo una debilidad técnica, es una brecha de cumplimiento.

Pasos prácticos con los que puedes empezar hoy

No necesitas una plataforma global para empezar. Los mismos principios se aplican a cualquier sistema interno que esté bien construido:

  • Haz inventario de tus agentes: enumera todas las herramientas de IA conectadas hoy a tus sistemas; el número te sorprenderá.
  • Una cuenta separada por agente: nunca compartas la cuenta de un empleado ni una clave de uso general entre varias herramientas.
  • Mínimo privilegio: si el agente solo necesita leer, no le concedas permiso para modificar o eliminar.
  • Tokens de corta duración: sustituye las claves permanentes por tokens que caducan y se renuevan automáticamente.
  • Un registro de auditoría completo: cada acción que realiza el agente queda registrada con su nombre, la marca de tiempo y el sistema afectado.
  • Un responsable humano: cada agente tiene un empleado responsable que revisa sus permisos periódicamente y puede detenerlo.
  • Aprobación humana para operaciones sensibles: las transferencias financieras, la eliminación de datos y los mensajes masivos a clientes necesitan un punto de control humano.

Cómo lo vemos en Origami

Cuando construimos un sistema a medida para un cliente y le conectamos un agente de IA, tratamos a ese agente desde el primer día como un usuario con una cuenta, permisos y un registro, no como un script que se ejecuta con la clave del administrador. Esa sencilla decisión de arquitectura ahorra al cliente una reconstrucción posterior y deja el sistema preparado para auditorías desde el principio, en lugar de tener que parchearlo ante la primera pregunta de un auditor o el primer incidente de seguridad.

El anuncio de Okta es importante porque convierte lo que antes era una decisión que tomaba cada desarrollador por su cuenta en un estándar del sector respaldado por grandes proveedores de herramientas. Quien construya hoy sobre esta base se encontrará automáticamente alineado con lo que será un requisito básico dentro de uno o dos años.

En resumen: la IA dentro de tu empresa ya no es una herramienta que usas, es una parte que actúa en tu nombre. Y cualquier parte que actúe en tu nombre necesita una identidad y límites claros; de lo contrario, estás gestionando un riesgo que no puedes ver.

Fuentes