Provision a Service Inside an Agent Session

Before you start

You need an agent that can run shell commands in a working directory and a person available to open a URL within 24 hours. Node with npx must be on the path. No Cloudinary account, no API key and no dashboard visit is required before step 1 — that is the point of the sequence below.

Decide the working directory first. The command writes a credential into ./.env relative to wherever it runs, so an agent that runs it from a scratch directory has put the secret somewhere the project will not find it. This is the same decision covered in where an agent stores issued credentials.

Steps

1. Run the provisioning command from the project root.

   npx @cloudinary/cloud

   This is unauthenticated. It returns working credentials without a login, an invite, or a support ticket, which is what removes the human round trip that normally stops an agent mid-task. The usual failure shape — agent reaches a step needing a vendor account, stops, asks the human, waits — does not occur, because the account creation is the agent’s own step. Cloudinary documents the flow in its starting guide for agents.

2. Read the credential from ./.env, not from the terminal output.

   The command writes CLOUDINARY_URL to ./.env and prints a claim URL to stdout. Both matter. The file write is what makes the secret survive a lost terminal buffer, a truncated tool result, or a context window that rolls over before the agent uses the value — the credential exists on disk regardless of what happened to the transcript.

   The inverse is the reason this is documented behaviour rather than a convenience. An agent that prints a secret into chat has published it to every downstream store that transcript reaches: the session log, the provider’s retention, any observability pipeline tailing tool output, any teammate the thread is shared with. There is no unpublishing it; the only remedy is rotation. Writing to a file keeps the secret in one place with one lifecycle. Have the agent read ./.env and reference process.env.CLOUDINARY_URL, never echo it.

3. Note the IP restriction before you test delivery.

   Delivery from the provisioned environment is locked to the public IP the command ran from. If the agent provisioned from a CI runner or a container and you open a delivery URL from your laptop, it fails — and it fails in a way that looks like a broken transformation rather than an access rule. Pass --ip for additional addresses; it is repeatable up to three. See IP-locked delivery as an agent failure mode for what that looks like in practice.

4. Give the claim URL to a person, and have them open it within 24 hours.

   The provisioned environment expires automatically after 24 hours unless a person claims it. This is the property that makes the whole pattern acceptable to run unattended: an agent that provisions a resource and then crashes, loops, or gets abandoned has not created a permanent account on someone’s behalf. The resource fails closed. Nothing accumulates in a billing account nobody opened, and there is no orphaned environment to find and delete six months later. The same expiry-by-default reasoning applies to other resources an agent creates on a user’s behalf.

   The corollary is that the deadline is real. An unclaimed environment and everything in it is gone at the 24-hour mark, so treat the claim as part of the task, not as follow-up.

5. Claim it, and keep building against the same credentials.

   Claiming preserves the credentials that were issued in step 1. The CLOUDINARY_URL in ./.env continues to work, the environment keeps its name, and uploads made during the temporary window remain addressable. Code the agent wrote against the temporary environment does not need rewriting once the account is permanent — there is no swap of a throwaway credential for a real one, no second .env, no find-and-replace across the files the agent touched. Cloudinary’s claimable cloud provisioning reference covers the claim step itself.

   If your situation is the reverse — a human present, wanting an account created programmatically rather than a temporary one to claim — the unauthenticated account-creation endpoint is a different route with different verification semantics, documented under getting started with AI agents.

Result

The agent has a working media backend it provisioned itself, with the credential on disk in ./.env and never in the conversation. If a person opened the claim URL, the environment is permanent and the code written during the session still runs unchanged. If nobody did, the environment and its contents are gone 24 hours after creation and no account exists in anyone’s name.

The pattern generalises past media: an unauthenticated provisioning command, a credential written to a file rather than printed, and a time-boxed resource that a human converts to a permanent one, is what a vendor integration has to look like for an agent to complete it without a human in the loop.