Identidad, autoridad y gobernanza en una etapa donde la inteligencia artificial comienza a operar sobre sistemas reales.
En ciberseguridad estamos acostumbrados a hacer preguntas bastante concretas: quién accedió a un sistema, qué privilegios tenía y qué hizo con ellos. Con los agentes de inteligencia artificial esas preguntas siguen siendo válidas, aunque empiezan a quedarse cortas.
Un agente puede recibir una tarea, consultar información, seleccionar una herramienta, invocar una API y ejecutar acciones sobre distintos sistemas. Puede hacerlo en representación de una persona, de una aplicación o como parte de un flujo donde intervienen otros agentes. El cambio parece sutil, pero desde el punto de vista de seguridad es considerable: ya no estamos hablando únicamente de una inteligencia artificial que procesa información o genera una respuesta, sino de software al que comenzamos a delegarle capacidad de acción.
Ahí aparece una pregunta que probablemente gane protagonismo a medida que estas arquitecturas se extiendan dentro de las empresas: ¿con qué autoridad está actuando esa IA?
No es solamente un problema de autenticación. Podemos identificar correctamente a un agente y, aun así, haberle otorgado permisos demasiado amplios, durante demasiado tiempo o para acciones que nunca contemplamos cuando diseñamos el flujo. En otras palabras, saber quién es el agente no resuelve automáticamente qué debería poder hacer.
Un problema nuevo construido sobre problemas conocidos
En febrero de 2026, el National Institute of Standards and Technology (NIST), a través de su National Cybersecurity Center of Excellence, publicó un documento conceptual dedicado específicamente a la identidad y autorización de agentes de software e inteligencia artificial. No se trata de un estándar definitivo, sino de un trabajo destinado a explorar cómo aplicar mecanismos y buenas prácticas existentes de identidad a sistemas capaces de operar con mayores niveles de autonomía.
La discusión incluye identificación, autorización, auditoría y no repudio para agentes que pueden interactuar con datos, aplicaciones y herramientas. Meses después, NIST volvió sobre el tema señalando situaciones que para cualquier profesional de IAM resultan conocidas: agentes utilizando credenciales humanas, API keys estáticas, tokens con una vida útil demasiado extensa y permisos cuyo alcance supera ampliamente lo requerido para una tarea.
El problema, entonces, no nació con la IA. Llevamos años encontrando cuentas técnicas con privilegios acumulados, credenciales que sobreviven al proyecto que las originó y servicios cuyo propietario ya nadie puede identificar con claridad.
Lo que cambia es la capacidad del actor que empieza a utilizar esos permisos.
Una persona puede tardar minutos en consultar distintos sistemas, interpretar los resultados y decidir cuál será la siguiente acción. Un agente puede recorrer esa misma secuencia mucho más rápido y, dependiendo de su diseño, escoger diferentes herramientas para completar un objetivo. Cuando esa capacidad se combina con privilegios excesivos, las consecuencias de una mala decisión también pueden acelerarse.
Por eso autenticar a un agente es necesario, pero no suficiente. Una credencial puede ser válida, la sesión legítima y los permisos técnicamente correctos, pero la acción final puede seguir estando fuera de lo que la organización pretendía autorizar en ese contexto.
El permiso empieza a importar tanto como el prompt
Durante buena parte de la conversación sobre AI Security nos concentramos, lógicamente, en el modelo. Prompt injection, exposición de información sensible, manipulación del contexto, envenenamiento de datos y otros ataques continúan siendo relevantes.
Pero cuando conectamos un modelo con herramientas, el problema cambia. Una respuesta deja de ser solamente una respuesta: puede transformarse en una acción sobre un sistema real.
Pensemos en un agente utilizado para resolver solicitudes de clientes. Para realizar su trabajo necesita consultar un CRM, revisar correos y acceder a determinada información financiera. Que necesite consultar el estado de una cuenta no significa que también deba modificarla. Y que en una situación puntual necesite emitir un reembolso tampoco implica que esa autorización tenga que permanecer disponible indefinidamente.
Este tipo de separación parece evidente sobre el papel, pero es precisamente donde históricamente terminamos generando cuentas de servicio con más privilegios de los necesarios. Con agentes existe el riesgo de repetir ese patrón sobre una arquitectura mucho más dinámica.
NIST plantea avanzar hacia credenciales más acotadas, dinámicas y de corta duración, apoyándose cuando sea posible en tecnologías que ya conocemos, como OAuth 2.0, SPIFFE, JWT o certificados X.509. La lógica es razonable: si un agente necesita determinado permiso para completar una tarea concreta, la autorización debería ajustarse a esa necesidad en lugar de convertirse automáticamente en un privilegio permanente.
La pregunta deja entonces de ser simplemente “¿este agente tiene acceso?” y empieza a ser más específica: ¿está autorizado para realizar esta acción, sobre este recurso, dentro de esta tarea y en este momento?
Esa diferencia cambia bastante la arquitectura.
Agentic IAM comienza a formalizarse
La discusión tampoco se limita a NIST. El Technical Steering Committee de la Coalition for Secure AI (CoSAI) aprobó el 20 de marzo de 2026 su framework de Agentic Identity and Access Management, presentado públicamente en abril.
La propuesta plantea que los agentes puedan ser gestionados como identidades verificables y auditables, con credenciales propias, controles sensibles al contexto y mecanismos capaces de reconstruir la autoridad delegada. Si una persona inicia una acción que posteriormente ejecuta un agente, deberíamos poder distinguir quién solicitó la tarea, qué agente intervino, qué permisos recibió y qué terminó haciendo.
Esto también permite poner el problema en perspectiva. No necesariamente necesitamos inventar desde cero una nueva disciplina de seguridad. Buena parte de la respuesta probablemente esté en controles que llevan años formando parte de IAM y Zero Trust: ciclo de vida de identidades, mínimo privilegio, acceso just-in-time, segregación de funciones, auditoría, revisión de permisos y revocación.
La dificultad está en adaptar esos controles a un actor cuyo comportamiento puede ser más dinámico que el de una aplicación tradicional.
También aparece una cuestión práctica: qué ocurre cuando un agente deja de ser necesario. La experiencia con cuentas técnicas debería servir de advertencia. Una identidad olvidada puede mantener permisos durante años simplemente porque nadie recuerda que existe. Si la adopción de agentes crece de manera desordenada, podemos terminar reproduciendo ese mismo problema a una escala considerablemente mayor.
Lo ocurrido esta semana muestra por qué importa
El 25 de septiembre de 2026, Microsoft Security Research publicó una investigación sobre actividad asociada a Storm-3168, vinculada también con JADEPUFFER. El caso involucró el compromiso de service principals dentro de Azure y su utilización para reconocimiento, obtención de credenciales y operaciones destructivas.
Según Microsoft, una de las identidades realizó más de 300 operaciones exitosas de lectura y reconocimiento durante aproximadamente quince horas y media. Posteriormente, otra identidad comprometida fue utilizada en una etapa mucho más agresiva: se observaron más de 150 intentos de operaciones destructivas o relacionadas con credenciales en unos 35 minutos. La fase destructiva principal se concentró en aproximadamente siete minutos e incluyó más de cien intentos de eliminación de cuentas de almacenamiento.
Es importante no exagerar lo que demuestra el caso. La investigación no establece que una inteligencia artificial autónoma haya decidido y ejecutado por sí sola toda la operación. Microsoft describe patrones de coordinación que considera fuertemente indicativos de automatización o ejecución mediante scripts y relaciona esta evolución con un escenario ofensivo donde la IA puede aumentar velocidad y capacidad operativa.
Para esta discusión, sin embargo, hay un detalle más importante que la etiqueta utilizada para describir el ataque: las acciones siguieron los roles que esas identidades ya tenían asignados dentro de Azure.
La automatización no necesitó crear mágicamente una nueva autoridad. Utilizó la que ya existía.
Eso deja una enseñanza bastante útil para el despliegue legítimo de agentes dentro de las empresas: la automatización amplifica el impacto de los permisos existentes. Un privilegio excesivo puede permanecer relativamente silencioso cuando detrás hay una persona que realiza unas pocas operaciones. La situación cambia cuando ese mismo privilegio puede ser utilizado para ejecutar decenas o cientos de acciones en pocos minutos.
Por eso la discusión sobre agentes no puede limitarse a proteger el modelo frente a un prompt malicioso. También debe incluir la identidad utilizada por el agente, el alcance de sus privilegios, la duración de sus credenciales y la velocidad con la que puede convertir una decisión en una acción.
Supervisión humana no significa aprobar todo
Frente a este problema aparece una respuesta lógica: mantener a una persona dentro del circuito. Para determinadas acciones es indispensable, especialmente cuando existe impacto financiero, operacional o de seguridad.
Pero human in the loop tampoco puede convertirse en una ventana de aprobación cada treinta segundos. Si un operador recibe suficientes solicitudes, el control humano pierde valor y puede transformarse en un acto mecánico. El problema ya es conocido en otros ámbitos de seguridad: cuando las alertas o solicitudes son excesivas, aparece fatiga y disminuye la calidad de la decisión.
La arquitectura necesita diferenciar niveles de autonomía. Consultar información de bajo riesgo puede no necesitar el mismo control que modificarla. Una operación fácilmente reversible puede admitir mayor autonomía que otra capaz de afectar producción, disponibilidad o información crítica.
La cuestión no debería reducirse a elegir entre autonomía completa o aprobación humana para absolutamente todo. El desafío está en establecer qué acciones pueden delegarse, cuáles requieren condiciones adicionales y cuáles deben permanecer bajo control humano.
América Latina llega a esta discusión en un momento interesante
Este debate resulta especialmente relevante para nuestra región porque la adopción de inteligencia artificial está avanzando rápidamente mientras muchas estructuras de gobernanza todavía se están construyendo.
El AI Readiness in Latin America Survey Report 2026 de RSM reunió respuestas de 461 líderes empresariales, aproximadamente 91% de ellos ubicados en América Latina. Cerca del 40% indicó que sus organizaciones ya estaban implementando soluciones de IA y, entre quienes habían iniciado esa adopción, 68% esperaba ampliar su utilización durante los doce meses siguientes.
El contraste aparece cuando se observa la gobernanza: solamente 18% reportó disponer de un framework formal de gobernanza de IA y 17% señaló contar con políticas formales para colaboradores.
Estas cifras deben interpretarse con cuidado. La encuesta fue realizada durante 2025, utiliza una muestra de conveniencia no probabilística y tiene una representación importante de perfiles de liderazgo. No corresponde utilizarlas como si fueran una fotografía estadística exacta de todas las organizaciones latinoamericanas.
Aun así, la tendencia merece atención. Las empresas quieren escalar IA mientras las estructuras destinadas a gobernarla todavía están madurando. Con asistentes generativos esa brecha ya tenía implicancias sobre privacidad, propiedad intelectual y seguridad de la información. Con agentes capaces de interactuar con aplicaciones e infraestructura, el problema también adquiere una dimensión operacional.
Latinoamérica tiene, al mismo tiempo, una oportunidad. Buena parte de estas arquitecturas todavía está siendo diseñada. No es necesario esperar a desplegar miles de agentes para preguntarnos cómo identificarlos, auditarlos y limitar sus privilegios.
Cuando el agente llega a OT
En infraestructura crítica y entornos industriales esta discusión se vuelve todavía más sensible.
Un agente puede aportar muchísimo valor en correlación de eventos, análisis de telemetría, investigación de incidentes, mantenimiento predictivo, priorización de alertas o asistencia al operador. Pero existe una diferencia fundamental entre analizar una situación y tener autoridad para intervenir sobre el proceso.
En un entorno IT, aislar un endpoint comprometido puede ser una acción relativamente habitual. En OT, ejecutar automáticamente esa misma decisión sin comprender la función del activo dentro del proceso puede afectar disponibilidad, producción e incluso condiciones de seguridad operacional.
Un agente puede identificar correctamente una anomalía y, aun así, recomendar una acción técnicamente válida desde ciberseguridad pero inconveniente para la operación.
Por eso, en sistemas críticos, identidad y permisos no deberían analizarse de forma aislada. También importa el impacto que puede producir una acción perfectamente autorizada.
Un agente podría disponer de autonomía para recopilar evidencia, correlacionar eventos y enriquecer una investigación, pero requerir aprobación para aislar determinados activos. En otros casos podrá ejecutar acciones reversibles y de bajo impacto mientras operaciones capaces de modificar el proceso industrial permanezcan bajo supervisión humana.
Ese límite no debería depender únicamente de que el modelo “entienda” la gravedad de la situación. Tiene que existir también en la arquitectura de autorización.
Del prompt al permiso
Estamos entrando en una etapa distinta de la inteligencia artificial empresarial. Durante mucho tiempo discutimos qué modelo respondía mejor una pregunta. Después comenzamos a preocuparnos por los datos que utilizaba y por la seguridad del propio modelo. Ahora estamos conectando esos modelos con herramientas y sistemas reales, y eso obliga a desplazar parte de la conversación: del prompt al permiso, de qué puede responder una IA a qué puede ejecutar, y de la capacidad del modelo a la autoridad que estamos dispuestos a delegarle.
La buena noticia es que no partimos de cero. IAM, Zero Trust, gestión de privilegios, auditoría y segregación de funciones llevan años resolviendo distintas versiones de este mismo problema. Lo que cambia ahora es el actor al que debemos gobernar y, sobre todo, la velocidad y autonomía con la que puede utilizar los permisos que recibe.
Para América Latina, construir esta capa de control mientras la adopción todavía está creciendo puede convertirse en una ventaja. Sería preferible hacerlo ahora que descubrir dentro de algunos años un ecosistema de agentes utilizando cuentas compartidas, API keys permanentes y privilegios heredados que nadie recuerda haber autorizado.
Antes de preguntarnos cuánta autonomía queremos darle a una inteligencia artificial, quizá convenga resolver algo más básico: qué identidad tendrá, en nombre de quién actuará y qué autoridad estamos realmente dispuestos a entregarle.
Fuentes consultadas
National Institute of Standards and Technology (NIST) / NCCoE. Accelerating the Adoption of Software and AI Agent Identity and Authorization. Febrero de 2026.
National Institute of Standards and Technology (NIST). Back to the Future: Why Agentic AI Needs a Strong Identity Foundation. 27 de agosto de 2026.
Coalition for Secure AI (CoSAI). Agentic Identity and Access Management. Framework aprobado por el Technical Steering Committee el 20 de marzo de 2026 y presentado públicamente en abril de 2026.
Microsoft Security Research. Storm-3168: Agentic-driven cloud attacks using compromised service principals. 25 de septiembre de 2026.
RSM Latin America. AI Readiness in Latin America Survey Report 2026. 2026.