Roles as compression

Why does a tidy set of roles turn, over years, into hundreds nobody can explain?

Every access-control design starts the same way. Someone draws eight roles on a whiteboard — clerk, supervisor, auditor, administrator — and everybody agrees this is obviously right. Five years later the same system has four hundred roles with names like FIN_AP_SUPERVISOR_EMEA_TEMP_2 and nobody can say who should have them.

The tempting reading is that discipline slipped. But the same outcome appears in well-run organisations with review boards and naming standards, which suggests something structural rather than cultural. So ask what a role actually is, and see whether the failure is written into the idea itself.

Underneath any permission system there is a matrix: every person against every permission, with a mark where the two meet. Left alone that is unmanageable — thousands of rows, thousands of columns, and no way to see whether it says anything sensible.

A role is a compression of that matrix. Instead of storing every cell, you notice that many people have identical rows, name the repeated pattern, and store it once. People map to roles, roles map to permissions, and a matrix with millions of cells collapses to two small lists. That is a real and large gain, and it is the honest case for role-based access control.

But now ask the question that every compression scheme has to answer: what happens to the data that does not fit the pattern?

Here it is decisive. Suppose someone needs almost the clerk role plus one extra permission. There are two moves. You can widen the clerk role — which grants that permission to every clerk, quietly, forever. Or you can create a new role for this near-match. The first is a privilege escalation for a population; the second is safe, local, easy to justify, and takes a minute. Everyone chooses the second, and everyone is right to.

Follow that repeatedly. Every exception mints a role. Nothing about the mechanism resists it, and the incentive at each individual decision points the same way.

Now ask about the other direction. When is a role deleted? To delete one you have to know that nobody needs it, and that is not knowable from the role system, which records assignments rather than usage. Meanwhile deleting a role that somebody silently depends on breaks their work in a visible, blamed way, while keeping an unnecessary one costs nothing anybody can see. So creation is cheap and reversible-looking; deletion is expensive and risky. That is a ratchet, and ratchets have only one outcome.

Several other pressures push the same way. Provisioning by imitation — "give the new starter the same access as her predecessor" — copies accumulated exceptions into a fresh person. Reorganisations and migrations add a parallel vocabulary rather than replacing the old one. Temporary grants outlive their projects because nothing was set to expire them. And a person who changes jobs internally usually gains the new role without losing the old, which is entitlement creep at the level of the individual rather than the catalogue.

Now look at the endpoint, because it is the sharpest way to see the failure. When exceptions outnumber patterns, you approach one role per person. At that point the compression has fully decompressed: you are storing the original matrix again, and paying for an indirection layer on top of it, with role names that suggest a shared meaning they no longer carry. The scheme has not merely stopped helping. It is now worse than the thing it replaced, because it looks organised.

What would actually help? Two directions, and both should be stated with their costs. You can compute permissions from attributes — department, grade, project, location — so that the exceptions are expressed as policy rather than enumerated as new roles. That is attribute-based access control, and it does not abolish the problem; it relocates it into policy complexity, where growth is harder to see. Or you can attack the ratchet directly: expire grants by default, review entitlements periodically against actual usage logs, and periodically re-derive roles from what people really do rather than from what they were once given. That works, and it is unglamorous, continuous effort — which is why it is the part that gets dropped.

Three refinements.

First, role explosion is not caused by bad naming or weak governance, though both make it worse. It is caused by an asymmetry: adding a role is locally safe and deleting one is locally risky. Any structure with that asymmetry accumulates, regardless of who is running it.

Second, the security harm is indirect and therefore easy to underrate. The danger is not that four hundred roles exist; it is that nobody can any longer answer "who can approve a payment?" or notice that a leaver kept access. Access control that cannot be reasoned about has stopped being a control, whatever it still enforces.

Third, resist the reflex to fix it by a one-off cleanup. A consolidation project without a change to the incentives simply resets the counter, and the same forces regrow the catalogue on the same curve. The durable fixes are the ones that make deletion automatic — expiry by default, recertification, grants tied to a project's lifetime — rather than the ones that make the catalogue briefly tidy.

• Role mining: re-deriving a role set from observed access logs rather than from historical grants.
• Attribute-based access control, and whether policy complexity is a better problem to have than catalogue growth.
• Why time-boxed access by default is the single change with the largest effect on entitlement creep.

Every term the collection defines is gathered in the glossary.