Access Control Done Right

Most business software implements access control the same way: define a set of roles, assign each role a set of permissions, assign each user a role. Done.

It's simple to explain, simple to implement, and — for real business processes — often wrong.

The Role Abstraction Problem

Roles are a useful simplification, but they abstract away the context that often matters most. Consider a few scenarios that role-based systems handle poorly:

A contractor should be able to edit their own submitted timesheets but not anyone else's. Their role would need to be either "can edit timesheets" (too broad) or "cannot edit timesheets" (too restrictive). Neither matches the actual policy.

An invoice should be editable while in draft but locked once approved. The invoice's state should determine what's possible, but the user's role can't encode that — the role is the same whether the invoice is in draft or approved.

A regional manager should see all records in their region and only their region. A role can grant "view all records" or "view own records" but can't express "view records where region matches yours."

Why Static Roles Persist

Simple systems are easier to implement and easier to explain. For small teams with simple workflows, they're often sufficient. Role-based access control is taught in every security textbook because it covers the basics reliably.

But businesses grow. Workflows mature. The simple role structure that worked for five people doing similar things stops fitting a twenty-person team with specialized responsibilities and nuanced process requirements.

The Dynamic Alternative

Dynamic access rules evaluate permissions at access time, considering the specific record, its current state, and the specific user's relationship to it. Rather than "can this user type edit this object type?" the question becomes "can this user edit this record, given its current state and their relationship to it?"

This is closer to how businesses actually think about access. "Marketing can edit draft content but not published content." "Managers can approve their own team's expenses but not other teams'." These are natural policy statements that map directly to dynamic rules.

The Security Benefit

Static role systems often produce a false sense of security. The permissions look comprehensive, but edge cases that weren't anticipated at setup time often end up with either overly broad access or blocked workflows that get "temporarily" worked around — which is to say, permanently.

Dynamic rules are more work to configure correctly, but they produce access policies that actually match the intended behavior rather than approximating it.

Access control done right is context-aware. Static roles are the beginning of the story, not the end.