Engineers designing a permission model that has to cover both people and agents.
Which model to build on, and which decisions have to sit outside whichever one you choose.
The control gap
The usual comparison treats this as a maturity ladder: roles are simple, attributes are flexible, relationships scale. Agents break the ladder. An agent is not a role, it acts for a person whose own permissions matter, and the decisive fact is frequently a value inside the request rather than a property of the subject or the object. A model that cannot see the amount, the target record, or the environment will permit the call you wanted to stop.
What good looks like
Roles or relationships carry the durable structure, request attributes are evaluated where they exist, and the calls that need judgement reach a person instead of falling into whichever model was chosen.
- Use roles for coarse structure. They are readable and they are the reason most teams can explain their permissions at all.
- Use relationships where permission genuinely follows ownership or membership across many objects.
- Evaluate request attributes at the boundary rather than materialising them into subjects, which is where attribute models become unmaintainable.
- Add an approval outcome. No amount of modelling makes a boolean the right answer to an irreversible action.
A production workflow
- List the rules you need and mark each as subject-based, object-based, or request-based.
- Put the first two in the permission model and the third at the tool boundary.
- Identify the small number of actions that should never be automatic, and route them to a reviewer.
- Test the whole thing against recorded calls before enforcing any of it.
Evidence to require
- Which rule matched each decision and which model it belonged to.
- Request attributes that changed the outcome, retained with the decision.
- The delegation chain, since an agent's permission and its user's permission are different facts.
- Approvals raised, and how often a rule that looked automatic turned out to need one.
Buyer checklist
- How many of your rules depend on a value that only exists at request time?
- Does the model represent an agent and the person it acts for separately?
- What is the plan for the action that should require a human?
- How would you explain the current model to an auditor without reading code?
Practical answers
Common implementation questions
Is ReBAC always better than RBAC?
No. Relationships shine when permission follows ownership across many objects and are overkill when a dozen roles describe the business honestly. The cost of the wrong choice is paid in schema maintenance rather than in security.
Where does ABAC go wrong for agents?
Not in the model but in the data. Attribute rules need current attribute values, and keeping subject and object attributes fresh enough to authorize on is the work that sinks these projects. Evaluating the request's own attributes at the boundary avoids most of it.
Do we need a fourth model for agents?
No. What is needed is a third outcome and an enforcement point close enough to the action to see it. The permission model underneath can be any of the three.