The reporting user is not the other Beeswax login
Two credentials on the same instance can see different advertisers. Falling back to the other username does not fix a 401. It silently audits someone else's book.
Published 2026-09-10 · Search job: Beeswax reporting wrong account empty audit
A 401 on the reporting password is not a reason to retry with the other Beeswax username in the env file. Those two users can see different advertisers on the same instance.
We verified this on 2026-09-02. The product reporting user returned 5,000 inventory_agg rows, and 4,956 of them were our own Supply Bench campaigns. The other username authenticated fine and saw dozens of other advertisers. A scoped read of our campaign 4805 returned zero rows. A scoped read of another tenant's campaign returned over a thousand.
If you "fix" a stale password by substituting the other login, the scan can finish cleanly with no_account_rows or, worse, with someone else's rows. Your account then looks clean. Nothing threw.
Why the direct runner refuses to fall back
The local Supply Audit runner fails loudly on 401 and has no fallback. That is intentional. Local env on this workstation has returned 401 on the product password before. Production has not. The production cron produced a covered run the same day, with findings attributed to Supply Bench campaigns 4791 through 4810 plus one Growth Lab campaign.
A local empty run proves nothing about production coverage. Verify against the deployed API.
The shape of the mistake
This is the same class of error as checking one endpoint. One credential worked, so it looked like the seat. The rows were the wrong book.
Incomplete coverage is not clean is how the product now refuses to paint that result green. ztdsp supply-audit commands is how an agent should read coverage_verdict before it celebrates zero findings.