DEFAULT_PERMISSION_CLASSES and per-view permission_classes override boundary

Goal is to define a permission configuration for Django REST Framework where no view is unintentionally publicly accessible.

DRF’s documented default permission class is AllowAny, and a project-wide DEFAULT_PERMISSION_CLASSES setting in REST_FRAMEWORK can provide a baseline. Per-view permission_classes can override the global default, and the interaction between an omitted attribute, an explicit empty list, and a changed global setting creates uncertainty about the effective permission boundary.

Assumptions are for DRF 3.x with standard APIView and GenericAPIView usage. The desired behavior is a predictable, auditable mapping from global default to view-level override without silent reversion to public access.

Does an explicit empty permission_classes override inherit the global default or result in unrestricted access? Under what conditions does a view without permission_classes remain publicly accessible after DEFAULT_PERMISSION_CLASSES is modified? What documentation boundary should be treated as authoritative for permission inheritance?