Un agente con tus permisos es un problema de identidades

Los agentes de IA empiezan a ejecutar acciones en tus sistemas. El control que decide si un piloto sale bien vive en la identidad y los permisos que le das.

Tres avisos en la misma semana: el CTO de Red Hat explica que asegurar un agente consiste en asegurar la identidad, el runtime y la red que tiene alrededor; Okta dedicó su conferencia Oktane a tratar los agentes como identidades de primera clase; y el informe de Delinea sobre la brecha entre política y aplicación encontró que casi todas las empresas tienen una política de acceso para sus agentes, aunque el equipo de seguridad no siempre la aplica en los sistemas.

Si preparas un piloto de agente, este detalle te afecta más que la elección de modelo. Un agente que solo responde preguntas comete errores que se quedan dentro de la conversación. Uno que crea pedidos, mueve registros o escribe en tu ERP multiplica cada fallo. Gartner calcula que cuatro de cada diez aplicaciones empresariales llevarán agentes específicos antes de que termine 2026, así que el acceso a los sistemas se convierte en una decisión de negocio.

Los permisos que hereda

El patrón habitual en los pilotos: el agente funciona con el token de una persona o con una clave de servicio compartida. Así arranca rápido, y así hereda todos los permisos de esa persona. Si el agente que prepara confirmaciones de pedido entra con las credenciales de una operadora, puede leer todo lo que lee ella: nóminas si el ERP las guarda, datos bancarios de proveedores, lo que sea. Un mensaje malintencionado que llegue a su contexto (un correo, un ticket) puede bastar para que consulte lo que no debe.

El rastro queda igual de mal. Los registros dirán que la operadora consultó la tabla de nóminas a las tres de la madrugada. Nadie podrá distinguir qué hizo el agente y qué hizo la persona, y revocar el acceso del agente significa cortar el acceso de quien lo usaba. Una encuesta de Gravitee publicada en febrero lo pone en cifras: solo dos de cada diez equipos dan al agente identidad propia; el resto reparte claves compartidas o tokens genéricos.

Identidad propia y mínimo privilegio

El arreglo que el sector está estandarizando: cada agente con identidad propia y la persona como identidad distinta. Cuando el agente actúa en tu nombre, el token lleva las dos: quién delega y quién ejecuta. Con eso respondes a las preguntas que un auditor va a hacer: quién pidió la acción, qué agente la hizo y con qué permiso.

El segundo control es el principio de mínimo privilegio. Al agente le das acceso al proceso que automatiza, y hasta ahí: si su trabajo es consultar pedidos, no toca proveedores ni nóminas. Los proveedores de identidad ya traen soporte para esto (Entra Agent ID de Microsoft, identidades de agente en Okta, perfiles OAuth específicos en el protocolo MCP), de modo que el trabajo de tu equipo consiste en definir límites y revisarlos.

Y el tercero: credenciales de vida corta y aprobación humana en lo irreversible. Un token que caduca en minutos limita el daño de un secuestro de sesión. Un umbral humano (por encima de cierto importe, cualquier borrado o cambio de datos maestros) evita que el error de un agente se convierta en incidente.

Qué revisar antes de conectar el agente

Antes de darle acceso, tu equipo puede pasar esta lista:

  • ¿Con qué identidad entra? Si la respuesta es el token de una persona o una clave compartida, ahí empieza el arreglo.
  • ¿Qué puede hacer, más allá de lo que puede leer? Limita herramientas y recursos al proceso concreto, y revisa el alcance cuando el proceso cambie.
  • ¿Qué hace sin preguntar? Las acciones irreversibles piden aprobación humana y registro.
  • Si mañana se comporta de forma extraña, ¿en cuánto puedes cortar su acceso sin afectar a nadie más?

Delinea encontró que casi todas las empresas encuestadas tienen una política sobre a qué datos acceden sus agentes; el mismo informe mide la distancia entre esa política y lo que está aplicado en los sistemas. Esa distancia se cierra con identidades, permisos acotados y registros: el mismo trabajo de control de acceso que ya haces con las personas de tu equipo.

En Luxion conectamos agentes a sistemas reales (ERP, e-commerce, soporte) y montamos ese control desde el primer día: identidad propia para el agente, permisos limitados al proceso y aprobación humana donde toca. Si quieres verlo sobre un proceso tuyo, preparamos un prototipo conectado a tus datos y lo dejamos funcionando en pocas semanas.

¿Hablamos?

¿Te ha resonado algo de esto?

Si quieres aplicarlo a tu negocio, te escuchamos sin compromiso y te enseñamos un prototipo antes de cerrar nada.

¿Hablamos?

¿Te ha resonado algo de esto?

Si quieres aplicarlo a tu negocio, te escuchamos sin compromiso y te enseñamos un prototipo antes de cerrar nada.