RBAC para agentes de IA: control de acceso por roles sin privilegios excesivos

Idea en 30 segundos

RBAC (Role-Based Access Control) para un agente de IA define quién puede ejecutar qué acciones mediante tools en runtime.

Cuándo se necesita: cuando el agente trabaja con varios roles, varios tenants, o tiene acceso a acciones write en sistemas reales.

Problema

Sin RBAC, un agente suele ejecutarse con acceso "amplio": un rol, muchas herramientas, límites mínimos. En demo parece cómodo. En producción, se vuelve rápido una fuente de incidentes.

Un solo error en el plan del agente puede disparar una acción extra: tool incorrecto, tenant incorrecto, nivel de acceso incorrecto. Después es difícil responder incluso una pregunta básica: quién obtuvo acceso y por qué. Para evitar que este error se convierta en incidente, la validación de acceso debe vivir no en el prompt, sino en la capa de policy antes de cada llamada de herramienta.

Analogía: es como un pase universal en un edificio corporativo. Mientras todo está tranquilo, no se nota la diferencia. En el momento del fallo, ese pase abre demasiadas puertas.

Solución

La solución es mover el control de acceso a la capa de policy en runtime. Cada llamada de herramienta se valida con user context (role, permissions y tenant scope) antes de ejecutar. Empieza con una regla base: default deny y permisos explícitos solo para roles necesarios.

RBAC != solo allowlist

Allowlist define qué tools existen en el sistema.
RBAC define quién y cuándo puede llamarlos.

Uno sin el otro no funciona:

sin RBAC, se difuminan los límites de acceso entre roles
sin allowlist, el conjunto de tools crece sin control

Ejemplo:

allowlist: la tool refund.create existe y está disponible en el sistema
RBAC: solo el rol billing_manager puede llamar refund.create dentro de su tenant

Niveles de control de acceso (RBAC layers)

Estas validaciones trabajan juntas en cada paso del agente.

Nivel	Qué controla	Mecánicas clave	Para qué sirve
Roles (role mapping)	Quién ejecuta la acción	role assignment service account policy	Evita "un rol para todos"
Permisos (permissions)	Qué está permitido exactamente para el rol	action-based permissions default deny allowlist	Da límites claros para tools y acciones
Aislamiento por tenant (scope)	En qué datos se puede actuar (tenant es un espacio aislado de datos del cliente)	tenant_id check resource scoping	Evita acceso a tenant ajeno
Control de acciones write	Acciones riesgosas o irreversibles	separate write permissions human approval	Reduce el riesgo de errores costosos

Cómo se ve en la arquitectura

Policy layer (tool gateway) se coloca entre runtime y tools y valida cada llamada. Cada decisión (allow, deny, approval_required) se registra en audit log.

Flow: de solicitud a decisión

Cada llamada de herramienta pasa por este flow antes de ejecutarse: runtime no ejecuta acciones directamente, sino que delega la decisión a la capa de policy.

Resumen del flow:

Runtime forma una tool request
la capa de policy RBAC valida rol y tenant scope
allow -> se ejecuta la llamada de herramienta
deny -> stop reason + registro en audit log
approval_required -> stop reason + registro en audit log

Decisiones de policy

Cada llamada de herramienta termina en una de estas decisiones:

allow — se ejecuta la acción
deny — la acción se bloquea
approval_required — se requiere confirmación

Este es el punto centralizado por donde pasan todas las decisiones antes de ejecutar acción. Estas decisiones se usan como motivos de parada y se registran en audit log.

Ejemplo

Un agente de soporte (role = support_agent) recibe una solicitud de reembolso. La tool refund.create solo está permitida para rol billing_manager en su propio tenant.

Resultado:

support_agent -> refund.create -> deny("permission_denied")
role mismatch o tenant scope mismatch -> deny("permission_denied")
evento registrado en audit log con motivo de denegación

RBAC detiene el error a nivel de ejecución validando acceso antes de cada acción.

En código se ve así

PYTHON

decision = rbac.check(user_context, tool, tenant_id, args)
if not decision.allowed:
    audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason)
    return deny(decision.reason)

if decision.requires_approval and not approval.ok():
    audit.log(user_context, tool, tenant_id, "approval_required", reason="approval_required")
    return stop("approval_required")

result = tool.execute(args)
audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason, result=result)
return result

Cómo se ve durante la ejecución

TEXT

Escenario 1: acceso denegado (deny)

Solicitud: usuario pide refund
Runtime: llamada de herramienta formada -> refund.create
Policy: validación role + tenant scope + permissions
Decision: deny (permission_denied)
Audit: decision=deny, role=support_agent, action=refund.create, reason=permission_denied
Stop: acción no ejecutada

---

Escenario 2: acceso permitido (allow)

Solicitud: mismo caso para billing_manager en su tenant
Runtime: llamada de herramienta formada -> refund.create
Policy: validación role + tenant scope + permissions
Decision: allow
Tool: refund.create ejecutado
Audit: decision=allow, role=billing_manager, action=refund.create, result=ok
Return: resultado devuelto al cliente

Errores típicos

un rol "service" para todos los agentes y usuarios
falta de allowlist default-deny
validar solo rol sin tenant scope
falta de capa de policy centralizada
mismos permisos para acciones read y write
lógica RBAC solo en UI o prompt
falta de audit trail: role, action, tenant, policy decision reason

Como resultado, el sistema parece controlado, pero los límites de acceso se degradan con el tiempo.

Autoevaluación

Chequeo rápido de RBAC antes de lanzar en producción:

Existe un mapa explícito role -> allowed tools/actions
La política de acceso sigue el principio default deny
Cada llamada de herramienta pasa por una capa de policy centralizada
Se valida tenant scope para cada acción
Las acciones write tienen permissions separadas y (si aplica) approval
Cada policy decision tiene stop reason u outcome explícito
Los audit logs incluyen role, action, tenant y policy decision reason
Existe kill switch para parada de emergencia en incidente

Progreso: 0/8

⚠ Faltan controles base de governance

Antes de production necesitas como mínimo control de acceso, límites, audit logs y parada de emergencia.

FAQ

Q: ¿Cómo trabajar con tools que llaman a GitHub, Jira u otras APIs externas?
A: No des al agente una sola llave compartida para todo. Es mejor usar user-scoped credentials, tokens OAuth o policy de service account separada con límites explícitos.

Q: ¿En qué se diferencia role de tenant scope?
A: Role define qué se puede hacer. Tenant scope define dónde se puede hacer.

Q: ¿Cómo agregar de forma segura una nueva tool a RBAC?
A: Agrega la tool con modelo de permisos explícito: default deny, permisos separados read/write y validación de tenant scope.

Q: ¿Qué implementar primero: RBAC o approval?
A: Primero RBAC con default deny y tenant scope. Después añade approval para acciones write riesgosas.

Q: ¿RBAC solo alcanza para producción?
A: No. Además necesitas execution limits, presupuestos, audit logs y kill switch.

Dónde está RBAC en el sistema general

RBAC es una de las capas de Agent Governance.
Junto con presupuestos, límites, approval y audit, forma un sistema unificado de control de ejecución.

Páginas relacionadas

Siguiente en este tema:

Resumen de Agent Governance — modelo general de control de agentes en producción.
Allowlist vs Blocklist — por qué default-deny escala mejor.
Human Approval — cómo añadir confirmación manual para acciones riesgosas.
Audit logs para agentes — cómo reconstruir la cadena de decisiones en incidentes.
Kill Switch — cómo detener un agente en emergencia sin release.