"It works on my machine" is almost never about how your machine is configured. It is about the authority you hold on it.
Locally you are one principal with unlimited rights. Database owner. Long-lived credentials sitting in a dotfile. No egress policy. Every dependency reachable on loopback. Nothing in that code path has ever been denied anything, so the branch where permission gets refused has never run. Not in dev, not in review, not in tests.
Production hands that same code a narrower identity.
A role that reads the table but cannot touch the sequence.
A short-lived token minted hours before the request that needs it.
An egress allowlist that permits the payment provider and quietly drops the verification provider.
A replica that answers your SELECT and refuses your INSERT.
The dangerous part: partial authority does not fail the way missing config fails. Missing config fails at boot, loudly, in one place, before any user is involved. Partial authority fails mid-flow, on the second call, after you have already returned 200 and told the user their payment is accepted or their verification is submitted. In payments and KYC paths that is the write carrying the record of what happened, the one you need to reconcile against later.
So authority I treat as a test parameter, the same way I treat data shape and concurrency. Run locally as the production principal. Deny by default. Assert the refusal path explicitly, credential expiry included, not only credential absence. A permission error you have never watched execute is not handled code, it is untested code with optimistic comments.
I write up more of these failure shapes from production payment and compliance systems here: https://polycratia.com/c/1dd0f661
Where does scoped identity bite you first: storage writes, outbound egress, or token rotation?