Floor 23, Please: What Elevator Permissions Reveal About the Limits of Role-Based Access

Every office worker in America has interacted with one of the most sophisticated authorization systems ever deployed, and almost nobody thinks about it. Tap a badge in the lobby, step into an elevator, press a button. Some floors light up; others stay dark. If you work on 23, you press 23 and the doors open on 23. If you're a facilities contractor, maybe you have the service level and the roof — but only between 8 AM and 5 PM on weekdays.

It looks like role-based access control. It is, in fact, nothing like the RBAC most teams ship.

Where the Abstraction Starts to Crack

A naive RBAC model says: user has role, role has permissions, permission grants access to resource. Assign someone the "Tenant A Employee" role, and they can reach floors 20 through 25. Clean, legible, easy to demo in a sprint review.

Then the building introduces reality.

A tenant on floor 22 hosts a vendor for a week. The vendor needs floor 22, but only during business hours, and only until Friday. The fire marshal requires that every elevator respond to a firefighter's service key regardless of tenant configuration. A cleaning crew needs basement, floors 1 through 40, and the loading dock — but never the executive level, and never after 11 PM.

None of these are roles. They are constraints layered on top of roles: temporal bounds, delegations with expiry, emergency overrides, resource-specific carve-outs. A system that models all of this as more roles — "Vendor-Floor22-Temporary," "Cleaner-NoExecutive" — collapses into role explosion within a quarter. Anyone who has inherited a codebase with 400 roles named after individual exceptions knows exactly what this looks like.

The Building as a Counterexample, Not a Metaphor

Modern elevator controllers solved this decades ago, and their solution is instructive. The badge itself carries an identity. The elevator system evaluates that identity against multiple independent policy sources: tenant floor entitlements, time-window schedules, delegation records, and a hard override tier that supersedes everything else.

The critical design decision is that these layers are not flattened. The firefighter's override isn't a role someone might forget to assign — it's a separate evaluation tier that the system cannot skip. The vendor's temporary floor grant isn't a mutated tenant role — it's a scoped, expiring addition that leaves the base entitlement untouched.

Contrast this with the typical application: a single user.role column, a middleware check, and a growing pile of if statements for the exceptions. When someone needs "the same access but only on weekends," the path of least resistance is to clone the role and add a condition nobody documents.

A Layered Model Worth Shipping

Developers building authorization for anything hierarchical — buildings, org charts, folder trees, multi-tenant SaaS — should steal the elevator's architecture explicitly:

1. Base entitlements — the durable, role-like grants: which floors, which resources, which tenants.
2. Scoped delegations — time-bounded, resource-bounded grants that reference a base entitlement rather than duplicating it. They expire on their own; nobody has to remember to revoke them.
3. Context gates — checks evaluated at request time: is the requester inside the geofence, on the corporate network, within permitted hours?
4. Override tiers — break-glass and emergency paths that are structurally separate from the evaluation stack, heavily logged, and impossible to leave enabled by accident.

The difference between this and naive RBAC is that each layer answers a different question. Roles answer "what does this person normally have?" Delegations answer "what have they temporarily been given?" Context gates answer "does this specific request make sense?" Overrides answer "what must always work, no matter what?"

When these questions get crammed into one flat role, the result is both a security liability and a maintenance disaster — the two failure modes that authorization systems specialize in producing simultaneously.

Practical Advice for the Next Sprint

Start by auditing your permission checks for hidden assumptions. If a check reads only user.role, ask what the elevator would know that your system doesn't: time of day, physical or logical location, delegation chains, emergency state.

Second, make expiry a first-class citizen. Temporary access that requires a human to remember revocation is not temporary access; it's a permanent grant with a countdown nobody's watching. Delegations should carry their own tombstone date, and your system should enforce it.

Third, resist the urge to encode exceptions as data mutations. A vendor grant that edits the tenant role is a grant you can't untangle later. A vendor grant that sits in its own record, referencing the tenant role, is an audit trail you'll thank yourself for.

The elevator in your office building handles thousands of authorization decisions a day across dozens of overlapping policies, and it does so without a single "Vendor-Floor22-Temporary-Roof-Weekday" role. That's not because buildings are simple. It's because the engineers who designed the controller refused to flatten a layered problem into a single list of permissions.

Your authorization model deserves the same courtesy.