Permisos de agentes de IA: el riesgo de dar acceso de más

Un agente de IA que puede leer, escribir o ejecutar acciones en tus sistemas necesita permisos, igual que un empleado. La diferencia es que casi nadie revisa esos permisos: la mayoría de los agentes de IA desplegados hoy en las empresas tiene más acceso del que su tarea requiere, y eso abre una puerta que no estaba ahí antes de automatizar.

El problema no es que los agentes de IA sean inseguros por naturaleza. Es que se les da acceso de administrador para una tarea de lectura, se les conecta a sistemas enteros para resolver un caso concreto, y nadie vuelve a revisar ese permiso cuando la tarea cambia o el agente ya no la necesita.

Qué significa «permisos» cuando quien actúa es un agente, no una persona

Un permiso define qué puede ver y qué puede hacer una identidad dentro de un sistema: a qué datos accede, qué acciones ejecuta, durante cuánto tiempo y bajo qué condiciones. Con una persona, esto se gestiona con roles, contraseñas y revisiones periódicas de acceso.

Un agente de IA es una identidad distinta, pero casi ninguna empresa lo trata como tal. Según el estudio de Cloud Security Alliance y Aembit (enero de 2026, 228 profesionales de TI y seguridad), el 52% de las empresas hace que sus agentes operen con identidades de carga de trabajo, el 43% con cuentas de servicio compartidas, y el 31% directamente bajo la identidad de un usuario humano — exactamente el tipo de acceso que ningún marco de seguridad recomienda para un sistema que actúa de forma autónoma y, a menudo, sin supervisión en el momento de la acción.

Lo que dicen los datos: el acceso de más es la norma, no la excepción

El mismo estudio de CSA/Aembit, con el 85% de los encuestados ya usando agentes en entornos de producción, encontró que:

• El 74% reconoce que sus agentes de IA reciben más acceso del que necesitan para su función.
• El 68% no puede distinguir con claridad si una acción en sus sistemas la realizó un agente de IA o una persona.
• El 79% cree que los agentes crean rutas de acceso nuevas y difíciles de monitorizar.
• El 52% de los permisos que usan los agentes fue heredado de un acceso pensado originalmente para humanos u otros sistemas, no diseñado para ellos.
• El 33% no sabe con qué frecuencia se rotan las credenciales de sus agentes.
• Solo el 22% aplica un marco de control de acceso de forma consistente a sus agentes de IA.

McKinsey llega a una conclusión parecida desde otro ángulo: en su guía de seguridad para IA agéntica (noviembre de 2025), el 80% de las empresas ha visto a sus agentes de IA comportarse fuera de los límites previstos, el 39% ha sufrido ya un incidente de acceso no autorizado por parte de un agente, y el 33% ha visto manejo inapropiado de datos restringidos. Pese a esto, solo el 20% ha construido controles específicos para gestionar el riesgo.

La lectura conjunta de ambos estudios es clara: las empresas están desplegando agentes más rápido de lo que están aprendiendo a controlarlos.

Qué puede salir mal con un agente sobre-permisionado

Un ejemplo ilustrativo, no un caso real, ayuda a ver dónde aparece el problema en el día a día: una empresa conecta un agente de atención al cliente a su CRM para que pueda consultar el estado de un pedido. Por simplicidad técnica, se le da acceso de lectura y escritura a toda la base de clientes, no solo al campo de pedidos. Meses después, nadie recuerda por qué el agente tiene ese alcance, y una instrucción ambigua de un usuario (o una inyección de instrucciones en un correo que el agente procesa, el mismo tipo de riesgo que describimos al hablar de Shadow AI) puede hacer que el agente modifique o exponga datos que nunca debería haber podido tocar. El fallo no está en el modelo de IA: está en el permiso que nunca se ajustó.

El principio de mínimo privilegio, aplicado a agentes

El mínimo privilegio no es una idea nueva — lleva décadas en seguridad informática — pero aplicarlo a agentes de IA, sobre todo cuando varios agentes coordinan tareas entre sí (lo que tratamos en orquestación de agentes de IA), exige algo que la mayoría de las empresas todavía no tiene:

1. Credenciales con alcance (scoped), no genéricas. Un agente que consulta pedidos no necesita acceso a nóminas ni a contratos, aunque comparta plataforma con los sistemas que sí los tienen. 2. Privilegio cero por defecto (zero standing privileges). El agente solicita acceso cuando lo necesita para una tarea concreta, y lo pierde al terminarla, en vez de mantenerlo abierto permanentemente. 3. Trazabilidad a un responsable humano. Cada acción de un agente debería poder vincularse a la persona o al proceso de negocio que la autorizó, no quedar en una cuenta de servicio anónima. 4. Rotación y caducidad de credenciales, igual que con cualquier cuenta con acceso sensible — no credenciales estáticas que nadie revisa. 5. Registro y auditoría de cada acción, separado del registro de actividad humana, para poder responder con exactitud a «¿qué hizo este agente y con qué permiso?».

Antes de dar acceso a un agente de IA

La pregunta que casi nadie se hace a tiempo es la más simple: ¿qué es lo mínimo que este agente necesita para hacer su trabajo, y quién revisa ese acceso cuando el trabajo cambie? Antes de conectar un agente a un sistema, conviene mapear qué datos y qué acciones toca de verdad, no qué podría llegar a tocar «por si acaso» — y revisar ese mapa cada vez que el agente cambia de tarea o de alcance.

En Optima Quantum diseñamos y auditamos el acceso de los agentes de IA que ponemos en producción para empresas, con el mismo rigor que aplicamos al resto de la infraestructura: permisos con alcance, trazabilidad y revisión periódica, no credenciales abiertas de fábrica. Si ya tienes agentes de IA funcionando y no sabes con certeza qué pueden tocar, es el primer punto que revisamos en una auditoría de ciberseguridad. Contáctanos y lo repasamos juntos.

Preguntas frecuentes

¿Qué diferencia hay entre los permisos de un agente de IA y los de un usuario normal? En la práctica, muy poca diferencia técnica — ambos son identidades con acceso a sistemas y datos. La diferencia real está en la gestión: los permisos de los usuarios suelen revisarse con regularidad, mientras que los de los agentes de IA, según los datos de CSA/Aembit, casi nunca (solo el 22% de las empresas aplica un marco de control consistente).

¿Por qué un agente de IA necesitaría más acceso del que usa? Normalmente por comodidad en el despliegue: es más rápido conectar un agente a un sistema entero que definir con precisión qué campos y qué acciones necesita de verdad. Ese atajo es exactamente lo que el 74% de las empresas reconoce haber hecho, según el mismo estudio.

¿El mínimo privilegio ralentiza lo que puede hacer un agente de IA? No si se diseña desde el principio. Un agente con acceso definido con precisión a lo que necesita no es más lento al ejecutar su tarea; lo que cambia es que, si algo falla o se le da una instrucción maliciosa, el daño posible queda limitado a ese alcance.

¿Cómo sé si mis agentes de IA están sobre-permisionados hoy? Revisando, para cada agente, qué sistemas y qué datos puede tocar frente a lo que su tarea real exige, y comprobando si existe un registro que permita rastrear cada una de sus acciones hasta un responsable humano. Si esa revisión no existe, es la primera señal de que hay más acceso del necesario.

¿Esto aplica solo a agentes conectados a sistemas críticos (finanzas, RRHH)? No. Un agente de atención al cliente conectado «solo» al CRM, o uno que gestiona correo, maneja igualmente datos personales y de negocio sensibles. El riesgo no depende de lo crítico que parezca el sistema, sino de cuánto acceso real tiene el agente dentro de él.