← Back to Concept Contrast

Concept Contrast Fable

Granting permissions by role vs. granting permissions by attribute

Conclusion first:RBAC manages permissions through roles, which is clear and easy to audit; ABAC makes dynamic judgments based on user, resource, environment, and task attributes, which is flexible but has higher governance costs. After agents connect to enterprise systems, this difference directly affects the risk of privilege escalation.

RBAC manages permissions through roles, which is clear and easy to audit; ABAC makes dynamic judgments based on user, resource, environment, and task attributes, which is flexible but has higher governance costs. After agents connect to enterprise systems, this difference directly affects the risk of privilege escalation.

Fable

The warehouse keys and the gatekeeper's book of conditions

The west city warehouse stored account books, medicinal materials, and valuable instruments. In earlier years the rules were simple: the manager had the master key, the accountant had the account book key, the pharmacist had the medicine cabinet key, and porters could only enter the outer warehouse. Each person received a set of keys according to their position, and the gatekeeper let them through upon seeing their waist badge.

This approach is worry-free. When a new accountant joins, give them the accountant's key; when the accountant leaves, take the key back. During audits it is also easy to explain who can enter which room because of which role. Before the warehouse expanded, no one thought there was a problem with the rules.

Later, business became more complex. The pharmacist sometimes needed to see batches in the ledgers, the bookkeeping office sometimes needed to check herb costs, and temporary auditors from outside the city should only see certain types of records during the day. Issuing keys by position began to become too coarse, and the gatekeeper added temporary keys for every exception, making the key ring more and more tangled.

The new gatekeeper switched to a conditions book. He looked not only at position, but also at the visitor's name, task, time, cargo category, and whether there was approval. If the conditions were met, he opened the gate; if not, he refused. Temporary audits finally no longer required a string of permanent keys, only viewing specified ledgers at specified times.

The conditional register quickly grew too thick to flip through. Two conditions conflicted with each other, and the night-shift pharmacist could not get urgent records; some goods were mislabeled, and the system blocked ordinary herbs as if they were precious instruments. The gatekeeper spent every day explaining why the gate had opened or not opened.

The city lord did not abolish any system. He kept stable positions in the position keys, and assigned high-risk, temporary, cross-departmental, and environment-affected access to the condition ledger. Every condition had to be recorded: who changed the rule, why, and which doors were affected all had to be traceable.

The warehouse regained order. Position keys let most people skip steps, and the conditions book handled the boundaries that positions couldn't explain. The real trouble wasn't the number of doors, but the enterprise assuming one set of keys could cover every exception. At the monthly inventory, the city lord also spot-checked two kinds of doors: the common doors with many people, to prevent roles from snowballing; and the fine-grained doors with the most conditions, to prevent rules no one could understand. If a new task lasted only one day, no permanent role was added; instead the conditions and expiry time were written out clearly. That way the warehouse could both run and explain the reason for every door opening, and there would be records to check when the auditors came.

Role-based access control

RBAC assigns permissions based on user roles, suitable for organizational permission management with stable positions, clear responsibilities, and direct audit requirements.

Attribute-based access control

ABAC makes dynamic decisions based on attributes such as user, resource, action, environment and task, making it suitable for temporary authorization, fine-grained data access and complex compliance scenarios.

Story Mapping

  • Issue keys by position: RBAC maps permissions to roles
  • Temporary audits and cross-departmental access: exceptions that role models struggle to express
  • Name, time, task, cargo category: ABAC uses multiple types of attributes for authorization decisions
  • The condition book is too thick to flip through: ABAC rule governance and the cost of explainability
  • Keys for stable roles, condition books for high-risk access: a common hybrid design in enterprise permission systems

Applying it to enterprise Agent permissions

Internal employee tools can start with RBAC to control broad permission categories; when an Agent needs to invoke tools by customer, data level, task purpose, time, and location, only ABAC can express fine-grained boundaries. Don't let exception grants pile up endlessly into roles, and don't start by building a set of attribute rules no one can audit.

京ICP备2026014272号