---

name: backend-authorization description: > Use this skill when the user says 'authorization', 'access control', 'RBAC', 'ABAC', 'ReBAC', 'permissions', 'role', 'policy', 'Casbin', 'Cerbos', 'permission delegation', 'temporary access', 'break glass', 'super admin', 'JIT elevation', 'role hierarchy', or when designing or implementing authorization for any backend application. This skill covers: authorization model selection (RBAC/ABAC/ReBAC), permission architecture design, role hierarchy and inheritance, admin/master admin patterns, temporary JIT elevation, permission delegation, fine-grained ABAC policies, policy engine integration (Casbin, OPA, Cerbos, Permit.io), and authorization testing. Do NOT use for: authentication flows, JWT implementation, OAuth2/OIDC configuration, session management, or frontend route guards. version: "1.0.0" author: "j4flmao" license: "MIT" compatibility: claude-code: true cursor: true codex: true windsurf: true tags: [backend, universal, authorization, access-control, rbac, abac, phase-5]

Backend Authorization

Purpose

Design and implement authorization that is correct, auditable, and maintainable. Every protected resource must have an explicit access decision. Authorization rules live in code or policy, never in the developer's head.

Architecture Decision Trees

Authorization Model Selection

How many resource types need access control?
├── < 10 → Flat RBAC (simple role-permission map)
└── >= 10 → Do roles map well to resources?
    ├── Yes → Does every user fit a single role?
    │   ├── Yes → Hierarchical RBAC (roles + inheritance)
    │   └── No → RBAC + ABAC hybrid (roles for coarse, attributes for exceptions)
    └── No → Does access depend on relationships between entities?
        ├── Yes → ReBAC (Zanzibar-style relationship tuples)
        └── No → ABAC (attribute-based policies for maximal flexibility)

Regulatory requirements (SoD, audit)?
├── Yes → Constrained RBAC with SoD enforcement
└── No → Standard RBAC or ABAC

Multi-tenant?
├── Yes → RBAC + scope-based authorization (org/department/team isolation)
└── No → Single-tenant RBAC or ABAC

Policy Engine Decision Tree

Existing policy engine in stack?
├── Yes → Leverage existing engine
└── No → Cloud-native / K8s?
    ├── Yes → OPA (sidecar deployment, Rego policies, K8s admission control)
    └── No → Need GUI for non-devs to manage policies?
        ├── Yes → Permit.io (SaaS, visual policy editor)
        └── No → Multi-language support critical?
            ├── Yes → Casbin (libraries for 10+ languages, in-app)
            └── No → Fine-grained, human-readable policies?
                ├── Yes → Cerbos (YAML policies, sidecar)
                └── No → ReBAC at massive scale?
                    └── AuthZed / SpiceDB (Zanzibar, gRPC API)

Temporary Access Decision Tree

Emergency scenario (production outage)?
├── Yes → Break-glass protocol: MFA required, 30 min expiry, security team notified
└── No → Need temporary elevated permissions?
    ├── Yes → JIT elevation: request + approval, time-bound, auto-expire
    └── No → Need to delegate permissions?
        └── Delegation: delegator-scoped, time-bound, non-cascading

Agent Protocol

Trigger

Exact user phrases: "authorization", "access control", "RBAC", "ABAC", "ReBAC", "permissions", "role", "policy engine", "Casbin", "Cerbos", "Permit.io", "OPA", "permission delegation", "temporary access", "break glass", "super admin", "master admin", "JIT elevation", "role hierarchy", "permission model", "least privilege", "separation of duties", "I want to restrict access".

Input Context

• Application type and resource inventory (entities, actions per entity).
• User types and their organizational structure.
• Existing auth system (if any) — JWT claims, auth middleware.
• Compliance requirements (SOC 2, HIPAA, SOX, PCI DSS).
• Expected scale (users, roles, permissions, tenants).

Output Artifact

Authorization architecture document: model selection, role tree, permission matrix, policy structure, integration plan.

Response Format

Model: {RBAC|ABAC|ReBAC|Hybrid}
Role Tree: {top-level roles, hierarchy depth}
Granularity: {coarse|fine|mixed}
Policy Engine: {native|Casbin|OPA|Cerbos}
Admin Pattern: {flat|hierarchical|break-glass}
Testing: {matrix|regression|fuzzing}

Completion Criteria

• Authorization model selected based on requirements.
• Permission architecture designed with levels and granularity.
• Role hierarchy defined with inheritance.
• Admin/super-admin patterns specified.
• Temporary elevation or delegation mechanism (if needed).
• Policy engine integration planned.
• Authorization test matrix written.

Max Response Length

Authorization architecture: 25 lines maximum.

Workflow

Step 1: Identify Authorization Requirements

Map every resource and action in the system:

Resource	Actions	Conditions
Invoice	create, read, update, delete, approve	own dept only, business hours
User	read, update, deactivate	same org level
Workspace	create, read, update, delete, invite	quota limits
Report	generate, export, schedule	premium tier only

Collect:

• Resource inventory — every entity the system manages.
• Action catalog — Create, Read, Update, Delete, Execute, Approve, Delegate.
• User taxonomy — types, org levels, relationships.
• Environmental constraints — time, location, device trust, risk score.
• Compliance rules — SoD, data segregation, retention policies.

Step 2: Choose Authorization Model

Model	Granularity	Complexity	Scale	Best For
ACL	Per-resource	Low	Small	Simple file sharing
RBAC (Core)	Role-level	Low	Large	Enterprise apps, orgs with clear roles
RBAC (Hierarchical)	Role-level + inheritance	Medium	Large	Multi-level orgs, subsidiaries
RBAC (Constrained)	Role + SoD	Medium	Large	Regulated industries
ABAC	Attribute-level	High	Very large	Multi-tenant, document-level, context-aware
ReBAC	Relationship-level	High	Very large	Collaboration, social, hierarchical data

Decision matrix:

• Have < 10 roles with no hierarchy? → Core RBAC.
• Multiple org levels (parent → subsidiary → department)? → Hierarchical RBAC.
• Regulated (finance, healthcare)? → Constrained RBAC with SoD.
• Need document/row-level permissions? → ABAC or ABAC-over-RBAC.
• Social/collaboration app (who can see what depends on relationships)? → ReBAC.
• Different resources need different models? → Hybrid (RBAC core + ABAC for fine-grained).

Step 3: Design Permission Architecture

Define permission levels and granularity:

Global (SaaS-wide)
  └── Organization (company)
        └── Workspace (project/team)
              └── Resource (document, record, asset)
                    └── Field (specific column/attribute)

Coarse-grained permissions (RBAC level):

• workspace.read, workspace.write, workspace.delete
• Role: editor can workspace.read + workspace.write

Fine-grained permissions (ABAC level):

• document.read where document.department == user.department
• invoice.approve where amount < 10000 && user.role == 'manager'

Permission types:

Type	Example	Enforcement
Functional	report.export	UI hide + API guard
Data	read own records only	Query filter + row-level security
Field	view salary column	GraphQL field resolver
Environmental	approve during business hours	Policy condition
Administrative	deactivate user	Admin guard + audit

Step 4: Implement RBAC Core

// Role-to-permission mapping (source of truth)
const PERMISSIONS = {
  admin:     ['*'],
  manager:   ['workspace.*', 'report.*', 'user.read', 'user.invite'],
  editor:    ['workspace.read', 'workspace.write', 'document.*'],
  viewer:    ['workspace.read', 'document.read'],
  guest:     ['document.read']
};

// Authorization check
function authorize(user, action, resource) {
  const role = user.role;
  const permissions = PERMISSIONS[role];
  if (!permissions) return false;
  if (permissions.includes('*')) return true;
  return permissions.some(p =>
    p === `${resource}.${action}` ||
    p === `${resource}.*` ||
    p === `*.${action}` ||
    p === '*'
  );
}

Rules:

• Permissions use {resource}.{action} format with wildcard support.
• One role = one set of permissions. No per-user overrides (use attribute-based for exceptions).
• Role is assigned at user level, stored in JWT or session.
• Never hardcode user IDs in permission checks.

Step 5: Implement Advanced RBAC

Role hierarchy with inheritance:

super-admin         (everything, cross-org)
  └── org-admin    (everything within one org)
        └── manager  (inherits manager perms + department scope)
              └── lead  (inherits lead perms + team scope)
                    └── member (basic perms)

// Role hierarchy with inherited permissions
const ROLE_HIERARCHY = {
  'super-admin':  { parent: null,   scope: 'global' },
  'org-admin':    { parent: 'super-admin'  | 'org-admin'   | 'manager'      | 'lead'         | null, scope: 'org' },
  'manager':      { parent: 'org-admin',    scope: 'department' },
  'lead':         { parent: 'manager',      scope: 'team' },
  'member':       { parent: 'lead',         scope: 'self' }
};

function getEffectivePermissions(role) {
  let perms = new Set(PERMISSIONS[role] || []);
  let current = ROLE_HIERARCHY[role];
  while (current?.parent) {
    const parentPerms = PERMISSIONS[current.parent] || [];
    parentPerms.forEach(p => perms.add(p));
    current = ROLE_HIERARCHY[current.parent];
  }
  return [...perms];
}

Separation of Duties (SoD):

// Static SoD — mutually exclusive roles
const SOD_STATIC = {
  'purchase-approver': ['purchase-requester', 'purchase-receiver'],
  'auditor':           ['accountant', 'treasurer']
};

// Dynamic SoD — cannot act on same resource
function checkDynamicSoD(userId, action, resourceId) {
  const history = getRecentActions(userId, resourceId);
  if (action === 'approve' && history.includes('submit')) {
    return false; // Cannot approve your own submission
  }
  return true;
}

Scope-based authorization for multi-org:

function authorizeScoped(user, action, resource, resourceOrgId) {
  const roleInfo = ROLE_HIERARCHY[user.role];
  if (!roleInfo) return false;

  // Scope check
  switch (roleInfo.scope) {
    case 'global':  return true;  // super-admin sees everything
    case 'org':     return user.orgId === resourceOrgId;
    case 'department': return user.deptId === getResourceDept(resourceOrgId);
    case 'team':    return user.teamId === getResourceTeam(resourceOrgId);
    case 'self':    return user.id === getResourceOwner(resourceOrgId);
    default:        return false;
  }
}

Step 6: Implement Fine-Grained Access (ABAC)

For when role-level is too coarse:

// ABAC policy rule
const POLICY = {
  "effect": "deny",
  "target": {
    "resource": "invoice",
    "action": "approve"
  },
  "condition": {
    "all": [
      { "subject.role": { "neq": "admin" } },
      { "resource.amount": { "gt": 10000 } },
      { "subject.department": { "neq": "resource.department" } }
    ]
  }
};

// ABAC evaluation engine
function evaluateABAC(subject, resource, action, env, policies) {
  for (const policy of policies) {
    if (matchesTarget(policy.target, resource, action)) {
      if (evaluateConditions(policy.condition, { subject, resource, env })) {
        return policy.effect === 'allow';
      }
    }
  }
  return false; // default deny
}

Attribute sources:

Attribute Type	Examples	Source
Subject	role, department, clearance, location	JWT token / User DB
Resource	owner, department, classification, tier	Resource DB
Action	read, write, approve, delete	Request path + method
Environment	time, IP, device trust, risk score	Request context

Step 7: Implement Temporary & Delegated Permissions

JIT (Just-In-Time) elevation:

// Elevation request
async function elevateRole(userId, targetRole, reason, durationMinutes) {
  if (!canRequestElevation(userId, targetRole)) {
    throw new Error('Elevation not permitted');
  }
  const approval = await requestApproval(userId, targetRole, reason);
  if (!approval.approved) {
    throw new Error('Elevation denied');
  }
  // Create time-bound elevation
  await createElevation({
    userId,
    elevatedRole: targetRole,
    expiresAt: Date.now() + durationMinutes * 60_000,
    reason,
    approvedBy: approval.approvedBy,
    auditId: crypto.randomUUID()
  });
  // Log audit event
  await logSecurityEvent('role_elevation', {
    userId, targetRole, reason, durationMinutes, approvedBy: approval.approvedBy
  });
}

Permission delegation:

async function delegatePermission(delegatorId, delegateId, actions, resourceScope, expiresAt) {
  // Verify delegator owns the resource scope
  if (!ownsScope(delegatorId, resourceScope)) {
    throw new Error('Cannot delegate what you do not own');
  }
  await createDelegation({
    delegatorId, delegateId, actions, resourceScope, expiresAt,
    revoked: false
  });
}

// Check including delegation
function authorizeWithDelegation(user, action, resource) {
  return (
    authorize(user, action, resource) ||
    hasDelegatedPermission(user.id, action, resource)
  );
}

Break-glass (emergency access):

async function breakGlassAccess(userId, resourceId, reason) {
  // Must have break-glass capability
  if (!userHasCapability(userId, 'break-glass')) {
    throw new Error('User not authorized for break-glass');
  }
  // Create time-limited emergency session
  const session = await createEmergencySession({
    userId,
    resourceId,
    reason,
    accessLevel: 'admin',
    expiresAt: Date.now() + 30 * 60_000, // 30 minutes
    multiFactorRequired: true
  });
  // Notify security team immediately
  await notifySecurityTeam('BREAK_GLASS_ACTIVATED', {
    userId, resourceId, reason, sessionId: session.id
  });
  // Log everything
  await logSecurityEvent('break_glass', {
    userId, resourceId, reason, sessionId: session.id
  });
  return session;
}

Admin role patterns:

Pattern	Access	Use Case
Super Admin	Unrestricted, cross-system	Platform-wide emergency, initial setup
Org Admin	Full within one org unit	Subsidiary administration
System Admin	Infrastructure only	DevOps, deployments
Audit Admin	Read-only + audit log	Compliance, investigations
Support Admin	User management + read	Customer support
Billing Admin	Finance + subscriptions	Billing operations
Delegated Admin	Scoped subset of admin	Department leads managing their team

Step 8: Integrate Policy Engines

Engine	Language	Model	Deployment	Best For
Casbin	Go, Node.js, Python, Java, .NET, Rust	PERM metamodel	In-app library	RBAC/ABAC/ACL in any language
OPA/Rego	Rego	Declarative policies	Sidecar/bundle	Cloud-native, K8s, multi-service
Cerbos	YAML	Resource policies	Sidecar/Docker	Fine-grained, user-friendly
Permit.io	Python, Node.js, Go, REST	RBAC/ABAC/ReBAC	SaaS/self-hosted	Rapid deployment, GUI policy editor
AuthZed/SpiceDB	Zanzibar	Relationship tuples	gRPC API	ReBAC at scale

Casbin example (Node.js):

const { newEnforcer } = require('casbin');

// model.conf (RBAC with hierarchy)
// [request_definition]
// r = sub, obj, act
// [policy_definition]
// p = sub, obj, act
// [role_definition]
// g = _, _
// g2 = _, _
// [matchers]
// m = g(r.sub, p.sub) || g2(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

const enforcer = await newEnforcer('model.conf', 'policy.csv');
const allowed = await enforcer.enforce('alice', 'invoice:123', 'approve');

OPA example (Rego):

package authz

default allow = false

# RBAC rules
allow {
  user_has_role(input.user_id, "admin")
}

allow {
  role := user_role(input.user_id)
  permission := data.permissions[role][_]
  permission.resource == input.resource
  permission.action == input.action
}

user_has_role(user_id, role) {
  data.roles[user_id] == role
}

user_role(user_id) := data.roles[user_id]

Step 9: Test & Audit Authorization

Permission matrix testing:

// Test every role against every resource+action
const TEST_MATRIX = [
  { role: 'admin',     actions: ['*'],                           expected: 'allow' },
  { role: 'manager',   actions: ['workspace.*', 'report.*'],     expected: 'allow' },
  { role: 'manager',   actions: ['workspace.delete'],            expected: 'deny' },
  { role: 'editor',    actions: ['workspace.read', 'doc.write'], expected: 'allow' },
  { role: 'editor',    actions: ['workspace.delete'],            expected: 'deny' },
  { role: 'viewer',    actions: ['workspace.write'],             expected: 'deny' },
];

test('authorization matrix', () => {
  for (const { role, actions, expected } of TEST_MATRIX) {
    for (const action of actions) {
      const result = authorize({ role }, action, 'workspace');
      expect(result).toBe(expected);
    }
  }
});

Negative testing:

• Unauthenticated access → deny.
• Expired tokens → deny.
• Deleted users → deny.
• Out-of-scope org → deny.
• Rollback after elevation expires → previous perms restored.

Audit requirements:

• Log every authorization decision (allowed or denied) with: timestamp, user, action, resource, decision, reason.
• Log every role change, permission grant/revoke, elevation, delegation.
• Weekly reports on denied access attempts (potential attacks).
• Quarterly access certification: "Does every user still need their current roles?"

Regression testing for policy changes:

• Maintain a test suite for every permission set.
• Run on every change to role definitions or policies.
• Snapshot current behavior before changes, diff after.

Anti-Patterns

1. Role explosion: Creating hundreds of roles for every unique permission combination. Fix → Use attributes for exceptions, keep roles to < 20.
2. Super admin everywhere: Every admin is super admin. Fix → Follow least privilege: scoped admin roles (org-admin, audit-admin, support-admin).
3. Client-side authorization only: Hiding UI buttons but not enforcing server-side. Fix → API gateway or middleware enforces every decision.
4. Permission check in domain logic: Auth logic mixed with business logic. Fix → Authorization is infrastructure, enforced before domain.
5. Hardcoded user IDs in policies: if (user.id === 'admin-user'). Fix → Never reference specific users — use roles and attributes.
6. No default deny: Everything is allowed unless explicitly denied. Fix → Reverse: deny by default, explicitly allow.
7. Caching decisions indefinitely: Cached allow/deny results become stale. Fix → Cache with TTL tied to token expiry or policy change events.
8. Ignoring delegation chain depth: Delegated permissions cascade infinitely. Fix → Limit depth to 1 (direct delegation only) or max 3 hops.
9. Break-glass without notification: Emergency access with no audit trail. Fix → Always log, notify, and auto-expire.
10. Elevation never expires: JIT roles that last forever. Fix → Always set TTL on elevation. Cron job to clean up expired.
11. Overly complex policies: ABAC conditions that no one can understand or debug. Fix → Simpler RBAC + minimal ABAC. Document every condition.
12. Permissive wildcards: *.* grants access to everything. Fix → Be explicit. Use wildcards only for true admin roles.
13. SoD only in code: Separation of duties enforced but bypassable. Fix → Enforce SoD at the data layer, not just UI/middleware.
14. Authorization by omission: Granting access because no policy matches (default allow). Fix → Always default deny.

Security Considerations

Denial-of-Service via Policy Evaluation

• Complex ABAC policies with expensive conditions (DB lookups, API calls) can be flooded.
• Mitigation: cache policy evaluation results, rate-limit authorization requests, set query complexity limits.
• OPA: set default_decision timeout. Cerbos: configure evaluation deadline.

Privilege Escalation Vectors

• Horizontal: User A reads User B's data. Mitigation → scope-based checks on every data access.
• Vertical: User upgrades own role. Mitigation → role changes require audit trail + approval.
• Delegation abuse: Delegate permissions to gain more than you have. Mitigation → delegation inherits delegator's scope, never exceeds.

Timing Attacks on Authorization

• Different response times for "valid token, denied" vs "invalid token" can leak info.
• Mitigation: consistent response times for all auth failures. Obfuscate error details.

Distributed Authorization Security

• Policy bundles must be signed (OPA bundle signing). Verify signature before loading.
• Sidecar-to-service communication must use mTLS.
• Policy engine API endpoints must not be exposed to untrusted networks.

Performance Considerations

Policy Evaluation Latency

Engine	P50 (simple)	P50 (complex)	P99 (complex)
In-app (Casbin)	~0.05ms	~0.5ms	~2ms
Sidecar (OPA)	~0.5ms	~5ms	~20ms
Sidecar (Cerbos)	~1ms	~3ms	~15ms
Network (SpiceDB)	~5ms	~15ms	~50ms
SaaS (Permit.io)	~15ms	~30ms	~100ms

Optimization Techniques

• Decision caching: Cache allow/deny results with TTL = token expiry or 5 min max. Invalidate on policy change.
• Batch evaluations: For list endpoints, batch all resource checks into one policy evaluation.
• Pre-computed permissions: Store effective permissions (allow list) in JWT for frequently accessed resources.
• Read-replica policy engines: For sidecar pattern, deploy policy engine as read-replica with local bundle cache.
• Connection pooling: For network-based engines (SpiceDB), pool gRPC connections. Reuse for multiple evaluations.

Data-Level Authorization

-- Row-Level Security (RLS) in PostgreSQL
CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.current_tenant_id'));

CREATE POLICY user_scope ON documents
  USING (
    owner_id = current_setting('app.current_user_id')
    OR current_setting('app.current_role') = 'admin'
  );

-- Always set session context at auth middleware
SELECT set_config('app.current_user_id', $1, false),
       set_config('app.current_role', $2, false),
       set_config('app.current_tenant_id', $3, false);

Middleware Implementation Patterns

Express middleware with policy engine:

function authorizeMiddleware(action, resourceType) {
  return async (req, res, next) => {
    const decision = await policyEngine.check({
      subject: { id: req.user.id, role: req.user.role, department: req.user.dept },
      resource: { type: resourceType, id: req.params.id, ...resourceMeta(req) },
      action,
      env: { time: new Date(), ip: req.ip }
    });
    if (!decision.allowed) {
      throw new ForbiddenError(decision.reason || 'Access denied');
    }
    // Attach decision metadata for downstream enforcement
    req.authz = { decision, scope: decision.scope };
    next();
  };
}

FastAPI dependency injection:

from fastapi import Depends, HTTPException

async def require_permission(action: str, resource: str):
    async def dependency(user: dict = Depends(get_current_user)):
        allowed = await authz_client.check({
            "subject": user,
            "action": action,
            "resource": resource
        })
        if not allowed:
            raise HTTPException(status_code=403, detail="Access denied")
        return user
    return dependency

@app.get("/invoices/{invoice_id}")
async def get_invoice(
    invoice_id: str,
    user: dict = Depends(require_permission("read", "invoice"))
):
    return await invoice_service.get(invoice_id, user)

ASP.NET Core policy-based auth:

public class InvoiceAuthorizationHandler : AuthorizationHandler<InvoiceRequirement, Invoice>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        InvoiceRequirement requirement,
        Invoice resource)
    {
        var userDept = context.User.FindFirst("department")?.Value;
        if (userDept == resource.Department)
        {
            context.Succeed(requirement);
        }
        return Task.CompletedTask;
    }
}

// Registration
services.AddAuthorization(options => {
    options.AddPolicy("InvoiceAccess", policy =>
        policy.Requirements.Add(new InvoiceRequirement()));
});

Go HTTP middleware:

func Authorize(engine *casbin.Enforcer) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            user := r.Context().Value("user").(*User)
            resource := r.URL.Path
            action := r.Method

            allowed, err := engine.Enforce(user.Role, resource, action)
            if err != nil || !allowed {
                http.Error(w, "Forbidden", http.StatusForbidden)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

Rules

• Default deny: if no policy explicitly allows, access is denied.
• Authorize at the right layer — data-level enforcement (RLS, query filter) is mandatory, UI hiding is optional UX.
• Never trust client-side permissions. Always enforce server-side.
• Role assignments and permission grants must have an audit trail with who approved them.
• Temporary elevation must expire automatically. Never leave JIT roles permanent.
• Break-glass access must notify security immediately and expire within 30 minutes.
• Delegated permissions must not exceed the delegator's own permissions.
• Every user has exactly one role. Use attributes for exceptions, not custom roles.
• Permission changes propagate immediately (no cache) or with documented delay.
• Policy evaluation is a synchronous hot-path operation. Keep it fast (<5ms p99).
• Default allow lists for known-safe operations (public endpoints, health checks). All else default deny.

References

• references/authorization-audit.md — Authorization Audit
• references/authorization-delegation.md — Authorization Delegation
• references/authorization-fundamentals.md — Authorization Fundamentals
• references/authorization-advanced.md — Authorization Advanced
• references/authorization-middleware.md — Authorization Middleware — Framework Integration
• references/authorization-models.md — Authorization Models Comparison
• references/authorization-policy-distribution.md — Policy Distribution and Synchronization
• references/authorization-testing.md — Authorization Testing
• references/data-level-authorization.md — Data-Level Authorization
• references/fine-grained-policies.md — Fine-Grained Access Policies (ABAC)
• references/permission-architecture.md — Permission Architecture
• references/policy-engines-comparison.md — Policy Engines Comparison
• references/rbac-hierarchy.md — RBAC Hierarchy & Admin Patterns
• references/temporary-delegated-access.md — Temporary & Delegated Access

Handoff

No artifact produced unless requested. Next skill: authentication (frontend) — implement login UI, route guards, token storage for the auth system. Next skill: multi-tenancy — combine authorization with tenant isolation for SaaS apps. Next skill: api-security — apply authorization to API endpoints with rate limiting and WAF. Carry forward: authorization model, role tree, permission matrix, policy engine choice.