A permission defines what an identified subject is allowed to do to a resource under stated conditions.
Read, edit, approve, publish, pay, delete, enter, export, share and administer are all permission-bearing actions. Good permission design separates identity, action, resource, scope, condition and duration instead of hiding them behind vague labels such as “access”.
Quick answer: how should permissions be categorised?
- Subject: which user, role, team, service or system receives the permission?
- Action: read, create, edit, approve, publish, delete, administer?
- Resource: which data, page, system, account or physical space?
- Scope: one object, folder, project, site, organisation or jurisdiction?
- Condition: under what state, location, device, time or approval?
- Duration: permanent, temporary, session-based or event-bound?
- Delegation: can the holder pass the permission to another?
- Inheritance: does permission flow from role, group or parent resource?
- Revocation: who can remove it and how quickly?
- Audit: what evidence records grant, use and removal?
This article complements How to Categorise Roles, How to Categorise Rules and How to Categorise Interfaces. Roles can carry permissions, rules can govern them, and interfaces expose them.
Permission is not identity
Knowing who someone is does not determine what they may do. Authentication and authorisation should remain separate.
Permission is not role
A role groups responsibilities and authority. Permissions are the concrete actions that role holders are allowed to perform.
Permission is not ownership
A user may have permission to edit a resource without owning it, and an owner may delegate use without transferring ownership.
Read permissions govern visibility
View, inspect and search access can be restricted separately from modification rights.
Write permissions govern change
Create, edit, upload and update permissions can apply at different scopes and should not automatically imply delete or publish authority.
Approval permissions govern acceptance
Approve, reject, sign, release and publish permissions often deserve stronger separation because they convert prepared work into consequential action.
Administrative permissions govern the permission system itself
Granting roles, changing policy and managing identities can be more powerful than ordinary content editing and should be classified separately.
Delete permissions deserve special treatment
Deletion can be recoverable, irreversible, local or cascading. The permission should reflect the actual consequence rather than one generic delete label.
Direct permissions attach to a subject
They are granted specifically to one user, service or account.
Role-based permissions attach to function
Users receive permissions because they hold a role such as editor, reviewer or operator.
Group permissions attach to membership
Teams or cohorts inherit a shared set of actions while membership remains the governing condition.
Inherited permissions flow through hierarchy
Access to a parent folder, project or organisation can propagate downward unless inheritance is blocked or overridden.
Conditional permissions depend on state
An action may be allowed only from a trusted device, during a defined time window, after approval, or while a case has a particular status.
Temporary permissions need expiry
Emergency, contractor and project access should end automatically or trigger review rather than becoming permanent through neglect.
Standing permissions create convenience and exposure
Persistent access reduces friction but increases the time window in which credentials can be misused or roles can drift.
Just-in-time permissions reduce standing privilege
Access can be granted only when needed and removed after the task, reducing unnecessary exposure.
Delegable permissions can propagate authority
If a holder can grant the same permission onward, that delegation path should be explicit and bounded.
Non-delegable permissions preserve control
Some approvals or rights belong only to the original authority and cannot be transferred casually.
Least privilege is a classification principle
Grant only the actions and scope necessary for the role or task rather than broad access “just in case”.
Separation of duties limits dangerous combinations
Create-and-approve, pay-and-reconcile, or publish-and-delete combinations can deserve additional review where misuse or error would be hard to detect.
Conflicting permissions need precedence
When one rule allows and another denies, the system must define which wins: explicit deny, higher authority, narrower scope or another governed precedence rule.
Revocation is part of permission design
Access that cannot be removed promptly is materially different from access with immediate revocation and session invalidation.
Permission use needs audit evidence
For consequential actions, logs should show who acted, what resource was affected, under which permission and when.
Dormant permissions create hidden risk
Old accounts, expired roles and unused service credentials can retain authority long after the original need disappears.
Permission reviews should compare intended and actual access
Role changes, reorganisations and inherited groups can produce access drift. Periodic review should remove permissions that no longer serve a valid purpose.
AI agents need bounded permissions
A model that can draft text is different from an agent allowed to send, publish, buy, delete or modify production systems. Tool permissions should match the narrowest necessary task and consequential actions should preserve receipts.
A practical permission record
- permission ID;
- subject;
- action;
- resource;
- scope;
- grant source;
- conditions;
- inheritance;
- delegation rights;
- start and expiry;
- revocation authority;
- conflicting permissions;
- audit requirements;
- last review;
- version.
The deeper idea
Permissions convert abstract authority into concrete possible actions. Their quality depends on whether that authority remains narrow, explainable, revocable and auditable.
To categorise a permission well is to know who may do what, to which resource, under which conditions, for how long, and who can revoke or audit that authority.
Final answer
Categorise permissions by subject, action, resource, scope, condition, duration, delegation, inheritance, revocation and audit. Keep permission separate from identity, role and ownership, minimise standing privilege, and preserve clear evidence for consequential grants and actions.