RBAC frente a ABAC: Elegir un modelo de control de acceso para agentes de IA

Qué es realmente RBAC

El control de acceso basado en roles (RBAC) añade una capa intermedia entre los usuarios y los permisos. En lugar de conceder directamente a Priya la capacidad de leer un grupo de secretos, se define un rol llamado Secret Group Viewer que contiene ese permiso y se le asigna a Priya.

El modelo de control de acceso basado en roles consta de tres componentes:

El valor principal radica en la indirección. Cuando el equipo de seguridad decide que los lectores ya no deben ver valores secretos, modifica un solo rol y el cambio se aplica al instante a todos los lectores. El NIST formalizó este modelo hace décadas, razón por la cual todas las consolas cloud incluyen una página de roles.

Su debilidad radica también en esta indirección. Los roles son conjuntos estáticos. Si un permiso solo debe aplicarse desde una IP corporativa o sobre registros de la propia región del solicitante, el modelo RBAC básico no puede expresarlo. Los equipos suelen responder creando más roles: analyst-eu, analyst-eu-readonly, analyst-eu-readonly-prod. Esto genera una explosión de roles, la razón más habitual por la que se evalúa la transición a ABAC.

Qué es realmente ABAC

El control de acceso basado en atributos elimina el paquete estático de permisos. En lugar de comprobar qué rol tiene un sujeto, evalúa una expresión de política en tiempo de solicitud a partir de cuatro categorías de atributos:

Una política típica sigue una estructura como: permitir lectura cuando subject.department == resource.owning_team y resource.classification != "restricted" y env.network == "corp". NIST SP 800-162 es la especificación de referencia; en la práctica, ABAC se implementa mediante lenguajes de políticas como XACML, Rego o Cedar integrados en un servicio de autorización.

ABAC ofrece una capacidad de expresión superior. Una regla bien definida puede reemplazar a un centenar de roles y permite gestionar relaciones que RBAC no puede representar, como por ejemplo: "el médico asignado a este paciente".

Sin embargo, esta flexibilidad tiene un coste. Las políticas son código: requieren revisión, pruebas, control de versiones y un análisis de cómo interactúan las distintas reglas. Además, la pregunta fundamental en cualquier auditoría —¿quién tiene acceso a estos datos?— deja de tener una respuesta directa mediante consulta. Se debe enumerar cada sujeto y evaluar la política para cada uno de ellos. Aunque algunos motores ofrecen herramientas de consulta inversa para abordar esto, la mayoría de los despliegues no las utilizan.

Diferencias entre RBAC y ABAC de un vistazo

Un aspecto que la tabla no muestra: ABAC requiere un requisito previo fundamental, atributos fiables. Una política basada en resource.data_region solo será tan precisa como la disciplina de etiquetado que mantenga ese campo. La mayoría de las organizaciones que intentan implementar ABAC descubren que tienen un problema de datos sin etiquetar antes de tener un problema de autorización. Además, ambos modelos no son excluyentes: el enfoque de producción más habitual utiliza RBAC como estructura base con algunas condiciones de atributos superpuestas.

Errores habituales en la adopción

Considerar la explosión de roles como un motivo para cambiar de modelo. La explosión de roles suele ser un error de delimitación del alcance (scoping), no un fallo del modelo. Si existen roles como analyst-team-a, analyst-team-b y analyst-team-c, no se necesitan atributos: basta con un único rol de analista vinculado de forma independiente a los recursos de cada equipo. La mayor parte de las dificultades atribuidas a RBAC surgen al conceder permisos a nivel de todo el tenant cuando la vinculación debería haberse aplicado a un recurso específico.

Adoptar una flexibilidad que no se puede auditar. ABAC permite redactar reglas que el equipo de cumplimiento normativo no puede interpretar fácilmente. Ese compromiso a veces es aceptable, pero nunca debe asumirse de forma no planificada. Antes de adoptar un motor de políticas, conviene definir quién responderá al cuestionario de revisión de accesos del siguiente trimestre y mediante qué procedimiento.

Olvidar que las concesiones de acceso se combinan. Un sujeto puede tener acceso directo y también heredarlo a través de un equipo; revocar un acceso no elimina el otro. La complejidad aumenta al integrar un motor de políticas sobre esta estructura, ya que dos sistemas diferentes pueden conceder permisos de manera independiente.

Configurar permisos para el usuario e ignorar al agente. Todos los controles aplicados al usuario son irrelevantes si el agente que ha configurado se ejecuta con un token de servicio compartido con acceso a todo el tenant.

¿Quieres ver el acceso acotado en práctica?

Inicia TrueFoundry y asigna un rol a un solo recurso en lugar de a todo el tenant: solo lleva un par de minutos.

Empieza gratis

Por qué los agentes de IA parecen el caso de uso ideal para ABAC

Un agente de IA es un sujeto no humano cuya autoridad efectiva no es estática. Puede leer un repositorio público en un paso y acceder a un registro de cliente en el siguiente. Actúa en nombre de diferentes personas en diferentes momentos. Sus entradas pueden ser manipuladas por terceros: el contenido malicioso de un issue puede redirigir al agente hacia una herramienta que no debería ejecutar. Y a diferencia de un usuario humano, no se detiene a evaluar si una acción es adecuada.

Al trasladar esto a un requisito de seguridad, el planteamiento coincide con la estructura de ABAC: permitir esta llamada a la herramienta cuando el usuario ejecutante tenga acceso previo al destino, la herramienta no sea destructiva y la solicitud no proceda de contenido no confiable. Tres atributos, una sola regla. ¿Por qué, entonces, casi ningún sistema se despliega así en producción?

Porque los atributos no siempre están disponibles de forma fiable en el momento de tomar la decisión. Determinar si "esta solicitud procede de contenido no confiable" no es un simple campo de datos, sino un problema técnico complejo. Verificar si "el usuario ejecutante tiene acceso previo" es posible, pero la forma más eficiente y precisa de hacerlo es consultar al sistema de destino utilizando las propias credenciales del usuario, en lugar de replicar su modelo de permisos en un motor de políticas local con el riesgo de que la copia quede desactualizada.

Además, el impacto en la auditabilidad es crítico en el entorno donde operan los agentes. Los permisos de los agentes son el punto principal de inspección en las revisiones de seguridad, y responder que "la política permite el acceso bajo estas condiciones" ofrece menor certeza que una tabla que confirme que este agente dispone del rol MCP Server User en tres servidores específicos.

Por lo tanto, los agentes requieren un acceso más restringido y más auditable que el de los usuarios humanos. ABAC aporta lo primero, pero dificulta lo segundo. Esto explica el patrón de despliegue predominante: RBAC con una delimitación estricta de recursos, combinado con controles contextuales específicos donde el contexto sea realmente crítico.

Cómo funciona este modelo en TrueFoundry

TrueFoundry implementa RBAC con vinculaciones de roles acotadas por recurso. No es un motor de políticas ABAC, y es importante remarcarlo de forma transparente. El modelo responde a una pregunta clara: ¿quién puede hacer qué y dónde?

• Un sujeto es la identidad que recibe el acceso: un usuario, un equipo, una cuenta virtual o un agente.
• Un recurso es el elemento al que se accede: una cuenta de proveedor de modelos, un servidor MCP, un agente, un cluster, un workspace, un repositorio o un grupo de secretos.
• Un rol es un conjunto definido de acciones permitidas.

Asignar un rol a un sujeto sobre un recurso genera una vinculación de rol (role binding). El acceso se gestiona de manera independiente a la configuración del recurso, lo que permite modificar los permisos de acceso sin necesidad de redesplegar componentes.

Las concesiones de acceso se realizan directamente desde el propio recurso: al abrir su menú de tres puntos y seleccionar Access Control:

A continuación, se seleccionan uno o varios sujetos y un rol. El panel lateral muestra las acciones incluidas en cada rol, permitiendo verificar los permisos antes de confirmarlos:

Los roles disponibles dependen del tipo de recurso: Manager y User en una cuenta de proveedor de modelos; MCP Server Manager, MCP Server User y MCP Server Approver en un servidor MCP; Agent Manager y Agent Access en un agente. Los clusters, workspaces y grupos de secretos cuentan con sus propios niveles de administración, miembro y lector.

Tres niveles de alcance

Los roles operan en tres niveles de alcance diferenciados:

Los roles Admin y Read-Only Member son fijos y no se pueden modificar. El rol Member sí se puede editar: es la base que recibe cada usuario por defecto y, de forma predeterminada, solo incluye cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup y agent:CreateAgent. No otorga acceso directo a ningún modelo, servidor MCP o workspace individual; estos permisos se obtienen mediante vinculaciones de recursos o pertenencia a equipos.

Los roles de equipo representan el concepto más cercano a una condición por atributo en este modelo. El rol Team Member incluye virtual-account:ReadVirtualAccount, acotado a las Virtual Accounts propiedad de los equipos a los que pertenece el usuario. El permiso es idéntico para todos los usuarios; el conjunto de objetos al que da acceso varía según cada persona.

Este mecanismo se basa en la propiedad del recurso (ownership scoping), no en ABAC: sin expresiones de políticas ni evaluación de atributos en tiempo de ejecución, únicamente una relación fija entre un equipo y sus recursos. Cubre el caso de uso habitual que suele motivar el uso de atributos, manteniendo la simplicidad y legibilidad.

Roles personalizados para permisos de alta granularidad

Cuando los roles predefinidos a nivel de tenant resulten demasiado amplios o restringidos, es posible crear roles personalizados utilizando el catálogo de permisos. Cada permiso sigue la estructura recurso:Accion, agrupado por tipo de recurso:

Una regla clave rige su uso: los permisos de un rol personalizado se aplican a todos los recursos del tipo seleccionado. Un rol personalizado con mcp-server:ReadMcpServer dará acceso a todos los servidores MCP del tenant. Para restringir el acceso a un solo recurso, debe utilizarse la página de Access Control de dicho recurso. Confundir este principio puede provocar que un rol diseñado para un único servidor otorgue acceso de lectura a nivel de todo el tenant.

Mecanismos de control contextual

TrueFoundry integra sensibilidad al contexto en cuatro puntos específicos. Ninguno utiliza políticas basadas en atributos y todos son plenamente auditables:

El segundo mecanismo cubre la mayor parte de las necesidades asociadas habitualmente a ABAC. Cuando un agente invoca una herramienta en nombre de un usuario mediante OAuth por usuario, el servicio de destino evalúa los permisos reales de dicho usuario. En lugar de replicar las listas de control de acceso (ACL) de un sistema externo como GitHub dentro de un motor de políticas, la evaluación se delega directamente en el sistema propietario, evitando inconsistencias por datos desactualizados. El modelo de control de acceso de MCP se basa directamente en este principio.

Una consideración importante: los tokens de Virtual Account otorgan el mismo nivel de acceso a todas las solicitudes. Son adecuados para la comunicación entre servicios (service-to-service), pero no deben utilizarse cuando se requiera gestionar permisos a nivel de usuario individual.

Ejemplo práctico de configuración

Dos escenarios habituales de la documentación ilustran el funcionamiento del modelo desde distintas perspectivas.

Conceder acceso de solo lectura a un auditor. Asignar el rol Read-Only Member desde Access > Users. Se trata de un rol predefinido a nivel de tenant que proporciona acceso de solo lectura en los tipos de recursos compatibles y no se puede modificar, garantizando que un rol de auditoría no pueda ser ampliado de forma no controlada. Para un grupo de auditores, se recomienda asignarlo a un equipo para que los nuevos miembros lo hereden automáticamente. Si el auditor solo debe acceder a recursos específicos, no se debe asignar un rol a nivel de tenant, sino conceder el rol de viewer o access directamente en cada recurso.

Permitir la creación de servidores MCP sin otorgar el rol de Admin. La tendencia habitual es asignar el rol de Admin porque la creación de un servidor requiere un permiso que Member no incluye. En su lugar, es preferible crear un rol personalizado que incluya exclusivamente mcp-server:CreateMcpServer:

A continuación, se asigna desde Access > Users o Access > Teams:

El comportamiento resultante es el punto clave: Create MCP Server permite a un usuario crear un nuevo servidor, pero no otorga acceso a los servidores existentes. Tras crear el servidor, el creador se asigna a sí mismo el rol MCP Server Manager desde la página de Access Control de ese servidor específico.

La autoridad de creación y la autoridad de acceso permanecen separadas sin interferir entre sí. Una política ABAC podría expresar esta misma regla, pero requeriría un análisis detallado para verificar su comportamiento exacto. En este modelo, equivale a dos filas en dos tablas. El patrón también es aplicable a menor escala: para permitir que los usuarios vean los controles del gateway sin ser Admin, basta con editar el rol Member y añadir gateway-controls:ListGatewayControls.

¿Listo para delimitar el alcance de tu primer agente?

Crea un rol personalizado, vincúlalo a un servidor MCP y verifica con precisión a qué puede acceder tu agente.

Empieza gratis en TrueFoundry

Consideraciones técnicas clave

Las concesiones de acceso se combinan y revocar una no elimina las demás. Un sujeto puede recibir acceso de forma directa y también mediante su pertenencia a un equipo. Al analizar por qué un usuario conserva acceso a un recurso, se deben revisar tanto las vinculaciones directas como las heredadas de sus equipos.

Modificar un rol por defecto de equipo afecta a todos los equipos. Los roles Team Member y Team Manager se editan en Access > Default Roles, y los cambios se aplican de forma global. Añadir virtual-account:ManageVirtualAccount para que un equipo gestione tokens otorgará esa capacidad a los miembros de todos los demás equipos. Cada usuario seguirá acotado a sus propios equipos, pero la funcionalidad estará disponible globalmente.

Los roles de tenant se combinan con los roles de tenant asignados a equipos. Un usuario tiene un rol de tenant asignado directamente. Si además pertenece a un equipo que posee un rol de tenant, sus permisos efectivos serán la unión de ambos. Por ello, la autoridad real de un usuario no siempre se refleja únicamente en su registro individual. Los equipos pueden crearse manualmente, aprovisionarse desde un IdP mediante SCIM o aplicarse con tfy apply utilizando un archivo YAML de equipo, pudiendo mapear un valor de claim del IdP directamente a un equipo.

Lecturas relacionadas

• Autenticación de API y RBAC en el AI Gateway: cómo se aplican estos roles en el tráfico del gateway
• Control de acceso en MCP: Asegurando agentes de IA con un MCP Gateway: permisos a nivel de herramienta y servidor en la práctica
• Control de acceso empresarial en MCP: escalado del modelo en múltiples servidores y equipos
• Qué es un MCP Gateway: Arquitectura y casos de uso: ubicación del punto de control y aplicación de políticas
• Construyendo un marco de gobernanza de IA: el contexto general de políticas en torno al control de acceso

Conclusión

El debate entre RBAC y ABAC no debe reducirse a una elección ambigua. ABAC es adecuado cuando el acceso depende de un contexto en tiempo de ejecución medible y fiable, y se dispone de la infraestructura y el equipo para mantener el código de las políticas. Para los demás escenarios, RBAC con una adecuada delimitación de alcance cumple el objetivo manteniendo una estructura clara y auditable por personas.

Los agentes de IA introducen nuevos retos en este esquema, requiriendo un enfoque ajustado: un alcance más acotado que el de los usuarios humanos, credenciales por usuario en lugar de tokens compartidos y supervisión humana para operaciones críticas. Ninguno de estos requisitos exige un motor de políticas complejo; basta con utilizar roles acotados a recursos individuales en lugar de a todo el tenant, acompañados de verificaciones puntuales en tiempo de ejecución.

Este es el enfoque que implementa TrueFoundry mediante un modelo RBAC estructurado. Cuando una auditoría de seguridad solicite verificar a qué recursos tiene acceso un agente, la respuesta debe ser una lista precisa y fácil de auditar.

Delimita el alcance de tu primer agente en TrueFoundry

Comienza gratis