Cuando una empresa adopta agentes de IA, la conversación suele empezar por los modelos y las capacidades. Pero la pregunta que de verdad separa un despliegue sólido de uno frágil es más aburrida y más importante: ¿quién puede hacer qué?
Dejar la gobernanza para “más adelante” es el error más caro que vemos. Retrofitear permisos sobre un sistema que ya está en producción es doloroso; diseñarlos desde el primer día es casi gratis.
Por qué el control de acceso es la base, no un extra
Un agente de IA no es un documento pasivo: es un actor que puede leer datos, ejecutar acciones y escribir en tus sistemas. Darle acceso sin control equivale a dar una llave maestra a un empleado nuevo el primer día.
Los riesgos son concretos:
- Un agente creado para una tarea inocua termina con acceso a datos sensibles.
- Alguien modifica un agente en producción sin que quede registro.
- Un usuario ejecuta agentes que nunca debió poder usar.
El control de acceso granular ataca los tres de raíz.
El principio de mínimo privilegio, aplicado a agentes
La regla de oro de la seguridad clásica se traslada tal cual: cada usuario y cada agente debe tener el mínimo acceso necesario para su función, ni uno más.
En la práctica esto significa separar claramente tres capacidades distintas:
- Ver un agente y su actividad.
- Usar un agente (ejecutarlo), sin poder cambiarlo.
- Editar o crear agentes y sus conexiones.
Muchos incidentes se evitan simplemente porque quien solo necesita usar un agente no puede editarlo.
El mejor permiso es el que nunca tuviste que conceder.
Roles en Root
En Root, los permisos se conceden por rol dentro de cada empresa y se vuelven a comprobar en cada petición. Una persona puede estar en varias empresas, con un rol distinto en cada una:
| Rol | Permisos |
|---|---|
| Owner | Todo dentro de la empresa, incluido conceder o retirar el rol owner. |
| Admin | Todo dentro de la empresa salvo gestionar owners. |
| Designer | Lo de un member y, además, crear y editar las pantallas de diseño. |
| Member | Lectura de la empresa y conexión de sus propios agentes al MCP. |
Además, cada herramienta que invoca un agente actúa con los permisos de la persona que lo autorizó: un agente no puede llegar a información que esa persona no tenía autorizada. Esto evita el escenario clásico de la “escalada silenciosa de privilegios” a través de un agente.
Cuatro buenas prácticas para empezar bien
- Define roles antes de crear agentes. Decide desde el inicio quién es owner, admin, designer o member.
- Aplica mínimo privilegio por defecto. Concede permisos amplios solo cuando haya una razón, no por comodidad.
- Revisa accesos periódicamente. Los equipos cambian; los permisos deberían cambiar con ellos.
- Exige trazabilidad. Asegúrate de que cada creación, edición y ejecución quede registrada.
La gobernanza habilita, no frena
Existe el mito de que controlar los accesos ralentiza a los equipos. Es al revés: cuando las reglas están claras y automatizadas, la gente se mueve con más confianza, porque sabe que no va a romper nada ni a exponer datos por error.
La gobernanza bien hecha es invisible cuando funciona. Y ese es exactamente el objetivo.
¿Quieres montar tus roles y permisos correctamente desde el inicio? Habla con nuestro equipo.