Authentication answers the question: who is calling? Authorization answers the harder question: what is this caller allowed to do? In enterprise systems, authorization is rarely simple. Access may depend on role, tenant, organization, geography, data classification, workflow state, patient relationship, contract terms, delegated authority, or emergency access rules.
Carrier's policy construct gives authorization and visibility rules a more explicit architectural home.
Role-Based Access
Role-based access is often the first layer. A role might represent a clinician, administrator, billing specialist, auditor, support agent, integration client, or tenant owner. But roles are rarely enough by themselves. A clinician may be allowed to view patient records, but not every patient record. A billing user may work claims, but only for a particular organization. Roles define capability. Policies often need to define scope.
Tenant Visibility
Tenant visibility is one of the most important authorization concerns in enterprise SaaS and multi-organization systems. A tenant-scoped model should not rely on callers to filter data correctly. The service should enforce tenant visibility as part of its access model. Otherwise, a single missed predicate can expose data across organizational boundaries.
Can administrative users cross tenant boundaries?
Are cross-tenant operations audited?
Policy-Driven Data Access
Policy-driven access means authorization is applied where data is selected, changed, or exposed. Route-level checks can be too coarse. A caller may be allowed to use a route but only see a subset of records. A user may be able to update one field but not another. A workflow may allow access only while a record is in a particular state. Policies should express these rules as close as possible to the data access pattern they govern.
Governance Implications
Authorization is one of the clearest places where architecture and compliance meet. A policy is not only a runtime rule — it is evidence of design intent. Enterprise governance should treat policy changes as significant changes. A new route may expose data, but a modified policy may expose more data through existing routes. Both deserve review.