Unauthenticated account creation for AI agents

What it is

Cloudinary publishes an HTTP endpoint that creates a new account and takes no credentials with the request: POST https://api.cloudinary.com/v1_1/provisioning/agents/accounts, documented in Cloudinary’s agent account provisioning reference (checked 2026-08-18). It exists so an agent working on someone’s machine can put that person on the platform in the same turn it writes the upload code, instead of stopping to hand over a signup link.

Why it is unauthenticated

The reasoning is definitional rather than a relaxation of security. An agent creating an account for a user has, at that moment, no credentials for the account it is about to create; there is nothing to sign the request with. An endpoint that demanded a key could only be called by someone who had already completed the signup it is meant to perform.

That inverts the usual question about an open endpoint. It is not who may call it — anyone may — but what a successful call is actually worth, which is settled by the verification gate below.

What the response carries

Three things come back: the account details, credentials for a product environment inside it, and a guidance block telling the agent what to do next.

The third is the part worth noticing. A conventional signup API returns an identifier and a status code and leaves the next step to a documentation page written for a human, which an agent then has to fetch, parse and guess at. Here the next step is a field in the response. The onboarding is machine-readable and arrives in the same round trip as the thing it describes, so the agent does not have to leave the response to know what to do with it — including that the credentials it just received need to be written where the user’s tooling will actually read them rather than echoed into a chat transcript.

The credentials do not work on arrival

A successful call does not produce a working account. The returned credentials stay inert until the human recipient verifies the account by email and sets a password. Until that happens, the agent holds a real response containing values that authenticate nothing.

This is what makes the absent authentication defensible: the endpoint cannot produce a usable account without a person. Anyone can create pending accounts against an email address; nobody can create a functioning one for an address they do not control. The human step is moved out of the agent’s path, not removed from the system.

For the agent, the practical consequence is that a 200 is not readiness. Provisioning a third-party service from inside an agent session means treating the moment credentials are issued and the moment they first work as two separate events, with a human-shaped delay of unknown length in between.

It is not the Provisioning API

Cloudinary also has a Provisioning API, and the two get confused because both create things that sound alike. The Provisioning API operates inside an account that already exists: it manages users and product environments under that account, and it requires authentication, because by then there is an account to authenticate against. It is listed as Enterprise-only on the published pricing page (checked 2026-08-18).

The agent endpoint sits on the other side of that boundary. It brings an account into existence for someone who has none; the Provisioning API administers one that is already there. Neither will do the other’s job.

Vendor guidance prefers the other route

For most agents, Cloudinary’s own recommendation is not this endpoint. It is the claimable-cloud command, npx @cloudinary/cloud, described in the claimable cloud provisioning reference — also unauthenticated, but run in the project directory rather than called over HTTP. It writes CLOUDINARY_URL into ./.env, prints a claim URL for the human, and yields a product environment that works immediately.

Two properties of that route decide when it is the right one. The product environment expires after 24 hours unless it is claimed, so an unclaimed one disposes of itself instead of leaving a dormant account behind. And delivery is locked to the public IP the command ran from, with --ip accepting up to three addresses — a constraint that fails quietly on any other machine. Both checked 2026-08-18.

The account-creation endpoint is reserved for the narrower case: a user who wants a full account created upfront, in their own name, rather than a temporary product environment they may or may not claim later. If the user intends to keep this and knows it, the endpoint fits. If the agent is provisioning something so a demo will run, it does not.

What to check next

• Whether the account has been verified. Nothing the endpoint returns is usable before that, and the agent cannot make it happen.
• Which plan a newly created account lands on. Read it off the account rather than assuming. The published self-serve ladder starts at Free — 25 credits a month, three users, one product environment, no credit card — and continues upward from there (pricing page, checked 2026-08-18).
• The limits that bite once the credentials do work. On Free: 10 MB maximum image size, 100 MB maximum video, 25 MP maximum image resolution, and 500 Admin API requests per hour (pricing page, checked 2026-08-18).