AgentOps
Los agentes de IA necesitan identidad y límites de acceso
Durante mucho tiempo, cuando hablábamos de identidad digital dentro de las empresas, la pregunta parecía relativamente conocida: ¿quién es el usuario que intenta acceder a determinado sistema y qué está autorizado a hacer?
Después llegaron las aplicaciones, las API, los servicios, los workloads y otras identidades no humanas. Ahora, los agentes de inteligencia artificial agregan una nueva dimensión al problema.
Un agente puede consultar documentos, acceder a bases de datos, utilizar herramientas, llamar a una API, abrir un ticket, activar otro sistema o incluso solicitar la actuación de otro agente. Dependiendo del nivel de autonomía recibido, también puede ejecutar acciones que antes dependerían directamente de una persona.
Cuando eso ocurre, saber solo quién es el usuario que inició el proceso deja de ser suficiente.
Necesitamos saber quién es el agente, en nombre de quién actúa, a qué recursos puede acceder, qué acciones está autorizado a ejecutar y cómo reconstruir después lo que efectivamente hizo.
La cuestión parece técnica, pero rápidamente se transforma en una cuestión de gobernanza.
Un agente que actúa también necesita tener identidad
Esta discusión ya empieza a aparecer de forma bastante concreta en las iniciativas de seguridad e identidad.
En 2026, el National Institute of Standards and Technology (NIST), organismo estadounidense responsable del desarrollo de estándares y referencias técnicas, por medio del National Cybersecurity Center of Excellence (NCCoE), centro del NIST orientado a la aplicación práctica de tecnologías y estándares de ciberseguridad, publicó un documento conceptual dedicado específicamente a la identidad y la autorización de agentes de software y de inteligencia artificial [1].
El punto de partida es bastante objetivo: a medida que los agentes acceden a diferentes conjuntos de datos, herramientas y aplicaciones para cumplir sus tareas, las organizaciones necesitan comprender cómo los principios ya conocidos de identificación, autenticación y autorización pueden aplicarse a ellos [1].
La diferencia entre estos conceptos es importante.
La identificación responde quién es el agente. La autenticación busca confirmar que realmente es quien afirma ser. La autorización determina qué puede hacer ese agente una vez reconocida su identidad.
Dar autonomía a un agente sin saber claramente quién es y qué está autorizado a hacer es crear una nueva identidad privilegiada sin los controles que ya aprendimos a exigir de las personas y de los sistemas.
Esta discusión también ayuda a corregir una simplificación común. Un agente no debería tratarse solo como una extensión invisible de la aplicación que lo ejecuta. A medida que recibe responsabilidades propias, su identidad también pasa a ser relevante para controlar y auditar lo que ocurre.
La identidad del agente no es necesariamente la identidad del usuario
Uno de los problemas más interesantes surge cuando un agente ejecuta una tarea en nombre de alguien.
Imagine un agente autorizado a consultar documentos corporativos para preparar un análisis. El usuario que solicitó la tarea tiene determinados permisos, pero el agente también necesita identificarse ante los sistemas a los que accederá.
Son dos preguntas diferentes: ¿quién es el agente? y ¿en nombre de quién actúa?
La documentación de Google Cloud sobre Agent Identity muestra cómo esta distinción ya está llegando a las implementaciones. El servicio asigna una identidad criptográfica propia a cada agente y le permite autenticarse ante recursos, herramientas y otros agentes, actuando tanto en nombre propio como en nombre de un usuario [2].
Esto es importante porque compartir una misma identidad entre diferentes agentes reduce la capacidad de saber cuál de ellos realizó realmente determinada acción. Una identidad individual permite aplicar políticas específicas y construir una trazabilidad más precisa del comportamiento de cada agente.
El propio documento del NIST trata explícitamente la delegación de autoridad en situaciones en las que el agente actúa on behalf of, es decir, en nombre de alguien, y también cuestiona cómo vincular la identidad del agente con la identidad humana cuando existe una autorización con participación de una persona [1].
Saber quién inició una tarea no es suficiente cuando otro participante, con identidad y capacidad de acción propias, pasa a ejecutarla.
Esta distinción tiende a volverse especialmente importante en procesos en los que diferentes agentes trabajan para diferentes usuarios, departamentos o clientes utilizando los mismos sistemas corporativos.
Identidad sin autorización resuelve solo la mitad del problema
Reconocer al agente es solo el primer paso. Después surge una pregunta más difícil: ¿qué puede hacer?
Un agente responsable de analizar incidentes quizá necesite consultar alarmas, topología, inventario y cambios recientes. Eso no significa que también deba tener permiso permanente para modificar configuraciones, reiniciar servicios o acceder a cualquier información disponible en el entorno.
Aquí el principio de least privilege, o mínimo privilegio, se vuelve particularmente relevante: cada identidad debe recibir solo los accesos necesarios para cumplir su función.
El documento del NIST coloca precisamente esta cuestión entre los desafíos de autorización para agentes: cómo establecer el mínimo privilegio cuando las acciones necesarias pueden no ser totalmente previsibles antes de la ejecución. El mismo documento también discute la autorización dinámica cuando el contexto del agente cambia y la delegación de autoridad en escenarios en los que actúa en nombre de otra identidad [1].
La Blueprint Alliance, iniciativa multivendor anunciada en septiembre de 2026 por empresas de identidad, nube, datos, aplicaciones y ciberseguridad, sigue una dirección similar. Entre sus principios están tratar a cada agente como una identidad propia, limitar el acceso a la tarea en lugar de mantener privilegios permanentes y preservar la trazabilidad de la delegación cuando los agentes crean subagentes o actúan en nombre de personas [3].
Este cambio es importante porque los agentes pueden operar de manera mucho más dinámica que las aplicaciones tradicionales.
El acceso adecuado puede depender de la tarea, del usuario representado, del recurso solicitado, del contexto de la operación e incluso del momento en que se ejecuta la acción.
En entornos agénticos, la pregunta deja de ser solo «¿este agente tiene acceso?» y pasa a ser «¿este agente debería tener este acceso, para esta tarea, en este momento y en este contexto?».
Esto acerca la identidad al contexto y transforma la autorización en una decisión potencialmente más dinámica.
Cuando un agente llama a otro, la cadena de responsabilidad no puede desaparecer
La complejidad aumenta de nuevo en entornos multiagente.
Un agente puede recibir una tarea y delegar parte de ella a otro agente, que consulta una herramienta, accede a un servicio y devuelve un resultado. Dependiendo de la arquitectura, esa secuencia puede continuar por varios pasos.
Si una acción inadecuada ocurre al final de esa cadena, será necesario reconstruir no solo qué agente la ejecutó, sino también de dónde vino la autorización, quién delegó la tarea y cómo llegó hasta él.
La Blueprint Alliance incluye la delegación trazable de extremo a extremo entre sus principios para entornos agénticos [3]. El NIST también trata la delegación, el vínculo entre identidades humanas y agentes y el registro de las acciones entre los elementos necesarios para construir esa trazabilidad [1].
En este contexto aparece también el concepto de non-repudiation (no repudio), utilizado en seguridad para garantizar que existan evidencias que permitan asociar una acción con la identidad que la realizó, evitando que su autoría pueda negarse posteriormente o quede sin una atribución clara.
Esta capacidad será importante no solo para la seguridad, sino también para la auditoría, la investigación de incidentes y la responsabilidad operativa. Si varios agentes participaron en un flujo de trabajo, necesitamos poder reconstruir la cadena completa: quién recibió la tarea, quién delegó, quién accedió a determinado dato, quién tomó determinada decisión y quién finalmente ejecutó la acción.
Cuanto mayor es la autonomía y la colaboración entre agentes, más importante será preservar la cadena de responsabilidad por lo que hacen.
Antes de controlar a los agentes, será necesario saber que existen
Hay además un problema anterior a la propia autorización.
Una organización puede no tener visibilidad completa sobre todos los agentes que empiezan a surgir en su entorno.
Los equipos pueden crear agentes internamente, los proveedores pueden incorporar agentes a sus aplicaciones y los usuarios pueden empezar a utilizar servicios que introducen nuevas identidades e integraciones sin pasar por los mismos procesos tradicionales de gobernanza.
Palo Alto Networks llama la atención sobre la necesidad de descubrimiento continuo, inventario y clasificación de los agentes, incluidos los llamados shadow agents, agentes que surgen u operan fuera de la visibilidad y de los controles formales de la organización [4].
La Blueprint Alliance también incluye el descubrimiento y la catalogación entre los primeros elementos de su arquitectura y propone que cada agente se registre como una identidad distinta, asociada a un responsable humano o a un equipo operativo [3].
Este punto acerca la discusión al problema más amplio de la Shadow AI, el uso de recursos de inteligencia artificial fuera de los mecanismos formales de conocimiento y gobernanza de la empresa.
No es posible gobernar la identidad, el acceso o el comportamiento de un agente cuya existencia la organización desconoce.
A medida que crear agentes se vuelve más fácil, el inventario y el ownership dejan de ser tareas administrativas secundarias y pasan a formar parte de la propia seguridad de la operación.
La identidad también necesita acompañar el ciclo de vida
Las personas ingresan, cambian de función y dejan las organizaciones. Los sistemas se crean, se modifican y se desactivan. Los agentes también tendrán un ciclo de vida.
Un agente puede cambiar de versión, recibir nuevas herramientas, pasar a atender otro proceso o dejar de ser necesario. Los permisos que tenían sentido en una determinada función pueden volverse excesivos después de un cambio.
Por eso la identidad no puede tratarse solo en el momento en que se crea el agente.
La propia arquitectura propuesta por la Blueprint Alliance relaciona la gobernanza de los agentes con revisiones de acceso, separación de funciones y disciplina de ingreso, cambio y salida aplicada al alcance, al responsable y a las versiones de los agentes [3].
Esto significa que la gestión deberá responder continuamente preguntas aparentemente simples: ¿este agente todavía existe? ¿Sigue ejerciendo la misma función? ¿Su responsable sigue siendo el mismo? ¿Los permisos continúan siendo adecuados? ¿Los recursos a los que tiene acceso siguen siendo necesarios?
En entornos con pocos agentes, esto puede ser administrable manualmente. A medida que crece el número de agentes y flujos de trabajo, tiende a convertirse en un problema operativo.
Es en este punto donde la identidad empieza a conectarse directamente con AgentOps.
Identidad, observabilidad y AgentOps empiezan a converger
En los artículos anteriores de esta serie, discutimos que poner agentes en producción exige una disciplina operativa capaz de acompañar su ciclo de vida, comportamiento, costos, resultados y confiabilidad. También vimos que la observabilidad pasa a incluir lo que los agentes hacen durante sus ejecuciones.
La identidad agrega otra capa a esta arquitectura.
Un trace puede mostrar que se llamó a una herramienta. La identidad permite saber qué agente hizo la llamada. La autorización ayuda a responder por qué tenía permiso para hacerla. La delegación permite reconstruir en nombre de quién o de qué otro agente ocurrió esa acción.
Estas dimensiones no se sustituyen unas a otras. Se complementan.
La propia Blueprint Alliance organiza su propuesta en torno a cuestiones que conectan descubrimiento, identidad, autorización, monitoreo en tiempo de ejecución y respuesta [3]. La documentación de Google Cloud también combina la identidad del agente con mecanismos de gateway y políticas de acceso a los recursos utilizados durante la ejecución [2].
A medida que los agentes ganan autonomía, por lo tanto, la identidad deja de ser solo una preocupación de seguridad y pasa a integrar la propia capacidad de operar esos sistemas.
Gobernar agentes exigirá conectar quiénes son, qué pueden hacer, qué hicieron efectivamente y qué resultado produjeron.
Este quizá sea uno de los cambios más importantes con respecto a las identidades de máquina que ya conocemos. No estamos solo autenticando un componente técnico que ejecuta una función definida previamente. Estamos empezando a atribuir identidad a sistemas capaces de interpretar contexto, elegir caminos y realizar acciones con grados crecientes de autonomía.
De la visión a la práctica: ARGUS
A medida que los agentes de IA reciben acceso a aplicaciones, herramientas e información corporativa, la identidad y la autorización pasan a formar parte de un desafío operativo más amplio. No basta con saber qué permisos se concedieron. También es necesario comprender cómo se utilizan durante la ejecución de las tareas.
ARGUS aborda esta dimensión por medio de sus capacidades de AgentOps y AI Gateway, que permiten relacionar la actuación de los agentes con las políticas aplicables, los recursos utilizados y la información disponible sobre sus ejecuciones.
La propuesta no es sustituir los sistemas corporativos de identidad y acceso. Es complementar esa capa con visibilidad sobre el comportamiento de los agentes y, cuando corresponda, con el contexto operacional construido a partir de las herramientas de monitoreo, observabilidad y gestión existentes.
Saber qué agente ejecutó una acción es importante. Comprender en qué circunstancias ocurrió y qué recursos se utilizaron hace que esa información sea mucho más útil para la gobernanza y la auditoría.
Conozca ARGUS y vea cómo funciona en la práctica.
Sobre el autor
Paulo Florêncio de Menezes es emprendedor, socio y cofundador de empresas como Target Solutions, BiPTT y ARGUS.
Es graduado en Procesamiento de Datos por la Universidad Federal de Amazonas (UFAM), tiene un MBA en Gestión Empresarial por la Fundação Dom Cabral (FDC) y una Maestría Profesional en Economía por la Fundação Getulio Vargas (FGV).
En su investigación de Maestría, desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.
Referencias
[1] National Institute of Standards and Technology / National Cybersecurity Center of Excellence. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. Concept Paper, 2026.
[2] Google Cloud. Agent Identity overview. Identity and Access Management documentation, 2026.
[3] Blueprint Alliance. Industry leaders form the Blueprint Alliance to advance a shared architecture for securing AI agents. 2026.
[4] Palo Alto Networks. Secure AI Agent Identities & Access. 2026.