Turning Audience Finder AI into a protected product.

What it needed to become

The requirements were not complicated but they were non-negotiable:

• The admin dashboard should be protected by real authentication, not just a local file and a token paste
• Review actions should write to the live backend, not localStorage
• The API token should never appear in browser JavaScript under any circumstances
• No outreach, no scraping, no autonomous decisions -- human approval at every step
• The system should be deployable with a documented release process, not just ad hoc wrangler commands

Why the admin-proxy pattern matters

The naive approach to a protected admin dashboard is to have the browser send the API token directly. That would work but it would also mean the token appears in JavaScript, in network requests visible in any browser dev tools, and potentially in server logs at any intermediate point.

The admin-proxy pattern solves this cleanly. The browser authenticates with Cloudflare Access (a hardware-grade identity gate). The admin-proxy Worker picks up the Access identity header, validates it against an allowlist that lives in a Worker secret, and only then adds the Bearer token to the upstream request. The token never leaves the Worker runtime. There is no point in the flow where a browser, a log, or a network capture could intercept it.

The pattern also gives a natural feature flag layer. The proxy checks AUDIENCE_ADMIN_REVIEW_ENABLED, AUDIENCE_ADMIN_CANDIDATE_ENABLED, and AUDIENCE_ADMIN_DISCOVERY_ENABLED before forwarding any write. Disabling a feature is a one-line config change and a redeploy -- no code changes required.

Manual review as a product feature

The review modal is not just a UI detail. It is a design decision about what kind of system this is.

Every review action -- Accept, Reject, Watch -- opens a modal. The modal shows the candidate's score dimensions and reasoning. It requires a reviewer note before submission. It shows a confirmation step before the write goes through. There is no way to batch-approve candidates, no keyboard shortcut that skips the confirmation, and no auto-accept path anywhere in the code.

This is deliberate friction. The system is not trying to move fast. It is trying to move carefully. The value is not in the number of domains processed -- it is in the quality of the ones that make it into memory.

The read-only audit log in the dashboard shows the latest 25 review events directly from the KV review log. It is not a separate data store -- it reads the same log that the API Worker writes to. The dashboard and the local PowerShell tools see the same data.

Controlled discovery

The discovery feature is the most constrained part of the system by design. "Controlled discovery" means exactly that: a deterministic seed pool of 19 curated sites, keyword matching against the candidate profile, stable sort, deduplication against existing KV memory, and a hard cap of 5 results per call.

There is no live search API. There is no scraping. The system does not contact any external site. It does not send any form of outreach. The discovery results land in the pending queue and wait for human review before any action is possible. The entire flow is: suggest candidates, add to queue, human reviews, human decides.

The seed pool will grow as the system proves itself. But the architecture stays the same: curated inputs, deterministic matching, human review, no autonomous action.

The hard parts

A few things that were not obvious going in:

• Cloudflare Workers can fetch other Workers, but only with the global_fetch_strictly_public compatibility flag. Without it, Worker-to-Worker fetch fails with error 1042 and the error message does not point clearly at the fix.
• Plain vars in wrangler.jsonc override Cloudflare dashboard variable values on every deploy. A flag enabled in the dashboard is silently reset to the config file value the next time you run wrangler deploy. All plain vars belong in the config file, not the dashboard.
• Cloudflare Pages Direct Upload does not activate Pages Functions routes. The Pages Function session proxy built in V1.9 returns 404 in deployment because Direct Upload bypasses the Functions runtime. The admin-proxy Worker pattern sidesteps this entirely.
• CORS preflight requests strip Cloudflare Access cookies. The browser must omit Content-Type on cross-origin fetch calls so the request stays simple and Access injects the identity header correctly. Adding a Content-Type header triggers a preflight OPTIONS request that Access blocks before the identity can be validated.

What this proves

• A governed AI workflow does not require a large team or a complex infrastructure stack -- Cloudflare Workers, KV, Access, and careful architecture decisions are enough to build a production-grade controlled system
• The admin-proxy pattern is a reusable approach for any system where browser clients need to trigger authenticated server-side writes without exposing credentials
• Feature flags in the Worker config are a lightweight release control mechanism that keeps deployment risk low and rollback fast
• Manual review is not a bottleneck -- it is a quality gate. The system is faster and safer because a human sees every decision
• A pre-release check script that does nothing but report current state is genuinely useful: it forces a review of git state, syntax, and config before every deployment

What comes next

• Expand the discovery seed pool as the system proves reliable at current scale
• Add a protected source registry management interface to the admin dashboard (same admin-proxy pattern)
• Add GitHub Actions for JS syntax checks on push -- read-only CI, no deploy automation
• Configure the custom domain admin.pl8ypus.io for the admin workspace
• Review the D1 migration plan before starting any relational data layer -- KV is still the right choice for current volume