How do I let agents sign up for my product?

to let agents sign up for your product, use an agent identity broker. a broker links an agent to a human owner with a verified email address, records the terms acceptance for the agent, and gives your service a signed proof it can check at signup. Agent Registrar is one broker. the protocol behind it, agent-identity-v1, is open.

the human verifies their email address once and signs one delegation agreement. that agreement lets each agent accept a provider's terms under the human's ownership, and the broker records the acceptance. each agent gets a sub-identity, an inbox, and scoped delegation. your product publishes one discovery document at /.well-known/agent-signup.json with your terms and a signup endpoint. the agent presents a short-lived signed assertion. you verify it against the broker's public keys, create or resolve the account, and keep the account, the credentials, the pricing, and every vendor capability. the broker is not in your request path.

other ways to let agents sign up

there are three other paths, plus a combination. each one solves part of the problem and leaves another part to you.

drive the browser with computer use

computer use lets an agent open your signup page, fill the fields, and click through like a person. it can finish a simple form, and it is a useful fallback when no other path exists. as a signup strategy it is slow, it breaks when the page changes, and it leaves you unable to tell who is behind the account. you receive a script that filled in a form, not a customer you can identify.

use Stripe Projects

Stripe Projects is a CLI for provisioning third-party services. an agent can add a database, host, or auth service, pull the credentials into .env, and manage billing through Stripe. it is a good fit if your service is in its catalog and your customers already use Stripe.

your service has to join the Stripe Projects network; Stripe asks interested providers to contact its provider-request address. account creation, the catalog, credentials, and billing run through Stripe's CLI and catalog. you also have to fit the provisioning and billing model the network defines, including plans, credentials, and payment. you do not own that front door or the experience around it. Stripe mediates the relationship rather than handing it to your product.

use auth.md and claimable resources

auth.md is an open protocol from WorkOS. a service publishes a Markdown file that lists the registration flows it supports. the anonymous flow lets an agent register without a human identity, receive restricted pre-claim access and a claim token, and provision a temporary resource. a human can claim the resource later and take ownership. Neon's Claimable Neon is a working example. an agent can create a temporary Postgres project with storage, transfer, and a 72-hour lifetime, and a person can move it into an organization when it is worth keeping.

claimable resources let the agent start before a human signs up. they do not tell you who the agent is. at creation time you are accepting anonymous capacity, so the controls that make it work are quotas, expiry, restricted scopes, and a claim ceremony. if any of those are loose, an agent can create temporary resources indefinitely and never claim them, and you have no one to pursue when the resource is abused.

combine claimable resources with a broker

the two approaches fit together. require a broker assertion before you create the temporary resource, then let the human claim it later. the agent keeps moving, and an unclaimed resource still has a verified human owner on record. if the same agent tries to create more resources, claim one, or upgrade, you can check the same identity and block it. you get the flexibility of a temporary resource with the recourse of an accountable human.

challenges of allowing agent signups

the main problem is identity. an agent is a process, not a person. it has no browser session, no inbox it can read, no legal identity, and no way to be liable for an account. when a request arrives, you can see a client, a user agent, and maybe an API key. you cannot see who is accountable, and you cannot tell a legitimate agent from an abusive one.

websites faced a version of this in the 2000s and 2010s. automated signups created accounts, posted spam, scraped content, and consumed free tiers. the response was CAPTCHA, email verification, rate limits, and risk scoring. those controls work by making automation harder. that is the right trade when the automation hitting your form is mostly unwanted. it is the wrong trade when a legitimate agent is the customer.

a malicious automated signup is not a good signup. it adds load and consumes capacity, which can become infrastructure cost. it can be a route to platform abuse, which can affect availability for everyone else. it can also be used for illegal activity, which creates legal exposure. and if no human with a verified identity accepted your terms, you may have no one to contact and no accepted agreement to point to, so your recourse is limited to closing the account. you cannot easily establish who was responsible for it.

building this yourself means building verification, delegation, consent capture, terms versioning, reachability, revocation, and abuse handling. each layer has edge cases. a shared API key has no customer record. a throwaway inbox gives you reachability but no accountability. an OAuth client authorizes access, but it does not create a customer. an agent card tells you what the agent says about itself. none of them gives you a verified human, the exact terms that human accepted, and a way to stop the agent later.

why should I let agents sign up for my product?

builders increasingly work through agents. they use ChatGPT, Codex, Claude Code, Cursor, and other harnesses to research, write, deploy, and operate their products. the agent goes out on their behalf. it provisions a database, deploys a service, connects an API, and tries to finish the task.

signup is where that collaboration breaks. an agent decides it needs product A. it can stop and ask the human to open a browser and create the account, which breaks the flow. or it can use product B, which lets it continue. if your product is A, the agent may never come back. the builder may never see what you offer.

this is not only about convenience. it is about where your customers come from. if builders work through agents, and your product cannot be used by an agent, you are asking the builder to leave the workflow to use you. some will. others will use a competitor that lets the agent continue. as agentic development grows, that gap gets more expensive.

not every product should accept agents. some services need a human to sign up, or need a higher assurance level than a verified email. that is a legitimate choice. if you have a self-serve signup and users who run agents, the question is whether they arrive through a path you can verify or through a workaround you cannot see.

how not to support agent signups

the wrong response is to weaken the human front door or automate it. four shortcuts look like a fix and leave the problem in place.

• removing CAPTCHA. CAPTCHA is annoying. it also blocks automated abuse. removing it so agents can sign up reopens the problem for every automated client, including the ones you do not want.
• dropping OAuth. OAuth is not the signup problem. it authorizes access for known clients and accounts. removing it does not create a customer relationship, and it makes access worse for the humans and integrations you already have.
• returning to a bare username and password form. no challenge, no verification, no risk controls. that is the 2000s setup with a 2026 cost base. it invites exactly the signups you spent years filtering out.
• treating computer use as your agent strategy. computer use automates the human form. it does not create an agent identity, and it does not give you a path you control. use it as a fallback.

none of these changes gives you an agent identity. they make the human path worse without giving you an agent path.

keep CAPTCHA and OAuth for humans. make that flow good. agents need a separate front door, not a worse human one. the same is true for the rest of your human signup: email verification, rate limits, and risk scoring are still useful. they protect the human path. they are not the agent path.

the front door for agents

keep your human signup. add an agent signup path next to it. publish discovery, verify an assertion, create or resolve the account. the broker records the human, the terms hash, and the acceptance. you create the account and keep your own risk controls. the integration is one discovery document and one assertion check, not a new identity system. no broker account or SDK is required to verify an assertion.

the broker does the identity part. it records the human owner, the terms acceptance, and the signup proof, and it gives you a revocation path and an abuse-report route. that is where it stops. your risk controls, your account decisions, and your terms stay with you.

read the provider quickstart to see the discovery document, assertion verification, and the account resolution step.