Security is a cross-cutting concern that can span several layers, and it does in different formats and ways from layer to layer.
Application layer
In the application layer, we implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).
At this level, the entity associated with security is not the customer; it's the well-known Account. In a nutshell, and from the security context standpoint, there are no customers, only accounts and privileges.
The Role of the user is set at this level. For example, there can be different types of accounts (Admin, Customer, Provider, Guest, ...).
This gets more complicated if accounts support multi-tenancy (multiple users per account).
For multi-tenant accounts, for one user to act on behalf of a partner, it must do it through the proper security function, so the application security is always aware of who was authenticated and who is the enabled user at the time.
Business layer
In this layer, we start speaking about Customer and concepts like tenancy (data ownership) and business rules (or policies) that enact an additional layer of security. For example, the business filters the data by its tenant, so outer layers are agnostic to data belonging to other tenants. To make this seamless to the application layer, the application layer MUST identify the user and retrieve the customer ID associated from the security context exclusively.
Domain layer
At the domain layer, the security is a bit blurred. For example, in this layer, we might find the abstraction (ports) of those policies and business rules I mentioned previously. The concrete implementation (adapters or use cases) can be located somewhere in the outer layers (business, application, infrastructure, ...).
We don't make them concrete at this level because business rules and policies can change rapidly for reasons unrelated to the domain. For example, we may need to add (or change) policies because we have implemented a new type of Account (or Role). Or we want to make security more astringent, so we need to implement a new security policy handler (adapter) to solve how policies stack with others. This sort of change is unlikely to be caused by changes in the domain (what we do); the reasons are commonly associated with business changes (how we do it from now on).
The pitfalls are the same associated with abstraction and decoupling. In order to keep each security implementation decoupled but still highly cohesive across all the layers, we increase the global complexity of the application, which is per se, already complex (due to the CA1).
1: Conceptually simple, but complex to implement due to the so many abstractions, models, mappings, etc