Give the agent a boarding pass, not a badge

It is 2 a.m. for the humans and the middle of the workday for the agent. A background coding agent has just finished a Cloudflare Worker. It wrote the handler, fixed the routing, and now it needs the one thing that tells it whether any of that was correct: a live deploy it can hit with a request.

So it runs the deploy command. And the tool asks it to sign in.

Not with a key from an environment variable. Sign in like a person. Open a browser, finish an OAuth flow, approve the prompt on a phone, maybe clear an MFA challenge, then come back and paste a token. There is no person here. The agent is the whole night shift. It cannot click the button, because the button assumes a hand.

This is the wall a lot of teams hit the first time they let an agent do real work instead of just suggesting it. The agent can build the thing. It cannot prove the thing, because proving it requires authority, and all the authority in the building is shaped like a human account.

The source signal

On June 19, 2026, Cloudflare shipped a direct answer to that wall: Temporary Cloudflare Accounts for AI agents.

The mechanic is small, so here it is straight. An agent can run wrangler deploy --temporary and deploy a Worker without anyone signing up for a Cloudflare account first. Cloudflare provisions a temporary account on the spot, hands Wrangler an API token, and returns a claim URL meant for a human. The deployment stays live for 60 minutes. Inside that window, a person can open the claim URL and make the account permanent. If nobody claims it, it expires and the deployment goes with it.

Cloudflare also closed the discovery gap, which is the part most "agent-friendly" features forget. They updated Wrangler so the tool's own output tells the agent the --temporary flag exists. The agent hits the sign-in wall, reads the message, reruns with the flag, and keeps moving. No human had to teach it the trick at 2 a.m.

Cloudflare frames the underlying problem the way anyone running background sessions will recognize: agents keep colliding with auth that was built for people. Browser-based OAuth, dashboards, tokens to copy and paste, MFA prompts. With a human in the loop those are a mild annoyance. With no human in the loop they are a hard stop, and the agent just sits there having done good work it cannot finish.

The model: a boarding pass, not a badge

Here is the model to keep once the Cloudflare specifics blur.

A badge is permanent identity. It says who you are, it opens doors for as long as you hold it, and it keeps working tomorrow. That is the right thing to give an employee. It is the wrong first thing to give an agent that needed to deploy once to check its own work.

A boarding pass is different. It is valid for one trip. It works at one gate, for one window, and after that window it is a piece of paper. Nobody investigates a used boarding pass, because it cannot do anything anymore.

The temporary account is a boarding pass. Valid for one trip, useless after the window closes, and only permanent if a person walks up and claims it. The agent gets exactly enough authority to finish the deploy-verify loop and not one minute more. The decision to turn that into standing identity stays where it belongs: with a human, made on purpose, after the work is already visible.

The risky shortcut teams reach for instead is the badge. The agent keeps getting stuck, so someone hands it a real account or a long-lived token "just to unblock it," and now a background process holds permanent authority that nobody scoped and nobody is watching. The boarding pass is the narrower move. Ephemeral authority, a claim URL, and a deadline.

The artifact: a claim ticket

Cloudflare built this for one platform and one command. Forget the command. The part you can reuse is what lands back in a human's lap: a claim ticket.

A claim ticket is the small handoff document an agent's temporary authority should generate every time. It answers the questions a person needs to answer fast at 9 a.m. when they find a deploy waiting: what did this touch, for how long, and do I keep it or let it die. You can write one for any system an agent needs to reach, not just Workers. Here is the shape.

On phones, each row shows all 3 columns; on wider screens, scroll sideways if needed.

Claim ticket field	What it records	Cloudflare example
Temporary resource	The thing the agent created or touched	A deployed Worker on a temporary account
Lifetime	How long the authority stays valid	60 minutes
Allowed action	The one thing this authority can do	Deploy and serve a Worker
Generated credential	The token the agent holds, and where it lives	API token issued to Wrangler at deploy time
Claim URL owner	The named human the claim goes to	Person who opens the claim URL
Evidence to inspect	What the human reviews before claiming	The live deployment and its behavior
Expiry behavior	What happens if nobody claims it	Account and deployment expire
Promotion rule	What turns temporary into permanent	Human claims the account inside the window
Revocation rule	How to kill it early	Let it lapse, or tear down before the window ends

Fill that out for one agent task and you will notice something. The Cloudflare launch quietly answers most of the rows for you: lifetime, expiry, promotion, and the credential are all decided by the product. The rows it leaves to you are the ones that were always yours to own. Who is the claim URL owner. What evidence makes a claim a yes instead of a reflex. What "allowed action" really means for your systems. Those blanks are the work. The control plane was never the table. It was the columns you could not fill.

Why this matters past Cloudflare

The deploy-verify loop is the thing that makes coding agents useful instead of merely talkative. An agent that writes a Worker and cannot deploy it is guessing. An agent that can deploy, send a request, read the response, and fix what broke is doing the job. You want that loop closed.

Close it the lazy way and you hand the agent a permanent credential just to stop the stalling. That swaps a workflow snag for a security one you will not see until inventory day, when a long-lived token turns up wired to a process nobody remembers standing up. We have written before about how fast that sprawl gets ahead of anyone counting it, in the agent swarm census, and about the drill of revoking an agent identity once it exists. The cheaper move is to never hand out the permanent thing in the first place. Temporary authority first. Permanent identity only after a human looks at real evidence and decides.

This is the same instinct behind keeping an agent on a short database query leash: scope the authority to the task, not to the convenience of never being asked again.

Where this sits in Cloudflare's wider agent push

Temporary accounts did not arrive alone. Two days earlier Cloudflare published its work bringing agent harnesses onto the platform, starting with Flue, framing production agents as a distributed-systems problem: resuming after an interruption, running untrusted code safely, using the tools they were trained to use. The Agents SDK sits at the durable-execution layer under all of that. The same-week Cloudflare One stack goes further, handing agents skills to configure and manage Zero Trust through a typed interface to the Cloudflare API instead of ad hoc calls.

Line the three launches up and the boarding pass stops looking like a one-off. Cloudflare is handing agents real authority over real infrastructure while keeping that authority shaped, expiring, and reviewable. The Model Context Protocol security guidance names the failure the boarding pass sidesteps: credentials passed through to a service they were never issued for, which makes auditing and incident response harder later. A scoped, expiring token is easier to reason about than a borrowed one.

What to build next week

You do not need a platform migration to use this. You need one honest pass over your own automations.

Pick one workflow where an agent currently borrows a human login. The coding agent that deploys with someone's account. The support automation running under a teammate's SaaS session. The script with a personal API key in its environment. Just one.

Then ask whether that task actually needs standing identity, or whether it needs a boarding pass. Write the claim ticket for it. Decide the lifetime, the one allowed action, the named claim owner, and the rule that turns temporary into permanent. Fill every row and you have scoped the authority. Hit a blank and you have found the decision to make before that agent runs unsupervised again.

Most workflows that "need" a permanent login only ever needed one trip.

---

Bring one agent workflow that currently borrows a human login. We will help turn it into a temporary authority path with a claim ticket, an expiry rule, and a named owner. Start with the process automation work if the agent already deploys or touches infrastructure, or the AI workflow controls if you want to scope what it may do before it does it.