Cloud Bridge Worker properly in request path (security architecture fix)

Status: Delivered
CAS: CAS-2196
Delivered: 2026-05-12
PRs: Infrastructure/config — no casaconomy-app code PRs (cloudflared config + CF Worker route)

What’s new

The Cloudflare Worker at ai-bridge.casaconomy.com is now the actual request path for all mobile (and desktop) AI requests. Previously, cloudflared was routing traffic directly to the daemon at localhost:7471, bypassing the Worker entirely — meaning authentication, rate-limiting, and request logging were deployed but never ran in production.

How to use it

Transparent to end users. All requests to ai-bridge.casaconomy.com now pass through the Worker before reaching the daemon. The Worker validates bearer tokens (SHA-256 hash lookup in CF KV), enforces the 200-requests/day rate limit, and logs request metadata. Pairing requests (/v1/pair/confirm) remain unauthenticated as designed.

What changed under the hood

New internal hostname bridge-tunnel.casaconomy.com is now the cloudflared-only ingress to the daemon (localhost:7471). This hostname is inaccessible without a Cloudflare Access service token.
ai-bridge.casaconomy.com now has a Worker route binding via wrangler.toml; all production traffic hits the Worker first.
Worker UPSTREAM_BASE_URL updated to https://bridge-tunnel.casaconomy.com (the internal hostname). The old config pointed at ai-bridge.casaconomy.com itself, which would have created a routing loop.
Cloudflare Access service token stored in ~/.paperclip/secrets/cloudflare.env for Worker → tunnel auth; injected by the daemon’s environment at startup.

Why we built it

During CAS-2105 end-to-end validation (2026-05-10), we discovered that cloudflared was routing ai-bridge.casaconomy.com directly to the daemon — bypassing the Worker entirely. The Worker was correctly deployed and tested in isolation but was never in the production request path. This meant anyone with the URL could hit /v1/chat and consume the regent’s Claude Max quota with no authentication or rate limit. The CAS-2098 security design (token validation, rate limits, metadata logging) was code-correct but completely inactive in production until this fix.

Known limitations / follow-on work

The Cloudflare Access service token (in ~/.paperclip/secrets/cloudflare.env) must be rotated if exposed. Rotation procedure: generate new token in CF Zero Trust dashboard, update the secret file, reload the daemon’s launchd plist.
bridge-tunnel.casaconomy.com is CF Access–gated for Worker traffic, but the tunnel DNS could theoretically be discovered. Confirm that cloudflared rejects non-Access-authenticated requests on that hostname.
Windows/Linux ports have no cloudflared/Worker equivalent; Worker-fronted AI routing is macOS-only until those platforms have daemon support.