Permisos Multi-Tenant vs Claude Code ACL

Los sistemas de permisos son aburridos — hasta que fallan. En un restaurante multi-tenant, un permiso mal configurado significa que el competidor ve tu menú y precios. En Claude Code, un permiso mal evaluado significa que la IA borra tu rama main sin preguntar.

Este artículo compara dos enfoques de producción: el RBAC multi-tenant de Cadences Platform (usado por decenas de verticales SaaS) y el sistema ACL tri-state de Claude Code (que inventó algo que la mayoría de frameworks RBAC no tiene: el estado "ask").

Al final proponemos un patrón híbrido: AI-Enhanced RBAC — RBAC clásico con los tres superpoderes que Claude Code descubrió.

Cadences Platform ejecuta múltiples verticales SaaS (restaurantes, viajes, salud) en una infraestructura compartida de Cloudflare Workers + D1. El aislamiento entre tenants es absoluto: cada query lleva WHERE tenant_id = ?.

// Cadences Permission Model
Tenant (restaurante/agencia/clínica)
  └── Roles
      ├── owner     → full access + billing
      ├── admin     → settings + staff management
      ├── manager   → operations + analytics
      ├── staff     → daily operations only
      └── viewer    → read-only

Enforcement: middleware en Workers
  request → extract tenant_id → extract role
         → check: role >= required_role?
         → allow / deny

Resources: menu_items, orders, settings,
           integrations, analytics, staff

Es un modelo probado y simple. Los permisos se resuelven en una sola comparación: ¿el rol del usuario tiene acceso a este recurso? Sí o no. No hay ambigüedad, no hay estados intermedios.

Claude Code inventó algo que la mayoría de frameworks RBAC no tiene: un tercer estado. No es allow. No es deny. Es ask — preguntarle al humano si esta operación específica está bien.

// Claude Code Permission Sources (cascading)
Level 1: Platform rules    ← Anthropic define
Level 2: Organization ACL  ← empresa define
Level 3: Project ACL       ← .claude/settings.json
Level 4: User preferences   ← ~/.claude/settings.json

// Evaluation order (deny-first)
for source in [platform, org, project, user]:
  if source.denies(tool, args): → DENY
  if source.allows(tool, args): → ALLOW

if mode == "auto":    → consult yolo classifier
if mode == "plan":    → ASK always
if mode == "default": → ASK if destructive

Los 3 estados

El Yolo Classifier: IA como juez

Cuando el modo es auto y una herramienta está en estado "ask", Claude Code no pregunta directamente — primero consulta al yolo classifier: un modelo de IA que evalúa si la operación específica es segura en el contexto actual.

El RBAC tradicional es binario. Puedes o no puedes. Pero en el mundo real hay operaciones que dependen del contexto:

"Ask" es el estado que le falta a la mayoría de sistemas RBAC. No todo es blanco o negro — a veces la respuesta correcta es "puede, pero primero confirma con alguien".

Claude Code tiene 4 fuentes de permisos en cascada. Cada nivel puede override al anterior con deny (nunca puede re-allow un deny del nivel superior). Cadences tiene un equivalente natural:

El yolo classifier de Claude Code es un modelo que clasifica operaciones por riesgo. ¿Podría Cadences usar el mismo concepto? Absolutamente:

Combinando lo mejor de ambos mundos, proponemos un patrón de 4 capas para sistemas SaaS con herramientas de IA:

// AI-Enhanced RBAC in Cadences Workers
async function evaluatePermission(request, env) {
  const { tenantId, role, action, resource, args } = request;

  // Layer 0: RBAC base
  const rbac = await getRBAC(env.DB, tenantId, role);
  if (rbac[resource] === 'deny') return DENY;
  if (rbac[resource] === 'allow') {

    // Layer 1: ¿es una operación ask?
    const askRules = await getAskRules(env.DB, tenantId);
    const matchedRule = askRules.find(r =>
      r.action === action && matchGlob(r.pattern, args)
    );

    if (!matchedRule) return ALLOW;

    // Layer 2: AI classifier
    const risk = await classifyRisk(env.AI, {
      action, resource, args,
      context: { tenantId, role, timestamp: Date.now() }
    });

    if (risk === 'LOW')    return ALLOW;
    if (risk === 'MEDIUM') return ASK(args.reviewer);
    if (risk === 'HIGH')   return DENY;
  }

  // Layer 3: circuit breaker
  if (await getConsecutiveDenials(env.DB, tenantId) >= 3) {
    return DENY_ALL_SESSION;
  }

  return ASK(role.owner);
}

El RBAC no está muerto — le faltaban tres cosas: un tercer estado (ask), fuentes en cascada, y un modelo de IA que entienda el contenido de la operación, no solo el tipo.