The authorization system’s default answer to “can this role call this function?” must be no. A role must be explicitly listed as permitted to call a function. If no permission is defined, access is denied with 403.

This is the same principle as the allowlist vs. blocklist argument in API3 — applied to functions instead of fields. A blocklist says “deny these specific functions.” An allowlist (deny-by-default) says “permit only these specific functions.” New functions are denied until explicitly permitted.

A team building 50 endpoints over 6 months will add new endpoints regularly. With a blocklist approach, each new endpoint is permitted by default until someone remembers to add it to the deny list. With deny-by-default, each new endpoint returns 403 until the developer explicitly grants access to specific roles — forcing the authorization decision to be made at the time the endpoint is created.

In an RBAC system: if endpoint /api/admin/reports has no role permission entry, the authorization middleware returns 403 before the handler runs. The developer must actively add an entry like PERMIT role=admin ON GET /api/admin/reports before the endpoint becomes accessible.