In DDD there are many architectures. Some of them are said to be layered, some are not. In any case, there is a layer (or slice or component or whatever you want to call it) that contains only domain code; that domain layer has not dependency to other layers, contains only pure business logic. The first client of that layer is called Application layer that contains Application services that have , among other, the authorization responsibility; it checks if a user is permitted to execute some command (modify the state of the system) or query (view some data). Although it may seem that this authorization contain business logic, this logic is different from the core business logic.
So, about your example, the domain code should not check by itself if a user has access to some computers. The repository should expose a filter that the Application services could use to filter the computers the user has access to. It is OK to put this functionality inside the repository. In fact, in my opinion, the repository does not belong in the domain layer, not even the repository interfaces.
In CQRS, the command side of the domain layer does not contain any trace of repository/infrastructure code/interfaces, only pure domain logic. The application service authorize the user, loads the aggregate then call a method on it (here stays the domain code) then persist the aggregate.
On the query side there may be infrastructure code involved in the read-model, in order to keep even the domain layer thin. Here reside the filters that can be used by the application services to filter the computers the user has access to, but those filters are no pre-applied by the domain code, they are just exposed to application services use.
So, the conclusion, is to not mix the authorization code with the domain/business logic code.