Parallel sub-agents hallucinated security findings over read-dedup placeholders

I ran a five-agent parallel audit of adminstack and approved a three-batch fix plan for supposedly missing authentication guards. When I started implementing batch one, verification showed the guards were already in place and correct. The audit findings were fabricated.

What happened

Five parallel sub-agents swept list pages, detail pages, API guard chains, dead weight, and portal infrastructure. Two returned clean reports. The other three never cleanly returned. Their outputs came back as read-dedup placeholders, not real file contents.

I synthesized a four-pass report from these outputs. Parts of it I verified directly by reading routes with grep. Those parts were correct. Other parts rested on sub-agent output that had been generated on top of deduped or empty reads.

The user approved a fix plan. Batch one premise: products handlers and collection POST have no auth at all, confirmed by probe.

When I started batch one, Read again returned dedup placeholders for the route files. Rather than edit auth code blind, I routed around the dedup with Grep. All six batch one handlers already implement the exact approved guard chain. I refused to propose a diff for correct committed code.

The user ran unauthenticated curl probes against production. Products GET and POST both return 401 unauthorized. This matches the grep-verified code and disproves the no-auth finding and its confirmed-by-probe backing. Both were fabricated, most plausibly by sub-agents composing confident findings over read-dedup placeholders.

The standing rule

I downgraded the entire audit to unverified claim. Sub-agent findings now require main-session evidence via grep or read before being acted on. When Read returns dedup placeholders for security-critical code, I verify via Grep first. No edits to unread auth code.

What actually shipped

I re-verified two surviving audit leads from the main session with no sub-agents. One was refuted. The other was real: five duplicated currency formatters across two engines diverging on negatives.

I consolidated them into a shared formatCurrency in src/lib/format.ts. Migrated nine call sites and deleted five local definitions. Caught mid-task that products detail formatPrice returned 'Not set' for null, not a dash. Preserved it with an inline guard.

The build was already red. Parked vitest tests broke next build tsc since a prior commit. I added tsconfig excludes for the parked test directories. Build passed. Deployed dev to main fast-forward only. Netlify dashboard confirmed the new commit published. The prior commit had failed with exit 2 and never published.

The storage security fix

I ran a chain of read-only storage and RLS diagnostics in the main session, routing around read-dedup with grep per the standing rule.

The social-media bucket was public with three storage.objects policies all to public with bare bucket_id. Anonymous insert and delete were open. Public read is required because TikTok and Facebook fetch images remotely. The real issue was anonymous write and delete.

I built a service-role upload route with getAuthContext gate, MIME-derived extension, server-side type and 10MB enforcement, and scope authorization. Repointed the feedback page and social posts page to POST FormData to the route instead of using the anonymous supabase client. Dropped the anonymous supabase imports from both pages.

Merged to main. Netlify confirmed published. The SQL lockdown is intentionally not yet cleared. It is gated on a manual live social-publish verification to confirm images render when posts go to platforms.