Por qué no es posible resolver el problema de identidad de los agentes de IA tan solo contratando personal

Una pregunta está llegando a las bandejas de entrada de casi todos los CISO y CIO en este momento.

“Esto de los agentes de IA se ve genial. Ahora bien, ¿a cuántos administradores de identidad tendré que contratar para gestionarlo todo?”

Es una pregunta completamente razonable. También es la pregunta equivocada si la interpreta al pie de la letra, porque las organizaciones que aborden la gobernanza de los agentes de IA como un problema de personal están destinadas al fracaso. No porque no puedan contratar personal con suficiente rapidez; incluso si pudieran, ningún volumen de gestión humana resuelve un problema que, básicamente, es de naturaleza arquitectónica.

La pregunta correcta no es cuántas personas se necesitan para gestionar a los agentes de IA, sino qué tipo de base se debe construir para que la respuesta siga siendo manejable a medida que la flota de agentes crezca de cientos a miles y mucho más. Esa base comienza con la identidad, y el momento para desarrollarla es ahora.

Por qué el problema de identidad de los agentes de IA es diferente de cualquier problema de IAM que hayas resuelto antes

Los agentes de IA rompen todas las suposiciones y reglas sobre las que se asentó la gestión de identidades y accesos (IAM) tradicional. Algunas de esas reglas tradicionales son las siguientes: 

• La identidad escala con la cantidad de nuevos empleados o clientes. La IAM humana crece a medida que contrata empleados o adquiere clientes. En cambio, la IAM de agentes se adapta a los pipelines de implementación. Un solo desarrollador puede implementar cientos de agentes entre la mañana y el mediodía. Los procesos de aprovisionamiento de su empresa no se crearon para esta velocidad, ni tampoco el equipo de administradores de identidad que resuelve solicitudes de soporte.
• Las identidades se conocen antes de que sean necesarias. El aprovisionamiento tradicional da por sentado que alguien envía una solicitud, se crea una identidad y se concede el acceso. Con los agentes, la implementación ya puede estar en producción antes de que el equipo de seguridad sepa que existe. No es posible contratar personal para una visibilidad que no tiene.
• Los titulares de la identidad se comportan de manera predecible. Una cuenta de servicio llama a las mismas tres API en la misma secuencia cada vez. Un agente, en cambio, toma decisiones autónomas sobre a qué acceder con base en el contexto y las instrucciones. La superficie de ataque ya no se limita solo a las credenciales que contiene; también incluye las decisiones que toma. 
• Las cadenas de identidad son superficiales. La IAM se diseñó para un modelo de usuario a aplicación o de usuario a sistema, algo muy sencillo. Los agentes introducen modelos completamente nuevos, como de agente a agente, de agente a herramienta o de agente a agente y a aplicación. Esto crea redes de acceso complejas. Redes que no le permiten a un administrador que revisa una solicitud de aprovisionamiento evaluar el riesgo de una cadena, pues no la puede ver.

Estas desviaciones de las reglas tradicionales de la IAM explican por qué no hay que preguntarse si es necesario contratar a más personas, sino cómo mejorar la arquitectura.

Si algo ejecuta acciones, necesita una identidad

Antes de llegar a la arquitectura, hay un principio clave sobre el que se construye todo lo demás, y las organizaciones que lo omiten crean un problema que ningún volumen de personal ni herramientas puede solucionar más adelante:

Cada agente de IA que opera en su entorno necesita su propia identidad. Sin excepciones. Punto final.

No una credencial compartida ni una cuenta de servicio prestada. No se trata de algo que se solucione después de la implementación. Es necesario aprovisionar una identidad a cada agente antes de que toque cualquier sistema de producción.

¿En qué consiste una identidad de agente completa?

• Un identificador único y verificable
• Un ámbito definido y documentado de acciones permitidas
• Un propietario humano designado que se responsabilice
• Un registro de auditoría de las acciones
• Una ruta clara de suspensión y revocación

¿Qué pasa si no tiene esto? Sabemos que la TI en la sombra puede ocasionar que los datos se almacenen en ubicaciones no autorizadas. Ahora, la IA en la sombra puede llevar a que se ejecuten acciones autónomas en contextos no autorizados. No se puede auditar lo que no se sabe que existe. No se pueden dimensionar correctamente los permisos que nunca se revisaron. No se puede revocar el acceso a un agente que nunca se aprovisionó formalmente. Y es absolutamente imposible formar un equipo lo suficientemente grande como para rastrear a agentes que, para empezar, nunca estuvieron en el sistema.

Cada agente necesita una conexión humana

Cuando un agente causa un incidente, ¿usted a quién llama?

Si no puede responder esa pregunta, tiene un problema de gobernanza que no se resuelve contratando personal. Mantener el factor humano requiere que dos conceptos trabajen en conjunto.

• Propiedad humana. Cada agente necesita un propietario designado y responsable dentro de su organización. No el desarrollador que lo creó hace tres meses y que, desde entonces, se cambió de equipo. No el proveedor que suministró el modelo de base. Más bien, una persona o un equipo cuyas responsabilidades actuales incluyan aprobar el ámbito del agente, recibir notificaciones cuando se comporte de forma anómala y asumir la responsabilidad cuando cause daño. Esto no es un puesto administrativo que requiera una contratación exclusiva, sino un requisito de gobernanza que se integra en la forma en que se implementan los agentes.
• Delegación y cadena de autoridad. Cuando un agente realiza una acción, una de dos cosas debe ser cierta: actúa dentro de sus permisos definidos explícitamente o bajo la autoridad que le fue delegada explícitamente por un ser humano. Ambas opciones son legítimas. Y ambas deben poder rastrearse.

Sin embargo, en los sistemas con múltiples agentes, esta cadena puede complejizarse rápidamente:

Un humano aprueba un flujo de trabajo → un agente orquestador actúa a partir de esa aprobación → se invoca a un subagente con ámbito delegado → una llamada de API llega a un sistema confidencial.

Cada eslabón de esa cadena debe rastrearse hasta el ser humano original. No solo porque los reguladores lo exijan (y lo harán), sino porque, cuando algo sale mal, es necesario reconstruir exactamente qué sucedió, por qué el agente creyó que estaba autorizado y dónde ocurrió la falla. Sin la cadena, se tiene una llamada a la API desde un proceso anónimo, y el equipo de respuesta ante incidentes empieza desde cero.

La propiedad responde a la pregunta sobre quién tiene la responsabilidad sobre el agente. La delegación responde a la pregunta sobre a quién pertenece la autoridad que el agente utiliza. En conjunto, ayudan a garantizar que ningún agente opere sin que un ser humano sea responsable. Ninguno de estos conceptos requiere un ejército de administradores para ponerlos en práctica, siempre y cuando estén integrados correctamente en la base.

Conectar a creadores con guardianes

Hay dos equipos en el centro de este problema, con diferentes incentivos y, a menudo, con poca superposición. 

• Los creadores se mueven rápido, miden en la entrega y resuelven problemas empresariales con características nuevas e impresionantes. La gobernanza de la identidad no es su principal preocupación, sino publicar cosas interesantes lo más rápido posible. 
• Los equipos de seguridad, IAM y cumplimiento normativo son responsables de la postura de riesgo. A menudo, se enteran de los nuevos agentes después de la implementación, incluso mucho después. Son responsables de un riesgo en cuya creación no tuvieron nada que ver.

Esta tensión no es nueva. Se desarrolló con la nube, con los dispositivos móviles y con la TI en la sombra. Sin embargo, con los agentes, hay mucho más en juego. Un contenedor de almacenamiento en la nube mal configurado puede exponer datos de forma pasiva. Un agente mal configurado puede realizar acciones, y el radio de explosión es completamente diferente.

La respuesta incorrecta de los equipos de seguridad es convertirse en un cuello de botella y exigir una revisión manual para cada implementación de agentes. Además de ralentizar todo, este enfoque tiene un porcentaje de error histórico del 100 %. Los desarrolladores encuentran formas de evitarlo y, al final, proliferan los agentes sin gobernanza en lugar de los agentes gobernados. También es, por cierto, el modelo que requiere contratar a más administradores para mantenerse al día con la velocidad de implementación.

La respuesta correcta es compartir la propiedad y hacer cumplir reglas de forma automatizada: los equipos de seguridad definen las políticas y las protecciones con anticipación; los equipos de desarrollo declaran el ámbito y la propiedad en el momento de la implementación; y el pipeline maneja el aprovisionamiento automáticamente. El equipo de seguridad obtiene visibilidad sin interponerse en la ruta crítica. Los desarrolladores consiguen velocidad sin eludir los controles. El equipo de identidad dedica su tiempo a diseñar marcos de gobernanza en lugar de procesar solicitudes.

¿Cómo es realmente la base para la seguridad de la identidad de los agentes de IA?

Volvamos a la pregunta original: “Esto de los agentes de IA se ve genial. Ahora bien, ¿a cuántos administradores de identidad tendré que contratar para gestionarlo todo?”

La respuesta es que no necesita ampliar su equipo de identidad de forma proporcional a su flota de agentes. Necesita construir una base que escale sin ellos.

Esa base tiene cuatro componentes:

• Identidad del agente como código. La identidad del agente no debe ser un paso de aprovisionamiento manual. Debería ser un artefacto de implementación, definido en un manifiesto junto con el código del agente, revisado como parte del proceso de desarrollo y aprovisionado automáticamente cuando se envía el agente. La revisión de seguridad debe realizarse durante la revisión de código, antes de la producción, y no como un paso administrativo posterior.
• Gobernanza basada en clases. Nunca gestionará directamente millones de instancias de agentes. Lo que gestionará serán algunas clases de agentes. Una clase define los sistemas permitidos y el acceso a los datos, el nivel máximo de clasificación de los datos, cuándo se requiere la intervención humana y cuáles son los requisitos de auditoría. Los agentes individuales heredan automáticamente la información de las clases. La gobernanza escala con la cantidad de clases que mantiene, no con la cantidad de instancias que se ejecutan en un momento dado. 
• Cero privilegio permanente. Los agentes no deben tener permisos persistentes. Cada acción requiere una credencial de ámbito limitado y de duración limitada para una tarea específica. Cuando la tarea termina, la credencial caduca. Esto no solo reduce su superficie de ataque, sino que también hace que el problema de la escalabilidad sea manejable. No existe una multitud de autorizaciones acumulándose entre miles de agentes que alguien deba revisar y limpiar. Cada emisión de credenciales es un evento de gobernanza con un registro automático.
• La cadena de delegación como infraestructura. Los flujos de trabajo con múltiples agentes deben tratar las cadenas de delegación como una preocupación prioritaria de la arquitectura, en lugar de una idea secundaria. Cuando la infraestructura se implementa a nivel técnico, se obtiene la trazabilidad de forma automática. Cuando un principio de diseño requiere una verificación manual, se convierte en un trabajo de tiempo completo.

La identidad nunca ha sido algo que se configure y se olvide, y los agentes de IA no cambiarán eso

Aprovisionar una identidad de agente en el momento de la implementación es el comienzo de la gobernanza, no el final. En este caso, la respuesta también es la automatización y la disciplina, no la cantidad de empleados.

• Los ciclos de revisión de acceso deben incluir a los agentes. ¿Este agente sigue activo? ¿Su ámbito sigue siendo apropiado? ¿Cambió el contexto de la empresa? Automatice la recopilación de datos y haga que los humanos tomen las decisiones sobre las excepciones. No diseñe un proceso que requiera que alguien revise manualmente miles de agentes trimestralmente; cree uno que muestre únicamente lo que necesita criterio humano.
• Se debe dimensionar adecuadamente según el comportamiento real. A menudo, a los agentes se les aprovisiona más ámbito del que terminan usando. Los datos de uso indican a qué accede realmente un agente, en comparación con aquello a lo que tiene permitido acceder. Deje que el sistema identifique la brecha y haga que las personas aprueben la reducción. Así es como se previene el tipo de expansión de permisos que, con el tiempo, requiere un esfuerzo administrativo significativo para resolverla.
• La desactivación es una operación primordial. Cuando un flujo de trabajo se retira, los agentes relacionados deben desactivarse automáticamente. Los agentes zombis, implementados y olvidados (pero todavía con credenciales), se encuentran entre los patrones de mayor riesgo en los entornos de agentes. También son el resultado directo de tratar la desactivación como un proceso manual que alguien realizará en algún momento.

La respuesta a la pregunta

Entonces, ¿a cuántos administradores de identidad tendrá que contratar para gestionar a miles de agentes de IA?

Si desarrolla una buena base, la respuesta es: no tantos como cree y muchos menos de los que precisaría sin ella. 

Lo que realmente necesita es un pequeño número de personas que puedan diseñar marcos de políticas, construir integraciones del pipeline, interpretar señales de comportamiento a gran escala y responsabilizar a los equipos de creadores de los estándares de gobernanza.

Lo que no necesita (y lo que no funcionará de todas formas) es un nuevo equipo de personas que aprovisione, revise y desactive manualmente las identidades de los agentes a partir de una lista de solicitudes de soporte. Ese modelo se derrumbará por su propio peso antes de alcanzar los cien agentes, ni que hablar de los mil.

Las organizaciones que mejor gestionen a los agentes de IA a gran escala no serán las que más rápido contraten personal. Serán las que desarrollen las bases correctas desde el principio, mientras la flota aún sea lo suficientemente pequeña para moldearla y antes de que la cuestión de la contratación se vuelva imposible de resolver.

Cinco pasos que debe dar antes de que crezca su flota de agentes:

1. Declarar el principio internamente. A partir de ahora, cada agente obtiene una identidad, sin excepciones.
2. Hacer un inventario de lo que ya se está ejecutando. Eso incluye las implementaciones que no realizó formalmente.
3. Requerir la asignación de un propietario humano. Cada agente que esté actualmente en producción debe tener uno.
4. Definir sus capas de clasificación de agentes. Hágalo antes de que los necesite a gran escala.
5. Convertir la identidad en un requisito de implementación. No deje que se transforme en una revisión posterior a la implementación.

La expansión de agentes no es un problema del futuro. Los agentes ya están llegando a los entornos de producción en organizaciones que aún no deciden cómo gobernarlos.

La oportunidad para desarrollar esto correctamente está al alcance de la mano. Y la respuesta nunca fue más personal, sino una mejor arquitectura.

¿Está desarrollando las bases para gobernar a sus agentes de IA? Okta cierra la brecha al permitir que los desarrolladores implementen más rápido y los equipos de seguridad obtengan una gobernanza escalable. Obtenga más información aquí.