Identidad de agentes de IA: control sin frenar la escala

Los agentes de IA solo escalan con identidad, límites y evidencias de cada acción. Cuando un agente lee datos, consulta sistemas, modifica registros o inicia flujos, deja de ser solo una interfaz de lenguaje. Pasa a operar como una identidad no humana dentro de la empresa.

Este cambio exige revisar un supuesto común: los permisos de aplicación no bastan para gobernar la autonomía. Un agente puede recibir una solicitud legítima y, durante la ejecución, encontrar instrucciones maliciosas en correos electrónicos, documentos, páginas o tickets. También puede combinar datos de fuentes distintas y producir una acción que ninguno de los sistemas aislados autorizaría de forma explícita.

El tema ganó densidad técnica recientemente. En febrero de 2026, el NIST abrió una propuesta específica sobre identificación, autenticación, autorización, delegación y no repudio para agentes de software e IA. En mayo, Google Cloud presentó las identidades de agente como un tipo distinto de principal, separado de usuarios y cuentas de servicio. OWASP también elevó el abuso de identidad y privilegios entre los riesgos más críticos de las aplicaciones agénticas. NIST, 2026 (nccoe.nist.gov) Google Cloud, 2026 (cloud.google.com) OWASP, 2026 (genai.owasp.org)

¿Qué es la identidad de agentes de IA y por qué debe estar separada?

La identidad de agentes de IA es el registro verificable que distingue a un agente de personas, aplicaciones genéricas y otros agentes. Debe contener atributos técnicos y operativos: propietario, entorno, finalidad, modelo utilizado, herramientas permitidas, origen del código, nivel de riesgo y ciclo de vida.

El error recurrente es ejecutar el agente con una cuenta de servicio amplia o, peor aún, con el token permanente de un usuario. Esto reduce la fricción inicial, pero elimina la accountability. Después de un incidente, el equipo sabe que una credencial ejecutó una acción, pero no puede responder preguntas básicas: qué agente la utilizó, bajo qué objetivo, en qué contexto y a solicitud de quién.

Una identidad propia resuelve la separación de responsabilidades. El usuario sigue siendo quien solicita una tarea. El agente se convierte en quien la ejecuta. La herramienta o API es el recurso protegido. Esta distinción permite aplicar políticas diferentes para cada relación.

El glosario ayuda a hacer el diseño objetivo:

• Identidad no humana: identidad de software, servicio, robot o agente que accede a recursos sin ser una persona.
• Delegación: autorización temporal para que el agente actúe en nombre de un usuario o proceso.
• Atestación: prueba criptográfica de que la carga de trabajo es quien afirma ser y se ejecuta en el entorno esperado.
• No repudio: capacidad de demostrar posteriormente qué identidad realizó una acción y con qué autorización.

La separación también impide que el agente sea tratado como un chat corporativo con acceso irrestricto. Un asistente que resume documentos tiene un perfil de riesgo diferente al de un agente que modifica precios, aprueba reembolsos o abre tickets para proveedores. La identidad debe expresar esa diferencia desde el registro.

¿Qué decisiones de acceso deben tomarse en cada acción?

La autorización debe evaluar la acción específica, no solo el permiso concedido durante la instalación. En sistemas tradicionales, una aplicación recibe scopes y los utiliza de manera relativamente predecible. En los agentes, la ruta de ejecución cambia según la tarea, el contexto recuperado y las herramientas disponibles.

Por eso, la decisión de acceso debe considerar al menos siete señales: identidad del agente, usuario o proceso delegante, recurso solicitado, acción prevista, datos involucrados, entorno y riesgo transaccional. Un agente de atención puede consultar el historial de un cliente. Esto no significa que pueda exportar toda la base de contactos o modificar condiciones comerciales.

Este modelo se conoce como autorización contextual. Combina RBAC, o control basado en roles, con ABAC, o control basado en atributos. RBAC determina una base simple, como “agente de soporte”. ABAC añade condiciones: región del cliente, clasificación del dato, horario, valor financiero, canal de origen y nivel de confianza de la sesión.

La documentación reciente de Microsoft recomienda preservar la autorización del usuario cuando el agente accede a tickets, archivos, correos electrónicos o registros de clientes. El patrón de acceso delegado es más adecuado cuando hay un usuario autenticado; el acceso exclusivo de la aplicación debe limitarse a tareas de back office, bien delimitadas y auditables. Microsoft Learn, 2026 (learn.microsoft.com)

En la práctica, la pregunta de la política no debe ser “¿el agente puede usar el CRM?”. Debe ser: “¿este agente, para este usuario, en esta tarea, puede leer este registro y ejecutar esta acción ahora?”. La diferencia parece semántica. Es una diferencia de arquitectura.

¿Cómo aplicar el privilegio mínimo cuando el agente decide el siguiente paso?

El privilegio mínimo para agentes significa conceder solo el acceso necesario para la siguiente etapa verificable. No significa entregar un conjunto amplio de permisos porque el flujo podría, en algún momento, necesitarlos.

La forma más segura de aplicar este principio es sustituir las credenciales permanentes por tokens cortos, específicos y revocables. Cada token debe tener un scope limitado por herramienta, recurso, acción y duración. Un agente que necesita crear un borrador de propuesta puede recibir acceso de lectura a datos aprobados del cliente y acceso de escritura solo a un repositorio de borradores. No necesita permiso para enviar el documento, aplicar un descuento o actualizar el registro maestro.

También conviene segmentar las herramientas según su criticidad. Organícelas en cuatro grupos:

1. Consulta de bajo impacto: buscar artículos, estado de pedido y documentación pública.
2. Consulta sensible: acceder a contratos, datos financieros, información de RR. HH. o datos personales.
3. Acción reversible: crear borradores, abrir tickets, sugerir cambios y actualizar campos no críticos.
4. Acción material: enviar pagos, eliminar datos, modificar precios, cambiar permisos o asumir compromisos externos.

Los grupos tres y cuatro exigen políticas adicionales. Para acciones materiales, utilice aprobación just-in-time, o JIT: el permiso se libera solo para esa decisión, en ese momento y con scope estricto. El usuario o gestor no “da acceso al agente”; aprueba una acción declarada.

Esto reduce el impacto de dos riesgos frecuentes. El primero es la inyección indirecta de prompt, cuando contenido externo intenta desviar al agente. El segundo es el uso indebido de herramientas, cuando una instrucción aparentemente inofensiva induce una acción fuera de la intención original. OWASP señala que el abuso de identidad y privilegios presenta una de las mayores brechas entre la severidad del riesgo y la preparación organizacional. (genai.owasp.org)

¿Dónde debe estar la política: en el prompt, en el agente o en la infraestructura?

La política de autorización debe aplicarse fuera del prompt y validarse antes de la ejecución de la herramienta. Los prompts orientan el comportamiento. No son controles de acceso. Un modelo puede interpretar mal una instrucción, recibir contexto conflictivo o ser manipulado por contenido externo. La decisión de permitir una transacción debe residir en una capa determinística.

Una arquitectura madura tiene cinco puntos de control. El primero es el inventario: cada agente, herramienta, servidor MCP, integración y credencial debe ser conocido. MCP, o Model Context Protocol, es un protocolo utilizado para conectar modelos y agentes con herramientas y fuentes de contexto. Puede acelerar integraciones, pero también multiplica la superficie de acceso.

El segundo punto es el proveedor de identidad. Emite y valida credenciales del usuario, del agente y de las cargas de trabajo. El tercero es el motor de políticas, que evalúa atributos y produce una decisión de permitir, denegar o solicitar aprobación. El cuarto es un gateway de herramientas, que intercepta llamadas a APIs, bases de datos, sistemas SaaS y automatizaciones. El quinto es la capa de observabilidad, responsable de registrar intención, contexto, decisión, ejecución y resultado.

El flujo recomendado es simple:

1. El usuario o proceso inicia una tarea.
2. El agente recibe una identidad propia y una delegación limitada.
3. Antes de cada llamada de herramienta, el gateway envía los atributos al motor de políticas.
4. La política permite, deniega o exige aprobación adicional.
5. El evento se registra con correlación entre usuario, agente, herramienta y recurso.

El NIST destaca exactamente estos frentes: identificación, autenticación, autorización dinámica, delegación, registro de acciones y trazabilidad del origen de datos y prompts. (nccoe.nist.gov) La consecuencia práctica es clara: la seguridad debe acompañar la ejecución, no solo el aprovisionamiento inicial.

¿Qué evidencias se necesitan para auditar un agente en producción?

Una trazabilidad de auditoría útil debe reconstruir la cadena completa de decisión, no solo enumerar llamadas de API. Los logs convencionales registran que se activó un endpoint. Para los agentes, esto es insuficiente. Es necesario saber por qué se tomó la acción y qué restricciones existían.

Cada evento relevante debe contener un identificador de correlación. Este identificador vincula la solicitud inicial, el usuario delegante, la versión del agente, el modelo, los documentos recuperados, el plan de acción, las herramientas llamadas, las decisiones de política y la respuesta final.

Registre también las versiones. Un agente puede cambiar de comportamiento cuando hay una modificación en el prompt de sistema, el modelo, la memoria, la herramienta o la política. Sin versionado, es difícil comparar incidentes e imposible atribuir una falla a una modificación específica.

Existe una distinción importante entre telemetría de ejecución y evidencia de control. La telemetría muestra latencia, volumen de llamadas, tasa de errores y costos. La evidencia de control demuestra que una acción fue autorizada de acuerdo con la política vigente. Las empresas necesitan ambas.

Defina indicadores que conecten la gobernanza con la operación: porcentaje de agentes inventariados, cantidad de permisos inactivos, volumen de acciones denegadas, aprobaciones por categoría de riesgo, intentos de acceso fuera de scope, tiempo para revocar credenciales y cobertura de logs por herramienta. Estos indicadores revelan si la organización está controlando la autonomía o solo observando su expansión.

¿Cómo implementar la identidad de agentes sin paralizar la operación?

La implementación debe comenzar por los agentes que ya acceden a sistemas críticos, no por una plataforma idealizada. El objetivo inicial es reducir la exposición real y crear estándares reutilizables.

Comience con un inventario de 30 días. Liste agentes en producción, prototipos con acceso a datos reales, integraciones de automatización, cuentas de servicio utilizadas por agentes, herramientas MCP y credenciales almacenadas en vaults o variables de entorno. Clasifique cada elemento por autonomía, datos accedidos e impacto de sus acciones.

Luego, elija un flujo de alto valor y riesgo controlable. Buenos candidatos son el triaje de tickets, la preparación de propuestas, la consolidación de indicadores o la actualización asistida de registros. Evite comenzar por pagos, eliminación de datos, permisos administrativos o decisiones regulatorias.

Cree para ese flujo una identidad exclusiva de agente, tokens cortos, scopes por herramienta y aprobación JIT para acciones materiales. Después, implemente el registro de correlación y simule fallas: instrucción maliciosa en un documento, token expirado, intento de lectura fuera de scope, herramienta no disponible y cambio de contexto durante la ejecución.

La expansión debe producirse mediante estándares, no mediante copias improvisadas. Un catálogo interno de agentes, herramientas aprobadas, políticas modelo y requisitos mínimos de logging reduce divergencias entre equipos. Las plataformas de orquestación, como Centriu, pueden concentrar la visibilidad operativa, siempre que la autorización siga aplicándose mediante controles independientes y verificables.

El resultado esperado no es impedir que los agentes actúen. Es lograr que cada acción tenga una identidad, una autoridad explícita, un límite técnico y una evidencia recuperable. Esta es la base para transformar la automatización en una capacidad operativa sostenible.