Enable Cloudflare Access on the /v1/admin perimeter before paid launch

[serge-ivo]

From the admin security audit (2026-08). Not a code bug — a deployment-posture gap.

cloudflareAccessGate() is wired in front of /v1/admin/* (workers/api/src/index.ts:99) but is inert until both CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD are set (lib/cf-access.ts — if (!cloudflareAccessConfigured(c.env)) return next();). Prod currently runs with these unset, so today the entire operator portal (every cross-tenant read: all users, all instance configs, all coding-session timelines, all errors, all spend) is protected by requireAdmin alone — a single HS256 bearer token.

The gate itself is sound: it requires both env vars, pins alg:RS256, verifies against fetched JWKS, and fails closed (JWKS fetch failure / malformed / expired / aud-mismatch → 403). It just isn't engaged.

Action

• Create a Cloudflare Access application for admin.proagentstore.online (self-hosted, policy = the operator email(s)).
• Set CF_ACCESS_TEAM_DOMAIN + CF_ACCESS_AUD as API Worker secrets (Doppler pags/prd → wrangler secret put).
• Verify the admin UI still loads through the Access login and a non-allowlisted identity gets 403.

Severity: MED. Do before the paid launch — a leaked/forged admin session or a mistaken ADMIN_ALLOWLIST entry is currently full game-over with no second factor.

Files: workers/api/src/index.ts, workers/api/src/lib/cf-access.ts.

[serge-ivo]

Triage note — the gate on this one has moved, and nothing here says so.

The title condition is "before paid launch". Per pags/CLAUDE.md, PAGS billing is intentionally disabled in production: wrangler.toml leaves STRIPE_PRICE_ID and PAYWALL_ENFORCE commented, the console shows a preview-status note instead of an upgrade CTA, and PAS is the product receiving the live paid launch.

So this is not "not needed" — it is a real security task whose trigger has been deferred indefinitely, on an issue with zero comments and no deferral label, sitting among the actively-worked ones.

Two things worth deciding rather than leaving implicit:

1. Label it deferred-by-#68 or deferred: no demand, like the other correctly-parked work. Not applying one unilaterally — it is a priority call.
2. Confirm the gate is still right. "Before paid launch" was a reasonable trigger when the admin perimeter was only reachable by the owner. If /v1/admin/* is now reachable by anyone other than you, the gate should be "before that", not "before money". The dedicated admin rate-limit bucket (Dedicated strict rate-limit bucket for /v1/admin/* #109, clamped to 20/min on an ip: subject) suggests someone already thought about unauthenticated reach.

No action taken beyond this note.

[serge-ivo]

Code half shipped in e46452b. The perimeter is still OFF, and there is a verified blocker in front of step 1.

Runbook: docs/admin-access-perimeter.md.

The split

Half	Who	State
JWT verification, gate states, observability, tests	code	done
Create the Access application + policy + IdP	Cloudflare dashboard, owner only	not done
Set CF_ACCESS_* secrets	owner, wrangler secret put	not done

The dashboard half is genuinely not automatable from here. Verified today with the workspace token:

GET /accounts/$ACC/access/apps               → 200, "result": []   (zero apps exist)
GET /accounts/$ACC/access/organizations      → 10000 Authentication error
GET /accounts/$ACC/access/identity_providers → 10000 Authentication error

It can list Access applications but cannot read the Zero Trust org or its identity providers, so it cannot create one. Matches the note in ~/dev/stores/CLAUDE.md.

Two findings that change this ticket's action list

1. admin.proagentstore.online does not exist. The checklist says to create the Access application for that hostname. There is no worker route for it (workers/host/wrangler.toml binds only the apex and console.) and it answers 522 — DNS resolves, nothing serves it. An Access app there would protect nothing. The admin UI is actually served at proagentstore.online/admin/ (workers/host/src/index.ts:155).

2. The admin UI and the admin API are different origins, and that is what makes enabling this risky. The gate runs in the API worker, so the Access application has to cover api.proagentstore.online/v1/admin. But the SPA hardcodes https://api.proagentstore.online (store/admin/src/lib/api.ts:6) and fetches it cross-origin with no credentials, so it cannot present an Access session. I could not verify Cloudflare's exact response to an unauthenticated cross-origin XHR on a protected path — I have no application to test against and I am not going to invent the behaviour — but in every plausible outcome (IdP redirect a fetch() can't follow, or a 401/403 at the edge) the request never reaches the Worker.

What I shipped, and why it is not just "set two secrets"

The failure mode here is total and self-concealing: set the vars while the header isn't arriving and every admin request 403s, with the portal you'd use to notice being the portal that's down. Whether the edge injects the header cannot be determined from inside the Worker, from a test, or from the dashboard — it has to be measured in production. So measuring must not be the same act as enforcing.

The gate is now three states:

Mode	Trigger	Behaviour
off	either var unset	No-op. Local, dev and prod today — unchanged.
audit	both vars set	Verifies, records what it found, allows the request anyway.
enforce	both vars set and CF_ACCESS_ENFORCE truthy	Missing/invalid → 403.

• Default off; the default the moment the vars appear is audit, not enforce. A half-finished rollout degrades to observation, never a lockout.
• Enforcement needs an explicit affirmative (1/true/yes/on). "", false, 0 and the literal undefined a shell yields from an unset var all mean audit — a typo must degrade to watching.
• Rollback is wrangler secret delete CF_ACCESS_ENFORCE (→ audit) or CF_ACCESS_AUD (→ off). No code change.

On #424's question — it was not observable, and now is. A 403 from this gate landed in source:"unhandled", indistinguishable from an ordinary permission wall, so "is Access rejecting me?" was unanswerable using the one instrument still reachable while locked out. Rejections now log under source:"cf-access" at warn. A valid token logs nothing (a row per request is a log nobody reads — #423), and repeats collapse hourly (0103), so a rollout failing on every request costs ~1 row/hour.

The verification signal, stated carefully

The Worker can only record requests that reach it, so silence alone is not the green light:

Audit log	Meaning	Do
carried no Access token / invalid rows	Requests reach the Worker without a valid JWT	Do not enforce — finding 2 is confirmed
Silent and portal works normally	Every admin request carries a valid JWT	Safe to enforce
Silent and portal broken	Access is blocking at the edge, before the Worker	Do not enforce — fix the origin split

Not shipped, deliberately

Making this properly workable most likely needs the UI and its API on one origin — a same-origin /admin/api/* proxy on the host worker (which already has an API service binding) forwarding Cf-Access-Jwt-Assertion, with the SPA on a relative base. A smaller variant is credentials: "include" plus a one-off top-level Access login on the API host, but that fails opaquely whenever the Access session expires. Both are real architecture changes to a live admin portal, they are separable from the gate, and which one is needed depends on the edge behaviour audit mode exists to reveal. Filing that on evidence beats guessing now.

Verification

Ten-gate bar green (6,638 tests). Tests sign real RS256 assertions against a generated key and serve a real JWKS rather than stubbing the verifier — aud mismatch, expiry, foreign issuer, alg:none, unknown signing key and unreachable JWKS all assert fail-closed under enforce; audit is asserted to never block; neither mode lets the error log decide the perimeter's answer. Mutating "audit never blocks" fails 3 tests. E2E skipped — no store/, agents/coder/web or Playwright-exercised code touched.

Production after deploy (both workflows green): /v1/admin/me → 401 (session auth, not 403), /admin/ → 200, /health → 200. The gate is inert, as intended. Note honestly that an inert gate has no positive production signal by construction — "deploy succeeded and the admin surface is byte-for-byte unchanged" is the full extent of what can be verified live until the secrets are set.

Leaving this open — the perimeter is not on. Remaining work is owner-only dashboard steps (§4 of the runbook) plus a decision on the origin split.

Re: the triage note above — the "before paid launch" gate is still deferred (PAS takes the paid launch), but this is no longer waiting on that. The code half is done and reversible; what remains is a dashboard action whose real trigger, per that note, should be "before /v1/admin/* is reachable by anyone other than the owner", not "before money".

[serge-ivo]

The origin split, decided: mechanism, blast radius, and what only audit mode can tell you

Read-only analysis of the decision the previous comment deliberately deferred. I changed nothing, set
no secret, created no Access application. Everything below is either measured today against
production or explicitly flagged as inferred.

What I re-measured first, because two of this ticket's premises had already expired once

probe	result
GET https://api.proagentstore.online/v1/admin/me (no auth)	401 — session auth, gate inert, as designed
GET https://proagentstore.online/admin/	200
GET https://admin.proagentstore.online/	522; DNS resolves to 104.21.34.196 / 172.67.164.54 (Cloudflare proxy, no origin)
OPTIONS /v1/admin/me, Origin: https://proagentstore.online, ACRH: authorization,content-type	204, access-control-allow-origin: https://proagentstore.online, access-control-allow-credentials: true, allow-headers: Content-Type,Authorization
my own session	roles: ["user","creator","admin"]; /v1/admin/me → {"admin":true}

So §3's two findings hold exactly as written, and the fourth row adds something the runbook does not
say: the server half of Option B is already built. workers/api/src/index.ts:80-96 sets
credentials: true on an explicit origin allowlist that includes the admin app's origin, and the
preflight is answering correctly today.

I also checked who else would be caught. Only the admin SPA calls /v1/admin/* — grep across
workers/, packages/, store/ and agents/ finds no other caller. In particular MCP's
list_errors goes to /v1/errors (workers/mcp/src/instance-tools/observability.ts:104), not
/v1/admin/errors, so the MCP debugging path stays reachable under enforce. That matters below.

---

Option A — same-origin /admin/api/* proxy on the host worker

Mechanism

1. One Access application on proagentstore.online, path admin. It covers the SPA shell and
   every XHR, because after the proxy they are the same origin and the same path prefix.
2. A visitor to /admin/ gets a top-level navigation into the IdP — the interaction redirects
   are designed for — and returns with CF_Authorization scoped to proagentstore.online.
   Cloudflare validates it at the edge and injects Cf-Access-Jwt-Assertion into the origin request.
3. The host worker gains one route: /admin/api/* → env.API.fetch() with the prefix stripped,
   forwarding method, body, Authorization and Cf-Access-Jwt-Assertion.
4. The API worker's existing gate verifies that header. requireAdmin still runs behind it —
   Access answers "may you reach the origin", the bearer answers "who are you".
5. store/admin/src/lib/api.ts:6 becomes const API = "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/admin/api". One line; every call site keeps
   its /v1/... path unchanged.

What it costs — more than "add a route", and three specifics that are easy to miss

• The host worker refuses every non-GET today. workers/host/src/index.ts:117-119 returns
  405 Method Not Allowed for anything that is not GET/HEAD. The admin SPA does POST (suspend,
  unpublish, cancel, revoke, roles) and DELETE. That guard has to be relaxed for this prefix, and it
  is currently a cheap blanket property of a read-only marketing worker.
• Route ordering. /admin/api/v1/admin/me contains no ., so it is matched by the existing
  path.startsWith("/admin/") && !path.includes(".") branch at :155 and would be answered with the
  SPA shell. The proxy must be registered before it.
• Service-binding subrequests do not traverse the edge, so the API worker sees the Access header
  only because the host copies it. That is the design, not a leak — but it means a forwarding bug
  presents exactly as carried no Access token in the audit log, which is the right failure shape.
• Forward an allowlist, not /v1/*. The proxy sends no Origin, so the API's CORS allowlist
  never applies to anything routed through it. That is not a new hole (this API authenticates with a
  bearer, and CORS was never its boundary), but a blanket /v1/* forward makes the apex a permanent
  second front door to every route. The SPA needs exactly /v1/admin/*, /v1/auth/me,
  /v1/auth/config and /v1/errors/client.
• Plus: a /admin/api entry in store/admin/vite.config.ts's dev proxy, and a host rebuild (the
  admin SPA is inlined into the worker at build time — workers/host/build.js:48-68).

Call it ~30 lines across two files and one config, versus one line for Option B.

Blast radius on a live portal

The dangerous failure is path-scoping the Access application to the whole hostname instead of
/admin. On the apex that takes the public storefront, /agents/*, /console/, /widget.js,
/sitemap.xml and /llms.txt behind a login. It is loud, immediately visible from any browser or
curl https://proagentstore.online/, and reversible in the dashboard in under a minute.

Second-order: the 405 relaxation. If it is written as "allow all methods on /admin/*" rather than
"on /admin/api/*", the SPA-shell branch starts accepting POSTs. Harmless in itself (it returns
HTML), but it is the kind of widening that is never narrowed again.

What it forecloses

• proagentstore.online/admin/api/* becomes a permanent second path to the API. Every future admin
  route is reachable two ways, and the allowlist above becomes a thing that has to be maintained.
• It commits the admin UI to living under the apex. Given admin.proagentstore.online does not exist
  and (per §3) should not be created, this is a cost only on paper.
• It adds one service-binding hop to every admin request. Sub-millisecond, same colo, not a real
  cost — but the portal's latency is now the host worker's problem as well as the API's.

---

Option B — credentials: "include" plus a one-off top-level Access login

Mechanism

1. Access application on api.proagentstore.online, path v1/admin (never the whole hostname —
   that breaks the console, every runner and the widget).
2. The operator opens https://api.proagentstore.online/v1/admin/me once in a top-level tab,
   completes the IdP, and gets CF_Authorization scoped to the API host.
3. store/admin/src/lib/api.ts adds credentials: "include" to its three fetch calls.
4. The cookie is sent on the SPA's cross-origin XHR, and this is the part worth being precise
   about: proagentstore.online and api.proagentstore.online are the same site (one
   registrable domain). SameSite constrains cross-site, not cross-origin, so Lax — and even
   Strict — permits it. This is not a SameSite=None gamble.
5. Server side needs no change: measured above, the preflight already answers with
   allow-credentials: true for this exact origin.

The hazard that decides it: the preflight is uncredentialed by definition

Every admin request carries Authorization and Content-Type: application/json, so every one of
them is preflighted. A CORS preflight is specified to be sent without credentials — no cookies,
ever. So Cloudflare Access sees an unauthenticated OPTIONS on a protected path on every single
call.

Inferred, not measured: Cloudflare Access applications carry their own CORS settings (allowed
origins/methods/headers + allow-credentials) precisely for this, and without them the preflight is
answered by Access rather than passed to the origin. I could not test this — no Access application
exists on the account, and the workspace token cannot create one (verified again: access/apps lists
[]; access/organizations and access/identity_providers both return 10000 Authentication error). I am not going to assert Cloudflare's exact response. What I will assert is the
consequence in either direction:

• If the preflight is answered by Access, the browser fails the request with an opaque CORS error and
  the Worker never sees it — so the audit log stays silent while the portal is dead.
• If the Access CORS settings are configured correctly, it works, and this option is one line of code.

The hazard that is not fixable by configuration: session expiry

Access sessions expire (24h by default). When one does, the XHR receives a 302 to the IdP.
fetch() follows redirects, lands on an HTML login page, and the SPA gets a JSON parse failure or an
opaque response. An XHR cannot complete an interactive login, and the SPA has no way to know it
should tell you to open a tab. The mitigation is redirect: "manual" plus detecting an
opaqueredirect response and rendering "open the API host and sign in" — which is real code, in the
one app you use when something else is already broken.

Option A does not have this failure: an expired session on a top-level navigation redirects to the
IdP and comes back, which is what the whole Access flow is designed to do.

Blast radius

Smaller in code, larger in operation. The misconfiguration that hurts is scoping the app to the whole
api.proagentstore.online hostname, which takes down the console, every pags up runner's relay
handshake, the widget and the public trial chat simultaneously. That is a worse outage than Option
A's worst case, though equally reversible.

What it forecloses

• credentials: "include" on the admin SPA is permanent, and thereafter any cookie ever set on the
  API host is sent by the admin app. Small, real widening.
• It leaves the origin split in place, so the next browser surface that needs an Access-protected API
  call re-derives all of this from scratch.

---

Recommendation: Option A, and not narrowly

Four reasons, in order of weight:

1. It deletes the question instead of answering it. Same-origin means no CORS, no preflight, no
   Access CORS settings to get right — the entire §B hazard stops existing rather than being
   configured around.
2. Expiry becomes benign, which is the failure that will actually happen, repeatedly, for as long
   as the portal exists.
3. It makes the audit signal legible. Under Option B, "silent" is ambiguous between healthy and
   edge-blocked, and the runbook has to warn you about it. Under Option A, an edge block is a visible
   login page on a navigation — you cannot fail to notice it.
4. The parts are already there: the API service binding exists and is used, the SPA is inlined
   into the same worker, and the dev proxy already maps /v1.

The cost difference is ~30 lines against 1, once, for a permanent operational property. That trade is
not close.

What would change my mind: if the Access application's CORS settings turn out to handle the
preflight cleanly and someone wants the perimeter on this week. Even then it is a stopgap, because
CORS settings cannot fix expiry — so I would frame it as "B now, A anyway", not "B instead of A".

---

What can only be learned by turning audit mode on

The gate is inert, so all six of these are currently unknown, and none of them can be established
from code, tests, or the dashboard:

1. Whether the edge injects Cf-Access-Jwt-Assertion at all for a path-scoped application on a
   hostname that is served by a route-mapped Worker. This is the load-bearing unknown.
2. Whether the JWT's claims match what the gate pins. verifyAccessJwt requires
   alg: RS256, aud to include CF_ACCESS_AUD, and iss === https://<team domain>
   (lib/cf-access.ts). A team-domain typo, or an aud copied from the wrong app, surfaces only
   here — as invalid, distinguishably from missing.
3. Whether the Worker can reach https://<team>.cloudflareaccess.com/cdn-cgi/access/certs. A
   JWKS fetch failure is 503 inside the verifier and resolves to invalid; fail-closed under
   enforce, fail-open under audit. Unmeasured.
4. Whether every request carries it, or only navigations — the SPA polls, and an XHR shape that
   misses the cookie shows up as a stream of missing rows.
5. Under Option B only: whether the preflight survives. This is the single highest-value thing
   audit + a scratch application would settle, and it is the reason not to guess it now.
6. Whether any non-browser caller exists. I found none by grep, and grep does not see a curl in
   someone's shell history.

The decision procedure, stated so it cannot give a false green light

The runbook's warning is right — silence alone is not the signal — but the test can be made
three-way and unambiguous, with no new code:

1. Read the log and note the current repeat_count / last_seen_at for any source: "cf-access"
   row (repeats collapse into an existing row within the hour and bump both — migration 0103), so
   "no new row" must mean "no bump", not "no row".
2. From a signed-in browser, load the admin portal and hit one admin route.
3. Re-read the log:

result	meaning	do
request 200s, no new/bumped cf-access row	header arrived and verified	safe to enforce
request 200s, a missing/invalid row appears or bumps	reaches the Worker without a valid JWT	do not enforce — this is §3(b)
request does not complete (opaque/network error), log silent	blocked at the edge, before the Worker	do not enforce — fix the origin split

Audit never blocks, so row 2 and row 3 are distinguished by whether the request succeeded, not by
whether the log spoke. That is the whole reason the three-state gate was worth building.

One correction to the runbook, and it is not cosmetic

§4 step 4 says to read the evidence with GET /v1/admin/errors?source=cf-access. That endpoint is
inside the perimeter it is measuring. Under audit it works (audit never blocks), so this is not
broken today — but in exactly the failure row where you need it most ("silent and the portal is
broken"), the diagnostic is blocked at the edge along with everything else.

Use GET /v1/errors?scope=all&source=cf-access instead, or MCP list_errors. Verified today: it is
registered at index.ts:174, outside the /v1/admin/* gate at :135, returns everyone's rows
for a session carrying admin (routes/errors.ts:57), and answers 200 for my session right now.

---

Proposed doc change — docs/admin-access-perimeter.md

This analysis belongs in the runbook, not only on the issue: the runbook is what someone will read at
the moment they are about to set the secrets. Proposed as a new §3a inserted between §3 and §4,
plus the two-word correction in §4 step 4. Full text ready to commit:

## 3a. The two ways to close the origin split — decided

## 3a. The two ways to close the origin split — decided

§3 establishes that the admin UI and the admin API are different origins and that the SPA cannot
present an Access session. There are exactly two remedies. This section records both and which one
was chosen, so the decision is not re-derived at the moment someone is about to set the secrets.

**Chosen: A — a same-origin `/admin/api/*` proxy on the host worker.**

| | A — same-origin proxy | B — `credentials: "include"` |
|---|---|---|
| Access application on | `proagentstore.online`, path `admin` | `api.proagentstore.online`, path `v1/admin` |
| Code | ~30 lines: a proxy route on the host worker, the SPA's base to `/admin/api`, a dev-proxy entry | 1 line: `credentials: "include"` |
| CORS | none — same origin | every request preflighted, and a preflight is uncredentialed by definition |
| Session expiry | a top-level navigation redirects to the IdP and returns | an XHR gets a 302 it cannot complete; fails opaquely |
| Worst misconfiguration | whole apex behind a login (storefront + console) | whole API host behind a login (console + every runner + widget) |
| Audit signal | an edge block is a visible login page | an edge block is an opaque XHR failure with a silent log |

**Why A.** It removes the CORS question rather than configuring around it, expiry stops being a
failure mode, and an edge block becomes visible instead of silent. The parts already exist: the host
worker has an `API` service binding, the admin SPA is inlined into that same worker at build time,
and `store/admin/vite.config.ts` already proxies `/v1` in dev.

**Three implementation notes that are easy to miss:**

1. `src/index.ts:117-119` returns `405` for every non-GET. The admin SPA POSTs and DELETEs. Relax it
   for `/admin/api/*` only — not for `/admin/*`, which is the SPA shell.
2. `/admin/api/v1/admin/me` contains no `.`, so the existing `path.startsWith("/admin/")` branch
   would answer it with the SPA shell. Register the proxy before it.
3. Forward an allowlist, not `/v1/*`. The SPA needs `/v1/admin/*`, `/v1/auth/me`, `/v1/auth/config`
   and `/v1/errors/client`. A blanket forward makes the apex a permanent second front door to the
   whole API — the proxy sends no `Origin`, so the API's CORS allowlist never applies to anything
   routed through it.

**If B is used as a stopgap**, note that it is a stopgap: the Access application needs its own CORS
settings (allowed origins, methods, headers, allow-credentials) for the preflight, and no setting
fixes expiry. The cookie itself is not the problem — `proagentstore.online` and
`api.proagentstore.online` are the same *site*, so `SameSite=Lax` still sends it cross-origin.

Correction to §4 step 4's verification command

*Verify, and this is the step that decides everything:* use the admin portal normally for a while,
then read `GET /v1/errors?scope=all&source=cf-access` (or MCP `list_errors`). **Not**
`/v1/admin/errors` — that endpoint is inside the perimeter being measured, so in the one failure
case where you need it (silent log, broken portal) it is blocked along with everything else.

Repeats collapse into an existing row within the hour and bump `repeat_count` / `last_seen_at`
(migration `0103`), so "nothing new" means "no bump", not "no row". Note both before you look.

---

Verified vs inferred

Verified today: every row of the probe table (curl against production); that only the admin SPA
calls /v1/admin/* (grep across all four trees); that MCP's list_errors uses /v1/errors; that
/v1/errors is registered outside the gate and returns 200 with scope=all for an admin session;
the host worker's 405 guard, its route ordering, its API binding and its inlining of the admin
SPA; the API's CORS block including credentials: true; the gate's claim pinning in cf-access.ts;
the repeat-collapse semantics in 0103/error-log.ts.

Inferred, and flagged as such: Cloudflare's exact treatment of an uncredentialed preflight on an
Access-protected path, and the existence/behaviour of per-application CORS settings. I could not
create an application to test it, and that specific uncertainty is a large part of why I am
recommending the option that never asks the question.

Not attempted: I did not set a secret, create an Access application, or send a single mutating
request. Nothing in this comment has changed the perimeter's state — it is still off.