Where to implement aggregate level permissions in DDD?

Assume I have an aggregate type of Order, which contains OrderItems. Depending on the state of an order, and the user-role operating on it, operations may be permitted or not permitted.

For example, if the user-role is Customer and the order's status is Open, then adding and removing items is permitted. Conversely, if the order's status is Processing then adding and removing items is not permitted. However, if the user-role is Manager and the order's status is Processing then adding and removing items is permitted.

My question is:

• Should the Order type handle these kinds of permissions? ie, it encapsulates all the logic about which roles can do what, and therefore has a dependency on user-role.
• Or should this be handled outside of the Order type in a permissions service that would accept a role, an operation, and the subject of the operation (an order instance) and determine whether the action is allowed? ie, logic is externalized and assumed to be validated before the operation is executed on the Order, which has no knowledge of the concept on user-roles.

(Notes: The real world use case is significantly more complex with large numbers of roles, statuses and actions. Authorization happens at an outer layer and has been applied already - this question is about instance specific permissions. In otherwords, a Customer is authorized to access the 'AddItemToOrder' API endpoint, but depending on the specific state of the order, the actual operation may or may not be allowed.)