Every request travels inward from a user node, through each active policy layer (gate), toward the protected resource at the centre. A request is only granted if it clears every active gate — one failed check anywhere in the chain is a denial, no matter how many earlier gates it passed.
Grant(u, r) = pass₁ ∧ pass₂ ∧ … ∧ pass_L (L = active policy layers)
pass_i = role(u).rank ≥ requiredRank_i [RBAC: role hierarchy]
∧ (mode = RBAC ∨ attrs(u) satisfy policy_i) [ABAC: contextual attrs]
∧ rand() ≥ strictness · excess(u, i) [least privilege]
excess(u, i) = max(0, role(u).rank − requiredRank_i) — over-provisioned access
requiredRank: outer gate 0 (Guest+), mid gate 1 (User+), inner gate 2 (Manager+)
ABAC step-up (inner gate only): requires trusted device ∧ business hours
- Policy model — RBAC checks only the role hierarchy; ABAC additionally requires the inner gate's contextual attributes (trusted device, business hours) to hold.
- Policy layers — how many sequential gates a request must clear; fewer layers means faster but shallower authorization, more layers means deeper defense-in-depth.
- Least-privilege strictness — the probability that a user with more privilege than a gate strictly requires still gets pruned, enforcing "just enough access" instead of "any access that happens to work".
- Request rate — how often new access requests are generated.
This mirrors real authorization stacks: a coarse outer check (is this identity known at all), a role-based middle check (RBAC), and a fine-grained, context-aware inner check (ABAC) right before the resource — each layer enforced server-side, never trusted from the client.