Applications often use a single, long-lived service account with broad permissions for convenience. This approach, however, is not a secure per-tenant authorization model for the actions your code performs. When a request for one tenant triggers an operation, the privileged service account can often access data belonging to other tenants. Relying solely on checking a tenant ID in a database is insufficient, as subsequent additions like caches or search indexes can bypass this limited check.To ensure security, service accounts should define the maximum process capabilities, not serve as authorization proof for every action. Before performing any side effect, authorization should be enforced, matching the scope of online APIs, even for background tasks. It is preferable to use short-lived, narrowly scoped tokens for outbound calls rather than a single, all-powerful secret. Accurate logging of tenant ID, resource ID, and the service identity used is crucial for incident investigation.If the same code path can successfully access resources from another tenant using a shared service account, it indicates a lack of authorization, not true security. While shared credentials manage the process execution, it is authorization that ultimately governs which objects can be accessed and modified.