A developer who asks an agent to deploy a Cloudflare Worker can leave before the deploy is finished. If the agent reaches the login boundary, Cloudflare's command-line tool now offers another instruction: run the deployment again with --temporary. The second command can return a live Worker, a temporary account, and a claim link with a 60-minute clock. No responsible person has authenticated yet, but the product is already doing something useful.
That reversal is easy to describe as smoother onboarding. It is more revealing to describe it as a change in custody. The agent receives enough temporary authority to make and test a resource. A person later claims the resource into a durable account. The service must then decide what persists, which credentials die, whose identity appears in the history, and who can recover the account when something goes wrong.
So who owns the account in the interval? The honest answer is that owns is doing too much work. The provider controls the temporary account. The agent or its platform holds a narrow credential. The person who requested the work may not yet be known to the provider at all. What exists is provisional product custody, not a settled legal conclusion.
Claimable accounts make an old fact newly visible: signup was never one event. It was a bundle of decisions that happened to share a screen.
A product before a customer
Cloudflare's temporary-account flow is unusually explicit about the order. An unauthenticated tool creates or reuses a temporary account, deploys a Worker, and gives the intended user a link. If nobody completes the claim within an hour, Cloudflare deletes the account and its resources. If the claim succeeds, supported resources survive, but the platform that performed the provisional deployment does not retain permanent access. Later deployments use the ordinary authenticated path.
Neon's claimable database flow stretches the interval to 72 hours. An agent can provision one capped project, receive credentials scoped to it, configure an application against the database, and pass a claim link to a human. The useful state comes first. The durable customer identity comes later.
Neither flow gives an anonymous agent an unrestricted account. Expiry, quotas, resource limits, scoped credentials, and deletion are what make the missing signup tolerable. The product is not removing the boundary so much as moving it. Instead of asking for a durable identity before any work begins, the service grants a small amount of reversible authority and waits to see whether someone accepts custody.
This is why the temporary account is best understood as a pre-customer state. It is not quite a trial, because a machine rather than a browsing person may be the first actor. It is not quite a service account, because the identity may disappear at claim. And it is not yet the customer's account, because the customer has not authenticated.
What signup used to hide
The conventional signup sequence made several questions look like one question: the identity present, the credentials it may use, the resources it may create, the organization that controls the result, and the person who can revoke access or recover the account. When the same person supplied an email address, chose a password, accepted the product's terms, and clicked the first button, the distinctions were easy to ignore.
An agent breaks that convenient sequence. It can discover an API, encounter an authentication wall, and still be capable of useful work while the person who will ultimately control the result is unavailable. The service now has to answer those questions at different times and for different principals.
WorkOS tries to make the choice discoverable through auth.md, a vendor-authored Markdown file that tells an agent which registration flows and scopes an application supports. One service may require a user to claim the result. Another may verify the agent. A third may allow a narrow anonymous path. The proposal is useful vocabulary, but it should not be mistaken for an adopted standard. Its more immediate significance is that registration policy is becoming something software can inspect before a person arrives.
The resulting order is not signup followed by product use. It is discovery, temporary authorization, product use, then a decision about durable custody. That order gives the claim link far more weight than its modest interface suggests.
Claim is a security event
Neon says that beginning a claim revokes the pre-claim access tokens and rotates the database credentials. Cloudflare says that claiming a temporary account does not grant the originating platform continuing access. These are not decorative precautions. They define the handoff.
If the bootstrap credential still works after claim, custody has not really changed. If the agent can no longer act but the audit history cannot say what it did before the handoff, the new owner inherits state without provenance. If a bearer claim link reaches the wrong person, the service may attach valuable state to the wrong durable principal. Conversion and security are the same transition here because the product becomes a customer account by changing who can control it.
That makes credential rotation, expiry, revocation, and recovery part of the acquisition design. A claim page can increase completion while weakening the boundary; a more restrictive flow can preserve the boundary while abandoning useful work. The design problem is not to maximize either smoothness or friction. It is to make the provisional authority small enough to reverse and the handoff explicit enough to audit.
The agent may need to remain itself
Not every piece of agent-created state should be transferred to the first human who clicks a link. Anthropic's agent identity model starts from a different setting: an agent works across a shared workspace or channel, where no single person's permissions describe what the group intends. The agent receives its own service identity, administrators define its baseline access, and central revocation can end that access everywhere it is used.
Here the stable non-human principal is the point. A particular person may invoke the agent, but the resulting action still needs to be attributable to the agent and to the compartment in which it acted. Human context matters without replacing agent identity.
This is the limit of the claimable-account story. A claim can attach a temporary resource to a durable organization. It does not decide whether the agent should have a persistent identity inside that organization, whether it acted on its own authorization or on a user's delegated authority, or which permissions should survive for the next task. Those questions begin after claim.
The distinction also explains why creating a fresh identity for every run is usually a poor substitute for narrow credentials. Microsoft's least-privilege guidance recommends stable, lifecycle-managed agent principals paired with short-lived entitlements, explicit purpose, named human responsibility, and end-to-end attribution. Identity can remain stable while permission expires.
The old pattern, moved into a new path
The strongest objection to all of this is historical: temporary infrastructure is not new. Neither are anonymous sandboxes, free trials, service accounts, resource transfers, or delegated OAuth access. Neon says so itself. Its earlier neon.new and Instagres experiences let developers create unauthenticated databases for workshops and demonstrations.
That objection should narrow the claim. Agents did not invent ephemeral credentials or the idea that a resource could later be transferred. What has changed is the default path by which software reaches the product. A machine can now be the actor that encounters the signup wall, creates the first useful state, and presents the eventual customer with something worth keeping. The preview-and-claim pattern has moved from a human-facing demo into machine-facing acquisition.
It may remain a small feature of a few infrastructure products. We do not have public claim rates, abandonment data, independent security reviews, or evidence that one lifecycle will spread across the market. Even the emerging identity work argues against treating every implementation as one model.
The IETF's current AIMS working-group draft is helpful precisely because it refuses that collapse. It treats an agent as a workload and separates its stable identifier from credentials, credential provisioning, authentication, authorization, observability, and remediation. It also distinguishes an agent acting on its own behalf from one exercising authority delegated by a user. The draft is work in progress, not a final standard, but its vocabulary exposes what a single word like account conceals.
What survives the claim
The consequential question is no longer whether a service can postpone signup. Cloudflare and Neon show that it can, within tight limits. The question is what record and authority cross the boundary when the temporary product becomes durable.
The account record should show which agent created the resource and under what credential. Bootstrap tokens should be invalidated, not merely forgotten by the interface. Any continuing agent access should pass through a named principal with newly delegated authority. An administrator should be able to reconstruct the sequence from request to provisional execution to claim, while recovery should follow the durable principal rather than simple possession of a link.
For now, vendors answer those questions inside their own products. The implementations do not form a common lifecycle, and they should not be described as one. But they point toward a useful test for every claimable account: the handoff is complete only when the old authority ends, the new authority is explicit, and the history connects them.
A claim link may look like the last step of onboarding. It is better understood as the first receipt in an account's chain of custody.
Published . Corrections