Separation of Definition and Assignment

The Principle

Separate what a role grants from who holds it. Role definitions are maintained separately from role assignments. Different people own each layer. Neither requires deep knowledge of the other.

Two Layers, Two Owners

A security or platform team defines the roles: what each one grants, across which systems, with what scope and constraints. They understand the downstream permissions, the blast radius, the compliance implications. They are the architects of the access model.

Managers assign people to roles: this person is a backend engineer, that person is a team lead, this contractor has a scoped-down role for their engagement. They understand the team, the work, and who needs what. They do not need to understand the specific permissions involved in each downstream system.

Why This Matters

Without this separation, either the security team becomes a bottleneck for each personnel change, or managers make permission decisions they are not equipped to make. Both are common. Both are dysfunctional.

With this separation, adding someone to a team is a simple assignment that a manager can make confidently, because the security implications are encoded in the role definition, not in the assignment. The blast radius of a manager's decision is bounded by the role definitions that the security team has already vetted.

Antipatterns

• Managers must understand individual permissions before they can assign someone to a role.
• The security team is a bottleneck for each personnel change.
• Managers make permission decisions they are not equipped to evaluate.
• The same IAM or cloud team are members of every group, even ones unrelated to their function, because they are the only people who can grant access.