¿Bajo qué identidad actúa un agente de IA? El problema que aparece cuando deja de solo responder

Mientras un agente se limita a responder preguntas, su identidad puede parecer un detalle técnico. Cuando empieza a consultar información sensible, utilizar herramientas, modificar datos o ejecutar acciones, saber quién es para cada sistema, con qué autoridad actúa y qué permisos tiene se convierte en una condición para llevarlo a producción.

Durante mucho tiempo, las organizaciones diseñaron sus modelos de identidad alrededor de dos grandes categorías: personas y aplicaciones.
Los agentes de IA introducen una tercera situación mucho menos cómoda.
No son personas. Pero tampoco se comportan necesariamente como una aplicación tradicional que ejecuta siempre la misma secuencia de instrucciones.
Un agente puede interpretar contexto, elegir entre distintas herramientas, decidir qué pasos realizar y encadenar acciones sobre varios sistemas para cumplir un objetivo.
Por eso, una pregunta aparentemente sencilla empieza a tener implicancias de arquitectura, seguridad y gobierno:

¿Bajo qué identidad está actuando ese agente?
La identidad y la autorización de agentes ya forman parte de la discusión sobre cómo operar Agentic AI en entornos enterprise. El problema no se limita a autenticar una aplicación: hay que poder identificar al agente, controlar bajo qué autoridad actúa y atribuir posteriormente las acciones que realiza sobre datos, herramientas y sistemas. Para una entidad financiera, esa conversación no debería empezar cuando el agente ya está conectado al core.
Debería formar parte de la estrategia y del diseño de la solución desde el inicio.

La identidad del agente no es solamente un usuario técnico

Cuando hablamos de Agent Identity estamos intentando responder quién es ese agente frente a los sistemas con los que interactúa. Para hacerlo, conviene separar cuatro conceptos:

Identidad: quién es el agente.
Credenciales: cómo demuestra esa identidad ante un sistema.
Permisos: qué está autorizado a consultar o hacer.
Accountability: quién responde por esa identidad, sus permisos y las acciones que ejecuta.

Parecen cuestiones similares, pero no lo son. Un agente puede tener una identidad perfectamente identificable y, aun así, disponer de permisos demasiado amplios. Puede tener permisos correctamente definidos pero utilizar credenciales compartidas con otras automatizaciones, haciendo difícil atribuir una acción. O puede estar correctamente autenticado y autorizado, pero no existir un owner claramente responsable de revisar sus accesos o desactivarlo cuando deje de utilizarse. Por eso, resolver la identidad del agente no significa simplemente crear una service account. Significa diseñar cómo será reconocido, autorizado, limitado y trazado dentro de la organización.

¿Por qué el problema cambia con Agentic AI?

Pensemos en un asistente que consulta documentación interna y responde una pregunta. Si únicamente puede recuperar información que el usuario ya está autorizado a ver, el problema de acceso es relativamente acotado.
Ahora imaginemos que ese mismo sistema evoluciona.
Puede consultar información de distintas aplicaciones. Puede abrir un caso. Modificar el estado de una operación. Ejecutar una consulta contra una base de datos. Utilizar una API. Iniciar un workflow. Incluso realizar una acción en nombre de una persona.
La pregunta pasa a ser: ¿Quién le dio autoridad para hacerlo?
A medida que el agente deja de responder y empieza a recomendar, decidir o actuar, aparecen nuevos requerimientos: identidad, permisos, herramientas autorizadas, autonomía, supervisión humana, logging, trazabilidad y responsabilidades. La capacidad técnica del agente deja de ser la única pregunta relevante. También importa bajo qué autoridad puede utilizar esa capacidad.

Tres modelos de autoridad que no deberían confundirse

No existe una única arquitectura de identidad válida para todos los agentes.
Una decisión fundamental consiste en determinar en nombre de quién actúa el agente.

1. El agente actúa bajo la autoridad del usuario

En algunos casos, el agente debe acceder solamente a aquello que la persona que lo está utilizando ya puede consultar o modificar.
Por ejemplo, un ejecutivo solicita a un agente que analice determinados documentos o consulte información sobre las cuentas que administra.
El usuario está autenticado y el agente actúa utilizando una autorización delegada y acotada. Pero incluso en este modelo hay una pregunta importante:
¿El agente debería poder hacer todo lo que puede hacer el usuario o únicamente el subconjunto de acciones necesario para completar esa tarea?
Delegar identidad no debería equivaler automáticamente a delegar todos los privilegios.

2. El agente actúa con identidad propia

Otros agentes realizan tareas sin que exista un usuario interactuando directamente con ellos. Por ejemplo, un agente puede monitorear información de manera continua, identificar excepciones y generar alertas tempranas.
En esos casos puede necesitar una identidad propia, administrada como una identidad no humana dentro de la organización.
Esto permite diferenciar claramente sus acciones de las realizadas por una persona y aplicar permisos específicos para su función.
A medida que las plataformas enterprise evolucionan, empiezan a aparecer modelos de identidad específicamente diseñados para agentes, con capacidades de lifecycle management, ownership y auditoría.
La implementación concreta dependerá del stack tecnológico de cada organización. El principio, sin embargo, es mucho más amplio: un agente que actúa debería poder ser identificado como agente.

3. El agente utiliza distintas autoridades según la acción

Los casos enterprise más avanzados pueden requerir una combinación.
El agente puede consultar determinados datos con identidad propia, acceder a otros en nombre del usuario y requerir una autorización adicional antes de ejecutar una acción de mayor impacto. Es justamente acá donde la arquitectura de identidad empieza a cruzarse con el diseño de autonomía. No todas las acciones deberían heredar el mismo nivel de autoridad.

Identidad y permisos: la diferencia entre “puede” y “debería poder”

Conseguir técnicamente que un agente acceda a un sistema no significa que ese acceso sea el apropiado. Una arquitectura preparada para producción debería aplicar el principio de least privilege: otorgarle únicamente los permisos necesarios para realizar su función. Eso parece evidente hasta que empezamos a implementar.
Para acelerar un MVP es habitual utilizar una cuenta técnica con acceso amplio, reutilizar credenciales existentes o habilitar una API completa aunque el agente necesite únicamente dos operaciones. Puede ser suficiente para validar el caso, no necesariamente lo es para producción.
El problema es que un permiso excesivo puede pasar inadvertido durante mucho tiempo y hacerse visible recién ante una revisión de Riesgos, un incidente o un comportamiento inesperado en producción.
La diferencia parece pequeña: ¿Puede acceder? versus ¿Debería esta identidad poder acceder a este recurso para completar esta tarea? Pero es una de las diferencias entre conectar un agente y gobernarlo.
Y ese control no termina cuando el agente entra en producción. Sus permisos deberían revisarse durante todo su ciclo de vida. A medida que cambia el caso de uso, las herramientas disponibles o su nivel de autonomía, hay que validar que conserve únicamente los accesos que necesita y retirar aquellos que dejaron de ser necesarios. Least privilege no es una configuración inicial. Es una política que necesita mantenerse en el tiempo.

La identidad debería limitar también el alcance de las herramientas

En Agentic AI, los permisos no terminan en los datos. Un agente opera utilizando tools: APIs, conectores, búsquedas, bases de datos, workflows, funciones u otros agentes. Eso significa que la arquitectura de autorización debería contemplar al menos tres niveles:

Qué recursos puede consultar.
Qué herramientas puede utilizar.
Qué acciones puede ejecutar mediante esas herramientas.

Por ejemplo, permitir acceso a una API bancaria no implica necesariamente habilitar todos sus endpoints. Un agente podría estar autorizado para consultar el estado de una transacción, pero no para modificarla. Podría generar una recomendación de ajuste sin poder ejecutarla. O podría realizar determinadas acciones solamente por debajo de un umbral y escalar el resto para aprobación humana. La identidad define quién es. La política define hasta dónde puede llegar.
Esas políticas pueden materializarse mediante guardrails, que establecen límites sobre datos, herramientas, acciones, niveles de autonomía y situaciones que requieren supervisión humana. En arquitecturas multiagente, este principio se vuelve todavía más importante. No todos los agentes necesitan la misma autoridad. Un agente puede consultar información. Otro puede ejecutar una modificación. Un tercero puede verificar o auditar el resultado.
Separar responsabilidades permite aplicar permisos distintos según la función de cada agente y reducir el alcance de una falla o de una acción incorrecta.

¿Qué ocurre con las credenciales?

Existe otra diferencia importante entre identidad y credenciales. Las credenciales (tokens, certificados, secretos u otros mecanismos) son aquello que permite a una identidad autenticarse frente a un recurso. En una arquitectura preparada para producción deberían evitarse, siempre que la plataforma lo permita, secretos permanentes incrustados en código o credenciales compartidas sin mecanismos claros de rotación y revocación. La pregunta no es solamente cómo obtiene acceso el agente hoy. También hay que poder responder:

¿Cómo revocamos ese acceso mañana?
¿Qué pasa si cambia su función?
¿Qué ocurre si el agente deja de utilizarse?
¿Quién revisa sus permisos?
¿Qué sucede si se compromete una credencial?
¿Podemos deshabilitarlo sin afectar otras automatizaciones?

El lifecycle de la identidad importa tanto como su creación.

El verdadero problema aparece cuando queremos reconstruir una acción

Imaginemos un caso sencillo. Un agente detecta una diferencia durante una conciliación financiera y modifica el estado de un registro. Semanas después, Auditoría necesita saber qué ocurrió. Decir que “lo hizo el agente” no alcanza.
La organización debería poder reconstruir:

qué agente ejecutó la acción
bajo qué identidad
qué usuario inició el proceso, si correspondía
qué datos consultó
qué permisos tenía en ese momento
qué herramienta utilizó
qué modificación realizó
si la acción necesitaba aprobación
quién la aprobó
y cuál era el owner responsable del agente.

Ahí aparece la relación entre identidad y trazabilidad. Sin una identidad diferenciada, la organización puede registrar que una acción ocurrió, pero no necesariamente atribuirla correctamente. Y sin atribución, el logging pierde una parte importante de su valor.

Un ejemplo: un agente para conciliaciones financieras

Supongamos que una entidad utiliza IA para automatizar parte del proceso de conciliación. En una primera versión, el agente puede leer extractos bancarios, consultar registros contables, comparar ambas fuentes, identificar diferencias y proponer una resolución.
En ese nivel, podría tener una identidad propia con permisos de lectura sobre fuentes específicas. Ahora la organización decide permitirle resolver automáticamente determinadas diferencias. El mismo caso cambia. El agente ahora necesita permiso de escritura, pero probablemente no sobre todo el sistema contable. Tal vez pueda ejecutar solamente determinadas modificaciones, dentro de ciertos montos o tipos de operación. El resto requiere aprobación humana. Y si posteriormente se amplía su autonomía, los permisos deberían volver a revisarse. La identidad puede ser la misma. La autoridad no necesariamente. Ese es justamente uno de los motivos por los que en COA planteamos la secuencia: leer ≠ recomendar ≠ modificar ≠ ejecutar. Cada salto requiere revisar identidad, permisos, guardrails, supervisión y trazabilidad.

En Perú, el ecosistema financiero se está volviendo más conectado

Esta conversación tiene un contexto particular para las instituciones financieras peruanas. El avance de Finanzas Abiertas, APIs estandarizadas, nuevos modelos de interoperabilidad y esquemas de autorización está llevando al sistema financiero hacia un entorno cada vez más conectado.
Esto no constituye una regulación específica sobre identidad de agentes de IA.
Pero sí muestra una dirección clara: cada vez más procesos dependerán de APIs, actores interconectados, autorización explícita y mecanismos de confianza.
Si a ese ecosistema incorporamos agentes capaces de utilizar esas interfaces y actuar sobre sistemas empresariales, la identidad de la máquina empieza a ser tan importante como la identidad del usuario que inicia una operación.

El riesgo de no resolver Agent Identity antes de escalar

El problema rara vez aparece con el primer agente. Aparece cuando empiezan a multiplicarse y, en arquitecturas más avanzadas, a interactuar u orquestarse entre sí. Un equipo utiliza una cuenta técnica, otro crea su propia service account, un tercero conecta un copilot con credenciales de aplicación, algunos agentes operan por delegación de usuario, otros tienen acceso persistente. Y en determinado momento nadie puede responder fácilmente cuántos agentes existen, qué pueden hacer o quién es responsable de cada uno.
Ahí aparece otro riesgo: agent sprawl.

Agent sprawl y guardrails: dos problemas distintos

Agent sprawl es la proliferación de agentes dentro de una organización sin suficiente visibilidad, ownership o gobierno sobre ellos. El problema no es que existan muchos agentes, sino no poder responder con claridad cuáles están activos, quién es responsable de cada uno, qué identidades utilizan, a qué sistemas acceden y qué permisos mantienen.
Los guardrails, en cambio, son los controles que determinan qué puede hacer cada agente y bajo qué condiciones puede hacerlo. Pueden limitar datos, herramientas, acciones o niveles de autonomía, y definir cuándo el agente debe detenerse, solicitar autorización o escalar una decisión a una persona.
La diferencia puede resumirse así:

Agent sprawl: ¿tenemos control sobre todos los agentes que existen?
Guardrails: ¿tenemos control sobre lo que puede hacer cada uno?

Son problemas diferentes, pero relacionados. Una organización puede tener guardrails bien diseñados para algunos agentes y, aun así, sufrir agent sprawl si no tiene un inventario, owners y un lifecycle común. Del mismo modo, tener un registro completo de agentes no garantiza que sus acciones estén correctamente limitadas. Escalar Agentic AI requiere resolver ambas capas: gobernar el ecosistema de agentes y gobernar el comportamiento de cada agente.
Cuando esto no ocurre, empiezan a aparecer permisos excesivos, credenciales difíciles de administrar, acciones difíciles de atribuir, dependencias entre agentes y cuentas compartidas, mayor exposición ante una identidad comprometida y dificultad para retirar accesos cuando cambia o desaparece un caso de uso.
La consecuencia de negocio tampoco es menor. Lo que inicialmente aceleró el MVP puede convertirse después en un obstáculo para Seguridad, Arquitectura, Risk o Auditoría cuando llega el momento de aprobar producción.

Agent Identity no es un problema aislado de Seguridad

Existe el riesgo de reducir toda esta discusión a IAM. Identity & Access Management es una pieza crítica, pero el problema enterprise es más amplio.
La identidad tiene que conectarse con el owner del caso, los datos autorizados, las herramientas disponibles, los límites de autonomía, las reglas de aprobación, el logging, la observabilidad, las excepciones y el lifecycle del agente. Por eso, en COA abordamos Agent Identity dentro de una capa más amplia de Controlled Agents, junto con Agent Registry, roles y permisos, Tool Registry, Policy Enforcement, Human-in-the-Loop, logging, trazabilidad, auditoría, accountability, guardrails y límites de autonomía. No alcanza con autenticar al agente. Hay que poder gobernar su autoridad.

Seis preguntas para revisar antes de conectar un agente a producción

Antes de permitir que un agente interactúe con datos o procesos críticos, una organización debería poder responder al menos estas preguntas:

¿Qué identidad utiliza el agente?
¿Actúa por sí mismo o en nombre de un usuario?
¿A qué datos, sistemas y herramientas puede acceder?
¿Qué puede leer, recomendar, modificar o ejecutar?
¿Cómo se otorgan, revisan y revocan sus permisos?
¿Podemos atribuir cada acción al agente y a un owner responsable?

Si alguna respuesta es difusa, probablemente todavía exista trabajo por hacer antes de aumentar su autonomía.

La pregunta no es solo qué puede hacer el agente

Los agentes de IA prometen automatizar procesos que hasta ahora requerían intervención humana. Ese es justamente su valor.
Pero cuanto más capaces se vuelven, menos sostenible resulta tratarlos como una API más o esconderlos detrás de una cuenta técnica genérica.
Una organización preparada para Agentic AI debería poder responder claramente:
quién es cada agente, bajo qué autoridad actúa, a qué puede acceder, qué puede hacer y quién responde por esas acciones. Porque dar autonomía sin identidad clara no elimina responsabilidad. Solo hace más difícil saber dónde está.
En COA abordamos Agent Identity como parte de una arquitectura más amplia de Data + Integration + AI + Governance, diseñada para que los agentes puedan operar sobre sistemas y procesos reales con identidad, permisos, guardrails, supervisión y trazabilidad definidos desde el diseño.

¿Sabés qué puede hacer cada agente dentro de tu organización?

Creamos una Matriz de permisos para agentes de IA para ordenar una conversación que suele quedar distribuida entre Data, Arquitectura, Seguridad y Negocio:
identidad → datos y sistemas → leer → recomendar → modificar → ejecutar → aprobación → auditoría → excepciones

Ver Matriz de permisos para agentes de IA

Preguntas frecuentes

¿Qué es la identidad de un agente de IA?

Es la identidad digital con la que un agente se autentica e interactúa con datos, aplicaciones, APIs y otros recursos empresariales. Permite diferenciar sus acciones de las realizadas por usuarios u otras aplicaciones y aplicar políticas específicas de acceso y autorización.

¿Un agente de IA debería usar una service account?

Depende de la arquitectura y de la plataforma. Para determinadas automatizaciones, una identidad de workload o service account puede ser adecuada. En agentes con mayor autonomía puede ser conveniente utilizar identidades específicas que permitan administrar ownership, permisos, lifecycle y auditoría. Lo importante es evitar identidades compartidas o excesivamente privilegiadas y garantizar scope, trazabilidad y revocación.

¿Cuál es la diferencia entre identidad y permisos de un agente?

La identidad determina quién es el agente frente a un sistema. Los permisos determinan qué está autorizado a hacer esa identidad. Una arquitectura segura necesita resolver ambas cosas.

¿Qué significa aplicar least privilege a un agente de IA?

Significa darle únicamente acceso a los datos, sistemas, herramientas y acciones que necesita para realizar su función. Esos privilegios deberían revisarse durante todo el ciclo de vida del agente, especialmente cuando cambia el caso de uso o aumenta su autonomía.

¿Por qué Agent Identity es importante para auditoría?

Porque permite atribuir acciones a una identidad concreta. Combinada con logging y trazabilidad, ayuda a reconstruir qué agente accedió a qué recurso, qué operación realizó y bajo qué autoridad.

¿Cuál es la diferencia entre agent sprawl y guardrails?

Agent sprawl es un problema de escala y gobierno: aparecen múltiples agentes y la organización pierde visibilidad sobre cuáles existen, quién los administra, qué identidades utilizan y qué accesos mantienen.
Los guardrails son controles aplicados sobre cada agente para determinar qué puede hacer, bajo qué condiciones y cuándo debe detenerse o solicitar intervención humana. En términos simples: Agent sprawl pregunta si tenemos control sobre todos nuestros agentes. Guardrails pregunta si tenemos control sobre lo que puede hacer cada uno.