Many backends talk to storage, email, or partner APIs with one long-lived service account: “the app can do everything.” That credential is an operational convenience. It is not a per-tenant authorization model for the effects your code causes.
When a request for tenant A triggers a write, send, or export, the privileged service account can usually touch tenant B’s data too. If the only gate is “we already looked up the row with the right tenant id in SQL,” you have a hope, not a policy. Hopes drift when someone adds a second lookup path, a cache, a search index, or a bulk job.
Patterns that hold up:
- Keep the service account as a ceiling for the process, not as proof that a specific effect is allowed.
- Before each side effect, authorize (or at least enforce the same tenant/resource scope your online APIs use) for the object you are about to change — including background paths that reuse the same credential.
- Prefer short-lived, narrowly scoped tokens per tenant or per effect for outbound calls, instead of one god-mode secret for every job.
- Log tenant id + resource id + which service identity was used. “App service account wrote object” without tenancy is useless in an incident.
Quick check: point the same code path at a resource id from another tenant while keeping the shared service account. If it succeeds because the credential is powerful, you never had authorization — only a trusted query.
Shared credentials run the process. Authorization still decides which object may be touched.
Top comments (0)