Conceder permisos a un agente de inteligencia artificial no es una tarea de configuración: es una decisión de riesgo que debería tomarse con el mismo criterio con el que se decide quién tiene firma en una cuenta bancaria. Cada permiso adicional amplía la superficie de daño posible, y esa ampliación no se compensa con la calidad del modelo, porque el riesgo no viene de que el modelo sea malo: viene de que puede ser manipulado o equivocarse dentro del alcance que le has dado.
La formulación que usamos internamente es sencilla: un agente no puede hacer daño en un sitio donde no tiene permiso. Todo el diseño de seguridad de un sistema agéntico se deriva de esa frase.
OWASP, en su Top 10 de riesgos para aplicaciones con modelos de lenguaje de 2025, coloca la inyección de prompt en el primer puesto por segunda edición consecutiva, y dedica una categoría entera —LLM06, *Excessive Agency*— a este problema exacto. La descompone en tres formas:
Las tres son decisiones de diseño, no fallos del modelo. Y las tres se toman, casi siempre, en la fase de integración, por conveniencia técnica y sin que nadie del negocio se entere.
El vector que las conecta es la inyección indirecta de prompt: un contenido externo —un correo, un PDF de un proveedor, una página web, un ticket de cliente— que incluye instrucciones dirigidas al modelo. El agente lo lee como parte de su contexto y actúa. Si sus permisos son amplios, un texto escrito por un tercero acaba ejecutando acciones dentro de tus sistemas.
Este es el motivo por el que la seguridad de un agente no se resuelve eligiendo mejor modelo. Se resuelve limitando lo que el agente puede hacer cuando alguien consigue influir sobre él.
Aquí hay un cambio estructural que muchas organizaciones no han incorporado a su gestión de accesos. Durante veinte años, el control de identidad se diseñó para personas: alta, baja, roles, revisión periódica. Los agentes introducen identidades que no son personas, se crean en minutos, no aparecen en el organigrama y rara vez se revisan.
El informe Cost of a Data Breach de IBM de 2025 ofrece el dato que cierra el argumento: el 97% de las organizaciones que sufrieron un incidente relacionado con IA carecía de controles de acceso adecuados. No es un problema de sofisticación del atacante. Es un problema de higiene de permisos.
Lo hemos tratado en profundidad en identidades no humanas, agentes de IA y ciberseguridad, pero el resumen operativo es este: si tu proceso de gestión de accesos no contempla identidades que no son personas, tu inventario de accesos está incompleto, y probablemente lo esté en la parte que más puede hacer.
No todos los permisos tienen el mismo perfil de riesgo. Esta clasificación permite decidir en una reunión de treinta minutos:
Nivel | Qué puede hacer el agente | Control necesario |
1. Lectura acotada | Consultar datos de un dominio concreto | Registro de accesos y límite de volumen |
2. Lectura amplia | Consultar múltiples sistemas y datos sensibles | Permisos por rol, enmascarado de datos, auditoría |
3. Escritura reversible | Crear borradores, propuestas, registros en estado pendiente | Validación humana antes de confirmar |
4. Escritura irreversible | Pagos, comunicaciones a clientes, cambios en producción | Aprobación explícita, doble control y plan de reversión |
La regla práctica es que la mayor parte del valor de negocio está en los niveles 1 y 3, y la mayor parte del riesgo está en el 4. Un agente que prepara el reembolso y lo deja pendiente de aprobación captura casi todo el ahorro de tiempo con una fracción del riesgo de uno que ejecuta el reembolso.
Cuando alguien insiste en el nivel 4, la pregunta correcta es cuánto valor adicional aporta frente al nivel 3. Normalmente es el tiempo que tarda una persona en pulsar un botón. Rara vez compensa.
Identidad propia por agente. Nunca una cuenta compartida ni la reutilización de una cuenta de servicio existente. Sin identidad propia no hay atribución posible de lo que ocurrió.
Permiso mínimo por tarea, no por agente. Si el agente hace tres cosas distintas, cada una debería tener su propio alcance. Un permiso concedido para una tarea queda disponible para todas las demás.
Credenciales de corta duración. Tokens que caducan, no claves permanentes en un fichero de configuración.
Lista blanca de acciones. Definir explícitamente qué operaciones puede ejecutar, en lugar de definir cuáles no. Lo segundo siempre está incompleto.
Límites de volumen y de importe. Un agente que puede emitir reembolsos debería tener un tope por operación y por día. Es el mismo principio que se aplica a cualquier persona con capacidad de gasto.
Registro completo e inmutable. Qué entró, qué decidió, qué ejecutó, con qué versión del modelo y qué persona validó. Sin esto no hay auditoría ni defensa posible.
Interruptor de parada. Un mecanismo para detener el agente sin desplegar código y sin depender del proveedor.
Ninguno de los siete es exótico. Todos son prácticas estándar de seguridad aplicadas a un actor nuevo. Lo llamativo es la frecuencia con que se omiten precisamente porque el actor es nuevo y no encaja en los procedimientos existentes.
El riesgo de este artículo es que se lea como un argumento para no hacer nada. No lo es. El enfoque que funciona es de escalado progresivo:
Este es el mismo principio de supervisión escalonada que aplicamos al integrar componentes de IA dentro de sistemas empresariales, y la razón por la que la gobernanza no es una fase final del proyecto sino una propiedad de su arquitectura, como explicamos en riesgos, alucinaciones y gobernanza de IA
Antes de aprobar cualquier despliegue de un agente, conviene responder a esto: si un desconocido pudiera escribir el texto que va a leer este agente, ¿qué es lo peor que podría conseguir que hiciera?
Si la respuesta es «consultar información pública», el riesgo es aceptable. Si la respuesta es «emitir un pago» o «escribir a todos nuestros clientes», el diseño no está terminado.
Porque determinan la superficie de daño posible. Un agente no puede causar daño donde no tiene permiso, con independencia de la calidad del modelo o de si es manipulado. OWASP dedica a este problema una categoría propia en su Top 10 para aplicaciones LLM de 2025: Excessive Agency.
Es la concesión de capacidad excesiva a un agente, en tres formas: funcionalidad excesiva (acceso a herramientas que su tarea no requiere), permisos excesivos (identidad con más privilegios de los necesarios) y autonomía excesiva (ejecución de acciones de alto impacto sin validación humana).
Es la concesión de capacidad excesiva a un agente, en tres formas: funcionalidad excesiva (acceso a herramientas que su tarea no requiere), permisos excesivos (identidad con más privilegios de los necesarios) y autonomía excesiva (ejecución de acciones de alto impacto sin validación humana).
Siete: identidad propia y no compartida, permiso mínimo por tarea, credenciales de corta duración, lista blanca de acciones permitidas, límites de volumen e importe, registro completo e inmutable de cada ejecución y un mecanismo de parada que no requiera desplegar código.
Solo para acciones reversibles y de bajo impacto, y después de haber medido durante un periodo suficiente qué porcentaje de sus propuestas se aprueba sin cambios. Retirar la validación humana por presión de calendario es la causa más común de incidentes en sistemas agénticos.
Igual que las humanas pero con más disciplina: alta documentada, propietario asignado, permisos revisables, caducidad de credenciales y revisión periódica. IBM documentó en 2025 que el 97% de las organizaciones con incidentes relacionados con IA carecía de controles de acceso adecuados.
¿Sabes qué puede hacer exactamente cada agente que tienes desplegado? Auditamos alcance, identidades, permisos y trazabilidad de tus sistemas de IA, y entregamos el diagnóstico por escrito. Solicita la auditoría → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
